-
-
Notifications
You must be signed in to change notification settings - Fork 69
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
Comments
Can you give an example of which attributes to preserve? |
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) |
I think effect sizes are well covered in parameters now... |
Yeah, I agree, we should query directly effect sizes from parameters rather than doing another posthoc synthesis |
I'll start looking into that, to remove all the calls directly to |
(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. |
But then we need to use at least one effectsize function somewhere, else CRAN checks might complain that not all imports are used. |
use |
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 So one way would be to basically run Though these single arguments for each effect size in model_parameters make it hard to work with. The 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... |
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 😬 |
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 guessThe text was updated successfully, but these errors were encountered: