9550 2006-06-22 17:04:29 -0700 Different rounding behaviors of toFixed 2006-06-22 22:01:03 -0700 1 1 1 Unclassified WebKit JavaScriptCore 417.x PC OS X 10.4 RESOLVED DUPLICATE 5307 javascript:alert(0.055.toFixed(2)) P2 Normal --- 0 fick_el webkit-unassigned ap oldest_to_newest 46754 0 fick_el 2006-06-22 17:04:29 -0700 toFixed(n) will round to the nearest number with n digits, however inconsistencies begin to occur when the number is exactly halfway between two possible results. When it is halfway the "standard" behavior is to round away from zero (up in a positive number, down in a negative one). ECMA-262, being based on IEEE 754, cannot truly represent some numbers (such as 0.045), so they are being rounded to 0.04: Using 0.045.toFixed(2) Safari "gets it right", assuming IEEE 754 number representation: SAFARI: 0.04 IE7: 0.05 FF: 0.04 OP9: 0.04 KONQUEROR: 0.04 MINEFIELD: 0.04 ICAB: 0.05 However, using 0.055.toFixed(2) Safari is pretty much the odd browser out (0.05 instead of 0.06): SAFARI: 0.05 IE7: 0.06 FF: 0.06 OP9: 0.06 KONQUEROR: 0.06 MINEFIELD: 0.06 ICAB: 0.06 So IE (and ICAB?) "correctly" round up regardless of IEEE 754 binary representation, FF/OP/KONQ round up based on IEEE 754, so naturally they all make the same consistent "mistakes". But Safari's results are sometimes inconsistent with those of others based on IEEE 754. 46762 1 ap 2006-06-22 22:01:03 -0700 I cannot reproduce this problem with current WebKit (http://nightly.webkit.org>. Most likely, fixed in bug 5307. *** This bug has been marked as a duplicate of 5307 ***