On Fri, 2019-09-27 at 11:50 -0700, Sebastian Berg wrote: > Hi all, > > Looking at the ufunc dispatching rules with an `out` argument, I was > a > bit surprised to realize this little gem is how things work: > > ``` > arr = np.arange(10, dtype=np.uint16) + 2**15 > print(arr) > # array([ 0, 2, 4, 6, 8, 10, 12, 14, 16, 18], dtype=uint16) >
Whoops, copied that print wrong of course. Just to be clear, I personally will consider this an accuracy/precision bug and assume that we can just switch the behaviour failry unceremoniously at some point (and if someone feels that should be a major release, I do not mind). It seems like one of those things that will definitely fix some bugs but could break the odd system/assumption somewhere. Similar to fixing the memory overlap issues. - Sebastian > out = np.zeros(10) > > np.add(arr, arr, out=out) > print(repr(out)) > # array([ 0., 2., 4., 6., 8., 10., 12., 14., 16., 18.]) > ``` > > This is strictly speaking correct/consistent. What the ufunc tries to > ensure is that whatever the loop produces fits into `out`. > However, I still find it unexpected that it does not pick the full > precision loop. > > There is currently only one way to achieve that, and this by using > `dtype=out.dtype` (or similar incarnations) which specify the exact > dtype [0]. > > Of course this is also because I would like to simplify things for a > new dispatching system, but I would like to propose to disable the > above behaviour. This would mean: > > ``` > # make the call: > np.add(arr, arr, out=out) > > # Equivalent to the current [1]: > np.add(arr, arr, out=out, dtype=(None, None, out.dtype)) > > # Getting the old behaviour requires (assuming inputs have same > dtype): > np.add(arr, arr, out=out, dtypes=arr.dtype) > ``` > > and thus force the high precision loop. In very rare cases, this > could > lead to no loop being found. > > The main incompatibility is if someone actually makes use of the > above > (integer over/underflow) behaviour, but wants to store it in a higher > precision array. > > I personally currently think we should change it, but am curious if > we > think that we may be able to get away with an accelerate process and > not a year long FutureWarning. > > Cheers, > > Sebastian > > > [0] You can also use `casting="no"` but in all relevant cases that > should find no loop, since the we typically only have homogeneous > loop > definitions, and > > [1] Which is normally the same as the shorter spelling > `dtype=out.dtype` of course. > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
