Prepare for n_init=auto in KMeans #6142
Conversation
This adds a warning for the upcoming switch from n_init=1 to 'auto'. This adds the possibility to use 'auto', which helps being compatible with sickit-learn.
|
I'd recommend we switch in 25.04 to get compatibility with the scikit-learn change as soon as possible. |
|
Works for me. There is a PR for a forward merge to 25.02, which makes me think that there won't be a 25.04? Is that right? 25.05 in that case? |
This way the hyper-parameter translator gets to see all arguments and we avoid deprecation warnings due to mismatches between the sklearn and cuml defaults
| sklearn_args = inspect.signature(self._cpu_model_class) | ||
| sklearn_args = sklearn_args.bind(*args, **kwargs) | ||
| sklearn_args.apply_defaults() |
There was a problem hiding this comment.
This means we use the constructor arguments and their default values of the scikit-learn class, combine them with what the user passed in and then feed it to the hyperparameter translator. This makes a difference for cases where the default values in scikit-learn and cuml are different and the user does not explicitly pass that argument.
# The scikit-learn class
class SkTimMeans:
def __init__(self, foo='bar'):
...
# The cuml class
class CuTimMeans:
def __init__(self, foo='baz'):
...
# User code
est = SkTimMeans()foo should be set to 'bar' in est because that is the default value of the scikit-learn class.
It also fixes the many deprecation warnings in the accelerator tests we were getting for KMeans due to the main change of this PR.
This adds a warning for the upcoming switch from n_init=1 to 'auto'. This adds the possibility to use 'auto', which helps being compatible with sickit-learn.
In which version should we switch to the new default?