Add fit_predict to BaseLabelPropagation
#24898
Conversation
|
Can you add a quick test for Otherwise this seems like a reasonable thing to add. |
| Predictions for input data. | ||
| """ | ||
| self.fit(X, y) | ||
| return self.transduction_ |
There was a problem hiding this comment.
transduction_ is already documented in LabelPropagation as:
transduction_ : ndarray of shape (n_samples)
Label assigned to each item via the transduction.
We can improve that description if you think it's not clear, and we can also add attributes to BaseLabelPropagation for clarity maybe. I think I might prefer that to implementing fit_predict.
There was a problem hiding this comment.
The reason I thought this should exist is that similar methods exist for other sklearn classes, e.g. KMeans.fit_predict does basically the same thing.
There was a problem hiding this comment.
Yes, but I'm not sure if that's a good thing.
cc @scikit-learn/core-devs
There was a problem hiding this comment.
It definitely feels (is) a bit redundant, but I think the benefit of a more "consistent" API is worth it. It helps newcomers infer usage across estimators. Overall I'm in favor if it strictly conforms to the expected semantics.
Edit: as @scottgigante-immunai mentioned, in this case fit(X, y).predict(X) == fit_predict(X, y) does not hold. I think this is not obvious a-priori and consequently I think enforcing access through transduction_ is more appropriate
@betatim this fails and for good reason -- when fitting, the predictions keep the existing labels in place (unless LabelSpreading alpha > 0) while calling |
In this case, I don't think we can add this. We should better document |
|
Agreed. With |
|
That all makes sense to me. I've opened a new PR #24985 which closes this and instead edits the docs. PS: I love that we're communicating with "people from the future". Such time travel :D |
What does this implement/fix? Explain your changes.
This PR adds a
fit_predictmethod toBaseLabelPropagation. The predicted labels forXare already computed, but there is no documented way of accessing them without callingpredictagain, which causes redundant computation.