Precision and CD's

[Andreas Strotmann]

On Tue, 20 Jul 1999, Stephane Dalmas wrote:

> > > 
> > > Other considerations:
> > > 
> > > The major advantage of floats/ bigfloats  is that the cost of
> > > operations is mostly a function of the desired precision, and 
> > > not (usually) the value. The usual
> > > operations include sqrt, exp, log, sin, cos  etc. as well as +-*/.
> > > 
> > If that's what you consider the essence of bigfloats, then the
> > representation should include a specification for the precision -- but
> > several people on the list (including you) have argued vehemently against
> > this: "bigfloats are exact rationals".
> 
> I may have miss a point or two in this discussion, but I agree with Richard
> here. A bigfloat is an exact rational, but it is subject to a strange
> arithmetic that is NOT the arithmetic on rational numbers. 

Hmmm.  Well, I guess that I'm concerned with making sure that OpenMath
objects have a precise mathematical meaning that is independent of
applications, date and time, or other vagaries and "strangeness"es.
OpenMath is a *content* language. 

I strongly believe that, while it is in every application's rights to
impose its own kind of "strange" implementation of arithmetic on bigfloat
objects, *mathematically* (or platonically, I suppose), the basic
arithmetic operations on them (+,-,*,/, base change) are well defined and
should be exact and lossless. 

In other words, OpenMath would define an exact semantics, and would
encourage applications to use implementations that approach those exact
semantics as closely as possible -- which is precisely the kind of
semantics that OpenMath defines, and recommendation it makes, wrt to all
the rest of its objects.

 -- Andreas

PS:  I also think that IEEE FP representations should be confined to the
binary encoding, where they could be used in a similar manner to "short"
integer representations -- as compact and/or efficient alternative
encodings of the more general concept.  This is also similar to how the
binary encoding defines structure sharing that the XML encoding doesn't
provide.

The use of NaNs and infinities of IEEE FPs is a bad idea, too, I think.
That use should be depracated by OpenMath, sort of along these lines:
 
  "it is an error if an IEEE representation is NaN or infinite."

(meaning applications are free to ignore the error or to throw an error,
and free to produce these weird objects to say that there was an error in
operations... in the binary encoding, that is;-)