rstats R models
Need help with easystats?
Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.
easystats

Description

:milky_way: The R easystats-project

294 Stars 31 Forks GNU General Public License v3.0 437 Commits 16 Opened issues

Services available

Need anything else?

easystats



.

What is easystats?

easystats is a collection of R packages, which aims to provide a unifying and consistent framework to tame, discipline and harness the scary R statistics and their pesky models.

However, there is not (yet) an unique “easystats” way of doing data analysis. Instead, start with one package and, when you’ll face a new challenge, do check if there is an easystats answer for it in other packages. You will slowly uncover how using them together facilitates your life. And who knows, you might even end up using them all. Gotta catch ’em all! <!-- 'tis a pokémon reference for y'all grandpas -->

Where to start

Each easystats package has a different scope and purpose. This means you the best way to start is to explore and pick the one(s) that you feel might be useful to you. However, as they are built with a “bigger picture” in mind, you will realize that using more of them creates a smooth workflow, as these packages are meant to work together.

  • report: 📜 🎉 Automated statistical reporting of objects in R
  • correlation: 🔗 Your all-in-one package to run correlations
  • modelbased: 📈 Estimate effects, group averages and contrasts between groups based on statistical models
  • bayestestR: 👻 Great for beginners or experts of Bayesian statistics
  • parameters: 📊 Obtain a table containing all information about the parameters of your models
  • performance: 💪 Models’ quality and performance metrics (R2, ICC, LOO, AIC, BF, …)
  • effectsize: 🐉 Compute, convert, interpret and work with indices of effect size and standardized parameters
  • insight: 🔮 For developers, a package to help you work with different models and packages
  • see: 🎨 The plotting companion to create beautiful results visualizations

Frequently Asked Questions

  • How is easystats different from the tidyverse?

You’ve probably already heard about the tidyverse, another very popular collection of packages (ggplot, dplyr, tidyr, …) that also makes using R easier. So, should you pick the tidyverse or easystats? Pick both! Indeed, they do not serve the same purpose. The tidyverse packages are primarily made to create a new R experience, where data manipulation and exploration is natural and consistent. On the other hand, easystats is more focused on helping you making this last mile from the analysis to your manuscript or stats report. It helps you understand and interpret your results and report them following best practices. You can definitely use the easystats functions in a tidyverse workflow! easystats + tidyverse = ❤️

  • Can easystats be useful to advanced users and/or developers?

Yes, definitely! easystats is built in terms of modules that are general enough so that they can be used inside of other packages. For instance, the insight package is made to easily implement support for post-processing of all the models / packages under the sun. We use it in all the easystats packages, but it also used for instance in ggstatsplot, ggeffects, and more. So why not in yours? Moreover, the easystats packages are very lightweight, with a minimal set of dependencies, which again makes it great if you want to rely on them.

Installation

The whole

easystats
suite can be installed at once with the following:
install.packages("devtools")
devtools::install_github("easystats/easystats")
library("easystats")

Related posts

Find an overview of all postings here.

Dependencies

Most of easystats packages are very lightweight, i.e., they don’t rely nor import any other packages! This means that you can safely use them as dependencies in your own packages, without the risk of butterfly effects (a small change in a distant downstream dependency with unexpected upstream consequences).

There is one exception. The see package is one of our high-level packages that is responsible for plotting and creating figures, relying thus on other packages such as ggplot2, which itself is plugged in the tidyverse, increasing package dependencies by a substantial amount. On the bright side of things, it gives a good overview of the place of easystats in the R ecosystem.

Citation

How to reference easystats?

  1. Cite specific packages

The most parsimonious approach is to cite only the particular package that helped you, e.g., “using bayestestR (Makowski, Ben-Shachar, & Lüdecke, 2019)”. However, as easystats is meant to be an ecosystem, with different people working on its different aspects (some being more “citeable” than others), please consider including also the “main” publication: not available yet.

  1. Cite the whole ecosystem :heart:

Want to credit the whole network of interconnected aspects of easystats? This can be done with a sentence like the following:

Data processing was carried out with R (R Core Team, 2019) and the easystats ecosystem (Lüdecke, Waggoner, & Makowski, 2019; Makowski, Ben-Shachar, & Lüdecke, 2019; Makowski, Ben-Shachar, Patil, & Lüdecke, 2020)

Click here to see the corresponding APA and bibtex entries
  • Lüdecke D, Waggoner P, Makowski D. insight: A Unified Interface to Access Information from Model Objects in R. Journal of Open Source Software 2019;4:1412. doi: 10.21105/joss.01412
  • Makowski, D., Ben-Shachar, M. S., & Lüdecke, D. (2019). bayestestR: Describing Effects and their Uncertainty, Existence and Significance within the Bayesian Framework. Journal of Open Source Software, 4(40), 1541. 10.21105/joss.01541
  • Makowski, D., Ben-Shachar, M. S., Patil, I., & Lüdecke, D. (2019). Methods and Algorithms for Correlation Analysis in R. Journal of Open Source Software, 5(51), 2306. 10.21105/joss.02306
