ENH: implement __complex__ by ewmoore · Pull Request #7229 · numpy/numpy

ewmoore · 2016-02-11T19:11:07Z

There is still some asymmetry here. Calling float() or complex() on a np.string_ scalar will try to convert the string to a float or a complex. But this still doesn't work for size = 1 arrays.

In [2]: float(np.array(['1.1']))
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-2-981e3b7ad7d1> in <module>()
----> 1 float(np.array(['1.1']))

TypeError: don't know how to convert scalar number to float

In [3]: float(np.array(['1.1'])[0])
Out[3]: 1.1

In [4]: complex(np.array(['1.1']))
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-4-a230266b5899> in <module>()
----> 1 complex(np.array(['1.1']))

TypeError: cannot convert to complex

In [5]: complex(np.array(['1.1'])[0])
Out[5]: (1.1+0j)

seberg · 2016-02-13T14:56:42Z

About time, someone does this. I guess it already works for scalars (or maybe they get forwarded to ndarray)?

Could you move this to the identical definitions for __float__, etc? Or is that not possible because __complex__ has no C-Api side definition?

charris · 2016-02-14T16:38:52Z

Needs release note.

ewmoore · 2016-02-15T20:37:11Z

It already works for scalars. I guess I could put it over with __float__, but since it doesn't have a C-Api definition I put it with the other methods like __copy__. I can move it if you want.

I've updated the PR to include a comment in the release notes and to handle object or string dtypes as well as to improved the error message provided when conversion cannot be done.

Supporting strings is mostly about completeness. Since it works for the scalar type it may as well work for the array type too. __float__ is broken in this case still.

seberg · 2016-02-15T21:14:39Z

Did not look at the code yet. Leaving it where it is sounds fine, since
the struct addition also is a point for here.
A comment next to the other ones is maybe a good idea, not sure.

No conversion from string please. Also I don't think it exists for the
scalars:

In [10]: a = np.array('1.j')
In [11]: a[()].__complex__()
----> 1 a[()].__complex__()

AttributeError: 'numpy.string_' object has no attribute '__complex__'

complex(a[()]) works, but that I guess that is because of coercion
from the string value that complex does, not because we say that it
is a reasonable thing to do.

ewmoore · 2016-02-15T21:41:30Z

I'll drop the string conversion then.

Mind that your example fails because complex() doesn't go via __complex__ for str types. Since np.str_ is a subclass of str it gets handled in the complex constructor via the string path. What this means in practice is exactly what I showed in the first comment, that scalars allow the conversion but arrays (even 0 dim arrays) do not.

ewmoore · 2016-02-15T21:44:48Z

Updated.

homu · 2016-02-21T03:38:04Z

☔ The latest upstream changes (presumably #7296) made this pull request unmergeable. Please resolve the merge conflicts.

ewmoore · 2016-02-22T14:10:05Z

rebased.

charris · 2016-02-22T15:21:06Z

Close and reopen to try to trigger appveyor.

seberg · 2016-03-04T17:16:12Z

Hmmm, whats wrong with AppVoyer? I will try the close + reopen again. @ewmoore if you have some time, one thing that is missing are tests the failure cases as well, those would be good. Otherwise LGTM.

seberg · 2016-03-04T17:17:53Z

Hmm, didn't help, but I very much doubt this has anything to do with the code, so....

seberg · 2016-03-04T17:20:42Z

Oh, would be nice if you can increase the indent here.

charris · 2016-03-04T17:22:51Z

The close, reopen trick doesn't work with appveyor.

homu · 2016-03-05T13:14:57Z

☔ The latest upstream changes (presumably #7373) made this pull request unmergeable. Please resolve the merge conflicts.

fixes numpygh-2491.

ewmoore · 2016-03-22T11:59:15Z

Rebased, comments addressed.

seberg · 2016-03-22T17:17:34Z

Could you still add a test for the failure cases like more then 1 element in the array, and maybe some weird void type conversion to scalar?

ewmoore · 2016-03-23T13:04:06Z

Tests added.

ewmoore · 2016-03-23T13:09:45Z

I can squash this if you'd prefer.

seberg · 2016-03-23T13:14:03Z

Squashing is nice, but I can live with three reasonably described commits.

Thanks a lot Eric!

charris added 01 - Enhancement 56 - Needs Release Note. Needs an entry in doc/release/upcoming_changes component: numpy._core labels Feb 13, 2016

ewmoore force-pushed the __complex__ branch from 7cf32be to c58f7bb Compare February 15, 2016 20:30

ewmoore force-pushed the __complex__ branch from c58f7bb to 97dc41e Compare February 15, 2016 20:40

ewmoore force-pushed the __complex__ branch from 7a7036c to 4b28af0 Compare February 22, 2016 14:09

charris closed this Feb 22, 2016

charris reopened this Feb 22, 2016

seberg closed this Mar 4, 2016

seberg reopened this Mar 4, 2016

seberg reviewed Mar 4, 2016
View reviewed changes

ewmoore added 2 commits March 22, 2016 07:46

ENH: implement __complex__

3d2c1ba

fixes numpygh-2491.

BUG: Don't allow converions of S or U arrays in __complex__

42ba22c

ewmoore force-pushed the __complex__ branch from 4b28af0 to 42ba22c Compare March 22, 2016 11:58

TST: also test cases that should fail in __complex__

5ed19d1

seberg merged commit 1380fdd into numpy:master Mar 23, 2016

Uh oh!

Conversation

ewmoore commented Feb 11, 2016

Uh oh!

seberg commented Feb 13, 2016

Uh oh!

charris commented Feb 14, 2016

Uh oh!

ewmoore commented Feb 15, 2016

Uh oh!

seberg commented Feb 15, 2016

Uh oh!

ewmoore commented Feb 15, 2016

Uh oh!

ewmoore commented Feb 15, 2016

Uh oh!

homu commented Feb 21, 2016

Uh oh!

ewmoore commented Feb 22, 2016

Uh oh!

charris commented Feb 22, 2016

Uh oh!

seberg commented Mar 4, 2016

Uh oh!

seberg commented Mar 4, 2016

Uh oh!

seberg Mar 4, 2016

Choose a reason for hiding this comment

Uh oh!

ewmoore Mar 22, 2016

Choose a reason for hiding this comment

Uh oh!

charris commented Mar 4, 2016

Uh oh!

homu commented Mar 5, 2016

Uh oh!

ewmoore commented Mar 22, 2016

Uh oh!

seberg commented Mar 22, 2016

Uh oh!

ewmoore commented Mar 23, 2016

Uh oh!

ewmoore commented Mar 23, 2016

Uh oh!

seberg commented Mar 23, 2016

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants