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
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
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
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
And such an improvement seems to be easy. For example, why isn't
"numpy.complex" simply equal to "numpy.complex_" instead of
Note: same remark for "numpy.bool" and "numpy.bool_"
More information about the NumPy-Discussion