Bug 9550
| Summary: | Different rounding behaviors of toFixed | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | yz <fick_el> |
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | ap |
| Priority: | P2 | ||
| Version: | 417.x | ||
| Hardware: | PC | ||
| OS: | OS X 10.4 | ||
| URL: | javascript:alert(0.055.toFixed(2)) | ||
yz
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Alexey Proskuryakov
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 ***