fmod for Javascript, will work with any ECMA-262 implementation.If you need a precision higher than 8, please use another implementaion of fmod.

fmod.js

/*
fmod for Javascript, will work with any ECMA-262 implementation.
If you need a precision higher than 8, please use another implementation of fmod.

1.05 % 0.05
  => 0.04999999999999999

Math.fmod(1.05, 0.05)
  => 0

Math.fmod(1.05, 0.019)
  => 0.005

Math.fmod(1.00000012, 0.00000005)
  => 0.00000002

fmod will most likely fail, if (Math.log(a)/Math.log(10) - Math.log(b)/Math.log(10)) > 8
Try to keep the difference in order of magnitudes as small as possible!:
Math.fmod(1000000.40, 0.07)
  => 0.07

Math.fmod(10000000.40, 0.07)
  => 0.039999999
*/

/* TODO: fix for  a=4.55  b=0.05  !!*/

Math.fmod = function (a,b) { return Number((a - (Math.floor(a / b) * b)).toPrecision(8)); };

This is already available in standard ECMA-262 as a % b. Contrary to C or C++, where this is an integer operation only, in Javascript it works for any Number, just like fmod.

@stephanmantler Thanks, that's great!

When I created this gist more than 10 years ago, I didn't try to add functionality, a % b existed back then already too.
I tried to mitigate the obvious shortcoming when using floats, where
1.05 % 0.05 should be 0, but actually evaluated to 0.04999999999999999 in JS.
I tried both chrome console and node repl and I still see the same behavior today:

Can you confirm 1.05 % 0.05 is actually 0 using ECMA-262?

The code in this gist is by no means reliable. If you need fmod in your (financial!) calculations, make sure to use a library that provides that functionality, e.g. mathjs:

I hope that makes sense.

No, it has the same issue of course -- which is primarily due to 4.55 and 0.05 not having finite representations in binary. The general solution would be to accept one digit less in precision:

Which is, annoyingly, off by one as one can see but that is caught easily enough.

However, mathjs is not immune to these round-off errors either, although it is likely to show in different ways due to different algorithms or sequences of operations (so maths.mod may end up showing rounding errors in edge cases where % doesn't). And of course one can always switch to arbitrary precision through decimal.js if necessary.

Great, thanks for sharing 👍