[Octave-bug-tracker] [bug #45481] rem and fmod may give very wrong results for large arguments

[Rik]

Follow-up Comment #5, bug#45481 (group octave):

Adding jwe to the CC list.

Octave produces nonsensical results for mod/rem operations on extremely large
numbers.  Tracing this, I find that Octave has handrolled our own mod/rem
functions in lo-mappers.h.  For example,


template <typename T>
T
mod (T x, T y)
{
  T retval;

  if (y == 0)
    retval = x;
  else
    {
      T q = x / y;

      if (x_nint (y) != y
          && (std::abs ((q - x_nint (q)) / x_nint (q))
              < std::numeric_limits<T>::epsilon ()))
        retval = 0;
      else
        {
          T n = std::floor (q);

          // Prevent use of extra precision.
          volatile T tmp = y * n;

          retval = x - tmp;
        }
    }

  if (x != y && y != 0)
    retval = copysign (retval, y);

  return retval;
}


Is there any reason to do this?  It seems better to rely on C/C++ standard
libraries.  If I do, I find that


fmod (1e62, 10) = 4


which is not accurate in a pure math way (should be 0), but is consistent with
Matlab and Sage and is not purely silly like 1.1e46.

Can we just map these functions onto the standard libraries as we do with
trunc(), fix(), floor(), etc.?






    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?45481>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/