An annoying JavaScript quirk
-
That has nothing to do with JavaScript specifically, it's how floating point numbers are stored. If you want a long explanation, try the Wikipedia article.[^] If you want a short answer, there is no way to represent 0.3 exactly as a floating point (which JS uses for all numbers).
Actually there is a rather short explanation by analogy: 0.3 cannot be represented exactly in binary for the same reasons that 1/3 cannot be represented in decimal - you'd need an endless number of digits.
-
Annoying; however, nothing important or critical should be left to JavaScript. :)
There are only 10 types of people in the world, those who understand binary and those who don't.
Unless you suggest symbolic programming (e. g. MatLab, Mathematica), there is no way to avoid that issue in any language. Which of the 10 types of people do you belong to? ;)
-
ryanb31 wrote:
nothing important or critical should be left to JavaScript
Err...who wants to break the news to Ryan? :~
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
So, curiosity got the better of me. Pleas explain. Javascript is uncompiled source code on the client. That means it can all be hacked, and somewhat easily too. Nothing critical of nature should be left to JS alone. Always validate server side. What part do you disagree with?
There are only 10 types of people in the world, those who understand binary and those who don't.
-
Actually there is a rather short explanation by analogy: 0.3 cannot be represented exactly in binary for the same reasons that 1/3 cannot be represented in decimal - you'd need an endless number of digits.
-
Except you did just represent it exactly in decimal: 1/3. There's also the 0.3 with a bar over the three. IEEE floating point does not support such notations though.
You are confusing 1/3 with 3/10th. The two are not the same. Actually the problem is 1/10th - which can't be accurately represented in binary floating point. (It can be represented in base_10 floating point - but base_10 floating point isn't perfect either. It can't represent 1/3.) The result is a rounding error on addition (1/10 + 1/10 + 1/10). Be very wary of doing financial calculations in base_2 floating point. It ALWAYS bites you eventually.
-
Except that Javascript isn't always run on the client. There is server-side javascript.
-
So, curiosity got the better of me. Pleas explain. Javascript is uncompiled source code on the client. That means it can all be hacked, and somewhat easily too. Nothing critical of nature should be left to JS alone. Always validate server side. What part do you disagree with?
There are only 10 types of people in the world, those who understand binary and those who don't.
Except that Javascript isn't always run on the client. There is server-side javascript.
-
You are confusing 1/3 with 3/10th. The two are not the same. Actually the problem is 1/10th - which can't be accurately represented in binary floating point. (It can be represented in base_10 floating point - but base_10 floating point isn't perfect either. It can't represent 1/3.) The result is a rounding error on addition (1/10 + 1/10 + 1/10). Be very wary of doing financial calculations in base_2 floating point. It ALWAYS bites you eventually.
-
So, curiosity got the better of me. Pleas explain. Javascript is uncompiled source code on the client. That means it can all be hacked, and somewhat easily too. Nothing critical of nature should be left to JS alone. Always validate server side. What part do you disagree with?
There are only 10 types of people in the world, those who understand binary and those who don't.
I was making a joke about how ubiquitous Javascript has become. From node.js to compiled JAvascript/HTML5 in Windows applications. Your statement that nothing important should be left to Javascript is now, unfortunately, ironic. It worries me. Not because I think there's anything inherently insecure about server side (or compiled) Javascript, it's just that, well, there are much, much better languages that guide (or even constrain) you into writing better, more maintainable and more efficient code.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
It's called floating point error. Ever look at floating point numbers in binary? Probably not, you young whippersnappers have never had to poke your noses behind the curtain. Just like decimals have certain precision problems (like 1/3), binary has the same problem, but for different numbers. 0.1 in floating point binary is a repeating value like 1/3 is. Modern calculators now have two extra guard digits that are used to round the values, so 1/3 *3 = 1 instead of 0.99999999... It depends on the math package as to how many digits are used versus reported. 0.1 = .0001000110011001100110011 (repeat the 0011 forever) in binary floating point.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
var j = 0; j += 0.1; j += 0.1; alert(j); // Alerts 0.2 j += 0.1; alert(j); // Take a guess
-= Reelix =-
Yup, this is why you always format floating point numbers before displaying them.
-
So what exactly is the precision-related quirk? I also notice that 0.8 and 0.9 exhibit the same behavior. Can you get around it by using
toFixed()?"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
Forget just 0.3, 0.8, and 0.9. It actually happens more often that it doesn't. I wrote a quick script that runs from 1 to 100 in 0.1 increments and more of them are wrong than right. See http://jsfiddle.net/txa9M/[^] UPDATE: Yes, you can get around it using
toFixed(1). See http://jsfiddle.net/txa9M/1/[^] -
0.30000000000000000004 :doh: (Chrome & Firefox)
Gryphons Are Awesome! Gryphons Are Awesome!
.30000000000000000004 is an 19 place accurate, 20 place number. real is 6 place, double is 12, a native 64 bit real would be 19 place. You're getting the most accurate version of the out of the box "real" numbers. To keep your "most" accurate answer, add 1 and when you render the result, it would be "result/10."