Re: XSD decimal syntax

Dan Connolly wrote:
> On Fri, 2005-10-07 at 15:31 +0100, Seaborne, Andy wrote:
> 
>>
>> > 7. Section 3.  Decimal values cannot be written as literals.  This
>> > seems like a needless limitation.  Suggest SPARQL use the literal
>> > definitions in XPath 2.0.
>>
>>In XPath 2.0,
>>
>>   3.4 is a decimal
>>   3.4e0 is a double (doubles must have an exponent)
>>
>>xsd:decimal is now one of the required supported types in rq23.
>>
>>In the RDF world N3/Trutle/cwm and programming languages would make 3.4 a 
>>double; Sesame makes it a decimal.  I'm not sure where tht leaves expectations.
>>
>>We could go either way.
> 
> 
> FYI, some community discussion sprung out in #swig. Inconclusive,
> but interesting.
> 
> 
> should 3.4 be a double or a decimal in SPARQL? 
> posted by DanC at 2005-10-14 15:34 (+) tags:
> http://swig.xmlhack.com/2005/10/14/2005-10-14.html#1129304057.498099
> DanC: afs to DAWG, following up on Comments on SPARQL from the XML Query
> and the XSL WGs 
> DanC: it's a double in turtle, N3, and SPARQL-last-call, but since it's
> a decimal in XPath 2, they're asking us to switch
> dajobe: my preference is that as xsd:doubles are more commonly used
> (typed) and should be the default. nobody wants to do 3.4e0 lots.
> bignums are rare in data
> timbl: In favour of decimal: That the coersion from decimal to float is
> safe, unlike the other way. That it is a pain when typically currency
> values are calculated as floats and end up as long approximate float
> values.
> timbl:  Decimal support in python 
> AndyS: Details of XSD decimal 
> logger: See discussion 
> DanC:  asking ashok about the change from XPath 1 to XPath 2
> 
> 
> http://chatlogs.planetrdf.com/swig/2005-10-14#T15-22-30
> 
> 

We seem to be stuck on this one:

== For 1.3 being xsd:decimal:

What gets written is exactly the value in the query itself (because both the
query and the datatype use a base 10 representation).

Arbitrary precision and precision of more than xsd:double (xsd:decimal
requires a minimum of 18 digits - I think that's 64 bits of precision) are
needed for financial information.

It's what XPath uses.

== For 1.3 being a double:

It's what cwm and programming languages do.  Note many programming languages 
interpret 1/3 as integer divide (i.e. result integer 1)

It's what SPARQL does at the moment.

==

For SPARQL, the expression "1/3" is a decimal (F&O division of two integers is 
always a decimal), so a strict implmentation would have decimal anyway.   It 
isn't an exact calulation under xsd:decimal or xsd:double.

In practice, using doubles for decimals provides an adequate lightweight 
implemention.


Checking, I find Python 2.4 has a suitable decimal data type.  So does Java
1.5 (java.math.BigDecimal).

Java 1.4 BigDecimal isn't quite perfect (division tends to extend the 
precision or requires a bit of fiddling first) but there is a suitable 
implementation in com.ibm.icu4j.math for Java 1.4 for exactness.

PHP has BCMath (PHP 3+ - bundled in later versions)


Conclusion:

The move to xsd:decimal is a disruption but better in the long run.

I propose changing the meaning of the syntax for a bare term like 1.3 to mean 
an XSD decimal.  Doubles remain available as a short form as 1.3e0.

	Andy

Received on Tuesday, 8 November 2005 16:44:43 UTC