478787 - parseFloat() does not convert string into number correctly

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Virtual Machine, defect)

Description

[Jeff Dyer]

Description:
The perseFloat() function does not convert long digits' string 
into number correctly.

Steps:
1. Write the frame action below:

var test0_str:String = "1.20000000000000e+51";
var n0:Number = parseFloat(test0_str);
trace(n0);
trace(n0 == (1.20000000000000e+51));
trace(n0-(1.20000000000000e+51));

2. See the result in the [Output] panel

actual results:
// [Output]:
1.20000000000000e+51
false
1.66153499473114e+35

expected results:
// [Output]:
1.20000000000000e+51
true
0

The result of ActionScript 2.0 seems to be correct.

// [Output]:
1.2e+51
true
0

Also if one digit is decreased, the result will come to be all 
right.

var test1_str:String = "1.2000000000000e+51";
var n1:Number = parseFloat(test1_str);
trace(n1 == (1.2000000000000e+51));
trace(n1-(1.2000000000000e+51));
// [Output]:
true
0
        
        
        
        
        
        
Transferred Comments:

BugDB Migration - Mon Jun 04 12:33:03 CDT 2007
[Fumio Nonaka 3/5/07]  Entered Bug.
[mdomingu 3/6/07] x'ferred to Auth. PFR to Tareq to triage.
[taljaber 3/15/07] For Nivesh to triage. i was able to reproduce it  with r486.
[taljaber 3/15/07] sorry sending it to QRB

[nrajbhan 3/19/07] Changed to All desktop platforms and few users will encounter.
[nrajbhan 3/19/07] The following incompatible language(s) were automatically confirmed when this bug was transferred to AS3 Compiler and VM:
Japanese

[nrajbhan 3/19/07] Transferred to Compiler bugbase.  Note that AS 2 handles this case correctly.
[ssubrama 4/16/07] Reproduced the bug with  avmplus d695.  Sending to QRB
[dansmith 4/24/07] Rick, is this  an incompatibility that we should be concerned with -- is this pointing to a significant difference or a minor change.

JIRA Migration Admin - Mon Jun 04 12:33:03 CDT 2007
Milestone ID = 1378
Milestone = FP 10 - Code Complete
Build ID = 24343
Build = AVMPLUS_1_0_0_d695
Fix Build ID = null
Fix Build = null


JIRA Migration Admin - Mon Jun 04 12:33:03 CDT 2007
Move from BugDB issue number 200343

Trevor Baker - Tue Jan 27 16:40:46 CST 2009
send to internal review for prioritization


This bug transferred from: http://bugs.adobe.com/jira/browse/ASC-2300

Comment 1

[Michael Daumling]

I'll check it out.

Comment 2

[Dan Smith]

QE: Is this bug an injection?

Comment 3

[Michael Daumling]

It is - quickPowTen() returns the "bad" value. Unfortunately, any other algorithm that is available has the very same problem. I've tried my own algorithm, which is BTW faster than the built-in algorithm, but with the same result. The problem is, simply put, that certain values, like 1e32, cannot be expressed exactly. Especially that value introduces the digit 1 as the last digit, and there is no way around this as far as I can see.

Please advise what to do.

Comment 4

[Lars T Hansen]

Dan: Is this an injection since when?  (Comparisons to AS2 not relevant IMO, since AS2 presumably uses the platform libs, not the AS3 libs, for parseFloat.)

Again, my recommendation is to rip out the string->number and number->string code in Tamarin and import David Gay's code from netlib en masse (relatively substantial job, get dtoa.c and g_fmt.c from http://www.netlib.org/fp/), as we have a number of bugs related to conversion in either direction.  I think I've written a larger comment on this elsewhere.  Quick recap: See Clinger's PLDI 1990 paper for string->number; Steele+White's PLDI 1990 paper for number->string, with update by Burger+Dybvig PLDI 1996.  All of this research is incorporated in Gay's code, I believe.

Comment 5

[Michael Daumling]

I doubt whether using the netlib routines would fix this problem. I have checked the bit patterns on my Windows machine:

1) Computed during parseFloat():e7 96 3d 28 96 a8 89 4a == 1.2000000000000001e+051
2) Compiler-generated value:    e6 96 3d 28 96 a8 89 4a == 1.9999999999999999e+051

The problem is IMHO that the compiler generates a different pattern (the last bit is different) than the AVM. It may be helpful to ensure that both the compiler and the AVM use the same conversion algorithm.

Finally, it may make sense to limit the precision of the double to ASCII conversion to 15 digits, and round the last digit.

Comment 6

[Michael Daumling]

Typo: the ASC-generated value is 1.1999999999999999e+051

Comment 7

[Michael Kohler [:mkohler]]

This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.

Comment 8

[Shannon Hickey]

Some additional test cases that I've come across that are affecting our product (FormsCentral/Acrobat.com). The expected result is that all comparisons are true. The actual results are true, true, true, false, false, false, false, false, false.

For contrast, the same test in Java provides all trues.

var first:Number = 1.23456789E+30;
var a:Number = parseFloat("1.23456789E+30");
var b:Number = parseFloat("1234567890000000000000000000000");
var c:Number = parseFloat("1234567890000000000000000000000.0");
var d:Number = parseFloat("1234567890000000000000000000000.00");
var e:Number = parseFloat("1234567890000000000000000000000.000");
trace(a == first);
trace(b == first);
trace(c == first);
trace(d == first);
trace(e == first);

var second:Number = 1E+99;
var f:Number = parseFloat("1E+99");
var g:Number = parseFloat("1.00E+99");
trace(f == second);
trace(g == second);

var third:Number = 9e299;
var h:Number = parseFloat("9E+299");
var i:Number = parseFloat("900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.00");
trace(h == third);
trace(i == third);

Comment 9

[Sylvestre Ledru [:Sylvestre]]

Tamarin is a dead project now. Mass WONTFIX.

Comment 10

[Sylvestre Ledru [:Sylvestre]]

Tamarin isn't maintained anymore. WONTFIX remaining bugs.