divide and comparisons allow a greater range of Python integer and integer array combinations

[ndgrigorian]

This PR closes #1711 by aligning divide with Numpy 2.0 behavior.

When a Python integer is out-of-bounds for a (strong, array) integer data type of the other input, _resolve_weak_types_all_py_ints uses np.min_scalar_type to find the minimum type that will fit it.

This does not affect the output type of comparisons or divide, and therefore aligns with NEP-50 while permitting such workflows as:

In [2]: dpt.divide(-4, dpt.asarray(3, dtype="u4"))
Out[2]: usm_ndarray(-1.3333334, dtype=float32)

This also fixes a bug introduced in #1650 where comparisons between uint64 data type arrays and Python integers larger than the maximum for the default integral data type no longer worked.

• Have you provided a meaningful PR description?
• Have you added a test, reproducer or referred to an issue with a reproducer?
• Have you tested your changes locally for CPU and GPU devices?
• Have you made sure that new changes do not introduce compiler warnings?
• Have you checked performance impact of proposed changes?
• If this PR is a work in progress, are you opening the PR as a draft?

[github-actions]

Deleted rendered PR docs from intelpython.github.com/dpctl, latest should be updated shortly. 🤞

[github-actions]

Array API standard conformance tests for dpctl=0.18.0dev0=py310ha798474_186 ran successfully.
Passed: 880
Failed: 15
Skipped: 119

[coveralls]

coverage: 87.614% (+0.005%) from 87.609%
when pulling 655a5d9 on resolve-gh-1711-fix-comparisons
into a40263d on master.

[github-actions]

Array API standard conformance tests for dpctl=0.18.0dev0=py310ha798474_187 ran successfully.
Passed: 894
Failed: 1
Skipped: 119

[oleksandr-pavlyk]

This example from gh-1711 still give unexpected result:

In [4]: dpt.floor_divide(dpt.asarray(7, dtype='u4'), -2)
Out[4]: usm_ndarray(0, dtype=uint32)

[ndgrigorian]

This example from gh-1711 still give unexpected result:

In [4]: dpt.floor_divide(dpt.asarray(7, dtype='u4'), -2)
Out[4]: usm_ndarray(0, dtype=uint32)

It won't after Numpy 2, because -2 will no longer be permitted to promote to uint32.

In general it may be a good idea to go back and disallow overflows from Python integers in asarray explicitly, just as Numpy has done.

But arguably, this result is "correct" in that it follows the NEP-50 rule (Python scalar value does not determine output dtype), it's just undefined behavior. The alternative would be to cast to int64, but this wouldn't match how it's handled in Numpy 2.

[oleksandr-pavlyk]

Indeed, with NumPy 2.0 in run-time environment, I am getting

OverflowError: Python integer -2 out of bounds for uint32

[github-actions]

Array API standard conformance tests for dpctl=0.18.0dev0=py310ha798474_193 ran successfully.
Passed: 894
Failed: 1
Skipped: 119

[github-actions]

Array API standard conformance tests for dpctl=0.18.0dev0=py310ha798474_193 ran successfully.
Passed: 894
Failed: 1
Skipped: 119

[oleksandr-pavlyk]

Thank you @ndgrigorian ! LGTM