On 2012/09/21 12:20 PM, Nathaniel Smith wrote: > 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?
An example of where tighter casting seems undesirable is the case of functions that return integer values with floating point dtype, such as rint(). It seems natural to do something like In [1]: ind = np.empty((3,), dtype=int) In [2]: rint(np.arange(3, dtype=float) / 3, out=ind) Out[2]: array([0, 0, 1]) where one is generating integer indices based on some manipulation of floating point numbers. This works in 1.6 but fails in 1.7. Eric > > -n > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
