[Numpy-discussion] __iadd__(ndarray<int>, ndarray<float>)

[Andreas Klöckner]

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: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20080325/4ec54552/attachment.sig>