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
n_neighbors inconsistency #601
Comments
I see. Could make sense. It would take 2 versions for the deprecation. However, you still have some other neighbors params in the smote variants as well. It could also be an issue. You could always create you grid on the fly: for pipe in [smote_pipe, adasyn_pipe]:
neighbors_params_name = [p for p in pipeline.get_params().keys() if 'neighbors' in p]
params = {p: range(3, 6) for p in neighbors_params_name}
gs_pipe = GridSearchCV(pipe, params)
gs_pipe.fit(X, y) |
I would argue that the extra I know this is a minor issue that has simple workarounds, but I felt that it was worth marking as an issue nonetheless. |
We could think about modifying this in 1.X since that we will have more freedom to break the API |
Additionally, I recently noticed the inconsistency also occurs with |
hey! come here from #680 Thanks for your answer. I know it's more or less complex and need some time for this cycle (waiting for two releases) but, is it going to start? Thanks |
Description
All the following classes use
n_neighbors
:ADASYN
OneSidedSelection
NeighbourhoodCleaningRule
NearMiss
AllKNN
RepeatedEditedNearestNeighbours
EditedNearestNeighbours
CondensedNearestNeighbour
Whereas
k_neighbors
is used withSMOTE
and all its variants.This poses a problem with duck-typing and pipelines.
Expected Results
SMOTE
would benefit usingn_neighbors
to have consistent API.Versions
Darwin-18.7.0-x86_64-i386-64bit
Python 3.7.3 | packaged by conda-forge | (default, Jul 1 2019, 14:38:56)
[Clang 4.0.1 (tags/RELEASE_401/final)]
NumPy 1.17.1
SciPy 1.3.1
Scikit-Learn 0.21.3
Imbalanced-Learn 0.5.0
The text was updated successfully, but these errors were encountered: