How can I deal with floating point number precision in JavaScript? [duplicate]

Question 1

I have the following dummy test script:

function test() {
 var x = 0.1 * 0.2;
 document.write(x);
}
test();

This will print the result 0.020000000000000004 while it should just print 0.02 (if you use your calculator). As far as I understood this is due to errors in the floating point multiplication precision.

Does anyone have a good solution so that in such case I get the correct result 0.02? I know there are functions like toFixed or rounding would be another possibility, but I'd like to really have the whole number printed without any cutting and rounding. Just wanted to know if one of you has some nice, elegant solution.

Of course, otherwise I'll round to some 10 digits or so.

Question 2

Actually, the error is because there is no way to map 0.1 to a finite binary floating point number.

Question 3

Most fractions can't be converted to a decimal with exact precision. A good explanation is here: docs.python.org/release/2.5.1/tut/node16.html

Question 4

@AaronDigulla: (new Number(0.1)).valueOf() is 0.1.

Question 5

@SalmanA: That your JavaScript runtime hides this problem from you doesn't mean I'm wrong.

Question 6

Disagree with Aaron, there are ways to code 0.1 perfectly and completely in binary. But IEEE 754 does not necessarily defines this. Imagine a representation where you would code the integer part in binary on the one hand, the decimal part on the other hand, up to n decimals, in binary too, like a normal integer > 0, and finally, the position of the decimal point. Well, you would represent 0.1 perfectly, with no error. Btw, since JS uses a finite number of decimals internally, they devs might as well coded the guts to not make that mistake on the last decimals.

Question 7

From the Floating-Point Guide:

What can I do to avoid this problem?

That depends on what kind of calculations you’re doing.

If you really need your results to add up exactly, especially when you work with money: use a special decimal datatype.

If you just don’t want to see all those extra decimal places: simply format your result rounded to a fixed number of decimal places when displaying it.

If you have no decimal datatype available, an alternative is to work with integers, e.g. do money calculations entirely in cents. But this is more work and has some drawbacks.

Note that the first point only applies if you really need specific precise decimal behaviour. Most people don't need that, they're just irritated that their programs don't work correctly with numbers like 1/10 without realizing that they wouldn't even blink at the same error if it occurred with 1/3.

If the first point really applies to you, use BigDecimal for JavaScript or DecimalJS, which actually solves the problem rather than providing an imperfect workaround.

Question 8

I noticed your dead link for BigDecimal and while looking for a mirror, I found an alternative called BigNumber: jsfromhell.com/classes/bignumber

Question 9

@bass-t: Yes, but floats can exactly represent integers up to the length of the significand, and as per ECMA standard it's a 64bit float. So it can exactly represent integers up to 2^52

Question 10

@Karl: The decimal fraction 1/10 cannot be represented as a finite binary fraction in base 2, and that's what Javascript numbers are. So it is in fact exactly the same problem.

Question 11

I learned today that even integers have precision problems in javascript. Consider that console.log(9332654729891549) actually prints 9332654729891548 (ie off by one!)

Question 12

@mlathe: Doh.. ;P... Between 25²=4,503,599,627,370,496 and 25³=9,007,199,254,740,992 the representable numbers are exactly the integers. For the next range, from 25³ to 254, everything is multiplied by 2, so the representable numbers are the even ones, etc. Conversely, for the previous range from 25¹ to 25², the spacing is 0.5, etc. This is due to simply increasing|decreasing the base|radix 2|binary exponent in/of the 64-bit float value (which in turn explains the rarely documented 'unexpected' behavior of toPrecision() for values between 0 and 1).

Question 13

I like Pedro Ladaria's solution and use something similar.

function strip(number) {
 return (parseFloat(number).toPrecision(12));
}

Unlike Pedros solution this will round up 0.999...repeating and is accurate to plus/minus one on the least significant digit.

Note: When dealing with 32 or 64 bit floats, you should use toPrecision(7) and toPrecision(15) for best results. See this question for info as to why.

Question 14

Any reason why you picked 12?

Question 15

toPrecision returns a string instead of a number. This might not always be desirable.

Question 16

parseFloat(1.005).toPrecision(3) => 1.00

Question 17

@user2428118, I know, I meant to show the rounding error, The outcome is 1.00 instead of 1.01

Question 18

