Well, after tinkering around with my implementation of the BBP algorithm a bit more, i was able to get it to work out until about 108, but no further. I suspect that some kind of implicit type conversion was happening that was truncating values in an inappropriate way, resulting in loss of precision. So, after grumping about that for a couple of days, I rewrote the basic algorithm again using the gnu bignum library, and ran it last night as I went to bed. In the morning, I found:
Script started on Thu 08 Mar 2007 11:15:07 PM PST [chessboard] % ./a.out 0.6631159945223164865255091753630803566662e0 0.9631390752150799992020096304874891670995e0 0.2731996222104393979293359647540544136843e0 0.1069573797110732818888081014815876046136e0 pi = 0.5895585a0428b564084e74a23ba96459fb@0 12412.399u 43.758s 3:27:37.39 99.9% 0+0k 0+0io 0pf+0w [chessboard] %
If you compare this to the digits listed in Bailey’s paper, you’ll see they match, offset by one. It appears that in Bailey’s programs, he counts the initial 3 at the head of Ï€, whereas my program does not. I’m not sure how many significant digits I’m using, I doubt I’m getting much more than about 14 significant hex digits in the result. I’ll do another run, offset by one and see how much they overlap. Total runtime was about 3x slower than my version which used the native floating point formats, which on the whole isn’t bad.
Addendum: Just as a check, here’s my run to compute the 10 millionth digits of π to compare with what I did earlier.
[chessboard] % ./a.out 10000000 0.9529379795180445077636575590185365825231e0 0.2166774963446692996905073127592122197319e0 0.2634515579817620244087507021447804419826e0 0.6346364623910829689209479177718852530542e0 pi = 0.7af5863efed8de97033cd0f6b756186bf9@0 103.966u 0.464s 1:46.88 97.6% 0+0k 0+0io 0pf+0w
[tags]Mathematics,Pi[/tags]