supporting option to format aov-like outputs in afex_aov style

[IndrajeetPatil]

For objects of class

c("aov", "aovlist", "anova", "Gam", "manova", "maov")

I always want the output to look like the following (where df and residual dfs are in the same row):

library(afex)

fit_all <- aov_ez("id", "value", obk.long, between = c("treatment"), within = c("phase"))
#> Warning: More than one observation per cell, aggregating the data using mean
#> (i.e, fun_aggregate = mean)!
#> Contrasts set to contr.sum for the following variables: treatment

as.data.frame(parameters::model_parameters(fit_all))
#>         Parameter Sum_Squares Sum_Squares_Error      df df_error Mean_Square
#> 1       treatment    37.35000          83.31667 2.00000 13.00000   6.4089744
#> 2           phase    27.35783          18.43333 1.74142 22.63846   0.8142486
#> 3 treatment:phase    15.40000          18.43333 3.48284 22.63846   0.8142486
#>           F            p
#> 1  2.913883 9.004088e-02
#> 2 19.293950 2.375283e-05
#> 3  5.430380 4.301327e-03

but most objects don't return output this way:

pk.aovE <- aov(yield ~ N * P * K + Error(block), npk)

as.data.frame(parameters::model_parameters(pk.aovE))
#>    Group Parameter Sum_Squares df Mean_Square           F           p
#> 1  block     N:P:K  37.0016667  1  37.0016667  0.48321870 0.525236141
#> 2  block Residuals 306.2933333  4  76.5733333          NA          NA
#> 3 Within         N 189.2816667  1 189.2816667 12.25873421 0.004371812
#> 4 Within         P   8.4016667  1   8.4016667  0.54412982 0.474904093
#> 5 Within         K  95.2016667  1  95.2016667  6.16568920 0.028795054
#> 6 Within       N:P  21.2816667  1  21.2816667  1.37829669 0.263165283
#> 7 Within       N:K  33.1350000  1  33.1350000  2.14597201 0.168647879
#> 8 Within       P:K   0.4816667  1   0.4816667  0.03119491 0.862752086
#> 9 Within Residuals 185.2866667 12  15.4405556          NA          NA

^{Created on 2020-12-21 by the reprex package (v0.3.0)}

So I am wondering if we can add an option for the .aov-relevant methods to format the output the same way afex does?

Session info

