Stockly.com Forums  

Go Back   Stockly.com Forums > Kenbak-1 Series 2 > Kenbak-1

Notices

Reply
 
Thread Tools Display Modes
  #1  
Old 11-04-2007, 01:16 PM
Architect Architect is offline
Junior Member
 
Join Date: Oct 2007
Location: Netherlands
Posts: 14
Default Calculating e

So I managed to calculate e

e = 1 + 1/1! + 1/2! + 1/3! ....

up to 88 decimals. I used 120-176 for the term and 320-376 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.
Reply With Quote
  #2  
Old 11-04-2007, 07:16 PM
Grant Stockly Grant Stockly is offline
Administrator
 
Join Date: Jan 2005
Posts: 447
Default

Bytes 129 to 131 are special. They are overflow and carry for the A/B/X registers.

That might be messing up your program???
Reply With Quote
  #3  
Old 11-05-2007, 02:04 AM
Grant Stockly Grant Stockly is offline
Administrator
 
Join Date: Jan 2005
Posts: 447
Default

Sorry, when you said 120-176 I thought we were talking about decimal byte count. I see that you then refer to 320-376 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...
Reply With Quote
  #4  
Old 11-11-2007, 11:54 PM
Cappellanus Cappellanus is offline
Junior Member
 
Join Date: Jul 2007
Posts: 24
Default 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 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.

Oh, and Grant: No, had a work emergency, so I didn't get much construction done on my Kenbak-1. I was very excited to hear about "no-clean" 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 radio-shack has some for very cheap. Got some, can't wait to try it!!!

Last edited by Grant Stockly; 09-10-2012 at 09:16 PM.
Reply With Quote
  #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
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 09:32 AM.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2024, vBulletin Solutions, Inc.