OM Floats

[David Carlisle]

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, and the hex expression being an encoding of the IEEE
representation. the hex form allows the encoding of some special cases
such as +Infinity and NotANumber.

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

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.

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.

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


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>

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.


David Carlisle