Add support for Linearmodels library

[jaisal1024]

Hi, i love the library and idea and I'd love to see support added for Panel Regressions from the linearmodels package - https://github.com/bashtage/linearmodels. This library extends statsmodels and should not be too incompatible. The issue now is that it does not return a RegressionModelSummary object from the statsmodel library and instead it's own summary object.

[toobaz]

My 2 cents: linearmodels might "extend" in some sense statsmodels but its objects do not seem to inherit anything from statsmodels' objects. I don't think it is worth for stargazer to support each library that is able to run regressions (e.g. including the more widely adopted scikit-learn), as it would then have to track any change in the internal layout of both statsmodels and the other library. Instead, I suspect it would be easy for linearmodels devs (or even an independent project) to build a compatibility layer which puts model internals where statsmodels expects them. I did something similar in https://github.com/toobaz/rmodel , which allows R models to be plugged into stargazer tables.

[MaxGhenis]

FWIW there's a SO question on this: https://stackoverflow.com/questions/60620142/using-stargazer-to-output-latex-code-from-linearmodels-model-fit

Maybe until it's implemented (if ever), it could throw a specific error saying it's not implemented for linearmodels?

[bashtage]

linearmodels might "extend" in some sense statsmodels but its objects do not seem to inherit anything from statsmodels' objects.

A bit of background: statsmodels is way too rigid to support data structures that are not easily described as a single y variable fit against an array of x variable. This has manifested itself in multiple places in statsmodels, e.g, Vector AR modeling. This is why linearmodels does not inherit from statsmodels although it tries to use similar vocabulary were reasonable (it does differ sometimes when statsmodels is too loyal to Stata to the point of confusion, e.g., bse -> std_errors).

[toobaz]

A bit of background: statsmodels is way too rigid to support data structures that are not easily described as a single y variable fit against an array of x variable.

I see, good point. I'm pretty sure that as of now, anything in linearmodels which deviates from the statsmodels' scheme is unsupported in stargazer.

So I see two possibilities (notice I have no experience with linearmodels, nor with tables involving complex R models):

1. the priority for linearmodels users is that at least models that "resemble statsmodels" can be used in stargazer: then I still guess linearmodels (or an independent project) should provide a translation to the statsmodels interface to get things working in reasonable time
2. the priority for linearmodels users is to extend stargazer so that it does more than what it currently does (e.g. multiple dependent variables): then I guess we could start by opening specific issues for missing features, and see what, in the statsmodels interface, would need to be updated

One thing to keep in mind is that stargazer is very far from even support of most models in statsmodels.

[bashtage]

1. the priority for linearmodels users is that at least models that "resemble statsmodels" can be used in stargazer: then I still guess linearmodels (or an independent project) should provide a translation to the statsmodels interface to get things working in a reasonable time

This can't happen since linearmodels is too widely used, is mature, and well tested.

2. the priority for linearmodels users is to extend stargazer so that it does more than what it currently does (e.g. multiple dependent variables): then I guess we could start by opening specific issues for missing features, and see what, in the statsmodels interface, would need to be updated

statsmdoels.base is a mess and should be considered practically unchangeable. It does a ton of duck typing of internal things (like hasattr and then forking on this value`.

I think it is the wrong approach to be overly wed to statsmodels' results as the object of interest. As a utility project, it would make more sense to have <any result> -> StargazerResult -> stargazer. This would allow users to target StargazerResult which provides a canonical like to attribute names. StargazerResult could be identical to OLSReults, so that these are interchangeable.

I posted some details of how I would approach it here.

[toobaz]

I posted some details of how I would approach it here.

I hope I made it clear that I'm thinking of sharing interfaces in the sense of standards, not of actual code... but let's continue the discussion there.

[PeikaiLi]

Are there any news about this feature?

[toobaz]

While I'm always open to direct collaboration with the Linearmodels project, for now I consider PR #98 by @dsliwka (thanks!), just merged, as a solution for this issue.