What @user2428118 said may not be obvious enough: (9.99*5).toPrecision(2) = 50 instead of 49.95 because toPrecision counts the whole number, not just decimals. You can then use toPrecision(4), but if your result is >100 then you're out of luck again, because it'll allow the first three numbers and one decimal, that way shifting the dot, and rendering this more or less unusable. I ended up using toFixed(2) instead

Question 19

For the mathematically inclined: http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

The recommended approach is to use correction factors (multiply by a suitable power of 10 so that the arithmetic happens between integers). For example, in the case of 0.1 * 0.2, the correction factor is 10, and you are performing the calculation:

> var x = 0.1
> var y = 0.2
> var cf = 10
> x * y
0.020000000000000004
> (x * cf) * (y * cf) / (cf * cf)
0.02

A (very quick) solution looks something like:

var _cf = (function() {
 function _shift(x) {
 var parts = x.toString().split('.');
 return (parts.length < 2) ? 1 : Math.pow(10, parts[1].length);
 }
 return function() { 
 return Array.prototype.reduce.call(arguments, function (prev, next) { return prev === undefined || next === undefined ? undefined : Math.max(prev, _shift (next)); }, -Infinity);
 };
})();
Math.a = function () {
 var f = _cf.apply(null, arguments); if(f === undefined) return undefined;
 function cb(x, y, i, o) { return x + f * y; }
 return Array.prototype.reduce.call(arguments, cb, 0) / f;
};
Math.s = function (l,r) { var f = _cf(l,r); return (l * f - r * f) / f; };
Math.m = function () {
 var f = _cf.apply(null, arguments);
 function cb(x, y, i, o) { return (x*f) * (y*f) / (f * f); }
 return Array.prototype.reduce.call(arguments, cb, 1);
};
Math.d = function (l,r) { var f = _cf(l,r); return (l * f) / (r * f); };

In this case:

> Math.m(0.1, 0.2)
0.02

I definitely recommend using a tested library like SinfulJS

Question 20

Il love this elegant workaround but seems not to be perfect: jsfiddle.net/Dm6F5/1 Math.a(76.65, 38.45) returns 115.10000000000002

Question 21

Math.m(10,2332226616) is giving me "-19627406800" which is a negative value... I hope there must be a upper limit - might be that is causing this issue. Please suggest

Question 22

This all looks great, but seems to have a mistake or two in there somewhere.

Question 23

Very quick solution he said...broken fix no one ever said.

Question 24

this is really bad for performance

Question 25

Surprisingly, this function has not been posted yet although others have similar variations of it. It is from the MDN web docs for Math.round(). It's concise and allows for varying precision.

function precisionRound(number, precision) {
 var factor = Math.pow(10, precision);
 return Math.round(number * factor) / factor;
}
console.log(precisionRound(1234.5678, 1));
// expected output: 1234.6
console.log(precisionRound(1234.5678, -1));
// expected output: 1230

var inp = document.querySelectorAll('input');
var btn = document.querySelector('button');
btn.onclick = function(){
 inp[2].value = precisionRound( parseFloat(inp[0].value) * parseFloat(inp[1].value) , 5 );
};
//MDN function
function precisionRound(number, precision) {
 var factor = Math.pow(10, precision);
 return Math.round(number * factor) / factor;
}

button{
display: block;
}

<input type='text' value='0.1'>
<input type='text' value='0.2'>
<button>Get Product</button>
<input type='text'>

UPDATE: Aug/20/2019

Just noticed this error. I believe it's due to a floating point precision error with Math.round().

precisionRound(1.005, 2) // produces 1, incorrect, should be 1.01

These conditions work correctly:

precisionRound(0.005, 2) // produces 0.01
precisionRound(1.0005, 3) // produces 1.001
precisionRound(1234.5, 0) // produces 1235
precisionRound(1234.5, -1) // produces 1230

Fix:

function precisionRoundMod(number, precision) {
 var factor = Math.pow(10, precision);
 var n = precision < 0 ? number : 0.01 / factor + number;
 return Math.round( n * factor) / factor;
}

This just adds a digit to the right when rounding decimals. MDN has updated the Math.round() page so maybe someone could provide a better solution.

Question 26

wrong answer. 10.2 will always return 10.19. jsbin.com/tozogiwide/edit?html,js,console,output

Question 27

@Žilvinas The JSBin link you posted does not use the MDN function listed above. I think your comment is directed at the wrong person.

Question 28

would Math.ceil not account for that 0.01 in the same way (it's making it an integer and then casting back down to a float afaik)

Question 29

wow, thanks, this works great for what I needed, using a precision of about 12 with precisionRoundMod does the trick for my use cases!

Question 30

You can replace Math.pow(10, precision) to 10 ** precision.

Question 31

Are you only performing multiplication? If so then you can use to your advantage a neat secret about decimal arithmetic. That is that NumberOfDecimals(X) + NumberOfDecimals(Y) = ExpectedNumberOfDecimals. That is to say that if we have 0.123 * 0.12 then we know that there will be 5 decimal places because 0.123 has 3 decimal places and 0.12 has two. Thus if JavaScript gave us a number like 0.014760000002 we can safely round to the 5th decimal place without fear of losing precision.

Question 32

... and how to get the exact amount of decimal places.

Question 33

0.5 * 0.2 = 0.10; You can still truncate at 2 decimal places (or less). But there will never be a number with any mathematical significance beyond this law.

Question 34

Do you have a citation for this? Also note that the same is not true for division.

Question 35

Griffin: a citation (and more importantly, an easy to understand explanation): mathsisfun.com/multiplying-decimals.html and math.com/school/subject1/lessons/S1U1L5DP.html In essence: "Because when you (my addition: manually on paper) multiply without the decimal point, you are really shifting the decimal point to the right to get it out of the way (my addition: for each number)" so, # shifts for x plus # shifts for y.

Question 36

@NateZaugg you can't truncate the the overflowing decimals, you have to round the amount, because 2090.5 * 8.61 is 17999.205 but in float it's 17999.204999999998

Question 37

I'm finding BigNumber.js meets my needs.

A JavaScript library for arbitrary-precision decimal and non-decimal arithmetic.

It has good documentation and the author is very diligent responding to feedback.

The same author has 2 other similar libraries:

Big.js

A small, fast JavaScript library for arbitrary-precision decimal arithmetic. The little sister to bignumber.js.

and Decimal.js

An arbitrary-precision Decimal type for JavaScript.

Here's some code using BigNumber:

$(function(){ 
 var product = BigNumber(.1).times(.2); 
 $('#product').text(product);
 var sum = BigNumber(.1).plus(.2); 
 $('#sum').text(sum);
});

<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
<!-- 1.4.1 is not the current version, but works for this example. -->
<script src="http://cdn.bootcss.com/bignumber.js/1.4.1/bignumber.min.js"></script>
.1 &times; .2 = <span id="product"></span><br>
.1 &plus; .2 = <span id="sum"></span><br>

Question 38

Using a library is definitely the best choice in my opinion.

Question 39

From this link github.com/MikeMcl/big.js/issues/45 bignumber.js -> financial decimal.js -> scientific big.js -> ???

Question 40

This needs to be the accepted answer or another big decimal library

Question 41

You are looking for an sprintf implementation for JavaScript, so that you can write out floats with small errors in them (since they are stored in binary format) in a format that you expect.

Try javascript-sprintf, you would call it like this:

var yourString = sprintf("%.2f", yourNumber);

to print out your number as a float with two decimal places.

You may also use Number.toFixed() for display purposes, if you'd rather not include more files merely for floating point rounding to a given precision.

Question 42

I think this is the cleanest solution. Unless you really really need the result to be 0.02, the small error is negligible. It sounds like what's important is that your number is displayed nicely, not that you have arbitrary precision.

Question 43

For display this is indeed the best option, for complicated calculations, check Borgwardt's answer.

Question 44

But then again this will return exactly the same string as yourNumber.toFixed(2).

Question 45

var times = function (a, b) {
 return Math.round((a * b) * 100)/100;
};

---or---

var fpFix = function (n) {
 return Math.round(n * 100)/100;
};
fpFix(0.1*0.2); // -> 0.02

---also---

var fpArithmetic = function (op, x, y) {
 var n = {
 '*': x * y,
 '-': x - y,
 '+': x + y,
 '/': x / y
 }[op]; 
 return Math.round(n * 100)/100;
};

--- as in ---

fpArithmetic('*', 0.1, 0.2);
// 0.02
fpArithmetic('+', 0.1, 0.2);
// 0.3
fpArithmetic('-', 0.1, 0.2);
// -0.1
fpArithmetic('/', 0.2, 0.1);
// 2

Question 46

I think that would give the same problem as a result. You return a floating point so a big chance the return value will also be "incorrect".

Question 47

You can use parseFloat() and toFixed() if you want to bypass this issue for a small operation:

a = 0.1;
b = 0.2;
a + b = 0.30000000000000004;
c = parseFloat((a+b).toFixed(2));
c = 0.3;
a = 0.3;
b = 0.2;
a - b = 0.09999999999999998;
c = parseFloat((a-b).toFixed(2));
c = 0.1;

Question 48

Perhaps this code could use some comments, as it's a bit confusing to follow as is. Also, .toFixed() only works if you know exactly how many decimal places you need at the time. Sometimes you might want to keep a certain amount of significant digits without knowing the exact number of decimal places. In that case, use .toPrecision() instead of .toFixed().

Question 49

You just have to make up your mind on how many decimal digits you actually want - can't have the cake and eat it too :-)

Numerical errors accumulate with every further operation and if you don't cut it off early it's just going to grow. Numerical libraries which present results that look clean simply cut off the last 2 digits at every step, numerical co-processors also have a "normal" and "full" lenght for the same reason. Cuf-offs are cheap for a processor but very expensive for you in a script (multiplying and dividing and using pov(...)). Good math lib would provide floor(x,n) to do the cut-off for you.

So at the very least you should make global var/constant with pov(10,n) - meaning that you decided on the precision you need :-) Then do:

