-
-
Notifications
You must be signed in to change notification settings - Fork 26k
TST test_k_means_fit_predict: do not test fit determinism together with predict/labels_ equality #13751
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
Conversation
There's a comment at the beginning of the test: |
It was approved as a short term fix, and no other fix was merged on the basis that the problem seemed to have gone away |
I'll remove the reference to fit from the comment, but the point we to check the iterative updating when fitting matched assignment by pairwise_distances_argmin |
Actually it was my intention :) |
Oh! |
My intention was just to test that calling |
But under the assumption that Can we rename the failing test to be |
I think it is. If I recalled correctly the failures appear when using elkan algorithm because the predict method always uses lloyd algo and even if both algo should give the same results, there might be some numerical instabilities. I'm ok to rename and skip the test |
I think this might fix #12644.
The comments there suggest the failure is due to
fit
andfit_predict
learning permuted clusters. I don't think the intention of this test is to check the determinism / idempotence offit
/fit_predict
, even if that would also be a good thing to ensure and to test.The intention of the test here is:
therefore this should not call
fit
twice, but rather check that callingpredict
afterfit_predict
gives the same labels. This is what we now test in the present PR.