29 Jul
2005
29 Jul
'05
1:25 a.m.
It was thus said that the Great Jerome H. Fine once stated:
I'll send file files directly to you (and not to the list).
-spc (Unless other people are interested in it ... )
After that, if the run times are reasonable, I can extend the code to
allow 64 bits - although I am not sure why since even running the
code to 20 billion takes more than 10 times 2 billion and doesn't
really prove anything. Looking at google, I have noted that PI(N)
has been successfully calculated up to:
N = 40,000,000,000,000,000,000,000
which is already over 70 bits, although it was not done by finding
the prime numbers, but by calculating Li(N) and then the error
between PI(N) and Li(N).
I think you are getting a bit confused. 4,000,000,000 can be represented
in 32 bits, but is only 10 digits. Generally, each 8-bit byte will give you
2.4 decimal digits of accuracy. So, 4 bytes will give you 9.6 digits, whch
is in the billions range (although only into the low billions---it's a
useful estimate). 70 bits will give you 21 digits. I think what you are
seeing above is that pi has been calculated to
40,000,000,000,000,000,000,000 digits, which would take something on the
order of 10**22 bytes to store (or 2**73 bytes, but I'm guessing they have
some other method of pulling out digits of pi other than storing them all
before printing).
For the PDP-11, I tend to understand that MUL is only
for signed
16 bit numbers, so I don't think MUL can be useful with unsigned
values which are required for a 64 bit multiple as per the above
example.
CAN SOMEONE PLEASE CORRECT ME IF I AM WRONG???
Easy enough method---just multiply the absolute values and record the
signs prior to multiplication, then reset the sign afterwards to the correct
value.
I have some C
code that does some of this---one is a C implementation of a
techique Woz used in calculating e to 100,000 digits (as described in Byte
magazine of either Dec 1980 or Dec 1981) and another one that does division
in C, if you are interested.
I am interested!!!!!!!