W3C home > Mailing lists > Public > public-qt-comments@w3.org > July 2009

[Bug 6998] Test orderBy35 / values larger than 1.0E6

From: <bugzilla@wiggum.w3.org>
Date: Wed, 08 Jul 2009 09:06:37 +0000
To: public-qt-comments@w3.org
Message-Id: <E1MOT6r-0005p3-Qq@wiggum.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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:27 UTC