NMF lite branch #123
NMF lite branch #123
Conversation
Sparseness is now measured by linearising the arrays.
Renamed some terms, improved some tests nndsvd instead of fast_svd sparseness instead of sparsity (discuss)
|
Is it OK if I do it like this and leave the tests unchanged for now? On Sat, Apr 2, 2011 at 7:06 PM, GaelVaroquaux
|
|
I renamed it to ProjectedGradientNMF and made a empty class When the MultiplicativeUpdateNMF will be added, the doc will have The question is, should I push this? On Sat, Apr 2, 2011 at 7:29 PM, Vlad Niculae [email protected] wrote:
|
Yes.
Push it to your branch. |
|
Also, should I put my name as author at the top of the file, and the On Sat, Apr 2, 2011 at 7:52 PM, GaelVaroquaux
|
|
Yes, you should add your name to the authors list, keeping the original authors in addition. |
|
+1 for merge to be done : write a MultiplicativeUpdateNMF based on the code in benchmarks. are we good? |
|
Hi, On Sun, Apr 3, 2011 at 12:29 AM, agramfort
|
|
It doesn't break, everything looks good. It does make an extra copy of On Sun, Apr 3, 2011 at 12:46 AM, Vlad Niculae [email protected] wrote:
|
Please do that. It will probably be useful for people to get a better understanding of the differences. Also, I am wondering if the imshows wouldn't look better in this specific example with "interpolation='nearest'". |
|
+1 for |
|
By the way, it's late here, and I need to do some urgent things with regards to the administrating the GSOC, so I won't be able to merge this tonight, and tomorrow I am leaving on conference. Alex, or Olivier, can you make sure that the merge happens. After the merge, it would be great to rationalize the shape of components_ across the codebase, and create a 'decomposition' sub-package. |
|
Also about the images: Would it be more useful or more confusing to On Sun, Apr 3, 2011 at 1:04 AM, ogrisel
|
|
Not sure. I guess I am -0 for inversion, unless both PCA and NMF get inverted. |
|
Pushed, hope the plots look good. I don't really understand yet how to On Sun, Apr 3, 2011 at 1:11 AM, GaelVaroquaux
|
|
Use 'pl.subplots_adjust' |
|
Ok this is merged. Thanks again for your contribution Vlad. Would you like to work on the |
|
@vene : you have now commit rights on the main branch. If you're willing to do what olivier suggests please do it in a pull request anyway. Welcome to the crew ! :) |
|
Thank you, wow! I am honored! I will take care of the decomposition package and consistency issue Best, On Sun, Apr 3, 2011 at 4:35 AM, agramfort
|
# More detailed explanatory text, if necessary. Wrap it to about 72 # characters or so. In some contexts, the first line is treated as the # subject of the commit and the rest of the text as the body. The # blank line separating the summary from the body is critical (unless # you omit the body entirely); various tools like `log`, `shortlog` # and `rebase` can get confused if you run the two together. # Explain the problem that this commit is solving. Focus on why you # are making this change as opposed to how (the code explains that). # Are there side effects or other unintuitive consequences of this # change? Here's the place to explain them. # Further paragraphs come after blank lines. # - Bullet points are okay, too # - Typically a hyphen or asterisk is used for the bullet, preceded # by a single space, with blank lines in between, but conventions # vary here # If you use an issue tracker, put references to them at the bottom, # like this: # Resolves: scikit-learn#123 # See also: scikit-learn#456, scikit-learn#789
# More detailed explanatory text, if necessary. Wrap it to about 72 # characters or so. In some contexts, the first line is treated as the # subject of the commit and the rest of the text as the body. The # blank line separating the summary from the body is critical (unless # you omit the body entirely); various tools like `log`, `shortlog` # and `rebase` can get confused if you run the two together. # Explain the problem that this commit is solving. Focus on why you # are making this change as opposed to how (the code explains that). # Are there side effects or other unintuitive consequences of this # change? Here's the place to explain them. # Further paragraphs come after blank lines. # - Bullet points are okay, too # - Typically a hyphen or asterisk is used for the bullet, preceded # by a single space, with blank lines in between, but conventions # vary here # If you use an issue tracker, put references to them at the bottom, # like this: # Resolves: scikit-learn#123 # See also: scikit-learn#456, scikit-learn#789
# More detailed explanatory text, if necessary. Wrap it to about 72 # characters or so. In some contexts, the first line is treated as the # subject of the commit and the rest of the text as the body. The # blank line separating the summary from the body is critical (unless # you omit the body entirely); various tools like `log`, `shortlog` # and `rebase` can get confused if you run the two together. # Explain the problem that this commit is solving. Focus on why you # are making this change as opposed to how (the code explains that). # Are there side effects or other unintuitive consequences of this # change? Here's the place to explain them. # Further paragraphs come after blank lines. # - Bullet points are okay, too # - Typically a hyphen or asterisk is used for the bullet, preceded # by a single space, with blank lines in between, but conventions # vary here # If you use an issue tracker, put references to them at the bottom, # like this: # Resolves: scikit-learn#123 # See also: scikit-learn#456, scikit-learn#789
# More detailed explanatory text, if necessary. Wrap it to about 72 # characters or so. In some contexts, the first line is treated as the # subject of the commit and the rest of the text as the body. The # blank line separating the summary from the body is critical (unless # you omit the body entirely); various tools like `log`, `shortlog` # and `rebase` can get confused if you run the two together. # Explain the problem that this commit is solving. Focus on why you # are making this change as opposed to how (the code explains that). # Are there side effects or other unintuitive consequences of this # change? Here's the place to explain them. # Further paragraphs come after blank lines. # - Bullet points are okay, too # - Typically a hyphen or asterisk is used for the bullet, preceded # by a single space, with blank lines in between, but conventions # vary here # If you use an issue tracker, put references to them at the bottom, # like this: # Resolves: scikit-learn#123 # See also: scikit-learn#456, scikit-learn#789
# More detailed explanatory text, if necessary. Wrap it to about 72 # characters or so. In some contexts, the first line is treated as the # subject of the commit and the rest of the text as the body. The # blank line separating the summary from the body is critical (unless # you omit the body entirely); various tools like `log`, `shortlog` # and `rebase` can get confused if you run the two together. # Explain the problem that this commit is solving. Focus on why you # are making this change as opposed to how (the code explains that). # Are there side effects or other unintuitive consequences of this # change? Here's the place to explain them. # Further paragraphs come after blank lines. # - Bullet points are okay, too # - Typically a hyphen or asterisk is used for the bullet, preceded # by a single space, with blank lines in between, but conventions # vary here # If you use an issue tracker, put references to them at the bottom, # like this: # Resolves: scikit-learn#123 # See also: scikit-learn#456, scikit-learn#789
7 participants
I created a branch with all of the NMF code except for CRO hierarchical clustering, which is slow and impractical at the moment.