@article{ludecke2019insight,
    journal = {Journal of Open Source Software},
    doi = {10.21105/joss.01412},
    issn = {2475-9066},
    number = {38},
    publisher = {The Open Journal},
    title = {insight: A Unified Interface to Access Information from Model Objects in R},
    url = {http://dx.doi.org/10.21105/joss.01412},
    volume = {4},
    author = {Lüdecke, Daniel and Waggoner, Philip and Makowski, Dominique},
    pages = {1412},
    date = {2019-06-25},
    year = {2019},
    month = {6},
    day = {25}
}


@article{makowski2019bayestestr,
    title = {{bayestestR}: {Describing} {Effects} and their {Uncertainty}, {Existence} and {Significance} within the {Bayesian} {Framework}},
    volume = {4},
    issn = {2475-9066},
    shorttitle = {{bayestestR}},
    url = {https://joss.theoj.org/papers/10.21105/joss.01541},
    doi = {10.21105/joss.01541},
    number = {40},
    urldate = {2019-08-13},
    journal = {Journal of Open Source Software},
    author = {Makowski, Dominique and Ben-Shachar, Mattan and Lüdecke, Daniel},
    month = aug,
    year = {2019},
    pages = {1541}
}

@article{makowski2020correlation,
  doi={10.21105/joss.02306},
  title={Methods and Algorithms for Correlation Analysis in R},
  author={Makowski, Dominique and Ben-Shachar, Mattan and Patil, Indrajeet and L{\"u}decke, Daniel},
  journal={Journal of Open Source Software},
  volume={5},
  number={51},
  pages={2306},
  year={2020}
}

Versioning

Package version numbers indicate following:

MAJOR.MINOR.PATCH.DEVELOPMENT
. As long as packages are in a more or less rapidly developing and changing state, the major version number is typically
0
. Once we think we will have a stable base that will likely not change dramatically or soon, the major version number will be set to
1
, and increased for following major changes that probably break the current API. When new features are added or (re)moved, we typically increase the minor version number. Minimal changes or bug fixes only are indicated by increasing the patch version number. Current development versions of our packages (i.e. master branch from GitHub) additionally have a development version number. You typically won’t find packages on CRAN with a development version number.

Downloads

| modelbased | correlation | see | effectsize | parameters | performance | bayestestR | insight | Total | | :--------- | :---------- | :----- | :--------- | :--------- | :---------- | :--------- | :------ | :-------- | | 12,622 | 38,159 | 47,372 | 256,672 | 339,790 | 368,423 | 403,474 | 748,652 | 2,215,164 |

Trend

Cumulative downloads

Average monthly downloads

Convention of code-style

Following conventions apply to the easystats-ecosystem, to ensure that function and argument names as well as element names for return-values follow a consistent pattern across all packages.

Importing other packages

  • No full import, only selective import of functions
  • Use base-R wherever possible (reduce dependencies)
  • Make sure R-version requirements are not too strict

Helper-functions

  • Own re-implementation of helper-functions, if it’s not too much effort (e.g. I typically use own functions to check if a string starts / ends with a pattern, or if an object (list, data frame) contains an element with a given name (like
    tibble::has_name()
    ), to reduce dependencies.

print
functions

  • print
    methods should invisibly return the original (unchanged) input (#65).

Function names

  • Lower case, underscore separated if more than one verb
  • Common prefix for functions that focus on specific “tasks” or workflows (e.g. insight,
    get_*()
    to get data,
    find_*()
    to find information, or performance,
    performance_*()
    to compute measures of model quality,
    check_*()
    to check model assumptions…)
  • Internal functions (that are not exported, like the previously mentined helper-functions) should always start with a
    .
    (e.g.,
    .do_some_internal_stuff()
    ).

Argument names

  • lower case, underscore separated if more than one verb

Element / Column names (for returned data frames)

1) First letter of the column name is capital, unless (6) applies (example:

Parameter
) 2) First letter of nouns is capital, unless (6) applies (example:
ROPE_Percentage
,
Prior_Scale
) 3) Using underscore rather than camelCase to separate words (example:
CI_high
) 4) Multiple words: common/main part first and adjective/specifier/variational part after, unless (8) applies (example:
Median_standardized
,
ROPE_percentage
) 5) Abbreviations: all uppercase (example:
ESS
,
MCSE
,
ROPE
) 6) Keep conventions for reserved words (example:
p
,
pd
,
Rhat
) 7) Adjectives / verbs: all lower case, unless (1) applies (example:
high
or
low
in
CI_high
or
CI_low
) 8) In case of multiple occurrences of column names that indicate the same measure or content (like
CI_low
or
SE
), the common part is appended as suffix to the context specific part (example:
CI_low
and
Eta2_partial_CI_low
, and not
CI_low
and
CI_low_Eta2_partial
). 9) The “squared” term in column names that refers to “common” statistics (
Eta2
,
Chi2
,
Omega2
, …) should be written as
2
, not
sq
,
squared
or
pétit-deux
(example:
Chi2
, and not
Chisq
,
Eta2
, and not
Eta_squared
). This rule does not apply to function names.

List of functions

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.