Add imag specification for returning the imaginary component of a complex number
#496
Conversation
…ent of a complex number array
|
As this is a straightforward addition and has already been discussed in consortium meetings, will merge. Any further revisions can be addressed in a subsequent PR. |
| Returns | ||
| ------- | ||
| out: array | ||
| an array containing the element-wise results. The returned array must have a floating-point data type with the same floating-point precision as ``x`` (e.g., if ``x`` is ``complex64``, the returned array must have the floating-point data type ``float32``). |
There was a problem hiding this comment.
Should this be "must" or "should"?
There was a problem hiding this comment.
In what scenarios should/would this not be the case? And why?
There was a problem hiding this comment.
Oh my bad I was reading this as if it were the input array, not the output. I see the input does say "should".
There was a problem hiding this comment.
For the input dtype, allowing array libraries to support real-valued dtypes makes sense in order to allow for backward compat; however, all array libraries should return an array having a dtype with the same precision.
I suppose you may be thinking if an array library supports real-valued int dtypes, would requiring a float dtype make sense, rather than a no-op or an array having an int dtype with the same precision?
This PR
adds a specification for
imag, an API for returning the imaginary component of a complex number for each elementx_iof an input arrayx.follows Add
realspecification for returning the real component of a complex number #427 and Addconjspecification for computing the complex conjugate #446 in restricting the API to only arrays having complex floating-point dtypes. This is as discussed in the Sept 22, 2022, Consortium workgroup meeting.