[Bug 8499] New: Expected results for numberulng1args-2 incorrect

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8499

           Summary: Expected results for numberulng1args-2 incorrect
           Product: XML Query Test Suite
           Version: unspecified
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XML Query Test Suite
        AssignedTo: andrew.eisenberg@us.ibm.com
        ReportedBy: kcormier@ca.ibm.com
         QAContact: public-qt-comments@w3.org


Test case numberulng1args-2 has the following query:

(:*******************************************************:)
(:Test: numberulng1args-2                                 :)
(:Written By: Carmelo Montanez                            :)
(:Date: Thu Dec 16 10:48:17 GMT-05:00 2004                :)
(:Purpose: Evaluates The "number" function               :)
(: with the arguments set as follows:                    :)
(:$arg = xs:unsignedLong(mid range)                      :)
(:*******************************************************:)

fn:number(xs:unsignedLong("130747108607674654"))

And it expects one of the following 2 results:

1.3074710860767466E17
1.307471086076747E17

The evaluation of this query should start with a cast from xs:string to
xs:unsignedLong, which does not change the value.  fn:number casts to
xs:double, which is this case means casting the xs:unsignedLong to an
xs:string, and constructing the xs:double from that.

"A literal in the ·lexical space· representing a decimal number d maps to the
normalized value in the ·value space· of double that is closest to d; if d is
exactly halfway between two such values then the even value is chosen. This is
the best approximation of d ([Clinger, WD (1990)], [Gay, DM (1990)]), which is
more accurate than the mapping required by [IEEE 754-1985]. " [1]

This implies that the xs:double value will be 1.30747108607674656E17.

The final step is to cast the xs:double to xs:string for display.  The
following rule applies:

"TV will be an xs:string in the lexical space of xs:double or xs:float that
when converted to an xs:double or xs:float under the rules of 17.1.1 Casting
from xs:string and xs:untypedAtomic produces a value that is equal to SV, or is
"NaN" if SV is NaN." [2]

In other words, we must be able to get back the original double value
1.30747108607674656E17 when we cast in the opposite direction.  So, any of the
following results would be valid:

1.30747108607674648E17 
1.30747108607674649E17 
1.3074710860767465E17
1.30747108607674651E17 
1.30747108607674652E17 
1.30747108607674653E17 
1.30747108607674654E17 
1.30747108607674655E17 
1.30747108607674656E17
1.30747108607674657E17 
1.30747108607674658E17 
1.30747108607674659E17 
1.3074710860767466E17   *
1.30747108607674661E17 
1.30747108607674662E17 
1.30747108607674663E17 
1.30747108607674664E17

One of these results (marked with an asterisk) is accepted by the test case,
but the other is not in this list and appears to be an error.

[1] XML Schema Part 2: Datatypes Second Edition, section 3.2.5:
http://www.w3.org/TR/xmlschema-2/#double

[2] XQuery 1.0 and XPath Functions and Operators, section 17.1.2:
http://www.w3.org/TR/xpath-functions/#casting-to-string


-- 
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 Tuesday, 15 December 2009 16:15:23 UTC