|
|
On Thu, 24 Apr 2003, Andrew Coppin wrote:
>> >3.1415926535897932384626 IIRC
>>
>> ha ha .. yes .. more or less .. off the top of my head I recall
>>
>> 3.14159 26535 89793 23846 26433 83279 50288
>
>3.1415926535897932384626433832975028841971693993 :-P
^^
I know that you have it in your head ( why? ) but you fingers had minor
dyslexia ! :)
>
>> more or less ... I think that I can do at least fifty digits in five
>> digit groups .. for no good reason.
>
>Likewise; whenever anyone asks why my memory is so bad, I tell them I
>already used it up with pi. (And statments like "the diffusional rate of a
>gas is inverstly proportional to the square root of its density" or "a
>relation is a subset of the extended Cartesian product of the domains of its
>attributes". And the op-code for RTS in 6502 machine code - in hex and
>decimal. Man, I need a life...)
oh God! another math-physics major!
I used to be able to program 6502 assembly off the top of my head also,
many years ago. Back when the Commodore 64 with 64K or RAM was huge!
>
>> In any case .. perhaps a POV render of Pi related art could be done?
>
>I know (or rather, have on file) a rather neat algorithm for calculating
>pi... used it to write a program which could find hundreds of digits fairly
>fast... hmmm...
well .. maybe there is a way to do a render in which a really slow method
of finding pi could be used to do successive image frames of geometric
objects where the approximation to pi would be used to generate the object
structures. After about 100 frames we could have pretty much perfection but
the initial fifty frames would be akin to a Salvador Dali painting coming
to life with lots of bent and twisted objects.
Sound cool?
The slowest convergence to pi is achieved with a Riemann sum where s=2
thus :
zeta(s) = 1 + (1/2)^s + (1/3)^s + (1/4)^s + (1/5)^s + ... + (1/n)^s where
n should be inf. It was Leonhard Euler that discovered in the 1700's that
zeta(2) converges on the square of pi divided by six. This simple and slow
fact has been used by me for two decades now to benchmark the floating ops
of various processors. The Sun UltraSparc III had an initial NAN problem
that would induce a massive wait state in the processor. This has since
been fixed. I have a Intel Pentium P90 processor system here with the math
flaw and it produces the same result on either of its two processors.
In any case, it would be neat, in a very geeky kind of way, to produce an
animation of various objects sorting themselves out with various n.
SunOS ag0 5.8 Generic_108528-10 sun4u sparc SUNW,Sun-Fire-280R
$ time -p ./pi
pi at n=1073741823 is 3.14159264498
real 30.81
user 30.80
sys 0.01
As you can see from the above, it takes a large n to get any real precision.
Dennis Clarke
dcl### [at] blastwaveorg
---------------------------------------------------------------------------
/********************************************************************/
/* Standard PI calculation using an infinite series - Dennis Clarke */
/* */
/* Purpose : Calculate pi using the least efficient method known */
/* without actually resorting to drawing a circle in the */
/* sand and measuring it. */
/* dcl### [at] blastwaveorg */
/********************************************************************/
#include <locale.h>
#include <stdio.h>
#include <sys/time.h>
#include <math.h>
int main(int argc, char *argv[]) {
double pi = (double) 0.0;
unsigned long i;
/*****************************************************/
/** sum the series 1/(x^2) **/
/*****************************************************/
fprintf ( stdout, "\n\n" );
for (i = 1; i < 1073741823; i++) {
pi = pi + (double)1.0/( (double)i * (double)i );
}
fprintf(stdout, " pi at n=%9u is %.12g \n", i, sqrt( pi * (double)6.0 ));
exit(1);
}
--------------------------------------------------------------------------
Post a reply to this message
|
|