[WIP] Try finish #6727: alpha deprecation in LabelPropagation #9192

jnothman · 2017-06-21T00:11:09Z

Travis likes it.

The previous way was breaking the test sklearn.tests.test_common.test_all_estimators

Based on the original paper.

This solution isn't great, but it sets the correct value for alpha without violating the restrictions imposed by the tests.

Changes to fixing scikit-learn#5774 (label clamping)

jnothman · 2017-06-21T00:23:39Z

@boechat107, it looks like kernel='knn' makes Travis happy. If you'd rather adopt this fix in your branch, that's fine. In either case, I hope we can get some quick reviews and merge soon.

jnothman · 2017-06-21T00:26:23Z

I've made another couple of small documentation fixes here.

MechCoder

Just a minor comment related to narrative docs.

MechCoder · 2017-06-21T04:28:44Z

doc/whats_new.rst

     :class:`linear_model.LassoCV`. :issue:`8973` by `Paulo Haddad <paulochf>`.

+   - Fix :class:`semi_supervised.LabelPropagation` to always do hard clamping.
+     Its ``alpha`` parameter now defaults to 0 and the parameter is deprecated


I'm confused, the algorithm and the documentation says that alpha is the percentage of the initial class distribution that will be maintained. Quoting the documentation.

"The LabelPropagation algorithm performs hard clamping of input labels, which means \alpha=1."

In that case, why does this default to zero assuming the definition of alpha is the same?

Nvm, I just read the documentation below. Can you please change the narrative documentation so that there is no confusion.

jnothman · 2017-06-21T05:23:53Z

Maybe I need to check a bit further that the semantics of this fix is right. I feel what's new is under-stating the change particularly because of the change from ...[unlabelled] to ...[~unlabelled]

musically-ut · 2017-06-25T13:09:07Z

Okay, so I understand why the test was failing: part of it was the implementation of the algorithm and part of it was misinterpretation of clf._build_graph() function.

The test should have looked like the following:

n_classes = 2
X, y = make_classification(n_classes=n_classes, n_samples=200, random_state=0)
y[::3] = -1
clf = SS.label_propagation.LabelSpreading().fit(X, y)

# adopting notation from Zhou et al:
# W = clf._build_graph()
# D = np.diag(W.sum(axis=1))
# Dinvroot = scipy.linalg.sqrtm(np.linalg.inv(D))
# S = np.dot(np.dot(Dinvroot, W), Dinvroot)

S = clf._build_graph()
Y = np.zeros((len(y), n_classes + 1))
Y[np.arange(len(y)), y] = 1
Y = Y[:, :-1]
for alpha in [0.1, 0.3, 0.5, 0.7, 0.9]:
    expected = np.dot(np.linalg.inv(np.eye(len(S)) - alpha * S), Y)
    expected /= expected.sum(axis=1)[:, np.newaxis]
    clf = SS.label_propagation.LabelSpreading(max_iter=10000, alpha=alpha)
    clf.fit(X, y)
    assert_array_almost_equal(expected, clf.label_distributions_, 4)

That is, the clf._build_graph() function directly returns S instead of returning W.

Then, the "actual" algorithm talked about in the paper is the following (our modifications are commented out):

        # clamp_weights = np.ones((n_samples, 1))
        # clamp_weights[~unlabeled, 0] = alpha

        # TODO TESTING
        clamp_weights = alpha * np.ones((n_samples, 1))

        # ...

        if alpha > 0.:
            y_static *= 1 - alpha
        # TODO TESTING
        # y_static[unlabeled] = 0

I have this version implemented in this branch of my local fork; one can check out that branch and verify that the sanity-check test does succeed in that case.

I can sort of see that the modifications we have made to the algorithm make sense. Similar guarantees probably can be worked out for this modified version as well, but I would be far more comfortable just using the version from the paper or finding a reference rather than use unpublished versions.

What do you think?

jnothman · 2017-06-25T13:27:50Z

Yes, confusing W for S would make a lot of sense. I didn't read into _build_graph. I would rather implement what they have in their paper. Let's apply alpha to all. But then we also need to have an explicit ValueError in the case that alpha=0, or we need to handle it specially as a limiting case, particularly if LabelPropagation relies on it. So we could say: * alpha > 0: F = alpha * F + (1 - alpha) * Y * alpha = 0: F = {F[i] if i unlabelled else Y[i]} Any harm keeping soft clamping available for LabelPropagation?

…

