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
Updated•19 years ago

Comment 1•19 years ago


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 doubleprecision arithmetic will also give this result. This includes Java and most implementations of C and C++.
Changing component to "Javascript Engine". "Javascript" component is being retired.
Updated•18 years ago

Comment 3•18 years ago


Verified Invalid
Comment 4•13 years ago


*** Bug 251585 has been marked as a duplicate of this bug. ***
Comment 5•13 years ago


Note that ECMA262 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
Comment 6•13 years ago


*** Bug 281659 has been marked as a duplicate of this bug. ***
Comment 9•13 years ago


*** Bug 283303 has been marked as a duplicate of this bug. ***
Comment 10•12 years ago


*** Bug 297361 has been marked as a duplicate of this bug. ***
Comment 11•12 years ago


*** Bug 320093 has been marked as a duplicate of this bug. ***
Comment 12•11 years ago


*** Bug 356566 has been marked as a duplicate of this bug. ***
Updated•10 years ago

Comment 39•4 years ago


Duplicate of the Bug: 15* 1.33 (instead of expected 19.95 it return 19.950000000000003)
Comment 41•21 days ago


(37 + Math.pow(2, 1) + Math.pow(2, 3) + Math.pow(2, 5)) * 1e32 3.7656250000000003e31 in my string to number converter, it comes out without the 0000000003 error amount.
Comment 42•21 days ago


at least into the console.
Comment 43•21 days ago


reopen this bug?
Comment 44•21 days ago


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)) * 1e32 3.765625e31 but came out (37 + Math.pow(2, 1) + Math.pow(2, 3) + Math.pow(2, 5)) * 1e32 3.7656250000000003e31 in the 54.0.1 console.
Description
•