[Numpy-discussion] __iadd__(ndarray<int>, ndarray<float>)
Andreas Klöckner
lists@informa.tiker....
Mon Mar 24 23:42:22 CDT 2008
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://projects.scipy.org/pipermail/numpy-discussion/attachments/20080325/4ec54552/attachment.bin
More information about the Numpy-discussion
mailing list