[Numpy-discussion] float32 to float64 casting

[Benjamin Root]

On Saturday, November 17, 2012, Charles R Harris wrote:

>
>
> On Sat, Nov 17, 2012 at 1:00 PM, Olivier Delalleau <shish at keba.be<javascript:_e({}, 'cvml', 'shish at keba.be');>
> > wrote:
>
>> 2012/11/17 Gökhan Sever <gokhansever at gmail.com <javascript:_e({},
>> 'cvml', 'gokhansever at gmail.com');>>
>>
>>>
>>>
>>> On Sat, Nov 17, 2012 at 9:47 AM, Nathaniel Smith <njs at pobox.com<javascript:_e({}, 'cvml', 'njs at pobox.com');>
>>> > wrote:
>>>
>>>> On Fri, Nov 16, 2012 at 9:53 PM, Gökhan Sever <gokhansever at gmail.com<javascript:_e({}, 'cvml', 'gokhansever at gmail.com');>>
>>>> wrote:
>>>> > Thanks for the explanations.
>>>> >
>>>> > For either case, I was expecting to get float32 as a resulting data
>>>> type.
>>>> > Since, float32 is large enough to contain the result. I am wondering
>>>> if
>>>> > changing casting rule this way, requires a lot of modification in the
>>>> NumPy
>>>> > code. Maybe as an alternative to the current casting mechanism?
>>>> >
>>>> > I like the way that NumPy can convert to float64. As if these
>>>> data-types are
>>>> > continuation of each other. But just the conversation might happen
>>>> too early
>>>> > --at least in my opinion, as demonstrated in my example.
>>>> >
>>>> > For instance comparing this example to IDL surprises me:
>>>> >
>>>> > I16 np.float32(5555)*5e38
>>>> > O16 2.7774999999999998e+42
>>>> >
>>>> > I17 (np.float32(5555)*5e38).dtype
>>>> > O17 dtype('float64')
>>>>
>>>> In this case, what's going on is that 5e38 is a Python float object,
>>>> and Python float objects have double-precision, i.e., they're
>>>> equivalent to np.float64's. So you're multiplying a float32 and a
>>>> float64. I think most people will agree that in this situation it's
>>>> better to use float64 for the output?
>>>>
>>>> -n
>>>> _______________________________________________
>>>> NumPy-Discussion mailing list
>>>> NumPy-Discussion at scipy.org <javascript:_e({}, 'cvml',
>>>> 'NumPy-Discussion at scipy.org');>
>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>>
>>>
>>> OK, I see your point. Python numeric data objects and NumPy data objects
>>> mixed operations require more attention.
>>>
>>> The following causes float32 overflow --rather than casting to float64
>>> as in the case for Python float multiplication, and behaves like in IDL.
>>>
>>> I3 (np.float32(5555)*np.float32(5e38))
>>> O3 inf
>>>
>>> However, these two still surprises me:
>>>
>>> I5 (np.float32(5555)*1).dtype
>>> O5 dtype('float64')
>>>
>>> I6 (np.float32(5555)*np.int32(1)).dtype
>>> O6 dtype('float64')
>>>
>>
>> That's because the current way of finding out the result's dtype is based
>> on input dtypes only (not on numeric values), and numpy.can_cast('int32',
>> 'float32') is False, while numpy.can_cast('int32', 'float64') is True (and
>> same for int64).
>> Thus it decides to cast to float64.
>>
>
> It might be nice to revisit all the casting rules at some point, but
> current experience suggests that any changes will lead to cries of pain and
> outrage ;)
>
> Chuck
>
>
Can we at least put these examples into the tests?  Also, I think the
bigger issue was that, unlike deprecation of a function, it is much harder
to grep for particular operations, especially in a dynamic language like
python. What were intended as minor bugfixes ended up becoming much larger.

Has the casting table been added to the tests?  I think that will bring
much more confidence and assurances for future changes going forward.

Cheers!
Ben Root
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20121117/6c4b40c7/attachment.html>