[Octave-bug-tracker] [bug #55238] Modulo [mod(X, Y)] of larger values seems to fail silently to output 0

[Michael Leitner]

Follow-up Comment #2, bug #55238 (project octave):

To the reporter: it is easily possible to answer what seems to be your issue
by providing a link to a document that is aptly named "What Every Computer
Scientist Should Know About Floating-Point Arithmetic":

https://www.itu.dk/~sestoft/bachelor/IEEE754_article.pdf

Octave (and Matlab, and numpy, and Julia...) is an environment for numerics,
not for arbitrary-precision arithmetics, so if you plan to use such software
in the future, you would do well to familiarize yourself with it.
Specifically, the argument to your modulo function is not 17^23 as an entity
in the ring of integer numbers (which you seem to suppose, as you use
number-theoretic tools to transform it), but rather is the closest-possible
approximation to it that can be represented as an IEEE-754 double. So for your
case of applied number theory, better use an environment with
arbitrary-precision arithmetics.

To the developers: Is there something to be done? The main issue of the
reporter is probably really that 17^23 is not what he expects it to be.
However, mod is also not exact in calculating the result of the actual
argument, because mod(2^100,3), which should be 1 ((-1)^100, as 2==-1(3)),
gives also zero. Most probably mod(a,b) just gives a-b*floor(a/b), and if a/b
is larger than bitmax, floor(x)==x. So this is an obvious condition which
could trigger a warning of lost precision in mod. Yes, sin and friends also do
not warn, but matrix inversion and friends do. Is this inconsistency a
deliberate choice (other than that Matlab does it also)?

By the way, there would be a way to do it exactly: repeatedly find the largest
n so that b*2^n<=a, and subtract this term from a, until n<=0. One could
special-case this in mod, any iteration should just take a few CPU cycles as
it involves only bit operations, and it should at worst only take 53
iterations.

    _______________________________________________________

Reply to this item at:

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

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