RE: Representation of floating point values.

I agree. It's not even clear that this is what schema intended. What it says
is:

A literal in the .lexical space. representing a decimal number d maps to the
normalized value in the .value space. of double that is closest to d; if d
is exactly halfway between two such values then the even value is chosen.
This is the best approximation of d ([Clinger, WD (1990)], [Gay, DM
(1990)]), which is more accurate than the mapping required by [IEEE
754-1985].

This text seems to lead inevitably to the conclusion that the lexical value
"1e10000" maps to the largest non-infinite double (because it's closer to
that than it is to infinity), but one feels that this is an accident of the
wording rather than a conscious design decision.

(I don't have access to Clinger and Gay, by the way.)

Of the three possible options:

1. Map to the largest finite double
2. Map to +Infinity
3. Raise an error

option 1 seems the least desirable.

Java does (2).

Michael Kay

 

> -----Original Message-----
> From: w3c-xml-query-wg-request@w3.org 
> [mailto:w3c-xml-query-wg-request@w3.org] On Behalf Of Daniel Engovatov
> Sent: 07 March 2005 21:43
> To: www-xml-schema-comments@w3.org
> Cc: w3c-xml-query-wg@w3.org
> Subject: Representation of floating point values.
> 
> 
> During our recent XQuery working group meeting we have closed an issue
> regarding what should be done if a numerical literal representing a
> float or double value is out of range for IEEE 754 values 
> (positive and
> negative overflow or underflow).
> 
> --------
> RESOLUTION: Too big float/double values.
> http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2005Feb/0084.html
> is rejected. No action required to 3.1.1. Schema says that one should
> map to the largest float or double value.
> --------
> 
> It does seem to me that this is an unfortunate choice in the Schema to
> just map a non-representable number into another number.  Probably,
> other options should be allowed for an implementation, such raising an
> error and mapping to +/- INF.
> 
> Sincerely,
> 
> Daniel Engovatov.   
> 
> 
> 
>

Received on Monday, 7 March 2005 22:16:01 UTC