An annoying JavaScript quirk
-
0.30000000000000000004 :doh: (Chrome & Firefox)
Gryphons Are Awesome! Gryphons Are Awesome!
-
var j = 0; j += 0.1; j += 0.1; alert(j); // Alerts 0.2 j += 0.1; alert(j); // Take a guess
-= Reelix =-
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).
-
0.30000000004 (give or take a few "0"s) It's something to do with the binary representation of the floating-point number, and it catches a lot of people out the first time they run into it.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
var j = 0; j += 0.1; j += 0.1; alert(j); // Alerts 0.2 j += 0.1; alert(j); // Take a guess
-= Reelix =-
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
-
var j = 0; j += 0.1; j += 0.1; alert(j); // Alerts 0.2 j += 0.1; alert(j); // Take a guess
-= Reelix =-
Ahhh, floating point issues. Doncha just love them. I'd imagine it was something slightly outside of 0.30000.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
var j = 0; j += 0.1; j += 0.1; alert(j); // Alerts 0.2 j += 0.1; alert(j); // Take a guess
-= Reelix =-
That is why 99% of all non-trivial code involving floating point numbers is wrong. Ok no, but close enough: the actual reason is that people don't expect it to work like this. They expect "math the way they learned it in school". An other problem is that usually the result is close enough that it's not obviously wrong (debuggers play a part in this too, by printing floats "nicely" rather than printing their actual value), so no one notices until suddenly everything breaks down.
-
var j = 0; j += 0.1; j += 0.1; alert(j); // Alerts 0.2 j += 0.1; alert(j); // Take a guess
-= Reelix =-
-
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.
-
var j = 0; j += 0.1; j += 0.1; alert(j); // Alerts 0.2 j += 0.1; alert(j); // Take a guess
-= Reelix =-
I don't see why you think that this is a JavaScript quirk? JavaScript uses single precision floating point numbers, so you should be aware of rounding errors as usual.
-
Tell that to the HTML5 spec :p JS is growing, and more and more stuff is being ported to JS due to WebGL :p
-= Reelix =-
I don't see what the HTML5 spec has to do with that. JS is not part of the HTML5 spec - it just defines a common interface (called the DOM) which could be accessed by programming languages. In fact the most common language to access the DOM is JavaScript - because most browsers implemented this (and sometimes only this) language.
-
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.
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
-
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
-
var j = 0; j += 0.1; j += 0.1; alert(j); // Alerts 0.2 j += 0.1; alert(j); // Take a guess
-= Reelix =-
That's a common problem with programming (Java and others)... then you end up comparing values by checking that its difference is smaller than the approximation you end up having there... X|
[www.tamautomation.com] Robots, CNC and PLC machines for grinding and polishing.
-
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.
