442273 - Number(String(x)) != x in some rare cases

Status: VERIFIED DUPLICATE of bug 510380

(Tamarin Graveyard :: Virtual Machine, defect, P4)

Description

[Brent Baker]

There seems to be an imprecision in the Number() method which causes differences when converting bewteen numbers to strings and back.

Example:
var n:Number = 24266.051846384562;
var s:String = n.toString();
var n2:Number = Number( s );
trace( n2, n - n2 );

//n2: 24266.05184638456
//Difference: 3.637978807091713e-12

This happens in both TT and TC

Comment 1

[Brent Baker]

There must be something in ecma-262 9.3.1 that I just don't understand which is causing this behavior. The last part of the section describes the rounding of numbers if there are more than 20 significant digits, which would cause this to happen, but there are only 17 significant digits.

var num:Number =  24266.051846384562;
var str:Number = "24266.051846384562";
trace("num: " + num);
trace("str: " + str);

output:
num: 24266.051846384562
str: 24266.05184638456

Comment 2

[Lars T Hansen]

But a double precision number only has 15 significant decimal digits, so there will be rounding even for shorter numbers.  And there are now several open bugs suggesting that the string->number and number->string conversions in Tamarin do not agree with other implementations.  (I have additional unlogged evidence for bugs in string->number conversions.)

Comment 3

[Zak Williamson]

The cases are not rare. If you generate random numbers between zero and 1, roughly 10.5% of the values fail to round trip successfully through the string representation.

Comment 4

[Dan Schaffer]

Attachment: vm testcase to regression test bug

Running 10,000 random numbers I reproduced about 5% of the numbers not working when toString() and converting back to Number.  Added a regression testcase we can add to TR.

Comment 5

[Dan Smith]

Notes from Chris Nuuja: We don’t use the David Gay code.   At the time we were worried about some legal issue or another.  In retrospect, his code is 10s of K bigger than ours (and we jump through hoops to save on download size for the player). 

We use Clinger’s alg for A2D. We use Robert G Burger and R. Kent Dybvig’s alg for D2A  http://www.cs.indiana.edu/~burger/FP-Printing-PLDI96.pdf  

 This is just a bug, not an oversight.  This usually ends up being somewhere in the BigInteger (and infinite precision integer) divide.  Or possibly with some build env change to the FPU mode, or some rendering code that alters the FPU control word and forgets to set it back.

Comment 6

[Zak Williamson]

Attachment: Floating Pointer toString Drift Example App

A little Flex app that allows you to try different ranges of values and get an idea of how often the round trip x == Number(x.toString()) succeeds or fails.

Comment 7

[Zak Williamson]

Attachment: Source for the example app

Comment 8

[Zak Williamson]

I'm still seeing a higher failure rate than Dan above (at least with Player 10.0.22.87).

Nearly 100% of Numbers that cause toString to output scientific notation fail to round trip.

7 to 11% of those output as decimal fail to round trip, including examples such as 1/11th.

Comment 9

[Dan Smith]

Targeting for 10.1

Comment 10

[Lars T Hansen]

(Poaching.)

Comment 11

[Lars T Hansen]

(In reply to comment #5)
> 
> We use Clinger’s alg for A2D.

This is not the case.  We use a naive algorithm; Clinger's algorithm is noted in the code as "to be implemented".

Comment 12

[Lars T Hansen]

See information on bug #521196: there is no evidence that toString is broken, the problem is the Number parser.

Comment 13

[Chris Peyer]

Verified dupe.  Also removing in-testsuite flag as dupe bug also has flag set.