On Sun, Feb 14, 2016 at 1:11 PM, Charles R Harris <charlesr.har...@gmail.com > wrote:
> > > On Sun, Feb 14, 2016 at 12:54 PM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> >> >> On Sun, Feb 14, 2016 at 12:35 PM, Nils Becker <nilsc.bec...@gmail.com> >> wrote: >> >>> 2016-02-13 17:42 GMT+01:00 Charles R Harris <charlesr.har...@gmail.com>: >>> >>>> The Fortran modulo function, which is the same basic function as in my >>>>> branch, does not specify any bounds on the result for floating >>>>> numbers, but gives only the formula, modulus(a, b) = a - b*floor(a/b), >>>>> which has the advantage of being simple and well defined ;) >>>>> >>>> >>>> >>> In the light of the libm-discussion I spent some time looking at >>> floating point functions and their accuracy. I would vote in favor of >>> keeping an implementation that uses the fmod-function of the system library >>> and bends it to adhere to the python convention (sign of divisor). There is >>> probably a reason why the fmod-implementation is not as simple as "a - >>> b*floor(a/b)" [1]. >>> >>> One obvious problem with the simple expression arises when a/b = 0.0 in >>> floating point. E.g. >>> >>> In [43]: np.__version__ >>> Out[43]: '1.10.4' >>> In [44]: x = np.float64(1e-320) >>> In [45]: y = np.float64(-1e10) >>> In [46]: x % y # this uses libm's fmod on my system >>> >> > I'm not too worried about denormals. However, this might be considered a > bug in the floor function > > In [16]: floor(-1e-330) > Out[16]: -0.0 > > However, I do note that some languages offer two versions of modulus, one floor based and the other trunc based (effectively fmod). What I wanted is to keep the remainder consistent with the floor function in the C library. Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
