IntelPython / dpnp / 31783905487

78%

push

github

Fix `OverflowError` in comparison functions and divide for out-of-range integer scalars (#3017)

Comparison ufuncs (`dpnp.equal`, `dpnp.not_equal`, `dpnp.less`,
`dpnp.less_equal`, `dpnp.greater`, `dpnp.greater_equal`) and
`dpnp.divide` raised `OverflowError` when an integer array was compared
with (or divided by) a Python `int` scalar outside the array dtype's
range. NumPy handles these cases and returns a well-defined result, so
this was a parity gap.

For example:
```python
import dpnp
dpnp.less(dpnp.array([0, 1, 2**63, 2**64 - 1], dtype="u8"), -1)
# Out: OverflowError: Python integer -1 out of bounds for uint64

dpnp.divide(dpnp.array([0, 2, 2**63], dtype="u8"), -1)
# Out: OverflowError: Python integer -1 out of bounds for uint64
```

NumPy instead evaluates the comparison against the true value of the
scalar (`-1` is less than any `uint64`, so the result is all-`False`)
and returns floating-point results for the division.

These functions used the default weak-type resolver
`_resolve_weak_types`, which forces a Python integer scalar into the
other operand's dtype before dispatch. When the scalar does not fit that
dtype (a negative value against an unsigned array, or a value larger
than the signed range), the coercion overflows and raises.

This PR:
- Pass `weak_type_resolver=_resolve_weak_types_all_py_ints` to the six
comparison ufuncs in `dpnp_iface_logic.py`.
- Pass the same resolver to `dpnp.divide` in
`dpnp_iface_mathematical.py` (also covers `dpnp.true_divide`).
- Un-skip test `test_binary_array_pyscalar_int`, which now passes

`dpnp.floor_divide` is intentionally left unchanged: NumPy itself raises
`OverflowError` for out-of-range integer scalars there, and dpnp already
matches that behavior.

1546 of 2896 branches covered (53.38%)

Branch coverage included in aggregate %.

1 of 1 new or added line in 1 file covered. (100.0%)

26513 of 32863 relevant lines covered (80.68%)

7915.39 hits per line