ENH: implement __complex__

[ewmoore]

Fixes gh-2491.

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]

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]

Needs release note.

[ewmoore]

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]

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]

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]

Updated.

[homu]

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

[ewmoore]

rebased.

[charris]

Close and reopen to try to trigger appveyor.

[seberg]

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]

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

[seberg]

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

[ewmoore]

Done.

[charris]

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

[homu]

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

[ewmoore]

Rebased, comments addressed.

[seberg]

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]

Tests added.

[ewmoore]

I can squash this if you'd prefer.

[seberg]

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

Thanks a lot Eric!