-
Notifications
You must be signed in to change notification settings - Fork 30
Implements logaddexp and hypot #1272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
16a1d58
to
0626792
Compare
View rendered docs @ https://intelpython.github.io/dpctl/pulls/1272/index.html |
Array API standard conformance tests for dpctl=0.14.5dev0=py310h7bf5fec_9 ran successfully. |
Array API standard conformance tests for dpctl=0.14.5dev0=py310h7bf5fec_9 ran successfully. |
0626792
to
224455b
Compare
Array API standard conformance tests for dpctl=0.14.6dev0=py310h7bf5fec_24 ran successfully. |
…or tensor.divide The _find_buf_dtype2 must stay consistent with _find_buf_dtype in that for binary_fn that can be expressed via unary_fn(other_binary_fn(unary_fn(in1), unary_fn(in2))), e.g. logaddexp(x1, x2) == log(exp(x1) + exp(x2)) the promotion of integral types to fp type must be consistence with both evaluation. The special-casing, necessary for proper working of dpt.divide, where dpt.divide(dpt.asarray(1, dtype="i1"), dpt.asarray(1, dtype="u1")) should give default fp type resulted in logaddexp(dpt.asarray(1, dtype="i1"), dpt.asarray(1, dtype="u1")) returning array of different data-type than if evaluated alternatively, since dpt.exp(dpt.asarray(1, dtype="i1")) and dpt.exp(dpt.asarray(1, dtype="u1")) both gave float16 arrays, and the result was of float16 data type. Now, both behaviors are fixed: ``` In [5]: dpt.log(dpt.add(dpt.exp(dpt.asarray(1, dtype="u1")), dpt.exp(dpt.asarray(1, dtype="i1")))) Out[5]: usm_ndarray(1.693, dtype=float16) In [6]: dpt.logaddexp(dpt.asarray(1, dtype="u1"), dpt.asarray(1, dtype="i1")) Out[6]: usm_ndarray(1.693, dtype=float16) In [7]: dpt.divide(dpt.asarray(1, dtype="u1"), dpt.asarray(1, dtype="i1")) Out[7]: usm_ndarray(1., dtype=float32) ```
275935a
to
d8437e6
Compare
Array API standard conformance tests for dpctl=0.14.6dev0=py310h7bf5fec_28 ran successfully. |
When NumPy's result has coarser dtype than that of DPCTL we must use the largest resolution from each dtype.
Array API standard conformance tests for dpctl=0.14.6dev0=py310h7bf5fec_30 ran successfully. |
@ndgrigorian The issue with type promotion has already been addressed in one of my commits to this branch. |
dpctl/tensor/libtensor/include/kernels/elementwise_functions/logaddexp.hpp
Outdated
Show resolved
Hide resolved
dpctl/tensor/libtensor/include/kernels/elementwise_functions/logaddexp.hpp
Outdated
Show resolved
Hide resolved
Array API standard conformance tests for dpctl=0.14.6dev0=py310h7bf5fec_31 ran successfully. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this PR is ready to go in. Thank you @ndgrigorian
Deleted rendered PR docs from intelpython.github.com/dpctl, latest should be updated shortly. 🤞 |
Array API standard conformance tests for dpctl=0.14.6dev0=py310h7bf5fec_26 ran successfully. |
This PR implements logaddexp and hypot.
To implement these functions, an issue with type promotion for binary functions has been addressed:
logaddexp
andhypot
both act like compositions of unary functions with binary functions and type promotion logic for binary functions has assumed pure binary functions, resulting in behaviors such as:where the dtype of the last array is
float64
.