OM Floats

Taneli Huuskonen huuskone at
Fri Jul 9 18:50:03 CEST 1999


Richard J. Fateman writes:

> the arguments for excluding bigfloats are just as valid for
> excluding double-precision IEEE.  Namely, a string of
> characters chosen from 0-9 or 0-F will have to undergo
> encoding, base-conversion, and perhaps syntax checking before
> a host computer can use the object as an internal number.
> After all, the internal form is BINARY, not hex or dec.

My point is that a single I/O library can be linked to a large number of
different applications.  Assuming the host computer has native IEEE
arithmetic, an application could input or output the value of a
floating-point number in OpenMath with just one call to the library.  On
the other hand, there is no such well-defined standard format for very
high precision floats, so most applications have to do some processing
anyway if they use a generic OpenMath library for I/O.

Therefore, I argue that bigfloats should be expressed as structured
OpenMath objects, built out of simpler ones.  A few different
constructor symbols for doing that should be defined in a Bigfloat CD.
One of them would certainly be a conversion from a decimal string
representation into the application's internal format.  Doing so would
keep the syntax of OpenMath, and, consequently, the I/O libraries and
their API's simpler, while any bigfloat-aware applications would just
get the same data, slightly differently packaged.

Taneli Huuskonen

Version: 2.6.3i
Charset: noconv

I don't   | All messages will be PGP signed,  | Fight for your right to
speak for | encrypted mail preferred.  Keys:  | use sealed envelopes.
the Uni.  | |

More information about the Om mailing list