SF [2159499] Full bigfloat precision for Gamma after the second call

Stavros Macrakis wrote:
> On Tue, Oct 14, 2008 at 12:51 PM, Raymond Toy <raymond.toy at ericsson.com
> <mailto:raymond.toy at ericsson.com>> wrote:
> 
>     fpprec:64;
>     zot(bfloat(1/2),fpprec)$
>     :lisp bigfloat%pi
>     ((BIGFLOAT SIMP 438)
>      557478319480384710099680955233841104245484663623488188587759156163931561121116157458028029845525521685028647707875576434771246873456
>      2)
>     :lisp (displa bigfloat%pi)
>     3.1415926535897932384626433832795028841971693993751058209749445923078164062862\
>     089986280348256812002485034480173261900300090541701233b0
> 
>     So, for some reason, zot computed a 438-bit value of pi.  But compare
>     this with the "true" value of pi:
> 
> 
> I repeat: neither Lisp nor Maxima code should EVER look at bigfloat%pi,
> which is an internal variable used as a cache by fppi.  If you want the
> bfloat value of pi, you should call (fppi) if you're in bfloat code
> (where the (bigfloat simp NNN) part is implicit; if you're outside
> bfloat code, you should call ($bfloat '$%pi).
> 
> And remember that the value of (fppi) is only valid for the *current*
> value of fpprec.
>
> Can you find a problem without looking at bigfloat%pi?

Whatever you might think, what I'm showing is, in fact, relevant.  The
call to zot eventually asks for a 438 bit value of pi.  That is the
value that is cached in bigfloat%pi.  The last 36 digits are flat out
wrong.  If the cached value is wrong, the value of bfloat(%pi) is also
wrong.  There's no avoiding that issue.

Further investigation seems to indicate the bug is in fprt18231_:

(defun fprt18231_ nil
  (let (a n d h)
     (setq a 1823176476672000)
     (setq n 42698670666)
     (setq d 1000)
     (do ((prec 10 (* 2 prec)))
         ((> prec $fpprec))
       (setq h n)
       (setq n (+ (* n n) (* a d d)))
       (setq d (* 2 h d)) )
     (fpquotient (intofp n) (intofp d)) ))

If you trace through some of the calls, you'll see that we're computing
a 438 bit value of pi, but $fpprec is actually 64 at the critical point.
 $fpprec = 64 implies about 212 bits, so the value returned by
fprt18231_ doesn't have enough precision.  Changing it to fpprec instead
of $fpprec appears to fix the problem.  (And I'm not sure about the
initial value for prec.  Maybe that should be changed?)

That also fixes the issue Dieter was seeing.  Each call to his test with
different fpprec values returns the same error value, and is close to
fpprec.

Ray