On 25 June 2017 at 23:09, Utkarsh Upadhyay ***@***.***> wrote: Okay, so I understand why the test was failing: part of it was the implementation of the algorithm and part of it was misinterpretation of clf._build_graph() function. The test should have looked like the following: n_classes = 2 X, y = make_classification(n_classes=n_classes, n_samples=200, random_state=0) y[::3] = -1 clf = SS.label_propagation.LabelSpreading().fit(X, y) # adopting notation from Zhou et al:# W = clf._build_graph()# D = np.diag(W.sum(axis=1))# Dinvroot = scipy.linalg.sqrtm(np.linalg.inv(D))# S = np.dot(np.dot(Dinvroot, W), Dinvroot) S = clf._build_graph() Y = np.zeros((len(y), n_classes + 1)) Y[np.arange(len(y)), y] = 1 Y = Y[:, :-1]for alpha in [0.1, 0.3, 0.5, 0.7, 0.9]: expected = np.dot(np.linalg.inv(np.eye(len(S)) - alpha * S), Y) expected /= expected.sum(axis=1)[:, np.newaxis] clf = SS.label_propagation.LabelSpreading(max_iter=10000, alpha=alpha) clf.fit(X, y) assert_array_almost_equal(expected, clf.label_distributions_, 4) That is, the clf._build_graph() function directly returns S instead of returning W. Then, the "actual" algorithm talked about in the paper <http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.115.3219> is the following (our modifications are commented out): # clamp_weights = np.ones((n_samples, 1)) # clamp_weights[~unlabeled, 0] = alpha # TODO TESTING clamp_weights = alpha * np.ones((n_samples, 1)) # ... if alpha > 0.: y_static *= 1 - alpha # TODO TESTING # y_static[unlabeled] = 0 I have this version implemented in this branch <https://github.com/musically-ut/scikit-learn/blob/tmp-semi-supervised/sklearn/semi_supervised/label_propagation.py#L251> of my local fork; one can check out that branch and verify that the sanity-check test does succeed in that case. ------------------------------ I can *sort of* see that the modifications we have made to the algorithm make sense. Similar guarantees *probably* can be worked out for this modified version as well, but I would be far more comfortable just using the version from the paper or finding a reference rather than use unpublished versions. What do you think? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#9192 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEz63D5y_ZgPPPUr4INZ_G5fe6ort9iks5sHlv1gaJpZM4OATgT> .

jnothman · 2017-06-25T13:28:47Z

Thanks for this great investigation, Manoj. I really appreciate being able to close a chapter on another dodgy implementation...

…

On 25 June 2017 at 23:27, Joel Nothman ***@***.***> wrote: Yes, confusing W for S would make a lot of sense. I didn't read into _build_graph. I would rather implement what they have in their paper. Let's apply alpha to all. But then we also need to have an explicit ValueError in the case that alpha=0, or we need to handle it specially as a limiting case, particularly if LabelPropagation relies on it. So we could say: * alpha > 0: F = alpha * F + (1 - alpha) * Y * alpha = 0: F = {F[i] if i unlabelled else Y[i]} Any harm keeping soft clamping available for LabelPropagation? On 25 June 2017 at 23:09, Utkarsh Upadhyay ***@***.***> wrote: > Okay, so I understand why the test was failing: part of it was the > implementation of the algorithm and part of it was misinterpretation of > clf._build_graph() function. > > The test should have looked like the following: > > n_classes = 2 > X, y = make_classification(n_classes=n_classes, n_samples=200, random_state=0) > y[::3] = -1 > clf = SS.label_propagation.LabelSpreading().fit(X, y) > # adopting notation from Zhou et al:# W = clf._build_graph()# D = np.diag(W.sum(axis=1))# Dinvroot = scipy.linalg.sqrtm(np.linalg.inv(D))# S = np.dot(np.dot(Dinvroot, W), Dinvroot) > > S = clf._build_graph() > Y = np.zeros((len(y), n_classes + 1)) > Y[np.arange(len(y)), y] = 1 > Y = Y[:, :-1]for alpha in [0.1, 0.3, 0.5, 0.7, 0.9]: > expected = np.dot(np.linalg.inv(np.eye(len(S)) - alpha * S), Y) > expected /= expected.sum(axis=1)[:, np.newaxis] > clf = SS.label_propagation.LabelSpreading(max_iter=10000, alpha=alpha) > clf.fit(X, y) > assert_array_almost_equal(expected, clf.label_distributions_, 4) > > That is, the clf._build_graph() function directly returns S instead of > returning W. > > Then, the "actual" algorithm talked about in the paper > <http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.115.3219> is the > following (our modifications are commented out): > > # clamp_weights = np.ones((n_samples, 1)) > # clamp_weights[~unlabeled, 0] = alpha > > # TODO TESTING > clamp_weights = alpha * np.ones((n_samples, 1)) > > # ... > > if alpha > 0.: > y_static *= 1 - alpha > # TODO TESTING > # y_static[unlabeled] = 0 > > I have this version implemented in this branch > <https://github.com/musically-ut/scikit-learn/blob/tmp-semi-supervised/sklearn/semi_supervised/label_propagation.py#L251> > of my local fork; one can check out that branch and verify that the > sanity-check test does succeed in that case. > ------------------------------ > > I can *sort of* see that the modifications we have made to the algorithm > make sense. Similar guarantees *probably* can be worked out for this > modified version as well, but I would be far more comfortable just using > the version from the paper or finding a reference rather than use > unpublished versions. > > What do you think? > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#9192 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAEz63D5y_ZgPPPUr4INZ_G5fe6ort9iks5sHlv1gaJpZM4OATgT> > . >

