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

ABC for Families #55

Open
wants to merge 21 commits into
base: main
Choose a base branch
from
Open

ABC for Families #55

wants to merge 21 commits into from

Conversation

postelrich
Copy link
Contributor

This PR adds an abstract base class for distribution families. To provide the same way to track subclasses as Regularizers, I added a RegistryClass that both abc's can inherit.

"""
Evaluate the logistic loglikeliehood
Evaluate the logistic loglikelihoodlihood
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

spelling. Also, this led to some confusion for the Poisson family so could you call out that this is the negative log-likelihood for all the families?

@postelrich
Copy link
Contributor Author

@moody-marlin @TomAugspurger feedback before I add tests?

@cicdw
Copy link
Collaborator

cicdw commented May 22, 2017

Nice, I like the organization and consistency this brings.

@cicdw
Copy link
Collaborator

cicdw commented May 24, 2017

@postelrich are you planning on adding more tests, or are you comfortable merging?

@postelrich
Copy link
Contributor Author

@moody-marlin im going to add tests

@postelrich postelrich closed this May 31, 2017
@postelrich postelrich reopened this May 31, 2017
from dask_glm.regularizers import Regularizer
from dask_glm.utils import sigmoid, make_y
from unittest.mock import patch
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will have to be installed and imported separately on python 2.

Could you explain a bit why you're using mock, rather than testing directly? Or maybe explain what the goal of test_family_pointwise_loss is? As I understand it, the thing being tested is pointwise_loss's signature? Would it be better to have a small class inside the test that implements the required interface for that test?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I understand what these tests are doing now. I haven't tested this, but would this work?

class Dummy(Family):
    def loglikelihood(self, Xbeta, y):
        return Xbeta, y

Still, I'm not sure I see the use. It seems to me like we're basically re-implementing the method in the test suite, which is fragile (though since the math isn't changing, we're probably ok here 😄 ).

Copy link
Contributor Author

@postelrich postelrich Jun 2, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TomAugspurger yea the point was just to make sure that if someone changes this code, the tests will catch it since every subclass would potentially break.

np.testing.utils.assert_array_equal(new_y, y)


def test_family_pointwise_loss():
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this seems to redefine the above test. Supposed to be test_family_gradient?

@cicdw
Copy link
Collaborator

cicdw commented Jul 17, 2017

@postelrich want to revisit this and get the tests passing?

@postelrich postelrich closed this Jul 28, 2017
@postelrich postelrich reopened this Jul 28, 2017
Base automatically changed from master to main February 10, 2021 01:06
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

Successfully merging this pull request may close these issues.

3 participants