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

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