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

BUG/ENH fix llnull, extra kwds to recreate model #1610

Merged
merged 5 commits into from Apr 21, 2014

Conversation

Projects
None yet
3 participants
@josef-pkt
Copy link
Member

commented Apr 20, 2014

This adds _init_keys to base.Model and fixes llnul in discrete models

includes one test precision adjustment for TestProbitCG.test_conf_int (use relative precision)

llnull
BUG #1221 missing exposure in llnul of countmodels
BUG #1608 missing loglike_method in llnul of NegativeBinomial

recreating models see #1093

no test yet for nb1 versus nb2 with exposure

@coveralls

This comment has been minimized.

Copy link

commented Apr 20, 2014

Coverage Status

Coverage remained the same when pulling 55fa677 on josef-pkt:clone_fix_llnull into e7e018a on statsmodels:master.

model = self.model
#TODO: what parameters to pass to fit?
null = model.__class__(model.endog, np.ones(self.nobs)).fit(disp=0)
return null.llf
mod_null = model.__class__(model.endog, np.ones(self.nobs), **kwds)

This comment has been minimized.

Copy link
@jseabold

jseabold Apr 20, 2014

Member

Couldn't you just attach exposure and offset here without going through the init_keys business?

This comment has been minimized.

Copy link
@josef-pkt

josef-pkt Apr 20, 2014

Author Member

I don't like adding ifs to a superclass that checks attributes that are only available in some subclasses.
I thought about just adding the method to the CountModels.

But I want a generic solution. Here I don't need any special code for loglike_method in NegativeBinomial except registering the keyword.
plus, we will need the same for other things see #1093 (e.g. diagnostic tests)

This comment has been minimized.

Copy link
@jseabold

jseabold Apr 20, 2014

Member

You have the generic solution, but you don't need it. I'm not saying take out init_keys, but you don't really need it here to check for parameters that are attached as attributes already.

This comment has been minimized.

Copy link
@josef-pkt

josef-pkt Apr 20, 2014

Author Member

We need it. Generically, we don't know which attributes have been attached from the model.__init__ signature.
This should also automatically catch weights in WLS, rho in GLSAR, ...
I got started with this a few days ago because I added an attribute in a Poisson subclass that broke llnul called by summary(). I fixed that in a different way, but it's going to happen all the time.

The alternative to a generic solution, requires lot's of code that handles special cases.

This comment has been minimized.

Copy link
@jseabold

jseabold Apr 20, 2014

Member

Thinking about it a bit, it's really not all that generic. You still need to know what keys you're looking for in _init_keys.

This comment has been minimized.

Copy link
@jseabold

jseabold Apr 20, 2014

Member

Yes that's a bug. My point is that only CountModels will have an exposure, so it should be a CountModel 'feature'. NegativeBinomial came after Poisson, so there's not the right amount of code sharing yet in CountModel.

This comment has been minimized.

Copy link
@josef-pkt

josef-pkt Apr 20, 2014

Author Member

The nice point of _init_keys is that we don't care what keywords names where added.
Whether they are exposure or weights or loglike_method or fixed_params_mask or order or ..., the code is generic as long as the original argument value (after data handling (*)) has been attached to the model instance as an attribute.

(*) to get ahead: I'm thinking of this for internal usage as for the use cases in #1093 where we don't need the formula or pandas metainformation.
I haven't seen or thought about any use case that might need pandas or formula information. That' much further down the road if we need it.

This comment has been minimized.

Copy link
@jseabold

jseabold Apr 20, 2014

Member

I understand the reason for _init_keys. But you've hard-coded exposure here. That's not generic. Admittedly, it's because we log it in the __init__ and store the logged version. So...either fix that as part of this PR too (and add logs whenever exposure is used / fix the hard-coded exposure or offset only) or only check for exposure in CountModel. That's my main point. My other point is that if you're going to introduce those changes in this (bug fix) PR, then go the whole nine yards and implement the _get_keys or whatever. This could've been a quick two line fix to close the bug but now I'd like to see the other issues fixed in this PR, if we're going to start the other changes.

This comment has been minimized.

Copy link
@josef-pkt

josef-pkt Apr 20, 2014

Author Member

I don't want to fix log(exposure) in this PR. it's not backwards compatible and needs better design (for example merge _offset_all = np.exp(exposure) + offset to avoid the repeated sum).

This comment has been minimized.

Copy link
@jseabold

jseabold Apr 20, 2014

Member

Why is it not backwards compatible? Nothing the user does would changed. I doubt there are people out there with pickled exposure variables, but we could add a warning.

This PR either 1) fixes the bug its for only 2) Goes all the way and solve 3-4 outstanding, related issues or 3) Solves 1.5 issues and adds a hack for checking exposure in models where we don't necessarily need to.

Right now it's 3, but it'd make more sense to do 1 or 2 I think. In any case, we've talked about this PR more than it warrants.


#TODO: workaround for #1609, find "generic" solution
if 'exposure' in kwds and kwds['exposure'] is not None:
kwds['exposure'] = np.exp(kwds['exposure'])

This comment has been minimized.

Copy link
@jseabold

jseabold Apr 20, 2014

Member

I think we should only do these checks in the appropriate subclass. Exposure should only be in count models. Offset could be in any.

josef-pkt added a commit to josef-pkt/statsmodels that referenced this pull request Apr 20, 2014

@josef-pkt josef-pkt changed the title BUG/ENH fix llnull, extra kwds to recreate modle BUG/ENH fix llnull, extra kwds to recreate model Apr 20, 2014

@josef-pkt

This comment has been minimized.

Copy link
Member Author

commented Apr 20, 2014

Ok, I figured out a way to avoid adding a special countmodel llnul
instead CountModel overwrites _get_init_kwds so no other code needs to know that exposure is funny.

@coveralls

This comment has been minimized.

Copy link

commented Apr 20, 2014

Coverage Status

Coverage remained the same when pulling 05116c2 on josef-pkt:clone_fix_llnull into e7e018a on statsmodels:master.

josef-pkt added a commit that referenced this pull request Apr 21, 2014

Merge pull request #1610 from josef-pkt/clone_fix_llnull
BUG/ENH fix llnull, extra kwds to recreate model

@josef-pkt josef-pkt merged commit 14b9537 into statsmodels:master Apr 21, 2014

1 check passed

continuous-integration/travis-ci The Travis CI build passed
Details

@josef-pkt josef-pkt deleted the josef-pkt:clone_fix_llnull branch Apr 21, 2014

PierreBdR pushed a commit to PierreBdR/statsmodels that referenced this pull request Sep 2, 2014

Merge pull request statsmodels#1610 from josef-pkt/clone_fix_llnull
BUG/ENH fix llnull, extra kwds to recreate model

@josef-pkt josef-pkt added this to the 0.6 milestone Apr 30, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.