ENH: np.angle: Remove unnecessary multiplication, and allow subclasses to pass through #11637
Conversation
There was a problem hiding this comment.
Looks like a net gain in efficiency for angle. One suggestion might be a unit test that ensures that when z is a subclass of ndarray (i.e., np.matrix) that it remains as such after angle is called on it. Maybe overkill, but nice to prevent regression after this improvement.
| z = asarray(z) | ||
| if (issubclass(z.dtype.type, _nx.complexfloating)): | ||
| z = asanyarray(z) | ||
| if issubclass(z.dtype.type, _nx.complexfloating): | ||
| zimag = z.imag | ||
| zreal = z.real | ||
| else: | ||
| zimag = 0 | ||
| zreal = z |
There was a problem hiding this comment.
perhaps worth noting that the code path where z isn't a subclass of complexfloating doesn't have test coverage, although that's probably not an issue with changes made here
|
Actually, not sure you could easily test for that -- even the returned object is described as |
7fc2c5d to
aea9eb2
Compare
|
Test added for the parts that changed in this patch. |
There was a problem hiding this comment.
Looks solid now. Would you say it is pretty unlikely that users depended on angle returning the ndarray base class only beforehand?
Not sure if the docstring for Returns should get a small update to reflect the increased flexibility in return type, perhaps in another small future PR.
|
Added a comment about that |
|
|
||
| a = arctan2(zimag, zreal) | ||
| if deg: | ||
| a *= 180/pi |
There was a problem hiding this comment.
Maybe np.rad2deg? Probably no faster.
|
Thanks Eric. |
…