Why does 1.4 - 0.5 result in 0.8999999999999999?

[Fredrik Celin]

I use IE 6.0 and does some calculations in a javascript.

If I run this code:
alert(1.4 - 0.5);

i get the result 0.8999999999 and not 0.9


Does anybody know why? Is this a bug in IE or what? Any fast and easy
ways to work around this problem?

B.R
The Duke

 

[Mabden]

I use IE 6.0 and does some calculations in a javascript.

If I run this code:
alert(1.4 - 0.5);

i get the result 0.8999999999 and not 0.9


Does anybody know why? Is this a bug in IE or what? Any fast and easy
ways to work around this problem?

Computers don't compute, sorry for any confusion. They can store a number in
memory, or retrieve a number from memory. They can also add one to a number,
or subtract one from a number. They can also add a number to another number.
That's about it.

 

[Grant Wagner]

Computers don't compute, sorry for any confusion. They can store a number in
memory, or retrieve a number from memory. They can also add one to a number,
or subtract one from a number. They can also add a number to another number.
That's about it.

That's not really an explanation for what he's experiencing. For example take:
0.05+0.01

The above operation probably involved storing number(s) in memory, retrieving
number(s) from memory and adding a number to another number. All of these things
are things you say a computer can do, yet the result is not equal to 0.06. In
fact, the outcome of the operation 0.05+0.01 has nothing to do with a computers
ability to "compute", it has to do with a computers ability to represent decimal
values in binary.

If the question the OP posed were phrased like this

"If I run this code alert(one-third + two-thirds); I get 0.999999999... and not
1"

It becomes obvious why this occurred if you change the representation of
"one-third" to 0.33333.... and "two-thirds" to 0.666666... 0.3333... +
0.6666... = 0.9999..., not 1. No one would suggest for a moment that the human
doing this math isn't "computing" right, or is only capable of storing numbers
in their brain and adding them.

It's simply an issue of representation and loss of precision.

As for the solution, the solution is to round the result to the appropriate
level of precision required for the task. If the numbers you are computing
involve money, it's usually best to do all your math using integers only (ie -
store the values as number of cents, or tenths of cents, or whatever level of
precision is required) and do the final formatting on output of the result. In
other words, don't add 0.05 dollars to 0.01 dollars. Add 6 cents to 1 cent, then
position the decimal point two digits from the right when outputting the result
(note: don't divide by 100, because you risk introducing the same problem you
are trying to avoid, instead, actually output the result as a string, with the
decimal point positioned when you require it).

--
| Grant Wagner <[email protected]>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/author/dhtml/reference/dhtml_reference_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-developer/upgrade_2.html

 

[Lee]

Fredrik Celin said:

I use IE 6.0 and does some calculations in a javascript.

If I run this code:
alert(1.4 - 0.5);

i get the result 0.8999999999 and not 0.9


Does anybody know why? Is this a bug in IE or what? Any fast and easy
ways to work around this problem?

The value I get is 0.8999999999999999

To put that result in perspective, the error is only slightly
more than 0.00000000000001 percent.

That same amount of error in measuring the distance around the
Earth at the equator would put you off by about one five-millionth
of an inch.

So you can see that the result is more than accurate enough for
any practical purpose. It just looks bad.
To make it look nice, you round it off, as described elsewhere.

 

[Dr John Stockton]

JRS: In article <[email protected]>, seen in

If the question the OP posed were phrased like this

"If I run this code alert(one-third + two-thirds); I get 0.999999999... and not
1"

It becomes obvious why this occurred if you change the representation of
"one-third" to 0.33333.... and "two-thirds" to 0.666666... 0.3333... +
0.6666... = 0.9999..., not 1. No one would suggest for a moment that the human
doing this math isn't "computing" right, or is only capable of storing numbers
in their brain and adding them.

It's simply an issue of representation and loss of precision.

Not a good example, since in javascript 1/3 + 2/3 gives exactly 1, and
numbers are NOT stored as decimals.

But (0.3 - 0.2) == 0.1 is false.

The OP should have read the newsgroup FAQ.

 

[Grant Wagner]

JRS: In article <[email protected]>, seen in


Not a good example, since in javascript 1/3 + 2/3 gives exactly 1, and
numbers are NOT stored as decimals.

