Fix out of bounds integer behavior in dpctl.tensor.full

[ndgrigorian]

Resolves #1230

This PR adjusts how integer overflow and underflow is handled by dpctl.tensor.full.

Previously, when an integer that would overflow the type of array in the result of full was passed in as fill_value, an exception would be thrown by pybind11.

Now, _to_scalar is used to get fill value back after it has been converted to a Numpy scalar, which brings the value into the range of the type and allows pybind11 to unpack the scalar.

• 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]

View rendered docs @ https://intelpython.github.io/dpctl/pulls/1266/index.html

[coveralls]

coverage: 83.261% (+0.005%) from 83.256% when pulling 3a814f6 on full-large-integer-fix into cc02941 on master.

[github-actions]

Array API standard conformance tests for dpctl=0.14.5dev0=py310h7bf5fec_3 ran successfully.
Passed: 388
Failed: 612
Skipped: 119

[antonwolfy]

I've tried to test the built Win package and the behavior is still different and looks incorrect:

numpy.full(3, 4294967295)
Out: array([4294967295, 4294967295, 4294967295], dtype=int64)

dpt.full(3, 4294967295)
Out: usm_ndarray([-1, -1, -1], dtype=int32)

looks fill_value was just silently casted to int32, but expected int64.

[ndgrigorian]

I've tried to test the built Win package and the behavior is still different and looks incorrect:

numpy.full(3, 4294967295)
Out: array([4294967295, 4294967295, 4294967295], dtype=int64)

dpt.full(3, 4294967295)
Out: usm_ndarray([-1, -1, -1], dtype=int32)

looks fill_value was just silently casted to int32, but expected int64.

Yes, this is to keep our conformity to the array API spec, which requires the output type be the default integer type.

Any possible changes to the default integer type on Windows will be made in a separate PR.

[antonwolfy]

I've tried to test the built Win package and the behavior is still different and looks incorrect:

numpy.full(3, 4294967295)
Out: array([4294967295, 4294967295, 4294967295], dtype=int64)

dpt.full(3, 4294967295)
Out: usm_ndarray([-1, -1, -1], dtype=int32)

looks fill_value was just silently casted to int32, but expected int64.

Yes, this is to keep our conformity to the array API spec, which requires the output type be the default integer type.

Any possible changes to the default integer type on Windows will be made in a separate PR.

Ok, I see. Thank you @ndgrigorian! I have no more comments. LGTM!

[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.14.5dev0=py310h7bf5fec_3 ran successfully.
Passed: 388
Failed: 612
Skipped: 119