[Numpy-discussion] numpy.complex

OC oc-spam66@laposte....
Sat Jul 21 10:44:43 CDT 2012


Thank you for your answers.

Chris Barker wrote:
 > for consistency with the rest of the numpy types

Then, why do "numpy.complex64(A)", "numpy.complex128(A)", 
"numpy.uint8(A)",... all work with arrays? It's very convenient that it 
works like this! It's awkward that "numpy.complex(A)" is the only one 
that does not.

Is there a problem to extend "numpy.complex" so that it acts the same as 
"numpy.complex64"?


Pauli Virtanen wrote:
> Remember that "numpy.complex", "numpy.complex64" (...) are types that
> represent scalar numbers, not arrays. (...) That you get an array
> out from "numpy.complex64(A)" rather than a "ValueError" is
> un-Pythonic.

Thanks for pointing this out. I don't see why it would be un-pythonic, 
and on the contrary this behavior is useful. Why shouldn't a "type" 
object offer such useful method/constructor? Is there a design mistake 
here? (from the Python point of view, not from the C++ point of view).

All the types you mention inherit from "numpy.generic", except 
"numpy.complex". Is there a reason for this? I find it awkward and 
misleading.

I understand that "numpy.real" and "numpy.complex" are different things 
from a programmer's point of view, the first being a "function" and the 
latter being a "type". However, from the syntax point of view, I think 
that an average user is founded to believe that they behave similarly 
with arrays.

And such an improvement seems to be easy. For example, why isn't 
"numpy.complex" simply equal to "numpy.complex_" instead of 
"__builtin__.complex"?

Note: same remark for "numpy.bool" and "numpy.bool_"


More information about the NumPy-Discussion mailing list