Which is why I wrote "one-third" and "two-thirds", and not 1/3 and 2/3. My example
was to show the same errors he accuses computers of making because they "don't
compute" can occur when humans do the math: 1 + 2 = 3, 3/3 = 1; but 0.333... +
0.666... != 1. It has to do with how values are represented. A ratio of one over
three _exactly_ represents the value with nothing repeating or being an
approximation, whereas the decimal value of 1 divided by 3 can only be an
approximation and does not exactly represent the value of the ratio (and never can).

In the same way, some values stored in decimal can exactly represent a value (0.3 or
0.2), but when that same value is stored in binary, it can only be stored as an
approximation.

I can exactly store a value represented as "2 x sqrt(2)", but the resulting value
would most likely be an approximation in both decimal and binary. In fact, with
imaginary numbers, you can exactly represent values which you can not even
approximate in decimal (or binary).

Representation is all important.

The OP should have read the newsgroup FAQ.

The OP was directed to the FAQ, I was responding to someone who had responded to the
OP with a flippant "computers don't compute and that's why numbers don't get
calculated right" remark.

--
| Grant Wagner <[email protected]>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/author/dhtml/reference/dhtml_reference_entry.asp
* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-developer/upgrade_2.html

 

[Grant Wagner]

I should have said "integer" where I said "number", which is what I meant.
By saying 0.05, you are implying a division operation (5/100) which was not
one of the operations on my list.

Actually, I'm not implying anything. Computers are perfectly capable of storing
the binary approximation of 0.05 and the binary approximation of 0.01 and adding
them. The answer doesn't come out to 0.06 because the binary representations of
those decimal values are approximations in binary.

Whether a CPU can or can't do division is irrelevant.

The issue is that computers can't _exactly_ represent certain floating point
values, they can only _approximate_ them. With more bits you could more
accurately _approximate_ some decimal values, but they would still be
approximations and errors would still creep into calculations involving those
approximated values.

--
| Grant Wagner <[email protected]>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/author/dhtml/reference/dhtml_reference_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-developer/upgrade_2.html

 

[Lasse Reichstein Nielsen]

Which is why I wrote "one-third" and "two-thirds", and not 1/3 and
2/3. My example was to show the same errors he accuses computers of
making because they "don't compute" can occur when humans do the
math: 1 + 2 = 3, 3/3 = 1; but 0.333... + 0.666... != 1.

Ok, I didn't say anything the first time, but now I can't keep myself
from nitpicking any more

0.333... + 0.666... = 0.999... = 1

That is, if the "..." means an infinite repeating sequence of decimals.

It has to do with how values are represented. A ratio of one over
three _exactly_ represents the value with nothing repeating or being
an approximation, whereas the decimal value

(decimal *representation*)

of 1 divided by 3 can only be an approximation and does not exactly
represent the value of the ratio (and never can).
Yep.

In the same way, some values stored in decimal can exactly represent
a value (0.3 or 0.2), but when that same value is stored in binary,
it can only be stored as an approximation.

Yes. The problem is not the the base of the representation, but the
finiteness of it. While 0.3 has a finite representation in base 10, it
doesn't in base 2. Just as 1/3 doesn't have a finite representation in
base 10, but does in base 3 ("0.1").

I can exactly store a value represented as "2 x sqrt(2)", but the
resulting value would most likely be an approximation in both
decimal and binary. In fact, with imaginary numbers, you can exactly
represent values which you can not even approximate in decimal (or
binary).

Are you sure you mean *imaginary* numbers (because you sure can make
decimal/binary representations of some of those, usually as pairs of
numbers).

We can represent all integers precisely and finitely in a positional
number system with any integer base larger than 1 (although there is
no upper bound on the sizes of the representations, each one of them
is finite).

We can also represent all rational numbers precisely and finitely. The
representation can be a pair of integers. However, we cannot represent
all rational numbers finitly in a single positional number system, no
matter what base (>=2).

We cannot represent all real numbers finitly with a finite alphabet,
no matter how we allow definitions to be written (including arbitrary
prose prose with a one-billion letter alphabet).

Whoa... better get back on track.

The OP was directed to the FAQ, I was responding to someone who had
responded to the OP with a flippant "computers don't compute and
that's why numbers don't get calculated right" remark.

Thanks for answering that. I'm not sure I could ... coherently.

/L