[Numpy-discussion] numpy.complex

Nathaniel Smith njs@pobox....
Sat Jul 21 11:09:50 CDT 2012


On Sat, Jul 21, 2012 at 4:44 PM, OC <oc-spam66@laposte.net> 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
> "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).

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
constructors.

> 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_"

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
it now.

(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.)

-n


More information about the NumPy-Discussion mailing list