[Numpy-discussion] Weird upcast behavior with 1.6.x, working as intended?
Mon Aug 8 14:38:05 CDT 2011
2011/8/8 Charles R Harris <firstname.lastname@example.org>
> On Mon, Aug 8, 2011 at 10:54 AM, Olivier Delalleau <email@example.com> wrote:
>> 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
>> 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
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.
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)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion