On Saturday, November 17, 2012, Charles R Harris wrote: > > > On Sat, Nov 17, 2012 at 1:00 PM, Olivier Delalleau > <sh...@keba.be<javascript:_e({}, 'cvml', 'sh...@keba.be');> > > wrote: > >> 2012/11/17 Gökhan Sever <gokhanse...@gmail.com <javascript:_e({}, >> 'cvml', 'gokhanse...@gmail.com');>> >> >>> >>> >>> On Sat, Nov 17, 2012 at 9:47 AM, Nathaniel Smith >>> <n...@pobox.com<javascript:_e({}, 'cvml', 'n...@pobox.com');> >>> > wrote: >>> >>>> On Fri, Nov 16, 2012 at 9:53 PM, Gökhan Sever >>>> <gokhanse...@gmail.com<javascript:_e({}, 'cvml', >>>> '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 <javascript:_e({}, 'cvml', >>>> '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') >>> >> >> 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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion