- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 08 Jul 2009 09:06:37 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6998 --- Comment #8 from Michael Kay <mike@saxonica.com> 2009-07-08 09:06:37 --- Firstly, the spec. After a great deal of deliberation, we decided that for float->string conversion, it should be legal to output any value that round-trips back to the original float. (Subject to the other rules e.g. that whole numbers are output without a decimal point.) Initially we used the XPath 1.0 rule that you should output the nearest number that is representable in decimal, but for various reasons this appeared unworkable. IIRC we also tried to mandate the shortest string that round-tripped back to the original float, but that had problems too. So as far as testing is concerned, any test whose result is floating point (or that contains the serialization of a value that includes floating point) has an infinite number of correct answers. This is clearly unsatisfactory, but it's hard to find a good way forward. Pragmatically, it can be useful when regular comparison of results fails, to try again parsing both results as float and outputting a comment if this succeeds, to aid manual inspection. At one stage I remember proposing that test results should be in a "wrapped" (self-describing) format for example <result type="xs:double">1.0e7</result>. Introducing this now would be a lot of work - and it still wouldn't solve the problem entirely, because comparison by converting back to double would give false positives, e.g. it would accept 10000000.0 as a valid result. Pragmatically, the best way forward is probably to refine individual tests that cause problems for example by using round-half-to-even to reduce the precision. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 8 July 2009 09:06:49 UTC