Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

dask.array.reductions.nanquantile never dispatches float32 input to numbagg, forcing a much slower fallback

Open Beginner friendly
  • Is something wrong?
#12,601 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 3 days

@Yi-111-a is already working on this.

Since Sep 24, 2026.

  • #12606 by @Yi-111-a — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
numpy, python
Domain
data, performance

Research direction

Start in dask.array.reductions.nanquantile and inspect the dispatch condition choosing _numbagg_nanquantile versus _custom_nanquantile. Run the minimal float32 and float64 reproduction from the issue, then verify that float32 selects numbagg, preserves the expected quantile results, and avoids the slower fallback.

Written by the indexing model from the issue text.

Description

needs triage

What we're seeing

dask.array.reductions.nanquantile's dispatch condition only routes to numbagg's nanquantile (GIL-releasing) when the input array is float64 or int:

if (
    HAS_NUMBAGG
    and (a.dtype.kind in "ui" or a.dtype == np.float64)
    and q_arr.dtype == np.float64
    ...
):
    func = _numbagg_nanquantile
else:
    func = _custom_nanquantile

float32 input unconditionally falls back to _custom_nanquantile. now numbagg doesn't have an optimised float32 version, but it does happily haldle float32 (NumPy/numba's generic ufunc casting silently upcasts to match the declared signature).

Why it matters

without numbagg, we fall back on _custom_nanquantile. That's slower, and most importantly, holds the GIL much more ~29.6% GIL-free vs. numbagg's ~63.4%.
Casting the array to float64 immediately before the quantile call (and back to float32 after) recovered numbagg dispatch and measured 29–43% faster wall clock and lower GIL contention on our workload, with no functional downside — but it would be much cleaner to just allow dask to dispatch float32 to numbagg.

Question / ask

Could we relax the dispatch condition to also route float32 arrays to numbagg? I'm happy to handle submitting a PR if this is something that would be accepted.

Versions: numbagg 0.9.4

Minimal repro:

import numpy as np, dask.array as da

x32 = da.from_array(np.random.default_rng(0).uniform(size=(20, 1000)).astype(np.float32), chunks=(20, 500))
x64 = x32.astype(np.float64)

# Confirm which function actually runs, e.g. via a quick monkeypatch/profile of
# dask.array.reductions._numbagg_nanquantile vs _custom_nanquantile
da.nanquantile(x32, 0.5, axis=0).compute()  # -> _custom_nanquantile
da.nanquantile(x64, 0.5, axis=0).compute()  # -> _numbagg_nanquantile
Dominant language
Python
Stars
13.9k
Forks
2k
Avg merge
3d 5h
Merged PRs (30d)
1

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dask/dask

All issues in dask/dask

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.