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

On Tue, Oct 14, 2008 at 1:18 PM, Raymond Toy <raymond.toy at ericsson.com>wrote:

> Stavros Macrakis wrote:
> > I repeat: neither Lisp nor Maxima code should EVER look at bigfloat%pi,
> > which is an internal variable used as a cache by fppi.
>


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

Only if the cached value is being used incorrectly.  fppi can do whatever it
wants to bigfloat%pi as long as fppi is correct.... I repeat: can you
demonstrate the bug using the correct interface, (fppi)?

(%i1) zot(z,fpprec):= bfloat(%pi*z/sin(%pi*z))$
(%i2) fpprec:64$
(%i3) zot(bfloat(1/2),fpprec)$
(%i4) :lisp (fppi)
(41356040229830605799206175877058042562270358908835127062817736159 2)
(%i4) :lisp ($bfloat '$%pi)
((BIGFLOAT SIMP 215)
 41356040229830605799206175877058042562270358908835127062817736159 2)
(%i4) :lisp (displa ($bfloat '$%pi))
3.141592653589793238462643383279502884197169399375105820974944592b0

I haven't read your code, but I would recommend the following code if you
are setting a local value of fpprec:

(defmacro bind-fpprec (val expr)
 `(let (($fpprec) (fpprec) (bigfloatzero) (bigfloatone) (bfhalf) (bfmhalf))
    (fpprec1 nil ,val)
    ,expr))

And don't forget that $fpprec is decimal digits, while fpprec is binary
digits.

          -s