logos and visuals about easystats HOT 7 CLOSED

Logo looks great! I would opt against HexBin, the logo looks good as it currently is. Maybe for packages we can think of HexStickers.

from easystats.

Have some important deadlines to meet at work, thus as always I've found it way more interesting to waste some time on illustrator 😅 🤦‍♂️

Besides these ideas for our little "zoo", here's a note for future reference, we could use this repo (easystats/easystats) for a wrapper package that loads all the easystats suite (of course for now it's not that useful but we never know 😏).

from easystats.

The way I imagined performance and parameters (if you have any better names ideas...), they would include algorithms for computing different things, but in a purely agnostic way (i.e., "here are the functions, do whatever you want with them"). The "opinionated" aspects (related to the defaults, to the output phrasing, to the information displayed) should be kept for higher levels packages (hence my comment for bayestestR about the "neutrality" of the print methods).

For instance, using parameters or performance, it will be very easy for users to compute for instance this particular R2 metric with weirdly bootstrapped parameters and non-traditional estimations of p values / confint. Nothing would prevent or warn the users that it might not be the best way of doing things, but their own judgment.

Whereas in report, the default choice of the model performance metric will be defined, for each model, based on a documented rationale. Another example; using bayestestR, people could compute and report in their manuscript the MAP-based p value. However, report will return (by default, although with some amount of possible customisation) the indices $suggested by the literature (among which hopefully our future paper 😅).

Anyway, it's best to have some concrete stuff to discuss over and play with, so I'll add the skelettons tomorrow to later evaluate their purpose and existence.

from easystats.

Same here... "cleaning up" some issues...

from easystats.

Logos look great! I think we should do some brainstorming and collect ideas for scope and functions for #9 and #8. Currently, I'm not sure which and how many functions would be suitable for the parameter package, it's still a bit vague in my mind.

According to the wrapper package: This will most likely be not accepted by CRAN (though tidyverse is on CRAN, who knows why). But CRAN explicitely asks to not submit "wrapper" packages.

from easystats.

tidyverse might have used the "hadley" magic card 😏

About the scope of the two packages, their existence is mostly related and tied to the needs of report. When thinking of how report would work, it became clear (in my mind!) that it would need to rely on some external utils dealing with overall model performance as well as with parameters-related metrics.

However, to clarify how it would work (even for me), I can create the two packages and try to make it work for a toy model (e.g., lm).

I think having a first implementation of a working architecture would help us to see the purpose, scope and improvement leads. This would help us decide what packages to remove, merge, split and so on.

from easystats.

I see the need for such functions / package. If it's just a few functions, however, we might think about merging it into a more general package. Else, I fear we build up our own dependency jungle, which we initially wanted to avoid ;-)

insight might be the "one-ring-to-rule-them-all", but if there are enough functions that deal with model parameters, it makes more sense to put them into an own package. We could, e.g., also include more own tidiers into that package, which also return confint, se etc. Maybe even p-values would fit into such a parameter package (although p-values are something between "parameter" and "performance", I think).

from easystats.