4881 2007-07-25 13:32:39 +0000 Should -NaN be allowed and given a meaning? 2008-05-16 17:15:53 +0000 1 1 1 Unclassified XML Schema Datatypes: XSD Part 2 1.1 only Macintosh All CLOSED WORKSFORME cluster: numbers resolved P4 major --- 1 cmsmcq cmsmcq www-xml-schema-comments oldest_to_newest 15914 0 cmsmcq 2007-07-25 13:32:39 +0000 In his survey of the impact of precision decimal on XPath and XQuery (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2006May/0023.html) [member-only link], Don Chamberlin observes 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. Should our description of NaN be modified to follow 754? 16059 1 davep 2007-08-06 03:33:20 +0000 (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? 16071 2 davep 2007-08-07 02:41:14 +0000 (In reply to comment #1) > allowed. If we wish to cover the case of the sign bit of NaNs in out lexical > representations, s/in out/in our/ Sorry. :-( 18111 3 cmsmcq 2007-12-17 15:59:10 +0000 The editors discussed this on the editors' call this morning. Comment #1 may be in error in saying the lexical form '-NaN' is not allowed (section 5.12.1 appears to allow it, but explicitly says that it has no meaning). Section 6.3 says that IEEE 754R (draft 1.5.0, October 2007) does not interpret the sign bit of NaNs. The editors recommend to the WG that this issue be closed without change, as WORKSFORME. 20146 4 cmsmcq 2008-05-16 17:15:40 +0000 At the telcon of 16 May 2008, the XML Schema WG adopted the proposal in comment #3 to close this issue as WORKSFORME.