OM Floats

[Bruce R Miller]

On Jul 7,  4:05pm, David Carlisle wrote:
> So the question is whether there is a usage for arbitrary precision
> floats that is sufficiently `canonical' that it could be added to that
> small list of primitive types, or whether there will always be
> sufficient variation in the way in which you want to construct these
> things that it makes more sense to have a CD containing such
> constructors and then to build floats by applying these symbols,
> as is currently done for the rationals.

OM has got Exact numbers pretty well covered: Integer (OMI), Rational (CD),
Exact Reals (symbolic expressions); although there are exact reals that might
be more conveniently represented as a floating point number with `infinite'
precision.

Inexact numbers are the problem, and by themselves, floats dont solve it.  With
an additional notion of precision, though, perhaps they do.
A precision attribute might be
   `inf'  : to mean the number is exact as given.
    n     : meaning n digits precision (decimal? or whatever)
            the conversion to internal form should preserve this much.
    blank : default meaning IEEE (for example), or ?
If the precision is blank or n < 16, this number can be represented internally
by a IEEE double.  Presumably it is acceptable for some applications to convert
_all_ floats to IEEE, but general purpose OM filters should not.

Having all floats coming through one `entry point' seems good because each OM
application can decide what internal representation is necessary or possible
based on the requested precision and what reps it has at its disposal.  It
might be desirable, for example, to have high precision numbers in an stored
expression, but still allow a graphics program to truncate the numbers to IEEE
as it reads them; that would become more difficult if every program has to
understand a variety of extra CD's with different formats.

And that is another concern I have with the CD approach: that we'll end up with
a bunch of special purpose CD, with the result that most applications wont
understand most numbers.  Of course, we will always have the possiblity for
people to define special purpose CD's for numbers if they need them, even if we
do modify OMF.

IF this were done as part of OMF, OMF might have a precision attribute -- it
could still have a IEEE attribute for encoding IEEE numbers in hex format.

How close does this come to addressing your concerns about the doubled
semantics and other things?


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