[Webkit-unassigned] [Bug 9550] New: Different rounding behaviors of toFixed

bugzilla-daemon at opendarwin.org bugzilla-daemon at opendarwin.org
Thu Jun 22 17:04:30 PDT 2006


           Summary: Different rounding behaviors of toFixed
           Product: WebKit
           Version: 417.x
          Platform: PC
        OS/Version: Mac OS X 10.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: JavaScriptCore
        AssignedTo: webkit-unassigned at opendarwin.org
        ReportedBy: fick_el at yahoo.com

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
SAFARI: 0.04
IE7: 0.05
FF: 0.04
OP9: 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
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.

Configure bugmail: http://bugzilla.opendarwin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

More information about the webkit-unassigned mailing list