octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #45481] rem and fmod may give very wrong resul


From: Rik
Subject: [Octave-bug-tracker] [bug #45481] rem and fmod may give very wrong results for large arguments
Date: Fri, 12 Jan 2024 18:52:17 -0500 (EST)

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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]