-----הודעה מקורית-----
מאת: [EMAIL PROTECTED] בשם Andreas Kl?ckner
נשלח: ג 25-מרץ-08 06:42
אל: Discussion of Numerical Python
נושא: Re: [Numpy-discussion] __iadd__(ndarray<int>, ndarray<float>)
 
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.

****************************************************
****************************************************
scalars are immutable objects in python. Thus the += (and alike) are "fake":

>>> a = 23
>>> id(a)
10835088
>>> a += 3
>>> id(a)
10835052      << 'a' is a different object
>>> l = ['a',3]
>>> id(l)
13523744
>>> l += [34]
>>> id(l)
13523744    << lists are mutable, thus 'l' stays the same

a += 3 is really equivalent to a = a+3. Python does not allow in place type 
change, it just creates a different object. numpy convention is consistent with 
the python's spirit. I really use that fact to write arr1 += something, in 
order to be sure that the type of arr1 is conserved, and write arr1 = 
arr1+something, to allow upward type casting.


  Nadav.
****************************************************
****************************************************

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

<<winmail.dat>>

_______________________________________________
Numpy-discussion mailing list
[email protected]
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Reply via email to