- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Mon, 28 Feb 2011 14:40:33 +0000
- To: SPARQL Working Group <public-rdf-dawg@w3.org>
(this is just part of the comments message but a part I wanted to check
up on)
> -------- Original Message --------
> Subject: avg testcase issues (was: Re: syntax error in testcase manifest)
...
> From: Jeen Broekstra <jeen.broekstra@gmail.com>
...
> 1. testcase aggregates/agg-avg-01 ("AVG")
>
> This testcase currently assumes a particular precision in xsd:decimal
> division, which is not mandated by the XPath definition. XPath defines
> that in xsd:decimal operations, rounding is implementation dependent
> (see http://www.w3.org/TR/xpath-functions/#op.numeric, near the end of
> the section).
>
> In the test, five numbers of type xsd:decimal are averaged (1.0, 2.0,
> 3.5, 2.2, 2.2). The average is computed by executing a op:numeric-divide
> on the sum of the five decimals: 11.1/5. The result of this is, as the
> testcase defines, 2.22. However, this result increases precision to 2
> decimals (note that the precision of the input is 1 decimal).
>
> While this is not wrong, it is not the *only* correct answer: an
> implementation that would round or truncate to 1 decimal and return 2.2
> as the answer would IMHO also perform the operation correctly.
>
> To fix this, I would suggest that the testcase numbers are adapted so
> that the result of the division when not rounded is of the same
> precision as the input. Alternatively, change the test case to work on
> floats or doubles, as division behavior is more precisely defined for
> those datatypes.
The issue seems to be that reading "2.0" is implying a precision of one
decimal place in the decimal. This isn't true - XSD decimal must
support at least 18 digits of precision and precision is not a facet of
the lexical space.
http://www.w3.org/TR/xmlschema-2/#decimal
"""
Note: All ·minimally conforming· processors ·must· support decimal
numbers with a minimum of 18 decimal digits (i.e., with a ·totalDigits·
of 18)
"""
1.0, 2.0 etc are at least 18 digits of precision and the way the decimal
is written is not relevant. i.e. In XSD, 2.00 is not promising more
precision than 2.0 - they are different ways to write the same value down.
"""
Precision is not reflected in this value space; the number 2.0 is not
distinct from the number 2.00.
"""
which is a little different from Java BigDecimal where scale is a factor
in BigDecimal.equals or some scientific styles where the number of
places does imply accuracy.
Andy
Received on Monday, 28 February 2011 14:41:11 UTC