Fix arange issues #945
Fix arange issues #945
Conversation
oleksandr-pavlyk
requested review from
ndgrigorian,
npolina4 and
antonwolfy
and removed request for
ndgrigorian
|
View rendered docs @ https://intelpython.github.io/dpctl/pulls/945/index.html |
|
Array API standard conformance tests for dpctl=0.14.0dev0=py310h8c27c75_195 ran successfully. |
|
Array API standard conformance tests for dpctl=0.14.0dev0=py310h8c27c75_197 ran successfully. |
|
The below example isn't aligned with |
Should be fixed now, please recheck. |
|
Array API standard conformance tests for dpctl=0.14.0dev0=py310h8c27c75_198 ran successfully. |
|
Array API standard conformance tests for dpctl=0.14.0dev0=py310h8c27c75_199 ran successfully. |
|
Array API standard conformance tests for dpctl=0.14.0dev0=py310h8c27c75_200 ran successfully. |
|
Array API standard conformance tests for dpctl=0.14.0dev0=py310h8c27c75_201 ran successfully. |
|
dpnp tests are passing now |
… dpnp dpt.arange(0, stop=10, step=None) raised, works in numpy dpt.arange(9.7, stop=10) gave empty array, gives 1 element array in numpy dpt.arange(0,stop=2, dtype='bool') raised, works in numpy First two were just bugs, and got fixed. The last one now works through special-casing bools. It works by constructing int8 temporary and casting it into bool array only if the resulting sequence has length 0, 1, or 2. Aligned with behavior of np.arange in computation of the step. To this end changed the logic of determining step argument for the call to `_linspace_step` routine. We now compute first and second element of the array of given type, and determine the step as a the difference of these. To avoid possible overflow message when subtracting unsigned integers, cast first and second element to int64, subtract, and cast to the target type.
Fixed test_arange and added test_arange_mixed_dtype
The test_arange test was specifying out of bounds starting value
for certain types.
Added tests to based on examples highlighting discrepancies.
dpt.arange(-2.5, stop=200, step=100, dtype='int32') now produces
the sequence consistent with np.arange output.
So does dpt.arange(9.7, stop=200, step=100, dtype='i4')
```ipython
In [1]: import dpctl, dpctl.tensor as dpt, numpy as np
In [2]: dpt.asnumpy(dpt.arange(9.7, stop=200, step=100, dtype='i4'))
Out[2]: array([ 9, 109], dtype=int32)
In [3]: np.arange(9.7, stop=200, step=100, dtype='i4')
Out[3]: array([ 9, 109], dtype=int32)
```
```
ty = np.float32
assert (
dpt.arange(
ty(0), stop=ty(504.0), step=ty(100), dtype=ty
).shape == (5,)
)
```
```
In [4]: import numpy as np
In [5]: np.arange(-5, stop=10**5, step=2.7, dtype=np.int64).shape
Out[5]: (37039,)
In [6]: import dpctl.tensor as dpt
In [7]: dpt.arange(-5, stop=10**5, step=2.7, dtype=np.int64).shape
Out[7]: (50003,)
```
oleksandr-pavlyk
force-pushed
the
fix-arange-issues
branch
from
e86a6d6 to
2e78bbb
Compare
|
This PR also fixed other two issues related to computation of output length : _stop = np.float32(504)
x = dpt.arange(0, stop=_stop, step=100, dtype="f4", device=x.device)
assert x.shape == (6,)
# ensure length is determined using uncast parameters
x = dpt.arange(-5, stop=10**2, step=2.7, dtype="int64", device=x.device)
assert x.shape == (39,) |
|
Array API standard conformance tests for dpctl=0.14.0dev0=py310h8c27c75_195 ran successfully. |
|
Deleted rendered PR docs from intelpython.github.com/dpctl, latest should be updated shortly. 🤞 |
|
Array API standard conformance tests for dpctl=0.14.0dev0=py310h8c27c75_195 ran successfully. |
This PR fixes several unexpected behaviors exposed when using
tensor.arangein dpnp.