This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This test aims to catch underflow in xs:decimal with an expected result of 0.0. Underflow is defined in: http://www2.hursley.ibm.com/decimal/daexcep.html as: "This occurs and signals underflow if a result is inexact and the adjusted exponent of the result would be smaller (more negative) than the smallest value that can be handled by the implementation (the value Emin). That is, the result is both inexact and subnormal." If I understand this correctly, underflow will occur for numbers very close to zero, not numbers which are large negative values. Therefore a suitable number for this test might be: 0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001 Note also that due to the EBNF for decimal literals: 142] DecimalLiteral ::= ("." Digits) | (Digits "." [0-9]*) this parses as: -(9999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999.1) i.e. operator unary minus applied to a large (possibly overflowing) decimal. (:*******************************************************:) (: Test: K2-Literals-7 :) (: Written by: Frans Englich :) (: Date: 2007-01-12T16:19:57+01:00 :) (: Purpose: Use a relatively small xs:decimal literal. :) (:*******************************************************:) -9999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999.1
I don't see what makes General Decimal Arithmetic Specification a valid reference in this context. Feel free to explain that for me. I base the test on XQuery 1.0 and XPath 2.0 Functions and Operators, 6.2 Operators on Numeric Values, which says: "For xs:decimal operations, overflow behavior ·must· raise an error [err:FOAR0002]. On underflow, 0.0 must be returned." Your comment on how a "negative" decimal is parsed sounds sensible; it makes me conclude that underflow can never happen with numeric literals, and that therefore the the valid baselines should be 1) the same as the input; and 2) FOAR0002.
As I understand the term, underflow is the condition where a number is so close to zero that a particular representation has insufficient precision to record the number accurately. Therefore a test for this condition is as follows: (:*******************************************************:) (: Purpose: Test for possible underflow of xs:decimal literals :) (:*******************************************************:) 0.00000000000000000000000000000000000000000000000000000000000000000000000000000000000001 The expected result is 0.0 in the case of underflow, or the correctly returned number if the implementation's decimal representation has sufficient precision. For the test you gave, either err:FOAR0002 will be raised or the correctly returned number if the implementation's decimal representation has sufficient precision. 0.0 could never be returned (unless the implementation's decimal representation was _really_ imprecise).
I think the meaning of "underflow" in terms of numerical arithmetic is well known and the F+O spec is clearly using the term in the general sense of IEEE 754. It means an operation that produces a result which is so close to zero that it cannot be accurately represented. See for example http://en.wikipedia.org/wiki/Arithmetic_underflow The term is generally used in connection with floating point arithmetic, where it means that the exponent is smaller (closer to minus infinity) than the smallest exponent allowed. It's moot what the F+O spec means when it uses the term in relation to xs:decimal arithmetic. I think the reasoning is simply that some implementations of xs:decimal might use a floating decimal point and might therefore be subject to underflow conditions.
Agreed. But in the test case, if the decimal number were to be written as a floating point value, the exponent would be a large positive number, not a large negative number. Hence if the purpose of the test is to exhibit an underflow condition, the test is wrong.
A fix has been attempted in CVS, and XQTS_current.zip has been updated to contain the new change. If it can be verified that the change is correct, it would be appreciated. If this resolution is satisfiable, feel free to change status to closed. Otherwise, reopen this report. If no opinion on the resolution is expressed within two weeks, I will change status to closed. This change to this report was part of a batch-change of several reports.
Although this test is now correct, I believe the expected result should be 0 and no 0.0. Although F+O spec does say: "For xs:decimal operations, overflow behavior ·must· raise an error [err:FOAR0002]. On underflow, 0.0 must be returned." when serialized, because 0.0 is in the value space of xs:integer, it will be converted from a decimal to an integer (F+0 17.1.2 Casting to xs:string and xs:untypedAtomic).
Yes, sounds correct. A fix has been attempted in CVS(see comment #5).
This test is now correct. THanks.