The number parser is naive and imprecise

NEW
Unassigned

Status

Tamarin
Virtual Machine
P2
major
8 years ago
3 years ago

People

(Reporter: Chris Peyer, Unassigned)

Tracking

(Blocks: 1 bug)

unspecified
Q1 12 - Brannan
x86
All
Dependency tree / graph
Bug Flags:
in-testsuite ?
flashplayer-injection -
flashplayer-qrb +
flashplayer-bug +
flashplayer-needsversioning +

Details

(Reporter)

Description

8 years ago
I am parsing a very large number (1e300) that comes in as a string (via socket connection). It seems to initialize a Number data type just fine, bot for some reason, it's not equal to a Number variable that was initialized with 1e300 directly. Also, the two variables print differently when passed to trace (as seen below).

Steps to reproduce:

var num1:Number = 1e300;
var num2:Number = Number("1e300");
trace(num1 == num2)
trace(num1);
trace(num2);
trace(num2-num1);
 
 Actual Results:

false
1e+300
1.00000000000000e+300
5.94806763391113e+284
 
 Expected Results:

true
1e+300
1e+300
0 

This bug transferred from: http://bugs.adobe.com/jira/browse/ASC-3693
(Reporter)

Updated

8 years ago
Flags: in-testsuite?
Flags: flashplayer-qrb?

Updated

8 years ago
Priority: -- → P3
Target Milestone: --- → flash10.1

Updated

8 years ago
Flags: flashplayer-qrb? → flashplayer-qrb+

Updated

8 years ago
Blocks: 521196

Updated

8 years ago
Assignee: nobody → lhansen

Comment 1

8 years ago
There are errors in the last places of the number returned by the number parser.  The number parser returns this value for 1e+300:

7e37e43c880075a0

whereas ASC produces this value for 1e+300:

7e37e43c8800759c

The underlying reason appears to be that the number parser does not implement the machinery that's necessary for avoiding this loss of precision.

Updated

8 years ago
Summary: very large number initialized from a string doesn't match the same number created directly. → The number parser is naive and imprecise

Updated

8 years ago
Blocks: 442273

Updated

8 years ago
Duplicate of this bug: 442273

Comment 3

8 years ago
There is a little more information attached to bug #442273.  Specifically, we do not implement Clinger's algorithm for parsing floating-point algorithms, we use a naive algorithm that computes 1.0 and 10^300 and multiplies the two together.  To do better, we need to implement Clinger's algorithm.
Status: NEW → ASSIGNED

Comment 4

8 years ago
Any fix for this bug will likely need version-checking for backwards compatibility.

Updated

8 years ago
Flags: flashplayer-needsversioning+

Updated

8 years ago
Target Milestone: flash10.1 → Future

Updated

8 years ago
Assignee: lhansen → nobody
Priority: P3 → --
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.
Status: ASSIGNED → NEW

Updated

8 years ago
Priority: -- → P2
Target Milestone: Future → flash10.2

Updated

7 years ago
Flags: flashplayer-bug+
Whiteboard: must–fix-candidate

Updated

7 years ago
Whiteboard: must–fix-candidate → must-fix-candidate

Updated

7 years ago
Flags: flashplayer-injection-
Whiteboard: must-fix-candidate
Target Milestone: Q3 11 - Serrano → Q1 12 - Brannan

Comment 6

3 years ago
Any update on this bug?
You need to log in before you can comment on or make changes to this bug.