search

pchampin / xsd_decimal

Thought on the xsd:decimal datatype
2 stars 0 forks source link

One presentation, two values. #1

Open afs opened 1 year ago

afs commented 1 year ago

Due to the silence, I'll make a comment.

This matter has arisen because of number handling in JSON-LD.

On https://github.com/w3c/dxwg/issues/1536#issuecomment-1297128272 @dbooth discuss the fact precision can mean that decimals and doubles are not the same. It's worse than David points out - integer values that can be represented by xsd:doubles jump in 2's at the end of the ranges.

But scale is also important.

1E400 is a legal xsd:precisionDecimal.

But as an xsd:double it is value +INF. But but xsd:precisionDecimal also has +INF which is different!

So what is 1E400 + 0? You can't ignore arithmetic on numbers in the definition of the datatype.

The same representation (lexical form) in the two interpretations give different answers (value space - the number line extended with +INF, -INF and NaN).

xsd:double and xsd:float are separate primitive datatype in XSD.

xsd:integer is not primitive; it is a derived type of xsd:decimal. For xsd:decimal/xs:integer a legal representation is same value on the number line.

xsd:double/xsd:float are not well-behaved numbers.

pchampin commented 1 year ago

The suggestion here is to simply extend the lexical space of xsd:decimal, without any change to its value space (and therefore, to the underlying arithmetic). Unless I am mission something, any E-notation representation can be unambiguously interpreted as a unique decimal (by simply shifting the decimal point and gettring rid of the E/e and everything after it).

Your are right, this might get confusing when 1E400 will be a valid representation for both xsd:decimal and xsd:float, but representing different things in the value space. But that's already the case of 1.1... So I don't think that this proposal makes things significantly worse.

xsd:double/xsd:float are not well-behaved numbers.

And that's why, IMO, we should make xsd:decimal as usable as possible. Making it more "tolerant" in its lexical space is a step in this direction.

afs commented 1 year ago

I don't think you can ignore the effect on arithmetic and F&O.

In going to the XSD community, there is a lot of work/history to consider. What might be seen here as non-breaking changes maybe viewed differently elsewhere.

XSD already has precisionDecimal so need to understand why it is not a primitive type (XSD terminology) - why does decimal not derive from precisonDecimal?

The original motivation is JSON-LD. The change here no longer solves that issue (1E400, NaN). For JSOn-LD the target needs to be the overlap of xsd:double and xsd:decimal (51 bit precision, no NaN, INF). Otherwise, there was one issue and now there are two :-)

xsd:decimal also has a precision requirement - at least 16 digits in XSD 1.1 (it was 18 in 1.0 - they reduced it - why?).