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

[bugzilla-daemon at opendarwin.org]

http://bugzilla.opendarwin.org/show_bug.cgi?id=9550

           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
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.


-- 
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.