Open DominiqueMakowski opened 4 years ago
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 effectsize
( 😢 ) but instead getting them from parameters
(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 . < - effectsize::r_to_d(1)
somewhere 😅
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...
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 😬
This was my first thought as well, but it's not easy (impossible?) due to this issue 😿 https://github.com/easystats/insight/issues/276
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