Sat Jul 21 11:09:50 CDT 2012
On Sat, Jul 21, 2012 at 4:44 PM, OC <firstname.lastname@example.org> wrote:
> 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).
It's unPythonic just in the sense that it is unlike every other type
constructor in Python. int(x) returns an int, list(x) returns a list,
but np.complex64(x) sometimes returns a np.complex64, and sometimes it
returns a np.ndarray, depending on what 'x' is.
I can see an argument for deprecating this behaviour altogether and
referring people to the np.asarray(x, dtype=complex) form; that would
be cleaner and reduce confusion. Don't know if it's worth it, but
that's the only cleanup that I can see even being considered for these
> 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
> with arrays.
> 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_"
There's also np.int/np.int_ and np.float/np.float_.
It's considered poor form to have variables names that clash with
builtins. People do write "from numpy import *", and it would be very
bad if that overwrote basic builtins like int/float/bool. I'd probably
have just had np.int_ be what it is, and np.int be undefined. But
hindsight is 20/20 and all that; it's a bit late to do anything about
(I suppose there probably aren't many people who depend on np.int, and
the ones who do are probably confused, so maybe that is a good
argument for deprecating the builtin aliases. But it's very difficult
to deprecate exports, so I guess this will probably never happen.)
More information about the NumPy-Discussion