# Why does floating point modulus exactness matters?

Most Smalltalk dialects currently implement a naive inexact floating modulus (fmod/remainder).
I just changed this to improve Squeak/Pharo and eventually other Smalltalk adherence to standards (IEEE 754, ISO/IEC 10967), as I already did for other state of the art floating point operations.

However for adoption of those changes, I anticipate that adhering to standard will not be enough to convince my peers, so explaining in which circumstances this exactness would really matter would help me a lot. I could not find a good example by myself so far.

Does any one here knows why/when/where (IOW in which algorithm) such exactness of modulus would matter?

• I think you might get better answers on Computational Science since such issues are more important in their (sub-)domain. In any case, the question is ontopic here and you should give our answerers a few days before reposting. – Raphael May 4 '14 at 10:36
• I've seen code relying on fmod/modf exactness which made me shudder, but the possibility that a language might dare to implement a naive inexact floating point modulus seems even more scary. Example code: (1) Take the remainder. (2) Stop if it is zero. (3) Multiply it by 2 and go to (1). One can do some useful work during this process, but the crucial point is that termination of this process relies on exactness of remainder and exactness of multiplication by 2. Not sure whether I should give a more complete answer here, because Computational Science seems more appropriate for this question. – Thomas Klimpel May 4 '14 at 12:41
• One guess: normalizing the input of a trigonometric function. – Paul A. Clayton May 4 '14 at 19:58
• @ThomasKlimpel I'm interested if you find references. Note that naive remainder is defined as (x - ((y/x) truncated * x)) with IEEE round to nearest even ops, we can prove that exactRem(x,y)==0 => naiveRem(x,y)==0. The problem is the contrary - false exact division positive - like naiveRem(4.0,0.1)==0.0 which unfortunately fits naive expectations in many cases! – aka.nice May 6 '14 at 15:06
• @PaulA.Clayton yes, for sine in degrees maybe... Though, my guess is that naive rem works equally well as exact rem up to approx. 1e16 degrees because 360 has only a range of 6 bits set, and because the division by 360 seems to never round up for predecessors of multiple of 360... For radians a decent library requires multiple precision, does an exact rem limited to double precision really help in such case? – aka.nice May 6 '14 at 17:42