JRS: In article <40***********************@news.skynet.be>, seen in
news:comp.lang.javascript, Tim Fooy <th*****@invalid.com> posted at Wed,
28 Apr 2004 13:25:13 :
No, it is not a bug. The reason for this result is the fact that the
internal representation of a float (which follows IEEE 754 standard) is
limited to 7 correct digits, because of the limitation to 32 bits. See e.g.
http://research.microsoft.com/~holla...ieeefloat.html (that
looks correct to me, i haven't read it all)
If you want a higher precision, you'll have to use a double precision
floating point variable, but i don't know whether this exists in javascript.
What you write would be true if Numbers in javascript were represented
by IEEE Singles. They are represented by IEEE Doubles.
Although the OP only gets 7 digits as desired, the error is actually of
the order of 1 in 1E16.
I cannot explain why the OP gets 31.992185999999997 ; ISTM that one gets
31.992185999999996.
The OP could have tested +"10.664062" + +"10.664062" + +"10.664062" or
10.664062 + 10.664062 + 10.664062 or 3*10.664062 all of which
give me 31.992185999999996 - which shows that the matter has nothing
to do with parseFloat.
The OP should have read the FAQ, specifically Sec 4.7, and what it links
to and/or my site and/or many others.
Try 0.2 + 0.4 and 0.1 + 0.7.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.