[om] OM Floats (XML Representation)

[Bill Naylor]

>
> Second I would like to raise a bug/query regarding the NaN symbol in the
> cd nums1. Both the CMP and FMP state that NaN \neq NaN. It also say in the
> definition "See IEEE standard for floating point representations."
>
> At http://www.w3.org/TR/xmlschema-2/#double, we are told
>
> "The double datatype corresponds to IEEE double-precision 64-bit floating
> point type [IEEE 754-1985]."
>
> we are also told
>
> "Not-a-number equals itself and ..."
>

I found a relevant statement by a "Curt Arnold" at:
http://lists.xml.org/archives/xml-dev/200104/msg00078.html
during a review of XML Schema datatypes he makes the statement:

---------------------------------

1. Treatment of NaN

In the definition for float and double, the following sentence appears:

"Not-a-number equals itself and is greater than all float values including
positive infinity."

This treatment of NaN appears to be incompatible with the treatment of NaN
in the IEEE spec and in Java and was introduced into this last draft
without any explanation.

For example, from the Java Language Specification:
http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html#9290

"NaN is unordered, so the numerical comparison operators <, <=, >, and >=
return false if either or both operands are NaN (15.20.1). The equality
operator == returns false if either operand is NaN,
and the inequality operator != returns true if either operand is NaN
(15.21.1). In particular, x!=x is true if and only if x is NaN, and (x<y)
== !(x>=y) will be false if x or y is NaN."

If this conceit has substantial value (like allowing double to be
ordered), then it should be appropriately explained and the limits to how
far its abnormal treatment of NaN needs to propagate into
other XML specs.

I am not aware of the motivation for this treatment, however if the
motivation is to force double and float to be fully ordered and support
the equality concept (which traditional NaN treatment
violates since NaN != NaN), then I would suggest removing NaN from the
lexical and value space of double and float, adding a distinct NaN type
(the first datatype whose value space does not support
the notion of equality) and adding unions of double and NaN and float and
NaN as built-in datatypes.

---------------------------------

It seems that there is a pretty substantial debate going on about the
truth or otherwise about NaN. Javascript says that neither NaN == NaN or
NaN != NaN, Java says that "Double.NaN == Double.NaN returns false" but
"If d1 and d2 both represent Double.NaN, then the equals method returns
true".

I suggest that either we remove the IEEE reference from the CD, or we put
some discussion about its equality (or lack of) with itself in its
discription.

Bill

--
om at openmath.org  -  general discussion on OpenMath
Post public announcements to om-announce at openmath.org
Automatic list maintenance software at majordomo at openmath.org
Mail om-owner at openmath.org for assistance with any problems