[Maxima] SF  Full bigfloat precision for Gamma after the second call
raymond.toy at ericsson.com
Tue Oct 14 13:03:03 CDT 2008
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
> > 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:
Compare that to the true value of pi:
That is the digits from 200248... are wrong.
And this happens because the cached value in bigfloat%pi is just plain
I think fppi is correct. It's the computation in fppi1 that is
incorrect because it uses $fpprec instead of fpprec.
More information about the Maxima