- From: Kalle Raita <kraita@nvidia.com>
- Date: Wed, 20 Feb 2008 14:36:59 +0100
- To: <www-svg@w3.org>
Hi Cameron, I hope you reconsider your stand over our complaint about test struct-svg-201-t. >> Moreover, constructing floats from strings cannot be guaranteed produce >> 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 example: 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 mobile 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 point. In other words, while ECMAScript does mandate IEEE support, the SVGt 1.2 specification 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 possible 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 presentation value is requested, return the internal result and hope that nobody expects 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 non-existent. 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 computations 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 getter. 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. Yours, - Kalle Raita Kalle Raita NVIDIA Corporation Tel. +358 40 723 1441 kraita@nvidia.com 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