Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AbstractFixedEffectModel #29

Open
jmboehm opened this issue Apr 27, 2020 · 6 comments
Open

AbstractFixedEffectModel #29

jmboehm opened this issue Apr 27, 2020 · 6 comments

Comments

@jmboehm
Copy link

jmboehm commented Apr 27, 2020

I would like to support GLFixedEffectModels in RegressionTables without requiring it as a dependency. The package produces a GLFixedEffectModel very similar to the FixedEffectModel (but with information on the distribution and link).

Could we have an AbstractFixedEffectModel that both FixedEffectModels and GLFixedEffectModels inherit from? I think the right place for this would be in FixedEffects.jl; then I wouldn't need to have FixedEffectModels.jl as a dependency in either package.

Happy to have a go at it if you approve of the idea.

@matthieugomez
Copy link
Member

matthieugomez commented May 5, 2020

I was hoping that the new functions in StatsBase would allow you to drop the dependence completely.

I think the only missing stuff are hasfe and hasiv, right?

what about doing the converse, ie define hasiv and hasfe in RegressionTable? I would be happy to take regressiontable as a dependency in FixedEffectModel.

@jmboehm
Copy link
Author

jmboehm commented May 9, 2020

Yes, I'm not sure which way around is better. If it's really only hasfe and hasiv that I need, I guess I could define regtable as a parametric function that takes arguments T <: RegressionModel and then check the type with typeof at runtime. It's very un-Julia but should work...
Edit: no, then I would need to define regtable as a macro. Argh.

@matthieugomez
Copy link
Member

I think it would be much better for you to define these two functions. Once it’s done I’ll update fixedeffectmodel to import them.

@matthieugomez
Copy link
Member

matthieugomez commented May 10, 2020

Overall I think it depends on the future of RegressionTables

One way to see RegressionTables is that (I) you define an API in RegressionTables (Ii) packages that want to be compatible have to define a type that satisfies this API. The issue is that packages like GLM etc may refuse to depend on RegressionTables.

Another solution is to add the methods you need in StatsBase such as hasiv hasfe etc. Then every package that returns a RegressionModel could be used in RegresssionTables.

The last solution is to import all possible stat packages in RegressionTable. It is less elegant but if this is what you need in the end, then feel free do a pull request in FixedEffects to copy the FixedEffexrModel type definition.

@jmboehm
Copy link
Author

jmboehm commented May 11, 2020

hasiv and hasfe are not absolutely crucial for RegressionTables, but I believe access to the formula object is not in the StatsBase interface and that's going to be a problem. I guess the best compromise would be to support basic printing of StatsBase.RegressionModel objects, and define an interface for an extended structure that also shows things that depend on formula etc.
I should have more time for this next week, and hope to get to this then.

@matthieugomez
Copy link
Member

Don’t hesitate to do pull request at StatsBase. They were pretty receptive when I wanted to add some methods on RegressionModels.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants