This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 3 years ago.
Why in the output, the length of decimals differ in these two scenarios?
33 * .1 = 3.3000000000000003
where as
33 * .01 = 0.33
Any idea why its like that?
NB: 33 in the above calculation can be any integer
When you convert .1 or 1/10 to base 2 (binary) you get a repeating
pattern after the decimal point, just like trying to represent 1/3 in
base 10. The value is not exact, and therefore you can't do exact math
with it using normal floating point methods.
This is the reason why you end up answer like above.
Related
This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 1 year ago.
Every time I do something like + 1.6 or something that's a decimal, I get a lot of random numbers spammed behind the result. how to avoid?
var test = 1.2345;
console.log(test.toFixed(2))
// It will trim the result to the specified decimal places.
// |----> output will be 1.23 in thid case... It will keep upto 2 decimal places
This question already has answers here:
javascript large integer round because precision? (why?)
(2 answers)
What is JavaScript's highest integer value that a number can go to without losing precision?
(21 answers)
Closed 7 years ago.
number 10205558742352809 gets reduced to 10205558742352808.
What?
TL;DR: Floating-point numbers can be screwy.
Long Answer
Javascript uses 64-bit floating point numbers (IEEE-754). The binary that makes up a floating point number is composed of 3 parts: sign bit (1 bit), exponent field (11 bits), and the significand field (52 bits). There are plenty of sources online that go into further detail about how this works.
If we convert 10205558742352809 to it's binary format then interpret that as hexadecimal for readability we get:
434220F367C941D4
Which is the same thing you'd get for 102...09. Compare that with 102...10:
434220F367C941D5
So 102...09 is not directly representable in IEEE-754 and in fact lies on the border between 102...08 and 102...10.
This question already has answers here:
parseInt rounds incorrectly
(2 answers)
Closed 7 years ago.
The parseInt function made my number loose precision: the last two digits changed from 18 to 20:
console.log(parseInt('76561198236425518', 10));
76561198236425520
Why did that happen and how to fix it?
Numbers are stored as floating point with a 53-bit manttissa. This limits the precision you can have to less than what you have in that number of yours, hence it has to round to the nearest floating point number it can represent.
The actual number of bits needed to represent a number N can be calculated as about log2N or, if you're working on a calculator that can't calculate logarithms to base two, logxN/logx2.
The value of log276561198236425518, roughly 56.1, shows that it requires about 56 bits, which is why it's not exact near the end.
This question already has answers here:
Is floating point math broken?
(31 answers)
Closed 8 years ago.
-224 / -37.333333333333336 = 6
-224 % -37.333333333333336 = -37.33333333333332
(-224 / -37.333333333333336) % 1 = 0
Why doesn't % return 0 if the first result is 6?
And why isn't the result a float in the third calculation?
All numbers in JavaScript are 64-bit floating point numbers. Just because it doesn't display the number as 0.0 doesn't mean it's not a double.
According to WolframAlpha:
-224 / -37.333333333333336 = 5.9999999999999995714285...
Due to accuracy limitations / rounding in floating point division, the division results in 6 in JavaScript.
The modulo operation, however, correctly sees that -37.3… doesn't quite fit into -224 six times. That means that the other 99.99…% of -37.33… is a leftover after the division, which corresponds to result of the modulo operation.
Hence, you get almost, but not quite, the divisor back.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Elegant workaround for JavaScript floating point number problem
I need a workaround for the fact that Javascript can't do floating math reliably due to the IEEE 754 standard from 1985 it uses. Basically, what I need is a way to evaluate an expression like 5+3*(2+8/6). I'm thinking of doing it with strings and rolling my own functions for basic operations (+-*/%), but I was wondering first if you know of any library that does this already.
It depends on how big the numbers are. For small numbers (e.g. fewer than 14 significant digits), rounding to acceptable precision may do the job. e.g. given your example:
var n = 0.5 / 5 + 1 / 5; // 0.30000000000000004
var p = Math.pow(10, 14); // where 14 is calculated based on the first
// significant digit and its relationship to
// the decimal place
n = Math.round(n * p) / p; // 0.3
Calculating the power of 10 to use shouldn't be that hard. If you have large numbers, then life is more difficult (see existing libraries).