Thread: Calculating e
View Single Post
  #5  
Old 12-02-2007, 11:36 PM
Architect Architect is offline
Junior Member
 
Join Date: Oct 2007
Location: Netherlands
Posts: 14
Default e and pi

Quote:
Originally Posted by Cappellanus View Post
I'm very intrigued on your calculation of e. Do you plan on sharing the program with us? I suppose you just need a division routine and an addition routine, but how exactly you do this isn't clear to me.

So you have to divide the "term" which starts at 1, by 2, 3, 4, 5, 6, and so on up to 78, which I guess are all holdable in a single byte. So after some allowance for decimal point, you just have to divide a 47-digit value by a single-digit (if you think of this as base-256 numbers), and keep track of where the decimal point is, and then add the result into the "sum". For the division, if you just shift a single-bit, and get a single-bit of the result, and only have to subtract 1 or 2 bytes out of the term, that wouldn't be too bad. But wouldn't that destroy the term, so you need another 47 bytes to keep track of intermediate results? I'm getting confused.

I may try writing the algorithm in "C" and suppose I could then check the term after each iteration, as well as the sum, and try to figure out where the error is.

I've always wanted to find a good "Pi" generator. I don't think there's a fast-converging taylor series for that, and I doubt there are similar simple algorithms. I think most quickly converging (high-digit producers) are more complex than I could program in assembly, especially if I have to toggle it in a byte at a time.

I'd love to see the code.

...
I've been traveling the last few weeks (Thanksgiving to the US actually) and haven't worked on the program.

For e I simply leave out the first term (1) and only keep track of the bits behind the decimal point. So I start with the TERM and the SUM being (binary): [0.]10000000 00000000 .... If you do the division with a number that is only one byte you see that you generate one bit per bit that you eat up with the division so that you can rotate the result left into the existing byte. Something like that. I will write it out in more detail next couple of weeks.

I once calculated pi from:

pi/4 = tan^(-1)(1/2) + tan^(-1)(1/3) where

tan^(-1)(x) = x - x^3/3 + x^5/5 -x^7/7 + ...

This converges for 1/2 and 1/3 pretty rapidly as well. This is not the way the real number crunchers calculate it, but it is enough to show you can calculate pi.
Reply With Quote