<br><br>On Saturday, November 17, 2012, Charles R Harris wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br><div class="gmail_quote">On Sat, Nov 17, 2012 at 1:00 PM, Olivier Delalleau <span dir="ltr"><<a href="javascript:_e({}, 'cvml', 'shish@keba.be');" target="_blank">shish@keba.be</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2012/11/17 Gökhan Sever <span dir="ltr"><<a href="javascript:_e({}, 'cvml', 'gokhansever@gmail.com');" target="_blank">gokhansever@gmail.com</a>></span><br><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><br><br><div class="gmail_quote">On Sat, Nov 17, 2012 at 9:47 AM, Nathaniel Smith <span dir="ltr"><<a href="javascript:_e({}, 'cvml', 'njs@pobox.com');" target="_blank">njs@pobox.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Fri, Nov 16, 2012 at 9:53 PM, Gökhan Sever <<a href="javascript:_e({}, 'cvml', 'gokhansever@gmail.com');" target="_blank">gokhansever@gmail.com</a>> wrote:<br>
> Thanks for the explanations.<br>
><br>
> For either case, I was expecting to get float32 as a resulting data type.<br>
> Since, float32 is large enough to contain the result. I am wondering if<br>
> changing casting rule this way, requires a lot of modification in the NumPy<br>
> code. Maybe as an alternative to the current casting mechanism?<br>
><br>
> I like the way that NumPy can convert to float64. As if these data-types are<br>
> continuation of each other. But just the conversation might happen too early<br>
> --at least in my opinion, as demonstrated in my example.<br>
><br>
> For instance comparing this example to IDL surprises me:<br>
><br>
> I16 np.float32(5555)*5e38<br>
> O16 2.7774999999999998e+42<br>
><br>
> I17 (np.float32(5555)*5e38).dtype<br>
> O17 dtype('float64')<br>
<br>
</div>In this case, what's going on is that 5e38 is a Python float object,<br>
and Python float objects have double-precision, i.e., they're<br>
equivalent to np.float64's. So you're multiplying a float32 and a<br>
float64. I think most people will agree that in this situation it's<br>
better to use float64 for the output?<br>
<div><div><br>
-n<br>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="javascript:_e({}, 'cvml', 'NumPy-Discussion@scipy.org');" target="_blank">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</div></div></blockquote></div><br></div></div>OK, I see your point. Python numeric data objects and NumPy data objects mixed operations require more attention.<div><br></div><div>The following causes float32 overflow --rather than casting to float64 as in the case for Python float multiplication, and behaves like in IDL.</div>
<div><br></div><div><div>I3 (np.float32(5555)*np.float32(5e38))</div><div>O3 inf</div><div><br></div><div>However, these two still surprises me:</div><div><br></div><div><div>I5 (np.float32(5555)*1).dtype</div><div>O5 dtype('float64')</div>
<div><br></div><div>I6 (np.float32(5555)*np.int32(1)).dtype</div><div>O6 dtype('float64')</div></div></div></blockquote></div></div><div><br>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).<br>
Thus it decides to cast to float64.<span><font color="#888888"><br></font></span></div></div></blockquote><div><br>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 ;)<br>
<br>Chuck <br></div><br></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Has the casting table been added to the tests? I think that will bring much more confidence and assurances for future changes going forward.</div><div><br></div><div>Cheers!</div><div>Ben Root<span></span></div>
<div><br></div><div> </div>