I think it would be nice to define a handling of NaNs for xp.sort (and other functions?) in the spec, in order to define the status quo as a standard (also for future array libraries that want to adopt the array api standard). Maybe we open an issue in the data-apis repo?

Agreed, it's on my to-do list. The outcome may just be that the spec explicitly states that nans handling method is left to the package though.

So there is a note that states:

the sort order of NaNs and signed zeros is unspecified and thus implementation-dependent.

see: https://data-apis.org/array-api/latest/API_specification/sorting_functions.html

So while it is not guaranteed to work, I think our implementation is acceptable. Maybe it's just like our assumption that arrays are stored 'C' order.

I see now, and I have also missed that note.

I agree that since the currently supported array libraries in scikit-learn all sort NaNs to the end (that is with the C order(?)), we're fine for now, and in case a new array library would handle this differently, there will be many places where this problem would pop up and then this will be re-discussed.

Thanks for looking into this! ❤

that is with the C order(?)

we assume arrays are stored by default C-contiguous (vs F-contiguous) (I don't have a default reference explaining this but you should be able to find articles on this).
I vaguely recall a note somewhere in the code about us assuming arrays are C-contiguous but I can't find it now.

Yea, I had read about this, but I think somewhere in numpy's docs. It's a question on what language (C or Fortran) the way of storing arrays is optimised for. I didn't find any directive on how scikit-learn deals with this. For the time being, I will just accept that we prefer C-ordered arrays then.