On Fri, Sep 21, 2012 at 10:04 PM, Chris Barker <chris.bar...@noaa.gov> wrote: > On Fri, Sep 21, 2012 at 10:03 AM, Nathaniel Smith <n...@pobox.com> wrote: > >> 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: > > I certainly agree that we would want that, however, numpy still needs > to deal tih pyton symantics, which means that wile (at the numpy > level) we can control what "a[...] =" means, and we can control what > "a + b" produces, we can't change what "a + b" means depending on the > context of the left hand side. > > that means we need to do the casting at the assignment stage, which I > gues is your point -- so: > > a_int += a_float > > should do the addition with the "regular" casting rules, then cast to > an int after doing that. > > not sure the implimentation details.
Yes, that seems to be what happens. In [1]: a = np.arange(3) In [2]: a *= 1.5 In [3]: a Out[3]: array([0, 1, 3]) But still, the question is, can and should we tighten up the assignment casting rules to same_kind or similar? -n _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
