Mine's limited to the size of the 83's memory (4 bytes per base-100 digit, or 2 bytes per decimal digit), so while it can do a few more than 10000, it can't come close to 1000000.

That just gave me an idea...how about a machine dedicated only to calculating pi? It could have a fast processor with an integrated FPU (to make the programming much easier), very accurate trig tables in the ROM, and HUGE amounts of RAM to store all the digits!

They already exist. Supercomputers have been reserved for the sole purpose of calculating pi.

what about my favorite number, e?

With high probability.

"very accurate trig tables in the ROM"

Um.

Oh yeah, that is sort of stupid...forget about that part...

If you're going to go that far, dispense with software, and make pi calculations a processor function (like square root on the G5). Then write it to a text file on a large SAN setup all RAID 0'ed together. When it's dne, all you'd need to do was move the cable on the SAN to a computer and write a program to read through the file and perform whatever further calculations necessary.

That's an even better idea...pi calculations in hardware...use a few high-density FPGAs or something like that. :-p

I tried, but I don't have the mad math skillz required. :^(

The largest you've ever seen!

Not to be a stupid idiot, but how would one go about writing a program to calculate Pi? (I usually write games, so this isn't really my field.)

Pi=integral(x=0 to 2,(4-x^2)^.5 dx)
Pi=1+sum(x=0 to infinity, increments of 2,-1/x)
Pi=4 Arccot 1
Pi=4(12 arccot 18 + 8 arccot 57 - 5 arccot 239)
(in the expressions involving infinity, just substitute a very large number - the larger the number, the greater the precision)

BTW, pi is NOT 22/7. (Hey, remember the time that guy said that it was, and we all spammed him with many digits of pi?)

Good times...

Not to be devious or anything, has anybody ever written a program to crash someone's calculator by calculating loadza digits of pi?

I don't think that could happen in BASIC, it would just stop and say Error Memory. It could probably happen in ASM, but I'm not sure, I don't program in ASM.

Do you mean overwriting their memory with digits of pi? It would be a lot easier and just as effective to overwrite it with all $00s or $FFs.

Style, buddy. It is all in the presentation and execution more than it is the end result. Yes, you will get the same result, but then you are not doing anything more than anyone else.

-W-

Can trig functions fairly be used? I'm not sure how they are derived but don't they NEED pi to function in the first place? (Just referring to the two latter examples.) Otherwise you could just type arccos(-1) Which of course is an apporximation.

No, I think many, if not all, trig functions use sums (the operation associated with those large pointy E-like symbols)...

Ahh, really? I thought they used look-up tables to grab trig values. And that's why you can't calculate pi with arccos(-1). You'd only get as many digits as were stored in the calculator (usually 12, I think?). You'd have to use one of the formulas above (like you were saying; one of the sum formulas) if you wanted to get more than 12(?) digits.

Err, but I'm often wrong, so don't listen to me :-P

Most machines probably do use trig tables, or have algorithms that have nothing to do with sigma summations.
But if you /did/ use sigmas to high accuracy, you could get pi with arccos(-1).

Calculators use look-up tables but only because it's quicker than calculating using the summation technique...the lookup tables were calculated using summation...

Your "large pointy E-like symbols" are sigmas.

Thanks, I keep on forgetting the name.

Not to sound stupid either (I am also a game programmer), but how do we compute the nth digit of pi? We can get the first 10-ish digits of pi on a calculator, but how do we get the 100th? The 10000? The 3141592653589th digit? Moreover, how do we do it accurately, when registers on an FPU are only 128 bits at most? This we do not know.

First Google hit (link)

You can calculate the nth hexit with it!

Furthermore, Plouffe discovered a new algorithm to compute the nth digit of p in any base!

A nice pi chronology site (link).

But 22/7 is a fair approximation, only .001% less accurate than 3.14. I did the calculations of that myself, like five years ago.

Wait...

Only 0.001% less accurate?

That would make (22/7+3.14)/2 an insanely accurate representation of pi.

Okay, not /that/ insanely accurate, but still insanely accurate enough for my purposes.

22/7 has a .0402499% error.

3.14 has a .0506957% error.

So I was wrong. 22/7 is better than 3.14. Oops. (I was remembering calculations I did years ago. I got them mixed up.)

The average [(3.14+22/7)/2 = 3.141428571] has a .0052228% error.

So it would be better to use pi.

Yes, it is accurate enough for most calculations, but it still looks like a huge difference to us nerds who memorize >50 digits of pi. ;-)

here is a c program that will calculate pi it is based on the formula:
PI/4 = 1/1 - 1/3 + 1/5 - 1/7 + ...
the more loops the more accurate.

float pi=1;
unsigned i;
for(i=0;i<100;i++){
float toadd=1/(float)(2*(i+1)+1);
if(i&1)pi+=toadd;
else pi-=toadd;
}
clrscr();
printf("%f",pi*4);
ngetchx();

That second equation of mine is obviously wrong, and I think the one you wrote is really what it's supposed to be...

Well, two things

I read somewhere that thid method of calculating pi was really inefficient. Like, it takes a ridiculous amount of loops just to get a few digits of accuracy. That does make sense though if you think about 1/n. (Please correct me here if I'm wrong) You'll only have accuracy in pi n digits after the decimal point after you get to the (10^n/2)th loop. So, for just eight digits of accuracy, you'd need 50 million loops. That would take forever.

The other problem with this is, floating points only hold so many digits. I forget how many it is, but they're limited. If you wanted to calculate a lot of digits of pi, you'd need a much larger variable type to work with. Perhaps if you could somehow allocate a large section of memory as a "long long long ..." unsigned integer... I don't know how to do that though. I thought of using a large string when I wanted to make a problem like this a while back, but then I realized that the conversion of numbers to and from the string would take too long and would slow the program down even more.

Anyway, the only real experience I have in calculating pi with a computer is with this program I made in Java a few years back, and if I remember correctly, I only got 7-8 digits of accuracy with it. Sometime in the future I'll come up with a better plan though.

You're right...it does take a huge amount of time, and, without making a super precise class, it won't give you any more precision than the float class in Java anyway...you'd have to find some way to store the number in a string and calculate division of 1 by 5893 accurate to 1,000,000 decimals...ugh...

Yeah, the entire thing can never be stored in one number, you have to calculate the digits separately or something like that...