Skip to content

Instantly share code, notes, and snippets.

@wteuber
Last active February 6, 2024 14:47
Show Gist options
  • Save wteuber/6241786 to your computer and use it in GitHub Desktop.
Save wteuber/6241786 to your computer and use it in GitHub Desktop.
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 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)); };
@stephanmantler
Copy link

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.

@wteuber
Copy link
Author

wteuber commented Feb 1, 2024

@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:
image

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:
image

I hope that makes sense.

@stephanmantler
Copy link

stephanmantler commented Feb 1, 2024

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:

Screenshot 2024-02-01 at 17 43 11

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.

@wteuber
Copy link
Author

wteuber commented Feb 6, 2024

Great, thanks for sharing 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment