-
Notifications
You must be signed in to change notification settings - Fork 30
Use sycl experimental complex namespace for real
and imag
#2062
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
`imag` uses static constant value of 0 for real inputs and both use sycl complex extension
Deleted rendered PR docs from intelpython.github.com/dpctl, latest should be updated shortly. 🤞 |
Array API standard conformance tests for dpctl=0.20.0dev0=py310h93fe807_164 ran successfully. |
return std::imag(in); | ||
using realT = typename argT::value_type; | ||
using sycl_complexT = typename exprm_ns::complex<realT>; | ||
return exprm_ns::imag(sycl_complexT(in)); |
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.
It might be unclear from the PR description what was the motivation to switch to experimental namespace and why other place where std::imag
used are not impacted.. Would it make sense to add clarity on that?
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.
The initial motivation was old technical debt to add the constant value for imag
, since we may as well use it for real-valued types.
In terms of why add in the experimental namespace change, complex
header is not supported on AMD and this has been an issue with recent AMD builds. I've pushed another branch which removes (almost) every use of complex
in kernel code aside from conversion to SYCL complex type. I want to see if this resolves issues with AMD builds on OS compiler.
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.
In general, I think it would be best to slowly transition to full use of the sycl complex extension. We also have benchmarking now and can see if this PR brings regressions once we have some unary elementwise benchmarks in place.
But it could be done in a separate PR, if you feel it makes more sense that way.
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 see now, thank you. I'm totally with that. Just it was a bit unclear from the PR description.
dpctl/tensor/libtensor/include/kernels/elementwise_functions/imag.hpp
Outdated
Show resolved
Hide resolved
Array API standard conformance tests for dpctl=0.20.0dev0=py310h93fe807_165 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.
LGTM
Closing PR because I think |
This PR proposes
imag
using static constant value of 0 for real inputsreal
andimag
both using the experimental complex namespace calls