Merging functionality with `modelsummary`

[vincentarelbundock]

Hey @michaeltopper1

I just saw on CRANberriesFeed that this package was released. Congratulations! This is very cool!

A while ago, I think we had an exchange on the modelsummary github about this type of functionality. I'm not 100% sure, but I think I proposed collaborating to integrate that kind of functionality in the main package. In any case, that obviously went nowhere and you did the work. Cool.

Looking at this now, I still wonder if it wouldn't make sense to integrate. As a proof of concept, I wrote a super simple wrapper function to combine modelsummary tables vertically. Here's a notebook to illustrate:

https://arelbundock.com/panelsummary.html

Obviously, there are lots of rough corners, especially w.r.t. aesthetics. However, I think this that there would be important benefits to integration. In particular, this very simple function already:

• Supports basically all the model types supported by modelsummary (except multinomials and other grouped outcomes)
• Supports almost all the same arguments that modelsummary does (except shape)
• Uses a consistent naming convention: title != caption
• Combines GOF at the bottom when possible but keeps them separate when not
• Allows panels with non-matching columns
• Supports all the output formats: gt, kableExtra, DT, flextable, huxtable, which gives us Word output, etc.

All of this with <50 lines of code (including lots of boilerplate).

Anyway, I just wanted to let you know I'd be very interested in collaborating to integrate something like that in the main package. It feels like this might be good for users and limit duplication of efforts by developers.

Let me know what you think.

[michaeltopper1]

Hey @vincentarelbundock !

I think this is a great idea—users would be better-off if everything was in one package. In addition, integrating with modelsummary is bound to be more robust than blindly seeing if certain model object-types work correctly in panelsummary. My package definitely only serves a niche.

Your small notebook to illustrate this idea is great. It looks like you achieved most of what panelsummary does in just a few lines of code. However, there are a few things I'd love to see if this was integrated with modelsummary:

• Make a new stars argument option. As you can see in panelsummary I have an option to set stars to "econ" which changes the significance stars to match the economics standard. I know this seems like a trivial request, but it would actually save a ton of time!
• Make an argument for panelnames. I personally don't like the idea of passing in a named list to each argument. I think for the common user, named lists are something that are overlooked and are not as intuitive as an argument.
• Getting the mean of the dependent variable. I know there are lots of tricks to be able to do this in modelsummary, but having an argument for it would be terrific. I realize why this is so difficult after developing panelsummary, but maybe you have a beter idea of a way this could be implemented.

Now comes the bad news: I am unforunately (or fortunately?) going to be on the job market next year and should be working on my job market paper. My internal deal with myself is that I would release this over winter break and then not look at it (much) until I get a job. I seem to find things like this way more interesting/fun than the research I'm working on, and it's going to be a more costly distraction as the job market looms closer.

So what is the best path forward? I think this is really up to you! I'm happy (and honored!) to hand over/chat about any codes or ideas I had in panelsummary to you and your coauthors for a modelsummary::panelsummary function as you described above. If it was implemented, then I could delete this package from CRAN and you would have one less downsteam dependency to worry about in the future. Myself working as a contributor on modelsummary, however, might do more harm then good.

Happy to chat more about this over email/phone!

[vincentarelbundock]

That all sounds good. Thanks for the positive response! And I totally understand re: finding a job is important.

Given all you said, I think I'll work on this function and integrate it in the main package if/when it looks solid enough.

I'll have to think about your suggestions; they sounds reasonable, but I'm not 100% sure I'll integrate them all. In the meantime, if you load this function in your environment, all modelsummary tables will display the mean of the outcome:

glance_custom.fixest <- function(x, ...) {
    data.table::data.table(`Mean of DV` = mean(insight::get_response(x)))
}

Your suggestions for panel names and stars are interesting and I'll consider them seriously. The only hesitations I have are:

• The named list is already the only mechanism for naming model columns in modelsummary. I know this is not the easiest for newbies, but it's well-document and people seem to figure it out. Using the same mechanism would be consistent with that.
• The two main reasons I developed modelsummary were that stargazer was not extensible and that it had 85(!!!) different arguments. This basically makes it impossible to "master" the package or read the docs. So I am extremely careful about adding new arguments.

But again, I'll think about this a bit.

Will ping you if/when something is ready to try.

[vincentarelbundock]

FYI, I added a new argument: shape = "rbind". There are also a bunch of examples on the website, including a few with fixest and automatic mean of outcome:

https://vincentarelbundock.github.io/modelsummary/articles/modelsummary.html#rbind-panels-of-models-in-stacked-regression-tables

This is not out on CRAN yet, but let me know if you have the time to try it and find some problems.