Skip to content

Changing meaning (or adding another flag) for has_nan=True, descending=True #234

Closed

Description

@seberg

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.

CC @r-devulap maybe just for a quick thought (CC @MaanasArora for awareness).

Activity

  1. r-devulap commented on May 9, 2026

    @r-devulap
    Member

    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?

  2. seberg commented on May 9, 2026

    @seberg
    MemberAuthor

    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.)

  3. r-devulap commented on May 11, 2026

    @r-devulap
    Member

    @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

  4. r-devulap commented on Aug 11, 2026

    @r-devulap
    Member

    Completed with #235

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions