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

Hello,

I have nothing to contribute to solve the problem, but thank you very much for
your work on the problem. 

It is very interessting for me to follow your discussion to solve the problem.

Dieter Kaiser

-----Urspr?ngliche Nachricht-----
Von: maxima-bounces at math.utexas.edu [mailto:maxima-bounces at math.utexas.edu] Im
Auftrag von Raymond Toy
Gesendet: Dienstag, 14. Oktober 2008 20:03
An: Stavros Macrakis
Cc: Maxima List
Betreff: Re: [Maxima] 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
_______________________________________________
Maxima mailing list
Maxima at math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima