[om] OM Floats (XML Representation)

[Richard Fateman]

How about if you decide that IEEE numbers are not numbers at all.

Ordinary numbers of limited precision can be represented as <sign> 
<fraction_part> <exponent>,   a triple of 3 integers, with the first 
being 0 or 1. The fraction with a given binary point, say to the left of 
the msb of fraction.  A NaN is represented by another structure which to 
OM is NOT A NUMBER.  That is, any comparison regarding this object or 
set of objects and numbers is no more valid than comparing an 
uninterpreted symbol like FOOBAR  and a number.

Similarly for infinities, if you really care.  What is sin(infinity) anyway?

In the translation between OM and a particular system, such triples can 
be converted into IEEE numbers, probably. Maybe with hints...

There could be a few extra fields like
"intended to be stored as an IEEE double;   .. or single ... or 
extended  ... or extra-length"
"intended to be precise only to x bits"

Frankly, if you want to transmit IEEE floats, go ahead,  but I suggest 
that you NOT CALL THEM NUMBERS. 

Regards
RJF

David Carlisle wrote:

>Bruce Miller said, quoting me
>  
>
>>Yuck! Still seems horribly broken.  If my schema says we only accept 
>>numbers greater than 10, or less than 10, I wouldn't want NaN in _either_ case!
>>But, again, it's not clear that this would affect the OM spec, unless
>>we expected people to derive a schema from the OM schema, and restrict
>>OMF in certain instances (?)
>>
>>    
>>
>>>Also schema types get used in other places (specifically xquery/xpath/xslt 2)
>>>and there of course operations such as equality testing and sorting are
>>>defined. However I just checked and they don't follow schema there:
>>>
>>>Despite Schema specifying NaN sorts high, XSL 2 draft says
>>>
>>>  However, NaN values, for sorting purposes, are considered to be equal
>>>  to each other, and less than any other numeric value. 
>>>
>>>
>>>(note that this is for xsl:sort, the rules for < and =  operators are as
>>>below)
>>>      
>>>
>>These sound mostly sane; sorting should do _something_ with NaN's;
>>which end they go to hardly matters as long as you specify it.
>>If they added an isNaN predicate it seems like it would be 
>>more or less complete & consistent.
>>
>>    
>>
>
>I've been looking at this again, and think really I agree with Bruce's
>comments. We should still usefully be able to use xsd:double in the
>schema for <OMF dec=... /> without impacting on the interpretation of
>doubles within OpenMath itself (just relaxing slightly the regexp for
>literal double values).
>
>
> 
>I'm not sure xsd is as broken as was claimed. The ordering and
>inequality rules in schema relate to the ordering and inequality testing
>done by the schema validator, they don't impose constraints on the
>application.
>
>There is only one NaN possible in a schema input as the only allowed
>syntax is "NaN" there are no operations in schema that could generate
>anything else. Given the semantics of schema validation testing, if NaN
>was not equal to NaN, then if a schema constrained an element to only
>have NaN then an XML file would never validate as an instance of that
>schema; as even if it had NaN in that element, it would be not equal.
>So all xsd is saying by NaN=NaN is that if a schema specifies that an
>element must, or can, have NaN, then an instance that has NaN is
>valid. This seems reasonable to me.
>
>Similarly the ordering. Schema has taken an arbitrary choice and placed
>NaN high, but the only thing this affects is the facets such as 
>maxExclusive and minExclusive. IEEE NaN is supposed to be unordered wrt to
>finite values, but that isn't really an option for schema. Given
>a schema that specifies bounds on a double, the validator has to answer
>valid or not given an instance that has NaN, the schema choice is
>arbitrary but as I say it only affects validation. XSLT as an example
>takes schema validated input but never uses that ordering, it has two
>other interpretations, one for xsl:sort and one for <.
>We should make a comment about this in the document (especially as we
>have the hex attribute and so OpenMath NaN _can_ have multiple internal
>values, but I don't think there is any harm, and possibly a lot of good,
>in typing the dec attribute as xsd:double so it ends up typically in a
>java (or C or C# or whatver) double (and so subject to the java
>interpretation of ieee, not xsd's) rather than a java string.
>
>
>David
>
>
>
>________________________________________________________________________
>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
>  
>

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