jnothman · 2017-06-25T13:31:35Z

I think I might have been a bit rough in my notation above. And I'm still a bit uneasy about it.

…

On 25 June 2017 at 23:28, Joel Nothman ***@***.***> wrote: Thanks for this great investigation, Manoj. I really appreciate being able to close a chapter on another dodgy implementation... On 25 June 2017 at 23:27, Joel Nothman ***@***.***> wrote: > Yes, confusing W for S would make a lot of sense. I didn't read into > _build_graph. > > I would rather implement what they have in their paper. Let's apply alpha > to all. But then we also need to have an explicit ValueError in the case > that alpha=0, or we need to handle it specially as a limiting case, > particularly if LabelPropagation relies on it. > > So we could say: > * alpha > 0: F = alpha * F + (1 - alpha) * Y > * alpha = 0: F = {F[i] if i unlabelled else Y[i]} > > Any harm keeping soft clamping available for LabelPropagation? > > On 25 June 2017 at 23:09, Utkarsh Upadhyay ***@***.***> > wrote: > >> Okay, so I understand why the test was failing: part of it was the >> implementation of the algorithm and part of it was misinterpretation of >> clf._build_graph() function. >> >> The test should have looked like the following: >> >> n_classes = 2 >> X, y = make_classification(n_classes=n_classes, n_samples=200, random_state=0) >> y[::3] = -1 >> clf = SS.label_propagation.LabelSpreading().fit(X, y) >> # adopting notation from Zhou et al:# W = clf._build_graph()# D = np.diag(W.sum(axis=1))# Dinvroot = scipy.linalg.sqrtm(np.linalg.inv(D))# S = np.dot(np.dot(Dinvroot, W), Dinvroot) >> >> S = clf._build_graph() >> Y = np.zeros((len(y), n_classes + 1)) >> Y[np.arange(len(y)), y] = 1 >> Y = Y[:, :-1]for alpha in [0.1, 0.3, 0.5, 0.7, 0.9]: >> expected = np.dot(np.linalg.inv(np.eye(len(S)) - alpha * S), Y) >> expected /= expected.sum(axis=1)[:, np.newaxis] >> clf = SS.label_propagation.LabelSpreading(max_iter=10000, alpha=alpha) >> clf.fit(X, y) >> assert_array_almost_equal(expected, clf.label_distributions_, 4) >> >> That is, the clf._build_graph() function directly returns S instead of >> returning W. >> >> Then, the "actual" algorithm talked about in the paper >> <http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.115.3219> is >> the following (our modifications are commented out): >> >> # clamp_weights = np.ones((n_samples, 1)) >> # clamp_weights[~unlabeled, 0] = alpha >> >> # TODO TESTING >> clamp_weights = alpha * np.ones((n_samples, 1)) >> >> # ... >> >> if alpha > 0.: >> y_static *= 1 - alpha >> # TODO TESTING >> # y_static[unlabeled] = 0 >> >> I have this version implemented in this branch >> <https://github.com/musically-ut/scikit-learn/blob/tmp-semi-supervised/sklearn/semi_supervised/label_propagation.py#L251> >> of my local fork; one can check out that branch and verify that the >> sanity-check test does succeed in that case. >> ------------------------------ >> >> I can *sort of* see that the modifications we have made to the >> algorithm make sense. Similar guarantees *probably* can be worked out >> for this modified version as well, but I would be far more comfortable just >> using the version from the paper or finding a reference rather than use >> unpublished versions. >> >> What do you think? >> >> — >> You are receiving this because you authored the thread. >> Reply to this email directly, view it on GitHub >> <#9192 (comment)>, >> or mute the thread >> <https://github.com/notifications/unsubscribe-auth/AAEz63D5y_ZgPPPUr4INZ_G5fe6ort9iks5sHlv1gaJpZM4OATgT> >> . >> > >

