`dpt.astype` behaves differently on Windows depending on type of input array

[antonwolfy]

There is a suspicious behavior I faced on Windows (LNL with fp64 support for GPU):

import dpctl, dpctl.tensor as dpt, numpy as np

dpctl.__version__
# Out: '0.22.0dev0+117.g7960513f68'

# for integer input the result is expected
a = dpt.asarray([160, 120])
dpt.astype(a, dpt.uint8)
# Out: usm_ndarray([160, 120], dtype=uint8)

# for float32 the result seems incorrect:
a = dpt.asarray([160., 120.], dtype='f4')
dpt.astype(a, dpt.uint8)
# Out: usm_ndarray([127, 120], dtype=uint8)

# but with float64 works as expected:
a = dpt.asarray([160., 120.], dtype='f8')
dpt.astype(a, dpt.uint8)
# Out: usm_ndarray([160, 120], dtype=uint8)

# NumPy returns the same result in both cases:

a = np.asarray([160, 120])
np.astype(a, dpt.uint8)
# Out: array([160, 120], dtype=uint8)

a = np.asarray([160., 120.], dtype='f4')
np.astype(a, dpt.uint8)
# Out: array([160, 120], dtype=uint8)

# for CPU device the result is the same as for NumPy:

a = dpt.asarray([160., 120.], dtype='i4', device='cpu')
dpt.astype(a, dpt.uint8)
# Out: usm_ndarray([160, 120], dtype=uint8)

I wonder if there is any limitation for float32 dtype or an issue.

[antonwolfy]

I found a similar issue IntelPython/dpctl#1540, but here the values of input array are in valid bounds of data types.

[ndgrigorian]

I was able to reproduce this on Iris Xe without double-precision support, and on Linux.

$ python -m dpctl -f
Platform  0 ::
    Name        Intel(R) oneAPI Unified Runtime over Level-Zero
    Version     1.6
    Vendor      Intel(R) Corporation
    Backend     ext_oneapi_level_zero
    Num Devices 1
      # 0
        Name                Intel(R) Iris(R) Xe Graphics
        Version             1.6.33578+42
        Filter string       level_zero:gpu:0
Platform  1 ::
    Name        Intel(R) OpenCL Graphics
    Version     OpenCL 3.0
    Vendor      Intel(R) Corporation
    Backend     opencl
    Num Devices 1
      # 0
        Name                Intel(R) Iris(R) Xe Graphics
        Version             25.18.33578
        Filter string       opencl:gpu:0

then

In [1]: import dpctl.tensor as dpt, dpctl, numpy as np
<ipython-input-1-d5d27e713722>:1: DeprecationWarning: dpctl.tensor is deprecated since dpctl 0.21.1 and will be removed in a future release. The functionality will be moved to separate package, dpnp (see: https://github.com/IntelPython/dpnp). After that, use 'import dpnp.tensor' instead.
  import dpctl.tensor as dpt, dpctl, numpy as np

In [2]: a = dpt.asarray([160, 120])

In [3]: dpt.astype(a, dpt.uint8)
Out[3]: usm_ndarray([160, 120], dtype=uint8)

In [4]: a = dpt.asarray([160., 120.], dtype='f4')

In [5]: dpt.astype(a, dpt.uint8)
Out[5]: usm_ndarray([127, 120], dtype=uint8)

what appears to be happening is:
in our casting logic, floating-point data types are cast into the signed integer data type first, then into the unsigned type. This works perfectly fine when the float is either negative, or inside the positive range of the signed type. But when the float is outside the range of the signed type and in the range of the unsigned type, it encounters undefined behavior.