IntelPython / dpnp / 36609985014

79%

push

github

Sort NaNs to the end for descending order (#3066)

`dpnp.sort`, `dpnp.argsort`, and their `dpnp.ndarray`/`dpnp.tensor`
counterparts placed `NaN` values at the *beginning* when sorting in
descending order, while NumPy 2.5 keeps `NaN` values at the *end* for
both ascending and descending order.

For descending order the sort kernels simply reversed the ascending
comparison, which also moved `NaN` (treated as the largest value) to the
front.

The PR proposes to change:
- Merge-sort comparators: only the comparison between non-`NaN` values
is reversed for descending order, so `NaN`s stay at the end. For complex
values the `NaN`-ness groups `(no nan) -> (imag nan) -> (real nan) ->
(all nan)` keep the same trailing order as ascending, and only the
finite-component lexicographic comparison is reversed.
- Radix-sort float casts (half / float32 / float64): map `NaN` to the
maximum key, so it lands in the last bucket regardless of direction.
This keeps the descending float radix fast path intact rather than
falling back to a slower comparator.
- `dpnp.tensor.top_k` inherits the change through the shared descending
comparator: `NaN` values (and complex values with a `NaN` component) are
now treated as the smallest, so `mode="largest"` no longer returns them
ahead of finite values.

`NaN` ordering under `sort`/`argsort` is left implementation-defined by
the Python Array API standard, and `top_k` explicitly permits sorting
`NaN` values to either end. The new "`NaN` last" behavior is therefore
spec-conforming and is chosen to match NumPy 2.5; it is now consistent
across the `dpnp` and `dpnp.tensor` namespaces.

1566 of 2924 branches covered (53.56%)

Branch coverage included in aggregate %.

26840 of 33212 relevant lines covered (80.81%)

8589.48 hits per line