Precision and CD's

Richard J. Fateman fateman at cs.berkeley.edu
Tue Jul 20 22:51:03 CEST 1999


>From owner-om at lars.math.FSU.EDU Tue Jul 20 11:47 PDT 1999
>From: J H Davenport <J.H.Davenport at maths.bath.ac.uk>
>To: David Carlisle <davidc at nag.co.uk>
>cc: om at lars.math.FSU.EDU


>>>> > Every bigfloat has a precision attribute.  If it is not
>>>> > obvious from its face what its precision is, then it should
>>>> > be noted explicitly.  
>Odd, I seem to recall some-one saying earlier in this group
>::The fact is, every floating point number is an
>::EXACT RATIONAL NUMBER. DEAD ON EXACT.  NOT AN INTERVAL. NOT SOME
>::KIND OF MYSTERY-FUZZ.   

Yep.  This is exactly correct and consistent.  All "precision" means
is the number of bits in the fraction. It has nothing to do with
accuracy.

Some examples. (all in decimal, since decimal-to-binary and
binary-to-decimal conversion would otherwise require more explanation)

31416x10^-4 in precision 5 decimal digits or
3.1416x10^0

   is the same as the rational number 31416/10000

3141600x10^-6 in precision 7 decimal digits or
3.141600x10^0
      is the same as the rational number 31416/10000

BUT If you want to specify this as
3.1416x10^0  in precision 7 decimal digits, then you better
say so.  

Since it gets tiring to write (and read) numbers
like 1.000000000000000000000 and 0.00000000000000000000
you might prefer to say
1.0e0 precision 35.

Note that 

3.1416x10^0 in precision 4 decimal digits IS IMPOSSIBLE!!!!!

The closest precision 4 decimal float is

3.142x10^0  which is the same as the rational number 3142/1000.

Notice that this too is an exact number.

All arithmetic is done with the general view towards finding that
number that 
(a) is a floating point number Z of the right precision and
(b) where Z is that (exact) fp number that is closest to the
   exact mathematical answer.  Rules for resolving "half-way"
   cases are needed; usually "round to nearest even" is used.

So to repeat:  all floating point numbers are exact. They have
a precision that is specified by the number of bits or digits
in the magnitude of their fraction.  If it is not obvious
on the face of it what the precision is, you'd be better off
specifying it.
If you allow x=1.e0 to mean 1 decimal digit precision,
 then (14*x)/10 =x. 
Mathematica has some crazy unenunciated rules that are something
like the precision is the minimum of (the number of 
input decimal digits*0.3010+some slush, 18)


>>>> hmm something not explicit in James' proposed construct in the CD.
>>>> It could be added though.
>This is precisely why the bigfloat CD does NOT have a precision view.

I don't know what "view" means here, but I hope I've clarified
why precision might very well be a separate attribute for bigfloats.

>It would certainly be possible to add more objects to the bigfloat CD,
>or create an extending CD which had precision as well, or to do
>various other things. However, there are some issues, such as absolute
>error versus relative error, which need to be thought about, and there
>is also the question of what semantics the precision implies. Do we
>even want to suggest the Mathematica semantics?

Ideal floating point arithmetic semantics are clear enough. Given
those semantics one can compute the maximum relative or absolute
error of any sequence of basic arithmetic steps. I do not expect
that more needs to be done beyond this.

Mathematica's semantics are terrible. They come from some 
freshman physics lab rule of thumb about error, totally inappropriate
for sequences of calculations such as convergent iterations.
Mathematica's use of the words "Precision" and "Accuracy" are
its usage alone.  Its rules for propagating them are, even after
several revisions (some of which I hope I may have provoked) still
inadequate.


>>>> > Let me repeat:  if the precision of a bigfloat in some representation
>>>> > is not apparent, then THAT IS NOT ACCEPTABLE.
>I have problems reconciling this with the statement I quoted above.

James:  are we reconciled now?")


>>>> James, what about adding a fourth child to bigfloat constructor?
>As you can probably guess by now, I am not convinced.
>I'd certainly want to think about it.
>James




More information about the Om mailing list