[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>
>>> > Thanks for the explanations.
>>> > For either case, I was expecting to get float32 as a resulting data
>>> > 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
>>> > 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
>>> > --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?
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion at scipy.org
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion