Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get effect sizes info only via parameters? #108

Open
DominiqueMakowski opened this issue Nov 5, 2020 · 12 comments
Open

Get effect sizes info only via parameters? #108

DominiqueMakowski opened this issue Nov 5, 2020 · 12 comments
Labels
question ⁉️ Further information is requested

Comments

@DominiqueMakowski
Copy link
Member

Initially, I wanted report to assemble the parameters table with the effect size table for parameters. Currently, the effect size table is retrieved via effectsize() and later assembled here. But since parameters will soon be able to include all effect size info (including their CIs), I'm wondering whether it's best to keep the current design, or streamline it and rely exclusively on parameters. The only thing is that we have to be sure that all of the attributes that are provided by effectsize() are also copied over and returned by parameters I guess

@strengejacke
Copy link
Member

Can you give an example of which attributes to preserve?

@strengejacke
Copy link
Member

library(parameters)
library(effectsize)
df <- iris
df$Sepal.Big <- ifelse(df$Sepal.Width >= 3, "Yes", "No")
model <- aov(Sepal.Length ~ Sepal.Big, data = df)
mp <- model_parameters(
  model,
  omega_squared = "partial",
  eta_squared = "partial",
  epsilon_squared = "partial"
)
str(eta_squared(model, ci = .9))
#> Classes 'effectsize_table', 'see_effectsize_table' and 'data.frame': 1 obs. of  5 variables:
#>  $ Parameter   : chr "Sepal.Big"
#>  $ Eta2_partial: num 0.0107
#>  $ CI          : num 0.9
#>  $ CI_low      : num 0
#>  $ CI_high     : num 0.0543

Created on 2020-11-05 by the reprex package (v0.3.0)

@strengejacke strengejacke added the question ⁉️ Further information is requested label Nov 8, 2020
@strengejacke
Copy link
Member

I think effect sizes are well covered in parameters now...

@DominiqueMakowski
Copy link
Member Author

Yeah, I agree, we should query directly effect sizes from parameters rather than doing another posthoc synthesis

@DominiqueMakowski
Copy link
Member Author

I'll start looking into that, to remove all the calls directly to effectsize ( 😢 ) but instead getting them from parameters

@mattansb
Copy link
Member

(This circular dependency between parameters and effectsize will bite us in the butt.)

Don't forget to add effectsize as an import so that effect sizes are always returned by parameters.

@strengejacke
Copy link
Member

But then we need to use at least one effectsize function somewhere, else CRAN checks might complain that not all imports are used.

@mattansb
Copy link
Member

use . < - effectsize::r_to_d(1) somewhere 😅

@DominiqueMakowski
Copy link
Member Author

That's not as easy. Because essentially, in parameters, the user has to activate one of the argument to get the effect size that he wants. Whereas report currently gets one as part of the standard processing. And how does it know which one to get, well it relies on the overwritable defaults of effectsize, as it simply runs effectsize(...). To add to the problem, report sometimes need the information stored as attribute in the output of effectsize().

So one way would be to basically run model_parameters() with hardcoded defaults for effectsize. For instance, for htest, it would run model_parameters(x, standardized_d=TRUE) or something.

Though these single arguments for each effect size in model_parameters make it hard to work with. The type="cohens_d" in effectsize makes it more easy to be overwritten by users.

So... I don't know... One could also argue that it "works" currently as is, with effectsize and parameters separate, so why break something that works...

@strengejacke
Copy link
Member

So... I don't know...

Well, it was you who opened the issue, so don't blame us if you don't want to do what you suggested in the opening post 😬

@mattansb
Copy link
Member

@IndrajeetPatil

This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question ⁉️ Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants