[Numpy-discussion] Weird upcast behavior with 1.6.x, working as intended?

Olivier Delalleau shish@keba...
Mon Aug 8 14:38:05 CDT 2011

2011/8/8 Charles R Harris <charlesr.harris@gmail.com>

> On Mon, Aug 8, 2011 at 10:54 AM, Olivier Delalleau <shish@keba.be> wrote:
>> Hi,
>> This is with numpy 1.6.1 under Linux x86_64, testing the upcast mechanism
>> of "scalar + array":
>> >>> import numpy; print (numpy.array(3, dtype=numpy.complex128) +
>> numpy.ones(3, dtype=numpy.float32)).dtype
>> complex64
>> Since it has to upcast my array (float32 is not "compatible enough" with
>> complex128), why does it upcast it to complex64 instead of complex128?
>> As far as I can tell 1.4.x and 1.5.x versions of numpy are indeed
>> upcasting to complex128.
> The 0 dimensional array is being treated as a scalar, hence is cast to the
> type of the 1d array. This seems more consistent with the idea that 0
> dimensional arrays act like scalars, but I suppose that is open to
> discussion.
> Chuck

I'm afraid I don't understand your reply. I know that the 0d array is a
scalar, and thus should not lead to an upcast "unless the scalar is of a
fundamentally different kind of data (*i.e.*, under a different hierarchy in
the data-type hierarchy) than the array" (quoted from

This is one case where it is under a different hierarchy and thus should
trigger an upcast. What I don't understand it why it upcasts to complex64
instead of complex128.

Note that:
1. When replacing "numpy.ones" with "numpy.array" it yields complex128
(expected upcast of scalar addition of complex128 with float32)
2. The behavior is similar if instead of "3" I use a number which cannot be
represented exactly with a complex64 (so it's not a rule about picking the
smallest data type able to exactly represent the result)

-=- Olivier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20110808/e1d6d30f/attachment.html 

More information about the NumPy-Discussion mailing list