-
-
Notifications
You must be signed in to change notification settings - Fork 25.8k
SLEP006 - equal requests? {fit, partial_fit}, {predict, predict_proba, predict_log_proba, decision_function} #22988
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
Comments
I think it's worth clarifying that we're not talking about I'm okay with this at first thought... what are the risks if we have to then split them up later??? |
I think having to distinguish between Also for classifiers, |
Hmmm… I suppose there are a couple of needs for the return parameters: either it is needed directly by a wrapping estimator, or it’s needed for scoring or similar and requested by the user. I had been thinking of the former case, but I suppose you are right about the latter |
If developers would want to remove an arg from the routing mechanism, the API as is allows us to do so:
The above code would remove So to summarize: Do we also want to keep the other |
There's a typo here, I think? |
I'm really unsure about this one. I think these methods are likely to have different |
So the conclusion seems to be that we're gonna keep them separate at least for now. I'll open a PR to reflect this. |
Fixed in #23342 |
Raised in #22986 (comment) the question is whether these two sets of methods should always accept the same metadata:
fit
andpartial_fit
predict
,predict_proba
,predict_log_proba
, anddecision_function
.I think they should, and I suggest we add a common test for them accepting the same metadata, and only have
set_fit_request
andset_predict_request
exposed to users.cc @jnothman
The text was updated successfully, but these errors were encountered: