OM Floats

[Bruce R Miller]

On Jul 9,  7:50pm, Taneli Huuskonen wrote:
> 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.

What you say is true, and is also true of OMI: there is no standard format for
very long integers.  Why shouldn't the API be simplified and restrict OMI to
32bit integers?  Bigints could be handled by a CD.

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

Many bigfloat-UNaware applications could still use high-precision floats by
simply truncating them to double (or whatever), and this option could be built
into the library if they are all OMF.  It might be more complicated if they're
coming from a separate CD.  It also means an application has to choose, at a
higher level, which format to use.

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