Closed
Bug 699463
Opened 13 years ago
Closed 13 years ago
[Test media] flt.toString() != String(Number(flt)) when flt is float.MAX_VALUE
Categories
(Tamarin Graveyard :: Virtual Machine, defect, P4)
Tracking
(Not tracked)
VERIFIED
FIXED
Q2 12 - Cyril
People
(Reporter: brbaker, Assigned: brbaker)
References
Details
Both are really the same value as far as float is concerned; the real question is why String(Number(v)) is (slightly) different than String(v). To investigate. Code: var v:float = float.MAX_VALUE; print(v.toString()); print(String(Number(float.MAX_VALUE))); print(v.toString() == String(Number(float.MAX_VALUE))); Output, notice the extra digit in the value that went through Number: 3.40282346638528e+38 3.402823466385289e+38 false However if you change the code to be String(Number(v)) then the string values are the same Testmedia: as3/Types/Float/flt_9_8.as Happens with and without JIT
Flags: in-testsuite+
Flags: flashplayer-triage+
Flags: flashplayer-qrb+
Flags: flashplayer-bug-
This is a manifestation of the AVM float precision bug, and not an ASC CE bug, as I thought earlier.
Comment 2•13 years ago
|
||
So, -Ojit and -Dinterp do not disagree; but Tamarin disagrees with ASC. It's worth noting that Brent's example works when run exclusively through Tamarin (ie. use "float.MAX_VALUE" only on the first assignment; use 'v' otherwise). Since ASC does 'pushstring "3.402823466385289e+38" ' I presume that the real disagreement here (i.e. the "float precision bug") is related to "what should String(v) produce, when v is float/Number". First, one observation: trace(String(float.MAX_VALUE)) pushes the string "340282346638528859811704183484516925440", which is definitely wrong (according to the spec, String(float(x)) should be always identical to String(Number(float(x))). So there's one bug. Second observation: current implementation of Number.ToString calls convertDoubleToString passing "15" as the precision (number of digits). IMO, given that the parameter passed is "15", Tamarin's behaviour is correct - so I understand that we should pass 16?? Should this be API-versioned?
Comment 3•13 years ago
|
||
Apart from the String(float.MAX_VALUE) bug you note, the bug here is probably in the test media (sorry). We know that ASC and Tamarin do not agree on number-to-string and string-to-number operations because of several bugs in Tamarin that will not be fixed at this point. For the test media, at this point, I think we should settle for agreements in sign, exponent, and first six digits of result plus the decimal point. We can and should do better but probably not now.
Updated•13 years ago
|
Priority: -- → P3
Target Milestone: --- → Q2 12 - Cyril
Comment 4•13 years ago
|
||
The bug with the constant folding of String(float.MAX_VALUE) has been logged separately: bug #709760.
Comment 5•13 years ago
|
||
At this point (after fixing the constant folding) ASC uses the same code to format Number, float, and the components of float4, and until further notice that is correct for ASC. At the same time, Tamarin has a behavior that is correct for Tamarin. It is known that these two behaviors do not always match, and that is a fact of life. IMO the test media needs to be updated to account for this. Checking that the strings are equal, or one is a prefix of the other, is probably adequate for now.
Assignee: nobody → brbaker
Updated•13 years ago
|
Priority: P3 → P4
Summary: flt.toString() != String(Number(flt)) when flt is float.MAX_VALUE → [Test media] flt.toString() != String(Number(flt)) when flt is float.MAX_VALUE
Comment 6•13 years ago
|
||
changeset: 7144:47b389d3301d user: Brent Baker <brbaker@adobe.com> summary: Bug 699463: update testmedia to compare exponent and partial fraction values when comparing string representation of float.MAX_VALUE and Number(float.MAX_VAUE) http://hg.mozilla.org/tamarin-redux/rev/47b389d3301d
Comment 7•13 years ago
|
||
changeset: 7145:75c5ef059b71 user: Brent Baker <brbaker@adobe.com> summary: Bug 699463: clean up some print statements http://hg.mozilla.org/tamarin-redux/rev/75c5ef059b71
Assignee | ||
Updated•13 years ago
|
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•13 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•