- From: <bugzilla@wiggum.w3.org>
- Date: Fri, 05 Jun 2009 18:34:33 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6998 Summary: Test orderBy35 / values larger than 1.0E6 Product: XML Query Test Suite Version: 1.0.2 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: XML Query Test Suite AssignedTo: andrew.eisenberg@us.ibm.com ReportedBy: bogdanb+w3c+bugzilla@gmail.com QAContact: public-qt-comments@w3.org Hello! I suppose this was discussed before, but I can't find any explicit decision. (By the way, I'm basing this on version 1.0.2 of the TS, I haven't checked if the CVS version does things differently, yet.) Test orderBy35 outputs several xs:float values representing powers of ten from zero to 17. The expected result is “1.0E17 1.0E16 1.0E15 1.0E14 1.0E13 1.0E12 1.0E11 1.0E10 1.0E9 1.0E8 1.0E7 1.0E6 100000 10000 1000 100 10 1 0”. However, for values over 1E6 the specifications allow several different representations. (Java, for instance, converts 1.0E17f to string “9.9999998E16”.) The FO specs mention this, and the test suite documentation also acknowledges that for tests that involve operations on floats/doubles and converting those results to strings, even as one explicit value is given, other values may also be acceptable. In view of the last paragraph, I'm not sure if this would be regarded as a bug. However, at least for this case, the test could be changed to avoid the problem. For instance, the test as written could remove all values above 1E6; separate tests could then check that, e.g.: * “xs:float(1000000000) eq xs:float("1.0E9")”, * “xs:string(xs:float("1E9"))” matches a specific regex, and that * “xs:float("1.0E17") lt xs:float("1.00000007E17") and xs:float("1.0E17") gt xs:float("9.999999E16")”. (The numbers in the last expression correspond to what Java's StrictMath says are the next highest and next lowest float values around 1.0E17; I assume it's correct about that...) Something similar could be done for most tests that involve conversion between float and string values (this probably applies to double, as well). It seems verbose, but other than changing the FO spec to create a unique canonical representation* for float values (which is not realistic, except maybe for 1.1) I don't see any other solution. (*: For instance, the canonical representation of a float value could be defined as “the shortest string that xs:float would convert to that value; if there are several, the first as ordered by the codepoint collation”. Though that may be computationally intensive, I haven't checked.) -- 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 Friday, 5 June 2009 18:34:39 UTC