devtools::session_info()
#> ─ Session info ───────────────────────────────────────────────────────────────
#>  setting  value                       
#>  version  R version 4.0.3 (2020-10-10)
#>  os       macOS Mojave 10.14.6        
#>  system   x86_64, darwin17.0          
#>  ui       X11                         
#>  language (EN)                        
#>  collate  en_US.UTF-8                 
#>  ctype    en_US.UTF-8                 
#>  tz       Europe/Berlin               
#>  date     2020-12-21                  
#> 
#> ─ Packages ───────────────────────────────────────────────────────────────────
#>  package      * version    date       lib source        
#>  abind          1.4-5      2016-07-21 [1] CRAN (R 4.0.2)
#>  afex         * 0.28-0     2020-09-20 [1] CRAN (R 4.0.2)
#>  assertthat     0.2.1      2019-03-21 [1] CRAN (R 4.0.2)
#>  bayestestR     0.8.0      2020-12-05 [1] CRAN (R 4.0.3)
#>  boot           1.3-25     2020-04-26 [2] CRAN (R 4.0.3)
#>  callr          3.5.1      2020-10-13 [1] CRAN (R 4.0.2)
#>  car            3.0-10     2020-09-29 [1] CRAN (R 4.0.2)
#>  carData        3.0-4      2020-05-22 [1] CRAN (R 4.0.2)
#>  cellranger     1.1.0      2016-07-27 [1] CRAN (R 4.0.2)
#>  cli            2.2.0      2020-11-20 [1] CRAN (R 4.0.3)
#>  coda           0.19-4     2020-09-30 [1] CRAN (R 4.0.2)
#>  codetools      0.2-16     2018-12-24 [2] CRAN (R 4.0.3)
#>  colorspace     2.0-0      2020-11-11 [1] CRAN (R 4.0.2)
#>  crayon         1.3.4      2017-09-16 [1] CRAN (R 4.0.2)
#>  curl           4.3        2019-12-02 [1] CRAN (R 4.0.1)
#>  data.table     1.13.4     2020-12-08 [1] CRAN (R 4.0.3)
#>  desc           1.2.0      2018-05-01 [1] CRAN (R 4.0.2)
#>  devtools       2.3.2      2020-09-18 [1] CRAN (R 4.0.2)
#>  digest         0.6.27     2020-10-24 [1] CRAN (R 4.0.2)
#>  dplyr          1.0.2      2020-08-18 [1] CRAN (R 4.0.2)
#>  ellipsis       0.3.1      2020-05-15 [1] CRAN (R 4.0.2)
#>  emmeans        1.5.3      2020-12-09 [1] CRAN (R 4.0.3)
#>  estimability   1.3        2018-02-11 [1] CRAN (R 4.0.2)
#>  evaluate       0.14       2019-05-28 [1] CRAN (R 4.0.1)
#>  fansi          0.4.1      2020-01-08 [1] CRAN (R 4.0.2)
#>  forcats        0.5.0      2020-03-01 [1] CRAN (R 4.0.2)
#>  foreign        0.8-80     2020-05-24 [2] CRAN (R 4.0.3)
#>  fs             1.5.0      2020-07-31 [1] CRAN (R 4.0.2)
#>  generics       0.1.0      2020-10-31 [1] CRAN (R 4.0.2)
#>  ggplot2        3.3.2      2020-06-19 [1] CRAN (R 4.0.2)
#>  glue           1.4.2      2020-08-27 [1] CRAN (R 4.0.2)
#>  gtable         0.3.0      2019-03-25 [1] CRAN (R 4.0.2)
#>  haven          2.3.1      2020-06-01 [1] CRAN (R 4.0.2)
#>  highr          0.8        2019-03-20 [1] CRAN (R 4.0.2)
#>  hms            0.5.3      2020-01-08 [1] CRAN (R 4.0.2)
#>  htmltools      0.5.0      2020-06-16 [1] CRAN (R 4.0.2)
#>  insight        0.11.1     2020-12-08 [1] CRAN (R 4.0.3)
#>  knitr          1.30       2020-09-22 [1] CRAN (R 4.0.2)
#>  lattice        0.20-41    2020-04-02 [2] CRAN (R 4.0.3)
#>  lifecycle      0.2.0      2020-03-06 [1] CRAN (R 4.0.2)
#>  lme4         * 1.1-26     2020-12-01 [1] CRAN (R 4.0.3)
#>  lmerTest       3.1-3      2020-10-23 [1] CRAN (R 4.0.2)
#>  magrittr       2.0.1      2020-11-17 [1] CRAN (R 4.0.3)
#>  MASS           7.3-53     2020-09-09 [2] CRAN (R 4.0.3)
#>  Matrix       * 1.2-18     2019-11-27 [2] CRAN (R 4.0.3)
#>  memoise        1.1.0      2017-04-21 [1] CRAN (R 4.0.2)
#>  minqa          1.2.4      2014-10-09 [1] CRAN (R 4.0.2)
#>  multcomp       1.4-15     2020-11-14 [1] CRAN (R 4.0.3)
#>  munsell        0.5.0      2018-06-12 [1] CRAN (R 4.0.2)
#>  mvtnorm        1.1-1      2020-06-09 [1] CRAN (R 4.0.2)
#>  nlme           3.1-149    2020-08-23 [2] CRAN (R 4.0.3)
#>  nloptr         1.2.2.2    2020-07-02 [1] CRAN (R 4.0.2)
#>  numDeriv       2016.8-1.1 2019-06-06 [1] CRAN (R 4.0.2)
#>  openxlsx       4.2.3      2020-10-27 [1] CRAN (R 4.0.2)
#>  parameters     0.10.1     2020-12-08 [1] CRAN (R 4.0.3)
#>  pillar         1.4.7      2020-11-20 [1] CRAN (R 4.0.3)
#>  pkgbuild       1.2.0      2020-12-15 [1] CRAN (R 4.0.3)
#>  pkgconfig      2.0.3      2019-09-22 [1] CRAN (R 4.0.2)
#>  pkgload        1.1.0      2020-05-29 [1] CRAN (R 4.0.2)
#>  plyr           1.8.6      2020-03-03 [1] CRAN (R 4.0.2)
#>  prettyunits    1.1.1      2020-01-24 [1] CRAN (R 4.0.2)
#>  processx       3.4.5      2020-11-30 [1] CRAN (R 4.0.3)
#>  ps             1.5.0      2020-12-05 [1] CRAN (R 4.0.3)
#>  purrr          0.3.4      2020-04-17 [1] CRAN (R 4.0.2)
#>  R6             2.5.0      2020-10-28 [1] CRAN (R 4.0.2)
#>  Rcpp           1.0.5      2020-07-06 [1] CRAN (R 4.0.2)
#>  readxl         1.3.1      2019-03-13 [1] CRAN (R 4.0.2)
#>  remotes        2.2.0      2020-07-21 [1] CRAN (R 4.0.2)
#>  reshape2       1.4.4      2020-04-09 [1] CRAN (R 4.0.2)
#>  rio            0.5.16     2018-11-26 [1] CRAN (R 4.0.2)
#>  rlang          0.4.9      2020-11-26 [1] CRAN (R 4.0.3)
#>  rmarkdown      2.6        2020-12-14 [1] CRAN (R 4.0.3)
#>  rprojroot      2.0.2      2020-11-15 [1] CRAN (R 4.0.3)
#>  sandwich       3.0-0      2020-10-02 [1] CRAN (R 4.0.2)
#>  scales         1.1.1      2020-05-11 [1] CRAN (R 4.0.2)
#>  sessioninfo    1.1.1      2018-11-05 [1] CRAN (R 4.0.2)
#>  statmod        1.4.35     2020-10-19 [1] CRAN (R 4.0.2)
#>  stringi        1.5.3      2020-09-09 [1] CRAN (R 4.0.2)
#>  stringr        1.4.0      2019-02-10 [1] CRAN (R 4.0.2)
#>  survival       3.2-7      2020-09-28 [2] CRAN (R 4.0.3)
#>  testthat       3.0.1      2020-12-17 [1] CRAN (R 4.0.3)
#>  TH.data        1.0-10     2019-01-21 [1] CRAN (R 4.0.2)
#>  tibble         3.0.4      2020-10-12 [1] CRAN (R 4.0.2)
#>  tidyselect     1.1.0      2020-05-11 [1] CRAN (R 4.0.2)
#>  usethis        2.0.0      2020-12-10 [1] CRAN (R 4.0.3)
#>  vctrs          0.3.6      2020-12-17 [1] CRAN (R 4.0.3)
#>  withr          2.3.0      2020-09-22 [1] CRAN (R 4.0.2)
#>  xfun           0.19       2020-10-30 [1] CRAN (R 4.0.2)
#>  xtable         1.8-4      2019-04-21 [1] CRAN (R 4.0.2)
#>  yaml           2.2.1      2020-02-01 [1] CRAN (R 4.0.2)
#>  zip            2.1.1      2020-08-27 [1] CRAN (R 4.0.2)
#>  zoo            1.8-8      2020-05-02 [1] CRAN (R 4.0.2)
#> 
#> [1] /Users/patil/Library/R/4.0/library
#> [2] /Library/Frameworks/R.framework/Versions/4.0/Resources/library

[strengejacke]

?

[mattansb]

This is related somewhat to #369 - which is what afex uses under the hood.
So really these are different model type, and so their output is different.

(If you change the output from aov/aovlist this is severely break effectsize!)

[IndrajeetPatil]

• In aov_ez from afex: residual degrees of freedom have their own column - df_error

• In all other aov-like objects: residual degrees of freedom have their own row

I am saying, for the latter objects, we can support in model_parameters a way to already return a dataframe where the residual degrees of freedom are contained in a column.

[IndrajeetPatil]

(If you change the output from aov/aovlist this is severely break effectsize!)

@mattansb Oh, I see!

I am not arguing for changing the defaults. We can provide an argument df_error_format = "nice" that returns the desired output. But I am not sure how difficult it would be then for effectsize to cover contexts like these.

[mattansb]

If this were to happen, effectsize would just have to set df_error_format = "NOTnice" 😅

[strengejacke]

I'm not so familiar with ANOVA to say what makes most sense here. But I think that the default summary output is meaningful. But nonetheless I'm open to any other suggestions if these indeed provide a better model summary.

[mattansb]

I think people who use ANOVAs (like me) are used to seeing these tables presented like they are - with a row for each SS.
Though it is true that for reporting in text having the values side-by-side per-test make sense, but maybe this can be resolved on in report?

[IndrajeetPatil]

I still think we should support this in parameters.

(If you change the output from aov/aovlist this is severely break effectsize!)

@mattansb I am a bit confused by this. How can it break effectsize if the default behavior will continue to be backward compatible?

Or do you mean if someone set df_error_format = "nice" and set omega_squared = TRUE, then effectsize would fail? In this, the solution would be to delay the reformatting of the dataframe after the effect size computation takes place.

So the dataframe can be "nicified" after this computation takes place.

parameters/R/methods_htest.R

Lines 212 to 221 in 02c6a92

	out <- .extract_htest_oneway(model)
	out <- .add_effectsize_oneway(
	model,
	out,
	omega_squared,
	eta_squared,
	epsilon_squared,
	ci = ci,
	verbose = verbose
	)

[strengejacke]

?

[IndrajeetPatil]

I am just continuing the conversation where we left off.

You tagged it as “won’t fix”, but I am still not sure why. That’s why I wanted to get to know more about how this would adversely affect effectsize, because that would be a good reason not to support this.

[mattansb]

I guess if it's off by default, it should be fine... But what would you want it?

[IndrajeetPatil]

Sorry, didn’t get you.
Do you mean why I want it?
It would be helpful for me in ggstatsplot context.