[om] OM Floats (XML Representation)

[Bruce Miller]

Mike Dewar wrote:
> I agree with James - we ought to stick with the IEEE definition of NaN
> since the XSD one is so far out of step with other standards.  However
> Bill was right to note that Java only has one NaN value, 

No, actually Java lets you create any of them (providing you know the bit
pattern). They've just used Double.NaN to represent a `canonical' NaN.
Any language that lets you use the string "NaN" for a double (OM, Schema, etc)
is doing the same thing: it represents _some_ arbitrary NaN.

So, whether or not we use a regexp or xsd:double for OMF, if "NaN" is
allowed: Does it matter _which_ NaN is implied, and if so, which one?
I suspect that it doesn't generally matter, and we should probably
clarify the spec with something like:

  "NaN represents an canonical NaN value: which specific NaN is used
   in an application is left to that application.  If a specific NaN 
   is required, the hex attribute should be used."

[Incidentally, Java does provide several types of equality, although the overloading 
of == to mean both numeric and object equality is certainly not as
clean as Lisp's (Remember: Sun can overload operators, but we
can't be trusted to! :> )  In the case of NaN's, Double.isNaN should check for
_any_ NaN, and, presumably the equals method should distinguish between them).
I can only guess that the lack of enough senses of equality is what led the
Schema people to come up with that awkward rule of NaN == NaN.]

even though the
> IEEE standard allows lots (as pointed out by Richard Fateman), so not
> everybody else is fully IEEE compliant either.  This should perhaps be
> pointed out in the standard as a possible issue for phrasebook
> developers.

Although Java certainly has it's problems
(See http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf),
it's really only XSchema that's way out of line.

> To get back to David's original question, although it would be useful to
> allow <OMF dec="NaN"/> we should be clear that this is not the only way
> to create NaNs and that e.g. <OMF hex="7FFFFFFF"/> is also OK (assuming
> that represents a NaN), so an application handling floating point data
> should be able to import both.  With that proviso I think that we should
> allow NaN, Inf and -Inf as values of the `dec' attribute, but that we
> should not type the value of the attribute as an xsd:double because of
> its definition of NaNs and that we should explain this decision in the
> section describing the XML encoding.

Not having `graduated' from DTD's to XSchema, I may be missing something,
but what, really, is the negative impact of using xsd:double here?
It certainly seems clearer than some hairy regexp.
If Schema are just used to validate OM documents, how could their
broken description of NaN's affect OM?  Could the schema ever come into
play transforming an OM doc, using the broken arithmetic?
 
> Maybe the informal description of OMF should also say something along
> the lines of "the dec attribute will typically be used to contain the
> result of calling a print method in a programming language such as C or
> Java, while the hex attribute will be used to contain a hexadecimal
> encoding of the actual bit pattern of the number in question".  What do
> people think?
> 
> Mike. 
> 
> ________________________________________________________________________
> This e-mail has been scanned for all viruses by Star Internet. The
> service is powered by MessageLabs. For more information on a proactive
> anti-virus service working around the clock, around the globe, visit:
> http://www.star.net.uk
> ________________________________________________________________________
> --
> 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
> 
> 


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