699463 - [Test media] flt.toString() != String(Number(flt)) when flt is float.MAX_VALUE

Status: VERIFIED FIXED

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

Description

[Brent Baker]

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

Comment 1

[Jeff Dyer]

This is a manifestation of the AVM float precision bug, and not an ASC CE bug, as I thought earlier.

Comment 2

[Virgil Palanciuc]

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

[Lars T Hansen]

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.

Comment 4

[Lars T Hansen]

The bug with the constant folding of String(float.MAX_VALUE) has been logged separately: bug #709760.

Comment 5

[Lars T Hansen]

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.

Comment 6

[Tamarin Bot]

changeset: 7144:47b389d3301d
user:      Brent Baker <[e-mail]>
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

[Tamarin Bot]

changeset: 7145:75c5ef059b71
user:      Brent Baker <[e-mail]>
summary:   Bug 699463: clean up some print statements

http://hg.mozilla.org/tamarin-redux/rev/75c5ef059b71