On Sat, Nov 17, 2012 at 9:47 AM, Nathaniel Smith <n...@pobox.com> wrote:
> On Fri, Nov 16, 2012 at 9:53 PM, Gökhan Sever <gokhanse...@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@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')
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
