W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > July to September 2007

[Bug 4881] Should -NaN be allowed and given a meaning?

From: <bugzilla@wiggum.w3.org>
Date: Mon, 06 Aug 2007 03:33:20 +0000
CC:
To: www-xml-schema-comments@w3.org
Message-Id: <E1IHtLM-0001FZ-Pc@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4881





------- Comment #1 from davep@iit.edu  2007-08-06 03:33 -------
(In reply to comment #0)

>     In 754r Section 5.10 we read "totalorder(-NaN, number) is 
>     true where -NaN represents a NaN with negative sign bit". 
>     (But there is no negative NaN value in XML Schema.)
> 
> It would appear from this that IEEE 754R assigns distinct meaning,
> for ordering purposes, to the sign bit of NaN values.  Our
> description of precisionDecimal requires the sign to be absent
> when the numericalValue is notANumber.  Our float and double
> types have a NaN, but no negative NaN.
> 
> If IEEE 754 does assign ordering or processing semantics to 
> -NaN, it may perhaps be useful for XPath and the other QT
> specs if XSDL distinguishes NaN and -NaN.

It's true that 754R provides for this alternate total ordering (which differs
from the usual not-quite-total ordering, also provided for).  However, 754R in
7.12.1 prescribes that "quiet" NaNs are to be represented lexically as "nan" or
some partially or entirely capitalized variant, and that "signaling" NaNs are
to be similarly represented by "snan" or "nan".  In either case, no sign is
allowed.  If we wish to cover the case of the sign bit of NaNs in out lexical
representations, according to 8.2.1 we must in addition to "nan" (or the
optional "snan") provide a bit patern that sets out all of the
system-defined-meaning bits that can vary in the various NaNs.  The WG
considered and rejected long ago the option (IIRC, WRT float and double) of
specifying such bit patterns.  Need we reopen that question?
Received on Monday, 6 August 2007 03:33:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:06 UTC