[Numpy-discussion] Odd numerical difference between Numpy 1.5.1 and Numpy > 1.5.1

Robert Kern robert.kern at gmail.com
Tue Apr 12 12:30:29 EDT 2011

On Tue, Apr 12, 2011 at 11:20, Mark Wiebe <mwwiebe at gmail.com> wrote:
> On Tue, Apr 12, 2011 at 8:24 AM, Robert Kern <robert.kern at gmail.com> wrote:
>> On Mon, Apr 11, 2011 at 23:43, Mark Wiebe <mwwiebe at gmail.com> wrote:
>> > On Mon, Apr 11, 2011 at 8:48 PM, Travis Oliphant
>> > <oliphant at enthought.com>
>> > wrote:
>> >> It would be good to see a simple test case and understand why the
>> >> boolean
>> >> multiplied by the scalar double is becoming a float16.     In other
>> >> words,
>> >>  why does
>> >> (1-test)*t
>> >> return a float16 array
>> >> This does not sound right at all and it would be good to understand why
>> >> this occurs, now.   How are you handling scalars multiplied by arrays
>> >> in
>> >> general?
>> >
>> > The reason it's float16 is that the first function in the multiply
>> > function
>> > list for which both types can be safely cast to the output type,
>> Except that float64 cannot be safely cast to float16.
> That's true, but it was already being done this way with respect to float32.
> Rereading the documentation for min_scalar_type, I see the explanation could
> elaborate on the purpose of the function further. Float64 cannot be safely
> cast to float32, but this is what NumPy does:
>>>> import numpy as np
>>>> np.__version__
> '1.4.1'
>>>> np.float64(3.5) * np.ones(2,dtype=np.float32)
> array([ 3.5,  3.5], dtype=float32)

You're missing the key part of the rule that numpy uses: for
array*scalar cases, when both array and scalar are the same kind (both
floating point or both integers), then the array dtype always wins.
Only when they are different kinds do you try to negotiate a common
safe type between the scalar and the array.

Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco

More information about the NumPy-Discussion mailing list