OM Floats

[Bruce R Miller]

On Jul 6, 11:40am, David Carlisle wrote:
> Subject: OM Floats
>
>
> At the 12th OpenMath workshop in Eindhoven the subject of the
> OpenMath Float object came up for discussion again.

As one of the instigators, I suppose I should jump in.

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

I propose that some change is necessary: I would insist that arbitrary
precision floating point numbers (in decimal, at least) should be officially
part of OM:  If not as (part of) OMF, then at the very least, part of an
official core CD.

One comment I heard was `Oh, you could always write a CD to define those'.
If it is not an official, standard, one, however, there will end up various
CD's floating around, each with phrasebooks for some few systems.  The end
result will be that these objects still won't be easily communicated, even
though at least as many potential OM applications will `understand'
multiprecision numbers as IEEE numbers.

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

Which `primitive' objects do you mean?  The internal representation of an
IEEE double vs a multiprecision object? How is that different from the OMI
where an integer may be a 32bit, or may be a multiprecision object?

--- Well, I'll offer one difference, myself: in the case of an integer
it's easy to tell which representation is needed, whereas for a float it is
less clear.  Given a decimal string, an application with both internal forms
can probably figure out which internal representation is required to maintain
the exact implied precision.  But that assumes that all digits of the printed
representation were significant. [I can imagine an analog of Lisp's floating
point contagion!] When might an application be allowed to truncate a
multiprecision number to an internal machine format? When outputting, the
application has to decide how many digits to use.

So clearly, if we allow two forms for such similar objects (whether or not
we've overloaded OMF) we need to provide, at least, some guidance to phrasebook
writers as to how to choose which representation and how many digits to use.

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

A direct encoding of _what_ bytes of _what_ internal representation?

Fateman  (Hi Richard!) makes similar comments about decimal being an
inconvenient or inaccurate representation.  But I think you both are assuming
too much about where the number came from.  A decimal radix representation is
not inherently less accurate than a binary radix; only if you are converting
from a binary internal representation.  However, the most natural
representation for a text editor or formatter would be decimal.  I believe the
internal representation of Maple's bigfloats is BCD, too.

While doing some legwork to come up with a proposal on this, I looked at the
user level API's in various CAS and languages.   I was trying to choose a
representation (mantissa,exponent) in some radix (w/ signs, offsets, whatever)
that would be generally useful, as I assumed this would be the most efficient
approach.

I found that the internal representations (when described at all) are all over
the place.   But, other than simply converting both numbers to multiprecision
floats and doing the mantissa*radix^exponent arithmetic explicitly, there
wasn't really any commonality there.  And thus no big win in encoding numbers
`the efficient way'.

What _was_ common across all the systems was that they could parse a decimal
string into thier internal rep.  Moreover, decimal is natural for editors and
formatters since it's already in the form they want; they wont need a math
library to convert from whatever clever format (or even IEEE :>).   I came away
from that concluding that decimal was the bestformat, rather than the worst,
for multiprecision numbers (again, whether OMF or in a CD).

That conclusion was reinforced when I belatedly realized that the long form of
the binary encoding of an OMI is, in fact, just a (mangled) ascii string.

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

I understand that there are cases where it is important to efficiently work
with IEEE numbers.  Still, I'm curious as to how it came about that IEEE is the
norm and multi-precision numbers are the exception --- if they're even to be
included!!  Why is the Semantics of OMF to be an IEEE double?  And how far
does this go -- are applications expected to use IEEE arithmetic? in what
rounding mode?

It used to be the worry that OM wouldn't support numeric computing, only CAS &
formatting.  Now I worry that the opposite is happening.

[...]

I think it is important to support multiprecision numbers.  However, having
both multiprecision & IEEE introduces some issues that need clarification ---
independently of whether we modify OMF or add a CD entry.   For symmetries
sake, I would prefer that OMF were extended, but either way...


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