Re: [xsl] decimal vs double value spaces

["C. M. Sperberg-McQueen" <cmsmcq@xxxxxxxxxxxxxxxxx>]

On 5 Nov 2009, at 04:28 , Justin Johansson wrote:

> Would someone kindly enlighten me as to the difference in
> the value spaces of xs:decimal's and xs:double's.

The xs:decimal value space contains every number expressible
in decimal notation using a finite number of digits.

The xs:double value space contains every number expressible
using a binary mantissa + exponent representation as
specified by IEEE 754.

Some numbers are in the decimal space but not in the double
space. For example, the decimal value space includes the
value 0.1 (one tenth), because that number can be represented
using a finite number of decimal digits.  The double value
space does not include that number, because in binary
notation the representation of that number is a repeating
fraction.

Some numbers are in neither space, e.g. the fraction 1/3,
which requires an infinitely repeating fraction both in
decimal and in binary.  And of course neither value space
contains any irrational numbers.

As far as I can tell (but I am not a numerical analyst), every
number expressible with a finite sequence of binary digits
can also be expressed with a finite sequence of decimal digits
(ten being divisible by two), so every number in the value
space of xs:double also makes an appearance in the value
space of xs:decimal. (Recall though that for simplicity XSD
treats all primitive value spaces as disjoint, so a sentence
like "The value space of xs:double is a subset of the value
space of xs:decimal" would provoke howls of pain from some
quarters.)

> I understand that the former doesn't lexically accept exponent
> notation (E+02 e.g.) but note that some (possibly unfinished/
> possibly naive) Java XPath engines internally represent xs:decimal and
> xs:double as Java doubles thereby reducing the (internal) distinction
> to nought.

I guess they are counting on the difference between the two
value spaces not to make much difference to their users.

Sometimes it doesn't; an implementor might well decide that
finishing the support for the sibling axes (or some other
feature) was more urgent than figuring out how to shift to
BigDecimal so that xs:decimal is supported properly.

If they think the implementation is conforming, though, I
think they are naive.

HTH

--
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************