350936 - Incorrect results from Number.toFixed() for large negative integer values

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Travers Carter]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.6) Gecko/20060808 Fedora/1.5.0.6-2.fc5 Firefox/1.5.0.6 pango-text; NG_Developer
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.6) Gecko/20060808 Fedora/1.5.0.6-2.fc5 Firefox/1.5.0.6 pango-text

The Number.toFixed() function in javascript gives incorrect results for large negative integer values.

The problem appears to be unrelated to the requested number of decimal places.
The problem is present in v2.0b1
The problem occurs on Linux i386, Linux x86-64, Windows i386 and Mac OS X PPC



Reproducible: Always

Steps to Reproduce:
1. javascript:alert(Number(-46957322767296060).toFixed(0));



Actual Results:  
Number(-4048045066146212400).toFixed(0)
> "-4048045066146212352"

Number(-46957322767296060).toFixed(3)
> "-46957322767296064.000"

Expected Results:  
Number(-4048045066146212400).toFixed(0)
> "-4048045066146212400"

Number(-46957322767296060).toFixed(3)
> "-46957322767296060.000"

Comment 1

[Steve England [:stevee]]

Reporter, do you still see this problem with the latest Firefox 2? If not, can you please close this bug as WORKSFORME. Thanks!

Comment 2

[Travers Carter]

Yes the problem is still present in at least:
 - Firefox 2.0.0.3 (Linux x86)
 - Firefox 2.0.0.4 (Windows XP x86)

Comment 3

[Steve England [:stevee]]

I've punted this over to Core:Javascript.
In the mean time, could you please try a trunk builds.
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment 4

[Travers Carter]

I can reproduce the problem on 3.0a6pre on Linux x86

Comment 5

[Brian Crowder]

Brief testing shows this to be fixed in newer dtoa library, will test more as I close in on integration.

Comment 6

[Robert Jurd]

I can produce the following on 2.0.0.11 release

Any number ending in .995

Number(8.995).toFixed(2);
> 8.99

Comment 7

[Bob Clary [:bc] (inactive)]

(In reply to comment #6)

> Number(8.995).toFixed(2);
> > 8.99

That is expected from the step in 15.7.4.5  Number.prototype.toFixed(fractionDigits) and as far as I can see is unrelated to this bug.

Comment 8

[Robert Jurd]

I'm not sure what you mean by expected... the function is returning incorrect results for a given number which is what this bug is about

Comment 9

[Brendan Eich [:brendan]]

(In reply to comment #8)
> I'm not sure what you mean by expected... the function is returning incorrect
> results for a given number which is what this bug is about

Wrong on both points. Did you read the summary ("for large negative integer values") or comment 0? As for "incorrect results", follow bclary's pointer to ECMA-262 Edition 3 15.7.4.5, and note how other browsers agree.

/be

Comment 10

[Robert Jurd]

Ok no point debating that here but I can't believe you guys have gone along with it, no mathematical sense what so ever...

Comment 11

[x0]

I don't see a bug here (and no different behavior for negative than for positive numbers).

4048045066146212400 is in binary

  2^61                                                2^9
  v                                                   v
  11100000101101100010111000101001001010011010101110101000110000

and will be rounded to

  11100000101101100010111000101001001010011010101110101000000000

(4048045066146212352) to fit into a IEEE 754 double, which has a 53 bit mantissa. So "-4048045066146212352" is what I would expect for (-4048045066146212400).toFixed(0).

Note that toString() happens to round the value back to 4048045066146212400 in decimal, but (4048045066146212300).toString() is "4048045066146212400" too.

46957322767296060 is in binary

  2^55                                                2^3
  v                                                   v
  10100110110100110110111110101111001001011110011000111100

and will be rounded to

  10100110110100110110111110101111001001011110011001000000

(46957322767296064; round to even, which is upwards here). Thus, "-46957322767296064.000" is the correct result for (-46957322767296060).toFixed(3).

Comment 12

[Brian Crowder]

I agree with x0.  Please reopen if you a convincing counterargument.