This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
I agree with the analysis. Another possible result is FOAR0002 if the implementation does not support 18-digit integers.
It appears that the value you consider to be in error, 1.307471086076747E17, was added as a response to Bug #2934, entered by Jerome. Jerome, as Kevin is asking that it be removed, I'll ask whether you agree or disagree with this action. Kevin, just to be clear, you are asking that 1.307471086076747E17 be removed as an expected result. Are you asking that any other values from the list you provided be added?
Yes, 1.307471086076747E17 should be removed as an acceptable answer, because the nearest representable double is 1.30747108607674704E17, rather than 1.30747108607674656E17. All of the other values are closer to 1.30747108607674656E17 and should be added as acceptable results.
I can't recall the details of Bug #2934 right now, but Kevin's analysis looks right to me. So no objections from my part.
I've removed 1.307471086076747E17 as an expected result and added the additional expected results that you suggested. Please close this bug report if you agree with this resolution.