[Numpy-discussion] float32 to float64 casting
Charles R Harris
charlesr.harris at gmail.com
Sat Nov 17 15:18:56 EST 2012
On Sat, Nov 17, 2012 at 1:00 PM, Olivier Delalleau <shish at keba.be> wrote:
> 2012/11/17 Gökhan Sever <gokhansever at gmail.com>
>
>>
>>
>> On Sat, Nov 17, 2012 at 9:47 AM, Nathaniel Smith <njs at pobox.com> wrote:
>>
>>> On Fri, Nov 16, 2012 at 9:53 PM, Gökhan Sever <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
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20121117/cc4159dd/attachment.html>
More information about the NumPy-Discussion
mailing list