On Fri, Sep 21, 2012 at 5:51 PM, Eric Firing <efir...@hawaii.edu> wrote:
> 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. > In [16]: rint(arange(3, dtype=float)/3, out=ind, casting='unsafe') Out[16]: array([0, 0, 1]) I'm not sure how to make this backward compatible though. Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