musically-ut · 2017-06-25T14:01:04Z

So we could say:

alpha > 0: F = alpha * F + (1 - alpha) * Y

alpha = 0: F = {F[i] if i unlabelled else Y[i]}

~~Err, I don't think the last case makes sense because the initial Y[i] are not supplied by the user (they are all 0s). It will be weird to return this without any hint of something having gone wrong.~~

~~Personally, throwing a ValueError makes more sense.~~

Update: No, it does make sense. Rethinking.

While we are at it, I also recommend adding a warning if the method did not converge after max_iterations, akin to this.

jnothman · 2017-06-25T14:17:36Z

I think Y[i] is supplied by the user where i is labelled. The idea here is that alpha=0 corresponds to hard clamping.

…

On 26 June 2017 at 00:01, Utkarsh Upadhyay ***@***.***> wrote: So we could say: - alpha > 0: F = alpha * F + (1 - alpha) * Y - alpha = 0: F = {F[i] if i unlabelled else Y[i]} Err, I don't think the last case makes sense because the initial Y[i] are not supplied by the user (they are all 0s). It will be weird to return this without any hint of something having any hint of a warning/error. Personally, throwing a ValueError makes more sense. While we are at it, I also recommend adding a warning if the method did not converge after max_iterations, akin to this <https://github.com/musically-ut/semi_supervised/blob/master/semi_supervised/label_propagation.py#L271> . — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#9192 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEz67tLFX_skYt2WtoQl6yOy1EQgRYJks5sHmghgaJpZM4OATgT> .

musically-ut · 2017-06-25T20:52:19Z

Okay, my suggestion is that we disallow both the extreme values of alpha, i.e. 0 and 1. The paper requires alpha to be in the open interval (0, 1) because in one case, we are completely ignoring the transduction and in the other, the input labels. Hence, I'll be happy to throw a ValueError in both cases for LabelSpread.

For LabelPropagation, I'm working on handling the case alpha == None gracefully and writing a similar sanity check for it.

musically-ut · 2017-06-25T20:57:57Z

Actually, I can use some help; my numpy matrix-fu might be wrong somewhere.

I'm trying to replicate the calculations done in eqn. (12) in the reference for LabelPropagation.

Am I doing the correct things here?

n_classes = 2
X, y = make_classification(n_classes=n_classes, n_samples=200, random_state=0)
y[::3] = -1

# Using Zhu.' 2002 notation:

clf = label_propagation.LabelPropagation().fit(X, y)
T_bar = clf._build_graph()

Y = np.zeros((len(y), n_classes + 1))
Y[np.arange(len(y)), y] = 1

unlabelled_idx = Y[:, (-1,)].nonzero()[0]
labelled_idx = (Y[:, (-1,)] == 0).nonzero()[0]

Tuu = T_bar[np.meshgrid(unlabelled_idx, unlabelled_idx, indexing='ij')]
Tul = T_bar[np.meshgrid(unlabelled_idx, labelled_idx, indexing='ij')]

Y = Y[:, :-1]
Y_u = np.dot(np.dot(np.linalg.inv(np.eye(Tuu.shape[0]) - Tuu), Tul), Y[labelled_idx])

expected = Y.copy()
expected[unlabelled_idx, :] = Y_u
expected /= expected.sum(axis=1)[:, np.newaxis]

assert_array_almost_equal(expected, clf.label_distributions_, 4)

Feedback on making this more efficient/easier to read also welcome.

musically-ut · 2017-06-25T22:31:55Z

Okay, I've pushed the changes to a branch on my fork which branches on alpha is None to differentiate LabelSpreading and LabelPropagation. This is a leaky abstraction but something I can live with.

I've also added the tests and have changed the old test from using knn to using rbf kernel because #8008. I've adjusted the gamma parameter such that the exp underflow is not a problem.

Curiously, adding a step to do the following:

LabelPropagation row-normalizes Y to be a valid probability, while LabelSpreading makes such no constraints on the analogous F(T). I suppose we should change this behaviour to be true to the original algorithms depending upon if fit is called from LabelPropagation or LabelSpreading.

