BUG: Do not raise deprecation warning for all nans in unique

[thomasjpfan]

Fixes gh-19300

This PR adjusts np.unique for the edge cases where all values are nan.

[seberg]

Thanks @thomasjpfan, LGTM.

[mattip]

This changed the result of np.unique(np.full(5, np.nan, dtype=np.float32)). It used to be array([nan, nan, nan, nan, nan], dtype=float32) but after this PR it is array([nan], dtype=float32). I think the previous value was correct: nan is always unique.

[seberg]

Oh, I missed that :(. @thomasjpfan do you want to have a look? If there is an argument to be made for returning only one NaN, that would indeed be a separate thing.

[seberg]

Sorry, this should have been on #18070 which changed the behaviour. Maybe that made this fix necessary though.

[thomasjpfan]

If there is an argument to be made for returning only one NaN, that would indeed be a separate thing.

In scikit-learn, we have a custom _unique to return only one NaN. From a practical machine learning point of view the nans should be treated all the same.

[mattip]

I came across this from a comparison of the Array API spec to NumPy. The spec returns multiple nans for unique, as does PyTorch:

>>> torch.unique(torch.tensor([math.nan]*5))
tensor([nan, nan, nan, nan, nan])

but that may be because NumPy used to also return multiple nans. Maybe chicken-and-egg problem?

[seberg]

Yeah, we changed in 1.21, it has a release note, but I don't think the list was pinged on it, which would have been good. I have send a mail to the list now. I lean towards just rolling with it, but lets see what everyone thinks, maybe I am missing something anyway.