Skip to content

Fix misleading TypeError for scalar overflow in dask.array elemwise#12301

Merged
jacobtomlinson merged 5 commits intodask:mainfrom
cluster2600:fix-elemwise-overflow-scalar
Mar 4, 2026
Merged

Fix misleading TypeError for scalar overflow in dask.array elemwise#12301
jacobtomlinson merged 5 commits intodask:mainfrom
cluster2600:fix-elemwise-overflow-scalar

Conversation

@cluster2600
Copy link
Copy Markdown
Contributor

@cluster2600 cluster2600 commented Feb 19, 2026

What this PR does

Fixes a confusing error when applying elemwise operations between a small integer-typed Dask array and a Python scalar that is out of bounds for the dtype.

Example:

import dask.array as da
import numpy as np

da.ones(2, dtype=np.int8) * 128

Previously raised:

TypeError: unsupported operand type(s) for *: 'Array' and 'int'

Now raises (matching NumPy semantics and message):

OverflowError: Python integer 128 out of bounds for int8

Why

dask.array.core.elemwise performs dtype inference via apply_infer_dtype. When inference fails, elemwise returned NotImplemented, causing Python to fall back to the scalar reverse-op and emit a misleading TypeError.

This PR:

  • Chains the original exception in apply_infer_dtype (raise ValueError(...) from e)
  • Detects scalar overflow (root cause OverflowError) in elemwise and re-raises it
  • Adds a regression test

Closes #12296

When dtype inference fails in elemwise due to a scalar overflow (e.g.
int8 * 128), Dask previously returned NotImplemented. This caused Python
to fall back to the scalar reverse-operator and raise a misleading
TypeError.

Preserve the original exception via chaining in apply_infer_dtype and
re-raise OverflowError in elemwise when that is the root cause.

Add regression test for int8 scalar overflow.
@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Feb 19, 2026

Unit Test Results

See test report for an extended history of previous test failures. This is useful for diagnosing flaky tests.

     21 files  ± 0       21 suites  ±0   5h 45m 9s ⏱️ + 15m 20s
 18 289 tests + 1   17 015 ✅ + 2   1 274 💤 ±0  0 ❌  - 1 
317 304 runs  +17  273 551 ✅ +11  43 753 💤 +7  0 ❌  - 1 

Results for commit 50f9cf3. ± Comparison against base commit ac02b7d.

♻️ This comment has been updated with latest results.

@cluster2600
Copy link
Copy Markdown
Contributor Author

The CI failure (test_elemwise_scalar_overflow_raises_overflowerror — "DID NOT RAISE OverflowError") was caused by an incorrect assumption about how Python chains exceptions.

apply_infer_dtype wraps the original OverflowError via raise ValueError(msg) from err, so in some Python versions the overflow appears on __cause__, but in others (notably 3.10 in the CI environment) the exception chaining can place it on __context__ instead.

Fixed by checking both: original = e.__cause__ or e.__context__. Verified locally with Python 3.10 — the test now passes. Pushed in commit 441d34a.

Copy link
Copy Markdown
Member

@jacobtomlinson jacobtomlinson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of questions.

@lucascolley if you have some time you may also want to take a look.

Let OverflowError propagate directly from apply_infer_dtype instead of
wrapping it in ValueError. Add a matching except clause in elemwise so
the error is not swallowed by the broad Exception handler.

Signed-off-by: Maxime Grenu <maxime.grenu@gmail.com>
@cluster2600 cluster2600 force-pushed the fix-elemwise-overflow-scalar branch from 083ccbe to 144bc8d Compare March 3, 2026 12:05
Copy link
Copy Markdown
Member

@jacobtomlinson jacobtomlinson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you also look at the failing CI? Given the errors are in mindeps I expect older versions of numpy don't raise an OverflowError when scalars overflow, they probably do something else instead. We need to handle this case too.

NumPy < 2.0 silently upcasts out-of-bounds scalars instead of
raising OverflowError, so the test cannot pass on those versions.

Signed-off-by: Maxime Grenu <maxime.grenu@gmail.com>
@jacobtomlinson jacobtomlinson merged commit 0993aa9 into dask:main Mar 4, 2026
29 checks passed
@cluster2600 cluster2600 deleted the fix-elemwise-overflow-scalar branch March 4, 2026 16:06
@lucascolley
Copy link
Copy Markdown
Contributor

thank you both!

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

poor error message when dtype is too small for scalar multiplication

3 participants