You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Changing meaning (or adding another flag) for has_nan=True, descending=True #234
We would like to add descending sorts in NumPy (numpy/numpy#31345), but one caveat is that the NaN sorting in NumPy should push NaNs to the end of the array in descending sorts.
However, the convention currently implemented here is the opposite: It considers NaNs like the largest possible value so that NaNs come first in a descending sort. This is a convention preferred e.g. by DataFrames (at least more common) I think, and has the advantage that the result differs from just flipping res[::-1] (for unstable sorts).
Adding another switch for it would probably not be hard, or if we expect no users of has_nan=True, descending=True one could change it (but it's an API break).
I would expect it is a relatively simple change otherwise.
Hi @seberg. Adding a dedicated flag for NaN positioning seems like the right way to go, especially if we default to the current behavior to maintain backward compatibility. I'll need to check how to propagate this through our APIs like qsort and argsort. I’ll give it some thought and get back to you—how urgent is this on your end?
I think we can also do it and you would only have to have a quick look if it looks fine. From a glance at the code it doesn't sound like it should be too difficult.
But yeah, a dedicated flag for NaN order seems indeed best and hopefully straight forward.
(In a sense not urgent, OTOH I would like to get descending sorts into NumPy very soon, I think we can cheat a bit since this should be straight forward merge things into NumPy and fix this as a speed bug after the RC -- which would give us another month. As it seems like a very safe/simple thing.)
@seberg see #235. Turned out to be a bigger patch than i thought, still have to add more tests to ensure the right behavior. please do review @seberg@MaanasArora
Activity
r-devulap commentedon May 9, 2026
Hi @seberg. Adding a dedicated flag for NaN positioning seems like the right way to go, especially if we default to the current behavior to maintain backward compatibility. I'll need to check how to propagate this through our APIs like qsort and argsort. I’ll give it some thought and get back to you—how urgent is this on your end?
seberg commentedon May 9, 2026
I think we can also do it and you would only have to have a quick look if it looks fine. From a glance at the code it doesn't sound like it should be too difficult.
But yeah, a dedicated flag for NaN order seems indeed best and hopefully straight forward.
(In a sense not urgent, OTOH I would like to get descending sorts into NumPy very soon, I think we can cheat a bit since this should be straight forward merge things into NumPy and fix this as a speed bug after the RC -- which would give us another month. As it seems like a very safe/simple thing.)
r-devulap commentedon May 11, 2026
@seberg see #235. Turned out to be a bigger patch than i thought, still have to add more tests to ensure the right behavior. please do review @seberg @MaanasArora
r-devulap commentedon Aug 11, 2026
Completed with #235