Re: [Maxima-discuss] bfloat accuracy, %pi

[Raymond T. <toy...@gm...>]

>>>>> "Richard" == Richard Fateman <fa...@be...> writes:

    Richard> consider
    Richard>    v:  18190586279576483
    Richard> which has the interesting property that it is
    Richard> only 17 digits long but it is very nearly a multiple
    Richard> of pi/2
    Richard> in particular,
    Richard> 5790243448268414.5b0*%pi

    Richard> is
    Richard> 18190586279576483.000000000000000025...b16

    Richard> consequently

    Richard> cos(v),numer   comes out -0.84
    Richard> cos(v),bfloat comes out 2.55...b-17

    Richard> so the answers
    Richard> differ by 16 orders of magnitude.

    Richard> This is not actually so surprising to me because we are using machine floats
    Richard> for the first, and software floats for the second.

    Richard> However, cos(v),bfloat should be more accurate  (good for fpprec
    Richard> decimal digits)
    Richard> but is not so.  Increasing fpprec changes many of the digits that
    Richard> should be right.
    Richard> So the computation of how many digits of pi are needed to normalize
    Richard> the answer is apparently inadequate.
    Richard> Thoughts?

It certainly would be nice.  I think maxima still uses your original
algorithm to compute these bigfloat values, so you're probably the
best one to comment on this. :-)

Setting *fpsincheck* to T seems to show that fpsin used up to 119 bits
(from 64) to compute the result.

Perhaps the cancellation check is too lose?

--
Ray