evalf()/Digits bugs

[Richard B. Kreckel]

Hi,

On Mon, 7 Jan 2002, Bob McElrath wrote:
> Well, it sounds reasonable, but is counter-intuitive.  Consider Maple:
> 
> (0)<mcelrath at draal:/home/mcelrath> maple
>     |\^/|     Maple V Release 5 (WMI Campus Wide License)
> ._|\|   |/|_. Copyright (c) 1981-1997 by Waterloo Maple Inc. All rights
>  \  MAPLE  /  reserved. Maple and Maple V are registered trademarks of
>  <____ ____>  Waterloo Maple Inc.
>       |       Type ? for help.
> > evalf(1/3);
>                                   .3333333333
> 
> > Digits:=30;
>                                  Digits := 30
> 
> > evalf(1/3);
>                         .333333333333333333333333333333
> 
> Here it not only returns the number of digits requested, but does not show odd
> rounding errors.  I'll see about a patch.
> 
> I worry a little bit that after some computations, your answer wouldn't be
> accurate to Digits accuracy because of machine-word rounding effects.

Oh, if you worry about that, then throwning away digits in the output is
not going to help since it is merely cosmetic.  If we could have
two digits, then compared to 3.3, you are saying that 3.333 is better than
3.3334.  Why bother?

If you are doing longish computations and at the end your result is either
NaN or zero or -10^5 while it should have been unity is something that
falls under the "shit happens" category.  It may happen with double-
precision and proper IEEE rounding, don't forget that!

The only way out seems to be interval arithmetic, but that is at least
twice as costly and can only be defined rigorously on ring-operations.

Another alternative would be to attach the precision to which any floating
point object is correct to that object and correctly handle that
precision.  But that does not work either.  Try this in Mathematica:

In[1]:= x=1.11111111111111111111;
In[2]:= Do[x=2*x-x,{50}];
In[3]:= If[x==x+1,"Mathematica fundamentally alters the mechanics of mathematics"]

You'll see a funny thing happen.  (BTW: the quote is from the book's
cover.)  And I bet you'll easily find similar things in Maple, too.

William Kahan once said that it is a "folk theorem" that under any
implementation of significance arithmetic there must exist chains of
operations that lead to either an unwarranted loss of significance, or to
a gain in significance, or both.  [Quoted from Richard Fateman's famous
Mma-Review.]

My point is that numerical stability is a game for which there is no
win-strategy.  Hence, we shouldn't pretend providing one.

Cheers
    -richy.
-- 
Richard B. Kreckel
<Richard.Kreckel at Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>