Math.floor(x*PREC_LIM)/PREC_LIM // floor - you are cutting off, not rounding

You could also keep doing math and only cut-off at the end - assuming that you are only displaying and not doing if-s with results. If you can do that, then .toFixed(...) might be more efficient.

If you are doing if-s/comparisons and don't want to cut of then you also need a small constant, usually called eps, which is one decimal place higher than max expected error. Say that your cut-off is last two decimals - then your eps has 1 at the 3rd place from the last (3rd least significant) and you can use it to compare whether the result is within eps range of expected (0.02 -eps < 0.1*0.2 < 0.02 +eps).

Question 50

You can also add 0.5 in order to do a poor man's rounding: Math.floor(x*PREC_LIM + 0.5)/PREC_LIM

Question 51

Note though, that e.g. Math.floor(-2.1) is -3. So perhaps use e.g. Math[x<0?'ceil':'floor'](x*PREC_LIM)/PREC_LIM

Question 52

Why floor instead of round?

Question 53

Notice that for the general purpose use, this behavior is likely to be acceptable.
The problem arises when comparing those floating points values to determine an appropriate action.
With the advent of ES6, a new constant Number.EPSILON is defined to determine the acceptable error margin :
So instead of performing the comparison like this

0.1 + 0.2 === 0.3 // which returns false

you can define a custom compare function, like this :

function epsEqu(x, y) {
 return Math.abs(x - y) < Number.EPSILON;
}
console.log(epsEqu(0.1+0.2, 0.3)); // true

Source : http://2ality.com/2015/04/numbers-math-es6.html#numberepsilon

Question 54

In my case Number.EPSILON was too small, which resulted in e.g. 0.9 !== 0.8999999761581421

Question 55

Number.EPSILON is useless as that value changes with the number. It works if the number is small enough. In a very large floating point number epsilon could get even above 1.

Question 56

decimal.js, big.js or bignumber.js can be used to avoid floating-point manipulation problems in Javascript:

0.1 * 0.2 // 0.020000000000000004
x = new Decimal(0.1)
y = x.times(0.2) // '0.2'
x.times(0.2).equals(0.2) // true

big.js: minimalist; easy-to-use; precision specified in decimal places; precision applied to division only.

bignumber.js: bases 2-64; configuration options; NaN; Infinity; precision specified in decimal places; precision applied to division only; base prefixes.

decimal.js: bases 2-64; configuration options; NaN; Infinity; non-integer powers, exp, ln, log; precision specified in significant digits; precision always applied; random numbers.

link to detailed comparisons

Question 57

how are "non-integer powers" a specific feature? it seems native Math.powi.e ** already handles that?

Question 58

