99999999999999.99 problem in JavaScript
Mahsha
<HTML>
<HEAD>
<TITLE> New Document </TITLE>
</HEAD>
<BODY>
<SCRIPT LANGUAGE="JavaScript">
<!--
alert(99999999999999.99)
//-->
</SCRIPT>
</BODY>
</HTML>
output i expecting alert popup 99999999999999.99
But output is 99999999999999.98
WHY????
Thomas 'PointedEars' Lahn
> I tried following html code
> <HTML>
> <HEAD>
> <TITLE> New Document </TITLE>
<http://www.w3.org/QA/Tips/good-titles>
> </HEAD>
> <BODY>
> <SCRIPT LANGUAGE="JavaScript">
> <!--
Remove this.
> alert(99999999999999.99)
window.alert(...);
> //-->
Remove this.
> </SCRIPT>
> </BODY>
> </HTML>
>
> output i expecting alert popup 99999999999999.99
> But output is 99999999999999.98
> WHY????
Floating-point rounding and/or string representation of Number values.
Your keyboard appears to be borken. RTFM, RTFFAQ, STFW.
<http://jibbering.com/faq/#posting>
PointedEars
rf
Why do so many many people come into CLJ without a basic understanding on
how floating point arithmatic is implemented on computers? Then again not
just within javascript but with computers in general.
And it's not just here. I see the same over in the C and C++ and PHP groups
as well. People who simply do not understand how binary floating point
works. Nor for that matter how any [base] floating point works.
Header: Organization: http://groups.google.com
In this case I've got a fair idea why.
Jorge
1.- Because in JS decimal numbers are represented internally in binary
"IEEE754 fp double (binary64)" format: 53 bits long mantissa * 10 bits
exponent * 1 bit sign.
2.- Because 0.99 isn't a sum of powers of 2, it can't be represented
exactly in a binary format: the best approximation possible in 53 bits
is: "0.1111110101110000101000111101011100001010001111010111".
3.- As 99999999999999 occupies 47 bits of the 53 bits internally
available: "10110101111001100010000011110100011111111111111"...
4.- ... there are only 6 bits left for the fractional part, so .99
becomes "0.111111" that is : (2^-1) + (2^-2) + (2^-3) + (2^-4) +
(2^-5) + (2^-6) === 1/2 + 1/4 + 1/8 + 1/16 + 1/32 + 1/64 === 0,984375.
5.- You can check it yourself:
javascript:alert(99999999999999.99-99999999999999) //-> 0.984375
Reducing the integer part of the number would "leave more bits
available" for the fractional part:
(2 "nines" less:)
javascript:alert(999999999999.99-999999999999) //-> 0.989990234375
(closer to .99)
(4 "nines" less:)
javascript:alert(9999999999.99-9999999999) //-> 0.9899997711181641
(even closer)
(7 "nines" less:)
javascript:alert(9999999.99-9999999) //-> 0.9900000002235174 (even
closer)
etc.
You can "see" the numbers here:
http://jorgechamorro.com/cljs/016/
--
Jorge.
Dr J R Stockton
g2000vbp.googlegroups.com>, Wed, 1 Apr 2009 08:18:52, Jorge
<jo...@jorgechamorro.com> posted:
>1.- Because in JS decimal numbers are represented internally in binary
>"IEEE754 fp double (binary64)" format: 53 bits long mantissa * 10 bits
>exponent * 1 bit sign.
The exponent is 11 bits.
See <URL:http://www.merlyn.demon.co.uk/js-misc0.htm#DW4>,
<URL:http://www.merlyn.demon.co.uk/pas-real.htm>,
<URL:http://www.merlyn.demon.co.uk/pas-type.htm>.
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt> RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.
Jorge
wrote:
> In comp.lang.javascript message <11811341-7933-458a-9add-f9075802dd9d@r3
> g2000vbp.googlegroups.com>, Wed, 1 Apr 2009 08:18:52, Jorge
> <jo...@jorgechamorro.com> posted:
>
> >1.- Because in JS decimal numbers are represented internally in binary
> >"IEEE754 fp double (binary64)" format: 53 bits long mantissa * 10 bits
> >exponent * 1 bit sign.
>
> The exponent is 11 bits.
Yes I know. And the mantissa is made up of 52 explicit bits plus an
implicit (always-set-to-1) leading bit. Bus as that made it into a
longer explanation I chose to ~ cut it short. To know more he should
go to : http://www.google.com/search?&q=ieee754
--
Jorge.
Pietje Puk
...
Onyour page:
cljs thread
Tested in Safari, Opera, Mozilla(s), iCab : OK.
IE: don't even get me started...
Like yourself I am not a big IE fan (yep, understatement). But I tested
it in IE and it runs fine. Why your remark?
Mike Duffy
@cache100.multikabel.net:
> Tested in Safari, Opera, Mozilla(s), iCab : OK.
> IE: don't even get me started...
>
> Like yourself I am not a big IE fan (yep, understatement).
I made the switch last night to FF. Not due to any great preferences in
terms of function or speed, but I was starting to get vexed with that
message box:
"Sorry for the inconvenience .... Internet Explorer will be shut down."
I even tried re-installing IE7, but that did not help.
I wonder how many of the people who use FF do so simply because IE is
broken. If you look at global statistics from the "Statcounter" service,
it is clear that there are a lot of people who use IE weekdays and FF
weekends.
Jorge
It always goes like this: I write something, debug-test it in
webInspector/fireBug until it runs/renders fine in Safari/FireFox.
Then test it in Opera, Chrome, etc : it runs/renders fine there as
well. Then comes IE(x) and it fails, either the code or the rendering,
due to any of the (hundreds of) stupid bugs and/or non-compliant
behaviour in IE. Always the same story, ever. Grrr. It makes me
happier to ignore it all together. Unless it's strictly unavoidable.
--
Jorge.