use insight::get_variances, add overdispersion() and zerocount() funs

[strengejacke]

No description provided.

[strengejacke]

@DominiqueMakowski What would you say, do functions to test overdispersion and zero-inflation fit into this package? Maybe we should rename zerocount() into zeroinflation_test() or so...

[DominiqueMakowski]

These functions are great!!! (I was not aware of their existence and purpose, they would definitely benefit from some more visibility)

As for the names, I would tend to agree that zerocount() can be improved.

Maybe we should think of a new "class" of functions, prefixed with check_*, made for... checking stuff for our models. This could be a way of regrouping them together and making them more discoverable. They would become check_overdispersion(), check_zeroinflation() etc.

Based on recent questions that I had from students, other possible functions (not necesserily implemented in performance) come to my mind, such as check_normality and check_homogeneity (of variances), and other functions that would facilitates the checks to see if it's suited for parametric analyses... which would be very useful for students.

[strengejacke]

yes, the check_* prefix makes sense!

As for check_normality... No, no, no! :-D I have those in sjstats (https://strengejacke.github.io/sjstats/reference/check_assumptions.html), and using tests usually will usually result in failed assumptions, because these tests are too strict. I always recommend visual inspections... But, it's up to the user. We may implement such functions, though I don't like them - but that's not the decision rule for implementation of features here. ;-)

[DominiqueMakowski]

sjstats' comprehensiveness strikes again! 😅 Let's leave these there ☺️

PS: I will redirect the students to sjstats then, I think it's a good experience for them to make the tests that they learn in class and see that indeed it fails in most of the cases, to increase awareness that we are doing things with 1) questionable assumptions that 2) we do not respect anyway :)

[DominiqueMakowski]

I've took initiative to rename:

• cronbachs_alpha -> alpha_cronbach: to be consistent wirh others (r2_*) in the form index_author
• ci.lvl: in ICC, to be consistent with others

Also, I would like to rename re.form into something more "plain". Currently, in estimate::estimate_response(), this argument is changed by the random parameter:

@param random Should it take the random effects into account? Can be \code{TRUE}, \code{FALSE} 
or a formula indicating which group-level parameters to condition on when making predictions. 
The data argument may include new levels of the grouping factors that were specified when the 
model was estimated, in which case the resulting posterior predictions marginalize over the relevant 
variables (see \code{posterior_predict.stanreg}).

  # Deal with random
  if (insight::model_info(model)$is_mixed & random) {
    if (!insight::find_random(model, flatten = TRUE) %in% names(data)) {
      warning("Could not find random effects in data. Will turn `random` to FALSE.")
      random <- FALSE
    }
  }
  if (random == TRUE) {
    re.form <- NULL
  } else if (random == FALSE) {
    re.form <- NA
  }

This way of handling random works in my narrow experience, but I am not certain it is able to deal with all the edge-cases. Thus, it might be interesting to find a consistent and general way of addressing it.