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

Stavros Macrakis wrote:
> On Tue, Oct 14, 2008 at 1:18 PM, Raymond Toy <raymond.toy at ericsson.com
> <mailto: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)?

Ok, ok. :-)

Here it is:

zot(z,fpprec):= bfloat(%pi*z/sin(%pi*z))$
fpprec:64$
zot(bfloat(1/2),fpprec)$
fpprec:128$
bfloat(%pi);
3.1415926535897932384626433832795028841971693993751058209749445923078164\
062862089986280348256812002485034480173261900300090541701b0

Compare that to the true value of pi:

3.1415926535897932384626433832795028841971693993751058209749445923078164\
06286208998628034825342117067982148086513282306647093844609\
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

That is the digits from 200248... are wrong.

And this happens because the cached value in bigfloat%pi is just plain
wrong.

I think fppi is correct.  It's the computation in fppi1 that is
incorrect because it uses $fpprec instead of fpprec.

Ray