The result you've got is correct and fairly consistent across floating point implementations in different languages, processors and operating systems - the only thing that changes is the level of the inaccuracy when the float is actually a double (or higher).

0.1 in binary floating points is like 1/3 in decimal (i.e. 0.3333333333333... forever), there's just no accurate way to handle it.

If you're dealing with floats always expect small rounding errors, so you'll also always have to round the displayed result to something sensible. In return you get very very fast and powerful arithmetic because all the computations are in the native binary of the processor.

Most of the time the solution is not to switch to fixed-point arithmetic, mainly because it's much slower and 99% of the time you just don't need the accuracy. If you're dealing with stuff that does need that level of accuracy (for instance financial transactions) Javascript probably isn't the best tool to use anyway (as you've want to enforce the fixed-point types a static language is probably better).

You're looking for the elegant solution then I'm afraid this is it: floats are quick but have small rounding errors - always round to something sensible when displaying their results.

Question 59

The round() function at phpjs.org works nicely: http://phpjs.org/functions/round

num = .01 + .06; // yields 0.0699999999999
rnum = round(num,12); // yields 0.07

Question 60

@jrg By convention, numbers ending with a "5" are rounded to the nearest even (because always rounding up or down would introduce a bias to your results). Therefore, 4.725 rounded to two decimal places should indeed be 4.72.

Question 61

To avoid this you should work with integer values instead of floating points. So when you want to have 2 positions precision work with the values * 100, for 3 positions use 1000. When displaying you use a formatter to put in the separator.

Many systems omit working with decimals this way. That is the reason why many systems work with cents (as integer) instead of dollars/euro's (as floating point).

Question 62

0.6 * 3 works fine:

function dec( num )
{
 var p = 100;
 return Math.round( num * p ) / p;
}

Question 63

Would this work though with something like 8.22e-8 * 1.3 ?

Question 64

0.6 x 3 = 1.8, the code you give results to 2... so not good.

score 613 · Accepted Answer · 2010-08-09 12:30:57Z

From the Floating-Point Guide:

What can I do to avoid this problem?

That depends on what kind of calculations you’re doing.

If you really need your results to add up exactly, especially when you work with money: use a special decimal datatype.

If you just don’t want to see all those extra decimal places: simply format your result rounded to a fixed number of decimal places when displaying it.

If you have no decimal datatype available, an alternative is to work with integers, e.g. do money calculations entirely in cents. But this is more work and has some drawbacks.

Note that the first point only applies if you really need specific precise decimal behaviour. Most people don't need that, they're just irritated that their programs don't work correctly with numbers like 1/10 without realizing that they wouldn't even blink at the same error if it occurred with 1/3.

If the first point really applies to you, use BigDecimal for JavaScript or DecimalJS, which actually solves the problem rather than providing an imperfect workaround.

I noticed your dead link for BigDecimal and while looking for a mirror, I found an alternative called BigNumber: jsfromhell.com/classes/bignumber
@bass-t: Yes, but floats can exactly represent integers up to the length of the significand, and as per ECMA standard it's a 64bit float. So it can exactly represent integers up to 2^52
@Karl: The decimal fraction 1/10 cannot be represented as a finite binary fraction in base 2, and that's what Javascript numbers are. So it is in fact exactly the same problem.
I learned today that even integers have precision problems in javascript. Consider that console.log(9332654729891549) actually prints 9332654729891548 (ie off by one!)
@mlathe: Doh.. ;P... Between 25²=4,503,599,627,370,496 and 25³=9,007,199,254,740,992 the representable numbers are exactly the integers. For the next range, from 25³ to 254, everything is multiplied by 2, so the representable numbers are the even ones, etc. Conversely, for the previous range from 25¹ to 25², the spacing is 0.5, etc. This is due to simply increasing|decreasing the base|radix 2|binary exponent in/of the 64-bit float value (which in turn explains the rarely documented 'unexpected' behavior of toPrecision() for values between 0 and 1).

CollectivesTM on Stack Overflow

How can I deal with floating point number precision in JavaScript? [duplicate]

46 Answers 46

Elegant, Predictable, and Reusable

The lack of precision in programming for floating point values

A possible solution: convert to integer, calculate, than back

Avoid dealing with floating points during the operation using Integers

Linked

Hot Network Questions