[Maxima] SF [2159499] Full bigfloat precision for Gamma after the second call
Stavros Macrakis
macrakis at alum.mit.edu
Tue Oct 14 12:46:22 CDT 2008
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.math.utexas.edu/pipermail/maxima/attachments/20081014/318e1e2f/attachment.htm
More information about the Maxima
mailing list