OM Floats

[Taneli Huuskonen]

-----BEGIN PGP SIGNED MESSAGE-----

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

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQB1AwUBN4Yn0gUw3ir1nvhZAQGpkAL/TfS3DVLDRXSFiW7UziKia85lPHjQ7ZpW
Rj6cSI72b2CCRz+FZM5R1NsJNLv6QvehfT4Rzs7ryVZDWWCBhIgMbhIQM4h977ff
q01/x1okn/bQfxmFakAjqZhMRHBLibY4
=7nvO
-----END PGP SIGNATURE-----
-- 
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.  | http://www.helsinki.fi/~huuskone/ | http://www.gilc.org/