[SYCL][DOC] Introduce sycl-marray-complex specialization proposal #8852
Conversation
|
The implementation of the |
| marray<T, NumElements> imag() const; | ||
|
|
||
| // subscript operator | ||
| reference operator[](std::size_t i); |
There was a problem hiding this comment.
This requires that the internal data representation is an array of complex. Are we reasonable sure no implementation wants the data storage to be one array for real and one for imag?
There was a problem hiding this comment.
Please, let me know if I misunderstood your feedback, but that's what the sycl::marray specialization for sycl::complex is about.
If needed, a user could use the real() or imag() method to let him work on the data split.
@TApplencourt, what do you think?
There was a problem hiding this comment.
There is already an implementation of this complex specialization of marray within this repo https://github.com/argonne-lcf/SyclCPLX.
No issues have been raised about having an array of complex rather than two arrays for real and imag.
Also, this PR is for the proposed directory and later will be moved onto the experimental.
We'll not be tied to this proposal implementation.
I believe it is conceivable to have an array of complex for this proposal as a start, and if needed we'll change the structure layout.
sycl/doc/extensions/proposed/sycl_ext_oneapi_complex_marray.asciidoc
Outdated
Show resolved
Hide resolved
sycl/doc/extensions/proposed/sycl_ext_oneapi_complex_marray.asciidoc
Outdated
Show resolved
Hide resolved
|
Gentle ping to get some attention into this PR 👍 @rolandschulz @steffenlarsen @gmlueck |
There was a problem hiding this comment.
This looks reasonable to me, but I would like @rolandschulz to confirm that his concerns have been addressed.
|
Ack! Sorry, I just noticed that my previous comments never got submitted. (They were stuck as "pending" in the PR.) Sorry about the delay. |
|
One other thought ... Why should this be a separate extension rather than an expansion of the existing sycl_ext_oneapi_complex? Of course you can argue that more granular extensions give implementors greater freedom to choose what they implement, but more extensions makes life harder for application developers who want to write portable code. Consider an implementor who already implements sycl_ext_oneapi_complex. Is there some reason that implementor might not be able to implement these marray functions? It seems like it's just a matter of some extra code on top of what they need already for sycl_ext_oneapi_complex. |
You are right, the better definition of that proposal is an expansion of the existing complex. Bringing other types which handle complex and overloads for the complex's math functions to support this new type. No, there is no reason that an implementor might not be able to implement these |
|
On my side, I got back to work on this today. Regarding the implementation of this proposal (#8647) I got back to it today as well, and I'll update the The next steps I'm working towards and hoping for would be:
|
I'd prefer an expansion of the existing extension unless we have a good reason to make a separate extension. |
|
Since we are moving away from having a separate extension, I'll create another PR to expand the complex extension with the modifications asked here. |
…array (#11792) This PR is the updated version of the "complex support for sycl::marray" extension, which used to be a separate extension. However, after discussing whether it should be a separate extension versus an expansion (#8852), the complex expansion has been decided. Following the proposal for `sycl::ext::oneapi::experimental::complex` which adds the support of complex for SYCL, this expansion proposes to incorporate complex support for `sycl::marray` and new complex math features. Implementation: #8647
Following the proposal for
sycl::ext::oneapi::experimental::complexand its implementation (#8068), which adds the support of complex for SYCL, this proposal allows for adding new complex math features.This PR proposes the specialization of
sycl::marrayto add support for storing complex numbers in arrays.