Add broom methods as enhancements

[nicholasjclark]

tidy, glance and augment can easily be added to help users save summaries in tidy formats for expanded workflows

[swpease]

Hi, I've been busy with things like Thanksgiving.

For tidy:

Do you think it would make sense to give the same options as in summary, so users could choose to get either parameters or smooth tests?

For returning parameters, it seems like that would entail more or less returning the mcmc_summary output with sensible parameter names? I think that would make it like coef, but for all parameters. Or maybe I should just be looking at what the tidybayes package does.

[nicholasjclark]

Thanks @swpease, I've also been busy with conferences and workshops so haven't been able to give this much thought. But we'll probably need to workshop this one a bit to make it as useful as possible. I see that tidy.lm() for example can return confidence intervals and test statistics for hypothesis tests, which we could certainly link to marginaleffects utilities in a nice and clean way. To me it makes sense to only return information about key terms in the model, and not all of the coefficients, as splines and GPs can have many coefficients that aren't interpretable on their own

[swpease]

Leaving out all those coefficients makes sense.

Did you have something in mind with marginaleffects? (Possibly a way to unify the output? I'm not familiar with it.) The broom authors mention possibly needing to provide an argument if outputs don't really make sense together (ref):

Sometimes a model will have several different types of components. For example, in mixed models, there is different information associated with fixed effects and random effects. Since this information doesn’t have the same interpretation, it doesn’t make sense to summarize the fixed and random effects in the same table. In cases like this you should add an argument that allows the user to specify which type of information they want.

I just realized I essentially wrote that in my earlier comment. Anyway, to my understanding the overarching structure / terms in an mvgam model can include:

1. Observation model, which can include any of:
   • conventional regression terms (fixed effects)
   • splines
   • random effects
   • GPs
2. Process model, which can include:
   • everything from (1)
3. Process time series component, aka the point of the package
4. These can each be multivariate

My current thoughts are:

• fixed effects and the random effects' mean/sd estimates could be in one output
  • include the time series model component as well?
• splines/re/other s() calls's "significance of GAM smooths" could be another
• do any of the time series models need special treatment?
• how to present matrix outputs / handle multivariate?

[swpease]

So I'm trying an implementation for this, and I found a small bug. I think it is a regression, because it shows up in my dev environment but not in my production environment. I noticed it via variables().

When the backend = "rstan", observation_pars gets all these "_var" names lumped in, e.g. any of the mvgam_examples. You can see it with parnames <- dimnames(mvgam_example1$model_output)$parameters.