Skip to content

[WIP] FIX Projected Gradient NMF stopping condition #2557

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

Closed
wants to merge 1 commit into from

Conversation

vene
Copy link
Member

@vene vene commented Oct 29, 2013

I caught a bug in the PG NMF stopping condition. All in all it seems that this solver is not at all bad, but I need to understand it properly.

@vene
Copy link
Member Author

vene commented Oct 29, 2013

Benchmarks against Lars's PR.
text
faces

@coveralls
Copy link

Coverage Status

Coverage remained the same when pulling dadc2fc on vene:pgnmffix into 30eb78d on scikit-learn:master.

proj_norm = norm(np.r_[gradW[np.logical_or(gradW < 0, W > 0)],
gradH[np.logical_or(gradH < 0, H > 0)]])
# stopping condition on the norm of the projected gradient
proj_norm = (
Copy link
Member

Choose a reason for hiding this comment

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

I find the code a bit hard to follow. I would rather define variables proj_grad_W and proj_grad_H and compute the Frobenius norms of those.

@vene
Copy link
Member Author

vene commented Nov 28, 2013

The non-negative least squares benchmark notebook version of the solver diverged a little bit. Most importantly the regularization is more properly done (but this makes the objective function and the parametrization different). Should I bring it in to this PR?

@ogrisel
Copy link
Member

ogrisel commented Nov 29, 2013

Could you summarize how it will impact the parametrization? Do you think there is a way to maintain backward compat with a deprecation cycle?

@vene
Copy link
Member Author

vene commented Jan 15, 2014

The default result of the estimator would change anyway in many cases because of the change in stopping conditions.

Should I just put the refactored solver in this PR to discuss it? Make a separate PR?

@ogrisel
Copy link
Member

ogrisel commented Jan 16, 2014

I am fine with bringing it into this PR to make it easier to see the changes.

@amueller
Copy link
Member

Should this be closed in light of #4852?

@agramfort
Copy link
Member

yes. Closing

@agramfort agramfort closed this Sep 22, 2015
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.

8 participants