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
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.
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.
Any fix for this bug will likely need version-checking for backwards compatibility.
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.
Any update on this bug?