OM Floats

[Richard J. Fateman]

At the risk of seeming both snippy and ignorable, I would suggest
that it is important for the person setting up this part
of the standard to actually be knowledgeable of the 
IEEE 754 standard for binary floating point arithmetic
  as well as the
IEEE 854 standard for radix independent floating point arithmetic.

As a participant in the standards committee for 754, but 
not a certifiable member of openmath,  (As a Californian,
I find it difficult to get to meetings in Europe!)
it is not clear if my input will register anywhere.




>From owner-om at lars.math.FSU.EDU Tue Jul  6 05:57 PDT 1999

>At the 12th OpenMath workshop in Eindhoven the subject of the
>OpenMath Float object came up for discussion again.

>Currently an OpenMath Float is specified in the draft standard as:

>>  They are double precision floating-point numbers following the {\sc
>>    ieee} 754-1985 standard~\cite{ieee754:85}.
>  

>In the XML encoding they take the form <OMF dec="123.456" /> or
><OMF hex="ABC123" /> with the decimal expression being the standard
>decimal expansion, 

A fully accurate  decimal representation is actually pretty hard
to compute.  A simple and exact way of transmitting this
is as two integers, representing 
integer x 2^(integer). 
How you encode the integers is up to you.

and the hex expression being an encoding of the IEEE
>representation. 

Um, which representation did you have in mind? My recollection
is that IEEE 754 doesn't specify a hex representation.  And
is it for single, double, or extended, and if extended, how
many bits? 80 total?

the hex form allows the encoding of some special cases
>such as +Infinity and NotANumber.

Certainly no other language has needed hex to represent floating
infinities.  The need for representation of the large number of
distinct NaNs is not especially better in hex than in any
other radix.

>There was some discussion as to whether this object should be changed to
>include arbitrary precision real numbers.

If we include arbitrary length integers, then arbitrary precision
reals are encodable as (convert-to-real :value (rational x (^ 2 y))
 :precision number-of-digits)    ;   using lisp key-word syntax.


>The outcome of the meeting was that as any change would be a change to
>the standard, proposers of the change should propose explicit changes
>to the draft which could then be discussed by the OM Society members.

Since I'm not a member, you are free to ignore me.


>This message is intended to help start any such discussion although it
>is in fact proposing that _no_ change be made in this area.

>It is important that double precision floating-point numbers should be
>able to be encoded in OpenMath, thus any change to include arbitrary
>precision reals must be _in addition_ to the current OMFloat object
>rather than a _change_ to the semantics of that object.

Since the double-precision semantics appears to be defective
all by itself, I'm neutral on this.

>One suggestion at the meeting would be to keep <OMF hex= as being the
>encoding for IEEE floats, but to allow <OMF dec= to encode arbitrary
>precision reals. I would strongly argue against this proposal as it
>would introduce an anomalous situation where two different
>primitive objects were encoded with the same XML element. 

I don't know if this really holds water.  You are representing
an exact real number.  Say 43.   Do you care how many bits
a host computer uses to store this?  8, 16, 32, 64, 80, or more?

If you wish to denote a real number, do it in an unequivocal exact
way.  Then any host computer "convert to the nearest IEEE double"
(etc) operator takes care of the rest.  

It seems the OM proposal on floats is intended to enshrine a bogus
few of floats as something whose fuzzy-ness is inherent and must
be preserved.  The fact is, every floating point number is an
EXACT RATIONAL NUMBER. DEAD ON EXACT.  NOT AN INTERVAL. NOT SOME
KIND OF MYSTERY-FUZZ.   
Not every rational is representable as a float exactly, but
every (not-infinite/NaN/) float is EXACTLY a rational.

>Also it
>is not really very convenient way to encode arbitrary precision reals,
>It would force all such values to be encoded in decimal when being
>encoded in XML which is presumably a relatively expensive operation
>compared to a direct encoding of the bytes used in the internal
>representation.

Whose internal representation? Intel's? DEC's?  If you want to
ship internal representations, is there not some rat-hole
designation allowing two computers of identical configuration
to communicate in binary?  If there is no such designation,
I suggest you devise one to allow transmission of (say)
large arrays of floats, binary programs, etc.


>Overloading the OMF element for the XML encoding of what we might call
>OMReal hides the fact that this would be a big change to OpenMath:
>It is not just a matter of allowing more digits in <OMF dec="1234...
>it requires a change in the semantics of abstract OpenMath objects and
>in the binary encoding to add a new class of object.

>If one is going to introduce a new class of basic object it would
>be better to make this explicit in the XML encoding as well:
>say <OMR>1.234</OMR> or <OMR base="16"/>FFFF FFFF</OMR> or some such.

>However this would be a big change in OpenMath requiring a change to
>all the encodings, and would only be of limited cosmetic benefit.
>In order to support the above, one would need to fix particular
>representations of these numbers in the specification of OMR,
>whereas in OpenMath as it stands today we can already do

><OMA>
><OMS cd="realnumbers" name="DecimalStringRepresentation"/>
><OMSTR>
>  1.234
></OMSTR>
></OMA>

This seems really pretty vague. At some point the real numbers
2.0
 and
1.99999999999999999999999999999999999999999999999999...
become indistinguishable.  When does that happen?

>or

><OMA>
><OMS cd="realnumbers" name="AxiomInternalForm"/>
><OMB>
> .bytes of internal form, which would be base64 encoded
> . in the XML encoding, but appear directly in the binary encoding.
></OMB>
></OMA>


>or any other encoding of real numbers suitable for the job in hand, as
>long as we have a symbol in a CD that says what the encoding is.

>So the form we have now is more flexible and more efficient in that it
>allows the internal forms of these numbers to be passed directly
>without having to arbitrarily re-encode to some other format for
>transmission via OpenMath. I would therefore argue that OpenMath Floats,
>and their binary and XML encoding should be kept as in the current
>draft. Probably there should be a CD in the core collection of CDs
>which gives some symbols for standard encodings for real numbers.

I don't follow everything here, but unless you have specified
algorithms for binary-to-decimal conversion, you haven't specified
what any decimal encoding means, exactly.  
If you send fraction and exponent separately, you're probably OK
for normal numbers. 


>David Carlisle