On Montag 24 März 2008, Stéfan van der Walt wrote: > > I think this is highly undesirable and should be fixed, or at least > > warned about. Opinions? > > I know the result is surprising, but it follows logically. You have > created two integers in memory, and now you add 0.2 and 0.1 to both -- > not enough to flip them over to the next value. The equivalent in C > is roughly:
<snip> Thanks for the explanation. By now I've even found the fat WARNING in the Numpy book. I understand *why* this happens, but I still don't think it's a particular sensible thing to do. I found past discussion on this on the list: http://article.gmane.org/gmane.comp.python.numeric.general/2924/match=inplace+int+float but the issue didn't seem finally settled then. If I missed later discussions, please let me know. Question: If it's a known trap, why not change it? To me, it's the same idea as 3/4==0 in Python--if you know C, it makes sense. OTOH, Python itself will silently upcast on int+=float, and they underwent massive breakage to make 3/4==0.75. I see 2.5 acceptable resolutions of ndarray<int> += ndarray<float>, in order of preference: - Raise an error, but add a lightweight wrapper, such as int_array += downcast_ok(float_array) to allow the operation anyway. - Raise an error unconditionally, forcing the user to make a typecast copy. - Silently upcast the target. This is no good because it breaks existing code non-obviously. I'd provide a patch if there's any interest. Andreas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
