Just to give one example 14.28 x 9 should be 128.52; your browser's answer = 128.51999999999998 This bug is also from Netscape 4.5
Status: NEW → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → INVALID
ECMAScript requires the use of IEEE double precision for numbers. 14.28 correctly rounded as an IEEE double is represented as 1.1100100011110101110000101000111101011100001010001111e3 in base 2, which is exactly equal to 14.2799999999999993605115378159098327159881591796875 decimal. Multiplying this value by 9 yields exactly 128.5199999999999942446038403431884944438934326171875. Per the ECMA spec, this is again rounded to the nearest IEEE double, which is 1.0000000100001010001111010111000010100011110101110000e7 base 2, or 128.51999999999998181010596454143524169921875 decimal. Why does the result print as 128.51999999999998? Well, the ECMA spec requires numbers to be printed with sufficient precision (and no more than that precision) so that if the printed string were read in again and converted back to a number, it would round to exactly the same IEEE double that was printed. Printing 128.52 would be incorrect because the rounding 128.52 to the closest IEEE double yields 128.520000000000010231815394945442676544189453125, which is closer than 128.51999999999998181010596454143524169921875. Thus we must print 128.51999999999998. Every other language that uses standard IEEE double-precision arithmetic will also give this result. This includes Java and most implementations of C and C++.
*** Bug 251585 has been marked as a duplicate of this bug. ***
Note that ECMA-262 Edition 3 added Number.prototype.toFixed, which takes a precision argument telling how many digits after the decimal point to show. Use this method well and you won't mind the disparity between finite precision base 2 and the "arbitrary" or "appropriate" precision base 10 that we use every day. /be
*** Bug 281659 has been marked as a duplicate of this bug. ***
*** Bug 20140 has been marked as a duplicate of this bug. ***
*** Bug 1813 has been marked as a duplicate of this bug. ***
*** Bug 283303 has been marked as a duplicate of this bug. ***
*** Bug 297361 has been marked as a duplicate of this bug. ***
*** Bug 320093 has been marked as a duplicate of this bug. ***
*** Bug 356566 has been marked as a duplicate of this bug. ***
Duplicate of this bug: 480475
Duplicate of this bug: 624189
Duplicate of the Bug: 15* 1.33 (instead of expected 19.95 it return 19.950000000000003)
(37 + Math.pow(2, -1) + Math.pow(2, -3) + Math.pow(2, -5)) * 1e-32 3.7656250000000003e-31 in my string to number converter, it comes out without the 0000000003 error amount.
at least into the console.
reopen this bug?
by the way, the representation of the mantissa is best represented in binary form (base 2). so that's what I have done. even successive adds above have not deterred my converter from coming out with the right result. does the debugger contain an old/defective IEEE in its JS engine? I don't know if it uses its own JS engine or whether it uses the browser's. to me it's only important to get right results. this should come out this should come out (37 + Math.pow(2, -1) + Math.pow(2, -3) + Math.pow(2, -5)) * 1e-32 3.765625e-31 but came out (37 + Math.pow(2, -1) + Math.pow(2, -3) + Math.pow(2, -5)) * 1e-32 3.7656250000000003e-31 in the 54.0.1 console.
same problem with: $('.chnagenumber').val()--> "3" $('.chnagenumber').val()*0.0001 --->"0.00030000000000000003" my dirty solution: alert(((0.0001*3)*1000000000000)/1000000000000); it display 0.0003 correcty https://en.wikipedia.org/wiki/IEEE_754
You need to log in before you can comment on or make changes to this bug.