Uh oh!
There was an error while loading. Please reload this page.
Fixed dpctl.tensor.result_type function for scalars - #1473
Conversation
View rendered docs @ https://intelpython.github.io/dpctl/pulls/1473/index.html |
Array API standard conformance tests for dpctl=0.15.1dev2=py310ha25a700_2 ran successfully. |
Array API standard conformance tests for dpctl=0.15.1dev2=py310ha25a700_3 ran successfully. |
Uh oh!
There was an error while loading. Please reload this page.
It handles scalars consistently with the way elementwise operations do, following NEP-0050. Some definitions were migrated from _elementwise_common to _type_utils.
850b9cd to
f53f816CompareArray API standard conformance tests for dpctl=0.15.1dev3=py310h15de555_3 ran successfully. |
Array API standard conformance tests for dpctl=0.15.1dev3=py310h15de555_4 ran successfully. |
ca3dc62 to
ab63295CompareArray API standard conformance tests for dpctl=0.15.1dev3=py310h15de555_5 ran successfully. |
Array API standard conformance tests for dpctl=0.15.1dev3=py310h15de555_5 ran successfully. |
ab63295 to
01e9d9cCompareArray API standard conformance tests for dpctl=0.15.1dev3=py310h15de555_5 ran successfully. |
ndgrigorian
left a comment
There was a problem hiding this comment.
Behavior for Numpy scalars seems worth noting
(the device does not support fp64)
In [9]: dpt.result_type(dpt.empty(0, dtype="f4"), np.float64(2))
Out[9]: dtype('float32')
But we usually treat them as Python scalars anyway, so I don't see a reason to change anything here.
Overall LGTM!
Added support for weak scalars data type.