i.e.,

            # ...
            self.label_distributions_ = safe_sparse_dot(
                graph_matrix, self.label_distributions_)

            if alpha is None:
                # LabelPropagation
                normalizer = np.sum(self.label_distributions_, axis=1)[:, np.newaxis]
                self.label_distributions_ /= normalizer
            
           # clamp
           # ...

did not change the outcome of the test, while changing increasing the gamma to even 10 brought about numerical instability in the tests (perhaps in the algorithm as well?), making the results diverge and the test fail.

Things still left to do in this PR:

Throw a ValueError for alpha = 0 or alpha = 1.
Normalize step for LabelPropagation before clamping.
More varied tests, esp. to check for numerical stability and with sparse matrixes.

Maybe:

[BUG] LabelPropagation should use undirected graphs for knn kernel. #8008 : Fixing knn implementation.
Show warning if the convergence was not achieved.

jnothman · 2017-06-25T23:56:15Z

I'm not surprised that normalisation or not does not change the test passing (the test itself normalises the final distribution, and everything else is affine, but I've not fully thought it through).

Using assert_array_almost_equal might be less robust to changes in gamma than assert_allclose which uses relative tolerance. I might be wrong, though.

jnothman · 2017-06-26T11:58:51Z

I know there's been a lot of this, but I'd be happy for you to take over here if you wish, or to send me a PR.

musically-ut · 2017-06-26T21:09:12Z

I've added throwing of ValueError for invalid alpha (including tests) and the normalization step before clamping LabelPropagation.

I'm sort of at a loss while designing tests, though. For example, I would love to have tests which:

would fail if the normalization in LabelPropagation was not done but succeeded afterwards (there must exist such a case because T is not row-normalized, only column normalized).
would verify that the implementation works for sparse matrixes.
would test the limit of numerical stability.

I've tried using assert_allclose and it succeeds after playing with rtol a little for LabelPropagation. However, looking at the definition of convergence in the the code:

def _not_converged(y_truth, y_prediction, tol=1e-3):
    """basic convergence check"""
    return np.abs(y_truth - y_prediction).sum() > tol

I don't think we should be using relative tolerance.

re: this PR; do you mean to close this discussion and start a new one?

jnothman · 2017-06-26T22:13:18Z

I don't mind if we close and start anew. testing for sparse should be easy. is it not already tested? On 27 Jun 2017 7:09 am, "Utkarsh Upadhyay" <notifications@github.com> wrote: I've added throwing of ValueErro 9E88 r for invalid alpha (including tests) and the normalization step before clamping LabelPropagation. I'm sort of at a loss while designing tests, though. For example, I would love to have tests which: - would fail if the normalization in LabelPropagation was not done but succeeded afterwards (there must exist such a case because T is not row-normalized, only column normalized). - would verify that the implementation works for sparse matrixes. - would test the limit of numerical stability.

…

------------------------------ I've tried using assert_allclose and it succeeds after playing with rtol a little for LabelPropagation. However, looking at the definition of convergence in the the code: def _not_converged(y_truth, y_prediction, tol=1e-3): """basic convergence check""" return np.abs(y_truth - y_prediction).sum() > tol I don't think we should be using relative tolerance. ------------------------------ re: this PR; do you mean to close this discussion and start a new one? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#9192 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEz6-raZanRIeFoJXf02MUXRYP0siMsks5sIB36gaJpZM4OATgT> .

jnothman · 2017-06-27T01:37:58Z

I think we might have to leave this broken for 0.19.0, and aim to merge it soon after the release.

musically-ut · 2017-06-27T12:43:04Z

testing for sparse should be easy. is it not already tested?

I don't think so. Does something like make_classification exist to generate sparse X?

I think we might have to leave this broken for 0.19.0, and aim to merge it soon after the release.

Not ideal, but sounds reasonable.

I don't mind if we close and start anew [pull request].

I'd rather keep this context around somehow. I missed the discussion on this thread for quite a while (~ 1 week?) because I wasn't automatically subscribed to it.

Note to self: Explicitly ping everyone involved on the new PR which will eventually be created.

MechCoder · 2017-06-27T12:50:23Z

Does something like make_classification exist to generate sparse X?

Why not just generate dense X and then convert to sparse?

musically-ut · 2017-06-27T17:48:29Z

Actually, the graph_matrix can only be sparse if the kernel returns a sparse matrix and only the kNN kernel returns that (which I am avoiding fixing in this PR).

