Precision and CD's

[Richard J. Fateman]

I disagree strongly with Andreas on almost every point here.
(Sorry.  I hope this email doesn't make people angry/upset!).

Also, I guess I am guilty of letting pass some proposals for
printing of bigfloats that I should have objected to.
So let me address that first.

Every bigfloat has a precision attribute.  If it is not
obvious from its face what its precision is, then it should
be noted explicitly.  

In most systems the radix is understood globally so it need
not be recorded in each number, but the radix might not be
known between systems so that it too might need to be conveyed.
Here is a bigfloat:

1. a signed integer F representing the fraction.
2. the radix R.  (sometimes understood)
3. the precision P.  (generally P = log of F in radix R, rounded up to integer)
4. a signed integer E representing the exponent.

Now some people have confused the issue by asking in which
radix one should print F.  I don't really care how it is
transmitted, but as long
as you are asking, why not worry about the radix in which you
are printing the radix or the exponent? (the radix always comes out "10")

Let me repeat:  if the precision of a bigfloat in some representation
is not apparent, then THAT IS NOT ACCEPTABLE.


>From owner-om at lars.math.fsu.edu Tue Jul 20 08:48 PDT 1999
>From: Andreas Strotmann <strotman at nu.cs.fsu.edu>
>>  (Dalmas)
>> 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 think that by imposing a SIMPLE mathematical meaning, you are
attempting to avoid computational issues that must be faced, and
cannot be "defined away".  

>(Strotmann)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. 

ABSOLUTELY NOT TRUE.  BIGFLOAT ARITHMETIC IS LOSSY.  For example.
decimal radix precision 2
99E0 + 1E-1 = 99E0   Not Exact.

I am afraid that Andreas' impression is that the fraction of a bigfloat
is an arbitrary-precision integer that can grow arbitrarily as you
do arithmetic.  Not true.  In 2-place decimal float, the available
fractions (assuming normalized, which everyone here seems to have
assumed anyway)  are 10, 11, 12, ...., 99.   That's all.
You maintain this 2-digit limit by rounding according to some
careful rules.  (The arbitrary precision part is that you could,
by prior agreement, choose 1000 decimal digits.  But then you'd
have to stick to that, and not go to 1001 to avoid "loss").

George Collins proposed using "binary rationals" in which all
the numbers he allowed were of the form x/y  with y=2^n  or
x*y   with y=2^n.  This does not cover every rational, but
can approximate any rational (or real...) arbitrarily closely.
This is NOT what a bigfloat is. It is a "cheap near-rational"
with the advantage that near-GCDs are very cheap. Cast out trailing
zeros.

(We have also not addressed the exponent size, which is kind of
significant computationally. A bigfloat with an unlimited exponent
provides an encoding opportunity for unbounded info in its log..
)


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

For bigfloats or floats, indeed the logic and semantics can be
entirely formally specified, in fact in several plausible ways.  But if
you say that the logic must be a simple one (say corresponding to the
field of rationals) you have made them useless computationally.  Why
not just use the rationals?  The essence of the floats is that
the precision  (= length of fraction) is bounded.


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

I think this is a terrible idea.  An analogous proposal would be this:
"it is an error if an integer representation is 0"  
Why would one do this?  This makes it possible to be sure that
division by an integer is always well defined.  No division by zero.

You may argue: but 0 is so useful, you can't leave it out.

I suspect the reason you think NaN or infinities can be left out
(or worse, made into some kind of "use it and anything could happen")
is that you don't personally know how to make use of these items.
Imposing your limitation on other potential users of OM is not
a good idea, especially when it has the effect of throwing out
(by unacceptable subsetting) an international standard!

If OM will insert into some other part of its capabilities some
encodings that make it redundant to use IEEE floats for NaN or
infinities, then that would be OK with me personally:
a service can easily translate them into IEEE representations
if necessary.   You'd need signed
infinities and an "indeterminate".  I have written on how these
could be +1/0, -1/0, and 0/0.  I also don't find the need for
double-precision infinity compelling, if you have single-precision...


>(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;-)

Is this what happens when someone transmits x/0,  or 0/0,  or 0^0 ?
I would personally want to know  how an application I use
intends to deal with such situations.  It would seem to me
to be part of the contract between a consumer and a provider.
If so, does OM have a way of conveying this contract?
If it does not, I think that is a major problem.  


By the way, I can see absolutely nothing wrong with 3/(+infinity) which
is 0, and not weird at all. An application that threw an error
in this situation would be inconsiderate, to say the least.

RJF