Test sctruct-svg-201-t: numerical issues (Was: Re: SVGt 1.2 Tests: 3 possible problems in struct tests)

Hi Cameron,
I hope you reconsider your stand over our complaint about test

>> Moreover, constructing floats from strings cannot be guaranteed
>> same result across implementations.
> They should be, since ECMAScript mandates IEEE-754 floats.
First of all, the equality x == ftoa(atof(x)) does not hold even within
IEEE-754 for all x.
Some decimal representations do not have exact float representation. For
x = 0.9119 != ftoa(atof(x)) = 9.1189998e-1 (with normal rounding). 

Moreover, as you state later, the SVGt 1.2 spec does not have any
accuracy constraints, so it is free to
store the "3.0" appearing in the document in a way that best suits the
needs of the UA.
If this storage is not a IEEE-754 float with the value produced by
IEEE-754 parsing the string,
there needs to be some conversion at the time the trait is accessed. For
devices without a FPU, doing math in emulated IEEE floats is too slow.
Much of the
internal math is likely to use either fixed point or relaxed floating

In other words, while ECMAScript does mandate IEEE support, the SVGt 1.2
does not require IEEE level accuracy for traits or any other features.

Basically the test suggests that the specification expects all valid
input values
to be returned through getFloatTrait unchanged. Let's see what are the
solutions to passing the test.

a) Store the IEEE float value produces by parsing the input as well as 
the internal representation for computations. Upon querying the value, 
the float value is returned instead of the internal value. If
value is requested, return the internal result and hope that nobody
anything bit-exact. Doubles the data storage for traits.

b) Make sure that the internal representation can always be converted
to float within IEEE precision requirements. For example, the spec gives

'-32,767.9999 to +32,767.9999' as the valid input range for content. 
Now, the end points can be represented exactly by fixed point integers, 
but not floats; the number of mantissa bits is just insufficient. 
This value can be then rounded correctly as per IEEE spec. The added 
complexity can be tolerable, but the value add for the user is 

c) Do separation between the internal calculations that can use
reduced accuracy and public results that need to be exact. Setting up 
the division is difficult and may end up in situation where same
need to be replicated to both classes. This also may have negative
effects on script performance as values returned from core need to
be processed with greater accuracy.

d) Handle "3.0" as special case to get past the conformance tests. Least
effort, no real sacrifice in the overall quality.

> So technically while there are requirements on values used in content,
> there are no restrictions on how those values are represented
> internally.  I think though that it is very unlikely that the internal
> representation used for float trait values is able to represent the
> value '3' exactly.

We don't have a problem in storing the value accurately. The small 
difference arises when we need to produce the IEEE float from that 
exact value. 

One of the grand rules of the conformance testing is that you cannot
expect exact floats ever. Unless the specification explicitly states
that the value set somewhere must be returned as-is from the respective

Just for the sake of argument, consider a similar case, but replace the
value "3" with "-32,767.9999". This would be legal in the spec sense. 
There is no float that can represent the value above. When the nearest
float is converted to string, it will be "-32768", not the input.

  - Kalle Raita

Kalle Raita 
NVIDIA Corporation 
Tel. +358 40 723 1441 
http://eu.nvidia.com <http://eu.nvidia.com/>  

This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.

Received on Wednesday, 20 February 2008 13:38:27 UTC