Hence, we don't need to test the sparse implementation right away. However, tests for in-the-loop normalization and numerical stability (how?) would be nice to have.

I am fairly confident that the code implements the algorithm correctly and merging it as-is will move the implementation in the correct direction (i.e. from flat Earth -> spherical Earth). The tests would help move it to the 'oblate spheroid' realm in my head, but coming up with tests is ... difficult.

Thoughts?

jnothman · 2017-06-27T22:33:48Z

do you mean my pr be fixing it, or your implementation? Sorry I've lost the time to focus on this.

…

On 28 Jun 2017 3:48 am, "Utkarsh Upadhyay" ***@***.***> wrote: Actually, the graph_matrix can only be sparse if the kernel returns a sparse matrix and only the kNN kernel returns that (which I am avoiding fixing in this PR). Hence, we don't need to test the sparse implementation right away. However, tests for in-the-loop normalization and numerical stability (how?) would be nice to have. I am fairly confident that the code implements the algorithm correctly and merging it as-is will move the implementation in the correct direction (i.e. from flat Earth -> spherical Earth). The tests would help move it to the 'oblate spheroid' realm in my head, but coming up with tests is ... difficult. Thoughts? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#9192 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEz6-hm8GeDbXgbjnQ26ARA-NbP74YTks5sIUBvgaJpZM4OATgT> .

musically-ut · 2017-06-28T06:52:16Z

I meant a new PR with your changes + the tweaks/tests we've developed over this thread, which are on my branch. I'll presently create a PR from it and link to it here.

ogrisel · 2017-06-29T13:28:33Z

@musically-ut can you please give us a summary of what remains to be done for this PR? Is this ready for final review? If so please update the title from [WIP] to [MRG].

ogrisel · 2017-06-29T13:30:37Z

A actually I understand that this should be closed in favor of #9239.

musically-ut · 2017-06-29T13:32:40Z

@ogrisel Thanks, yes, #9239 supersedes this PR.

boechat107 and others added 17 commits April 20, 2016 16:14

Files for my dev environment with Docker

f37cff0

Fixing label clamping (alpha=0 for hard clamping)

f725281

Deprecating alpha, fixing its value to zero

f609105

Correct way to deprecate alpha for LabelPropagation

3c4f627

The previous way was breaking the test sklearn.tests.test_common.test_all_estimators

Detailed info for LabelSpreading's alpha parameter

2499098

Based on the original paper.

Minor changes in the deprecation message

2c0645b

Improving "deprecated" doc string and raising DeprecationWarning

606d65e

Using a local "alpha" in "fit" to deprecate LabelPropagation's alpha

7b267a8

This solution isn't great, but it sets the correct value for alpha without violating the restrictions imposed by the tests.

Removal of my development files

bd1a06c

Using sphinx's "deprecated" tag (jnothman's suggestion)

2662196

Deprecation warning: stating that the alpha's value will be ignored

551feec

Use __init__ with alpha=None

91b7f9a

Merge branch 'master' into lpalpha

c5b515e

Update what's new

69b3e89

Merge pull request #2 from jnothman/lpalpha

297c16b

Changes to fixing scikit-learn#5774 (label clamping)

Merge branch 'master' into issue-5774

95f73ef

Try fix RuntimeWarning in test_alpha_deprecation

10d82d5

jnothman added this to the 0.19 milestone Jun 21, 2017

jnothman added 2 commits June 21, 2017 10:24

DOC Indent deprecation details

8000 70623f0

DOC wording

e778159

jnothman added Blocker Bug Waiting for Reviewer labels Jun 21, 2017

jnothman mentioned this pull request Jun 21, 2017

[MRG] Fixing label clamping for LabelPropagation #6727

Closed

MechCoder reviewed Jun 21, 2017

View reviewed changes

MechCoder changed the title ~~Try finish #6727: alpha deprecation in LabelPropagation~~ [MRG+1] Try finish #6727: alpha deprecation in LabelPropagation Jun 21, 2017

MechCoder approved these changes Jun 21, 2017

View reviewed changes

jnothman modified the milestones: 0.20, 0.19 Jun 27, 2017

musically-ut mentioned this pull request Jun 28, 2017

[MRG+1] Fix semi_supervised #9239

Merged

ogrisel closed this Jun 29, 2017

ogrisel modified the milestones: 0.19, 0.20 Jun 29, 2017

Uh oh!

[WIP] Try finish #6727: alpha deprecation in LabelPropagation #9192

[WIP] Try finish #6727: alpha deprecation in LabelPropagation #9192

Conversation

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants