#1




Calculating e
So I managed to calculate e
e = 1 + 1/1! + 1/2! + 1/3! .... up to 88 decimals. I used 120176 for the term and 320376 for the sum. The program that converts to decimals by multiplying with 10 and displaying the result digit by digit is actually larger than the program that calculates e. Next project is turning the handwritten programs into nice assembler listings. Perhaps I can find the mistake in the program as well. I used 47 bytes and that is 113 digits. I calculated up to 78! which has 115 digits and indeed the term was zero except for the very last bit. So over 110 digits should have been correct. Cannot be hardware, because 1 faulty bit in the delay line and absolutely nothing works. 
#2




Bytes 129 to 131 are special. They are overflow and carry for the A/B/X registers.
That might be messing up your program??? 
#3




Sorry, when you said 120176 I thought we were talking about decimal byte count. I see that you then refer to 320376 so that clears up the number representation.
My initial thought was that if you were overwriting the status registers then that could be a problem... 
#4




I wanna calculate 'e' toooo......?!?!...
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 47digit value by a singledigit (if you think of this as base256 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 singlebit, and get a singlebit 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 fastconverging taylor series for that, and I doubt there are similar simple algorithms. I think most quickly converging (highdigit 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. Oh, and Grant: No, had a work emergency, so I didn't get much construction done on my Kenbak1. I was very excited to hear about "noclean" solder. I'd never heard of this before. I always hated rosin residue, almost as much as I hated trying to clean it off without getting IC sockets coated with a thin layer. I googled it, I read up a bit, and was surprised to see radioshack has some for very cheap. Got some, can't wait to try it!!! Last edited by Grant Stockly; 09102012 at 09:16 PM. 
#5




e and pi
Quote:
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. 
Thread Tools  
Display Modes  

