On 31/07/12 16:32, David Booth wrote:
> On Tue, 2012-07-31 at 15:52 +0100, Andy Seaborne wrote:
>>
>> On 31/07/12 15:05, David Booth wrote:
>>> Hi Andy,
>>>
>>> On Tue, 2012-07-31 at 09:04 +0100, Andy Seaborne wrote:
>>>> David,
>>>>
>>>> Thank you for your comment on serializing xsd:decimal, xsd:float,
>>>> xsd:double.
>>>>
>>>> XSD defines the operations for these datatypes including rules for
>>>> precision. For xsd:decimal, the precision required is:
>>>>
>>>> [[ http://www.w3.org/TR/xmlschema11-2/
>>>> All ·minimally conforming· processors must support decimal values whose
>>>> absolute value can be expressed as i / 10k, where i and k are
>>>> nonnegative integers such that i < 1016 and k ≤ 16 (i.e., those
>>>> expressible with sixteen total digits).
>>>> ]]
>>>>
>>>> [[ http://www.w3.org/TR/xmlschema-2/
>>>> Note: All ·minimally conforming· processors ·must· support decimal
>>>> numbers with a minimum of 18 decimal digits
>>>> ]]
>>>>
>>>> SPARQL uses the work of XQuery/XPath Functions and Operators and the
>>>> requirements for handling these numeric datatypes derive from that body
>>>> of work. The SPARQL specification links to each operator required.
>>>>
>>>> RDF defines a literal as a lexical form and a datatype. It does not
>>>> consider the datatype to modify the behavior of forming the RDF literal.
>>>
>>> Should I understand this to mean that when a minimally conforming SPARQL
>>> server creates a value of type xsd:decimal, then at least 18 decimal
>>> digits of precision must be retained in *serializing* that value to
>>> lexical form? I understand that the computations must be performed with
>>> at least 18 decimal digits of precision, but serialization is
>>> (potentially) a different matter.
>>
>> Serialization can't truncate - it must represent the value and there is
>> no flexibility in the serialization step of forming the literal. If the
>> calculation says the value is X, then the serialization must represent X.
>>
>> The serialization represents the value. In some datatypes like
>> xsd:decimal, there are multiple ways to write the same value. It's a
>> feature of the datatype, not RDF itself. xsd:decimal does not record
>> precision with trailing zeros.
>
> If I've understood correctly, this means that a minimally conforming
> SPARQL server MUST retain at least 18 decimal digits of precision when
> an xsd:decimal is serialized into lexical form, though trailing zeros
> (after the decimal point) are optional. Thus, the value 3 may be
> serialized as any of these
>
> "3.0"^^xsd:decimal
> "3.00000000000000000"^^xsd:decimal
> "3.00000000000000000000000000000000000000000000"^^xsd:decimal
>
> but the value of pi must NOT be serialized as
>
> "3.14159"^^xsd:decimal
>
> because that serialization does not retain at least 18 digits of
> precision.
Let's avoid pi as that gets into what the constant is set to, which will
not be exactly pi.
Your example was:
0.049508196721311475409836
which has 16 significant places: 0495081967213115
(if rounded in the last place - I believe that ..114 would also be
right, if less right, as the two 16 digit closest numbers)
(XML schema 1.1)
so
"0.0495081967"^^xsd:decimal
and
"0.050"^^xsd:decimal
do not serialize that value as they represent distinctly different
values on the number line.
>>>> All ·minimally conforming· processors must support decimal values
whose
>>>> absolute value can be expressed as i / 10k, where i and k are
>>>> nonnegative integers such that i < 1016 and k ≤ 16 (i.e., those
>>>> expressible with sixteen total digits).
>
> If this is the case, then I am satisfied with this response.
>
> Thank you!
> David
>
>>
>> See http://www.w3.org/TR/xsd-precisionDecimal/ (W3C Working Group Note)
>> which is not a required datatype in SPARQL (or even an XSD processor)
>>
>> Andy
>>
>>>
>>> Thanks,
>>> David
>>>
>>>
>>>>
>>>> The working group is not planning to make any changes in this area.
>>>>
>>>> I would be grateful if you reply to this message to confirm that the
>>>> working group has responded to your comment.
>>>>
>>>> Yours, on behalf of the SPARQL Working Group,
>>>>
>>>> Andy
>>>>
>>>>
>>>> On 20/07/12 16:19, David Booth wrote:
>>>>> It is currently difficult to compare the results of two different SPARQL
>>>>> servers when xsd:decimal, xsd:float or xsd:double are used, because
>>>>> there does not seem to be any standard way to control the number of
>>>>> decimal places that are serialized. For example, if the decimal
>>>>> 0.049508196721311475409836 is computed, one server may serialize this as
>>>>>
>>>>> "0.0495081967"^^xsd:decimal
>>>>>
>>>>> and another may serialize it as
>>>>>
>>>>> "0.050"^^xsd:decimal
>>>>>
>>>>> One might (erroneously) attempt to round both of the serialized values
>>>>> to one decimal place in order to compare them, but if they have already
>>>>> been rounded once before serialization (as above) then this won't work,
>>>>> because 0.050 rounds to 0.1, while 0.0495081967 rounds to 0.0.
>>>>>
>>>>> I think the SPARQL standard should provide some "SHOULD" guidance, such
>>>>> as specifying that a SPARLQ server SHOULD (by default) serialize a
>>>>> specified number of decimal places (perhaps all available), and MAY
>>>>> provide a standard means of controlling the number of decimal places
>>>>> that are serialized.
>>>>>
>>>>> If it is too late in the WG process to consider this for SPARQL 1.1 (and
>>>>> I assume it is) then please add this to the wish list for the next
>>>>> version.
>>>>>
>>>>> Thanks!
>>>>>
>>>>
>>>>
>>>
>>
>>
>