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

Charles R Harris charlesr.harris at gmail.com
Tue Apr 12 13:27:19 EDT 2011


On Tue, Apr 12, 2011 at 10:49 AM, Mark Wiebe <mwwiebe at gmail.com> wrote:

> On Tue, Apr 12, 2011 at 9:30 AM, Robert Kern <robert.kern at gmail.com>wrote:
>
>> 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.
>
>
> I'm afraid I'm not seeing the point you're driving at, can you provide some
> examples which tease apart these issues? Here's the same example but with
> different kinds, and to me it seems to have the same character as the case
> with float32/float64:
>
> >>> np.__version__
> '1.4.1'
> >>> 1e60*np.ones(2,dtype=np.complex64)
> array([ Inf NaNj,  Inf NaNj], dtype=complex64)
>
> >>> np.__version__
> '2.0.0.dev-4cb2eb4'
> >>> 1e60*np.ones(2,dtype=np.complex64)
> array([  1.00000000e+60+0.j,   1.00000000e+60+0.j])
>
>
IIRC, the behavior with respect to scalars sort of happened in the code on
the fly, so this is a good discussion to have. We should end up with
documented rules and tests to enforce them. I agree with Mark that the tests
have been deficient up to this point.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110412/a6d800e8/attachment.html>


More information about the NumPy-Discussion mailing list