On 21 Sep 2012 17:31, "Chris Barker" <chris.bar...@noaa.gov> wrote: > > On Thu, Sep 20, 2012 at 2:48 PM, Nathaniel Smith <n...@pobox.com> wrote: > > because a += b > > really should be the same as a = a + b. > > I don't think that's the case - the inplace operator should be (and > are) more than syntactic sugar -- they have a different meaning and > use (in fact, I think they should't work at all for immutable, sbut i > guess the common increment-a-counter use was too good to pass up) > > in the numpy case: > > a = a + b > > means "make a new array, from the result of adding a and b" > > whereas: > > a += b > > means "change a in place by adding b to it" > > In the first case, I'd expect the type of the result to be determined > by both a and b -- casting rules. > > In the second case, a should certainly not be a different object, and > should not have a new data buffer, therefor should not change type.
You're right of course. What I meant is that a += b should produce the same result as a[...] = a + b If we change the casting rule for the first one but not the second, though, then these will produce different results if a is integer and b is float: the first will produce an error, while the second will succeed, silently discarding fractional parts. -n
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
