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

REF: exog_names versus param_names #4426

Open
josef-pkt opened this issue Apr 5, 2018 · 3 comments
Open

REF: exog_names versus param_names #4426

josef-pkt opened this issue Apr 5, 2018 · 3 comments

Comments

@josef-pkt
Copy link
Member

There is currently an incomplete refactoring to switch from exog_names to the more generic param_names.

  • base.model is now using mainly param_names
  • most of the individual models (that I checked) use and modify exog_names (e.g. count models with extra params)
  • some supporting code like summary _getnames uses exog_names
  • exog_names is in model, param_names in model.data
  • base.data uses xnames and param_names
  • results wrapper: those need names for the pandas Series or DataFrames. I'm not sure how the xnames/exog_names/param_names works for that.
    I think, model.exog_names is a reference to data.xnames. When we modify model.exog_names it correctly modifies the names for the pandas wrapper code. (i.e. we need the correct names in model.data)

Given the last point, it is unlikely that we can make structural changes.
The main refactoring that we might be able to do is to essentially rename exog_names to param_names, and consistently use param_names in all models.

One problem is that we have almost no test coverage for names. e.g. #4340 and some earlier bugs when summary is wrong because the names don't have the right length.

Another issue for summary will be when summary doesn't print the "params", either by dropping some or adding some. But summary methods of individual models can use the xname (singular !?) argument in summary supporting code.

related
#1970 required attributes

@josef-pkt
Copy link
Member Author

josef-pkt commented Sep 4, 2020

now wald tests use `cov_names, even more options to store and set names

changed in #6012 to support 2-d params

model specific names shouldn't really be in data to make it easier to set them as model attributes, e.g. extra params that are not related to exog.

My current problem is that I need to figure out where to add the extra params for a new model, and I don't remember or I'm not up-to-date. OrderedModel in #7021 (with 1-dim params)

edit
we need the names in data because that also does the results wrapping, it's not just input handling.

negbinP uses
self.exog_names.append('alpha')
inplace modification go back to the original attribute in data

GenericLikelihoodModel uses the model attribute for inplace modification and data attribute for setting

        if extra_params_names is not None:
            if self.exog is not None:
                self.exog_names.extend(extra_params_names)
            else:
                self.data.xnames = extra_params_names

MNLogit now sets data.cov_names

idx = MultiIndex.from_product((ynames[1:], self.data.xnames),
                                      names=(yname, None))
self.data.cov_names = idx

@josef-pkt
Copy link
Member Author

maybe if exog is None, then xname/exog_name/param_names should be an empty list instead of None.
Then, we could more easily extend to adding extra params, e.g. I needed this also in the no-exog null model for OrderedModel

        # from GenericLikelihoodModel.fit
        if self.exog is not None:
            self.exog_names.extend(threshold_names)
        else:
            self.data.xnames = threshold_names

@josef-pkt
Copy link
Member Author

similarly model.endog_names

e.g. io.lib.summary._getnames checks model endog_names and exog_names, and makes up generic names if not available.

endog_names and exog_names are properties in base.Model that return the model.data attribute, e.g.

@property
    def endog_names(self):
        """
        Names of endogenous variables.
        """
        return self.data.ynames

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

No branches or pull requests

1 participant