[om] OM Floats (XML Representation)

[Bruce Miller]

Bill Naylor wrote:
>>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 ..."

That is rather strange, included the elided bit about NAN being greater than all others.
Java says _any_ comparison involving NAN gives false (except x!=x).
(Taking the Java spec as faithful to IEEE754 ...)

Possibly they've gotten into that awkward position by using "doubles" in a
sort of double-duty: (1) for arithmetic and (2) checking document consistency,
namely you want to be able to check whether some field is NaN!

[...]
> 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, 

Meaning that they don't say either one?  Ecmascript does claim that thier
numbers correspond to IEEE754, including NaN, so maybe they've left the
implications to the reader to avoid contradicting themselves :>


Java says that "Double.NaN == Double.NaN returns false" but
> "If d1 and d2 both represent Double.NaN, then the equals method returns
> true".

Yes, but don't be mislead by that: the equals method really has nothing to
do with arithmetic. Think of it in terms of Objects; you pretty much need
such properties to do hashing and so forth -- more like option (2) above.
By the same token, if double d1 is NaN, and you do d2=d1, then d1==d2 is false,
but if they are Doubles then d1==d2 is true!
(or should be; haven't actually run it...)
 
> 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.

It seems to me that the OpenMath spec is consistent with itself and IEEE here;
if there's a problem, it's not being able to link directly the the IEEE spec
where it's clarified.  I don't suppose linking to the Java spec is satisfactory.
Possibly the phrasing in the CD could reinforce that this property is consistent
with IEEE, but I don't think it needs a long explanation.

Bill, you've got an truly _amazing_ eye for spotting inconsistencies across a wide
range of documents; thanks for your work!

-- 
bruce.miller at nist.gov
http://math.nist.gov/~BMiller/

--
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