Infinite Possibilities in Life, or NOT!

[dellcom]

ok i am running bc with these parameters:

*****

time bc -q -l << EOF > infty_craig.txt

scale=5000000

10^((l(2)/l(10))*11520000)

quit

EOF

exit 0

 

*****

 

I am running it on my server (P4 2.8 hyperthreaded) don't want to sleep in my room with my desktop on all nite. but the result should be ready tomorrow...

[CraigD]

When I get home, I’ll see if I can write all 3-ish MBs of the exact decimal value of [math]2^{11520000}[/math] to a file. The last digit will be 6 ;)

I claimed more than my ill-suited prototyping interpreter and clunky old laptop can quickly deliver.

 

Calculating a mere [math]2^{800*600} = 2^{480000}[/math] took it over 500 s, and produced the 144495 decimal digits in the attached text. As expected, the last (least significant) digit is 6. Calculating [math]2^{11520000}[/math] would take about 3 days! :(

 

My calculation uses a simple “long multiplication” program to extend my built in calculator’s precision from 18 digits precision to the precision limited to amount of free memory on my box. To reduce the number of multiplications from 480000 to 26, I use Newton’s (I think it was) old method:

[math]2^{480000} = (((((((((((((2^2)^2)^2)^2)^2)^2)^2)^2)^3)^5)^5)^5)^5)[/math].

The first 18 multiplications produce a roughly 28000 digit decimal number in under a second. The next 8 take about 500 seconds to produce the final 144495 digit number.

[alexander]

no it actually did not, took only a few minutes, one thing bc does really well is simple operations, like exponentiation... and it ends on 76 :P (check the attached 3 meg file)

 

you wanna calculate pi to the neares 1millionth place? no problem, just run bc, set scale to 1,000,000 and run 4*a(1) (thats [math]4*\arctan(1)[/math])

[dellcom]

The server is still computing your equation alex.

[alexander]

well, the answer sould be damn close to what we have computed before, just its a hell of a lot harder to calculate (probably will take days...)

 

Craig, you can double check the answer file with what you get once you are all done calculating it, i'm sure the answer will be the same though, bc does as good of a job at math as any other arbitrary decimal point calculator, also only limited by your hardware...

 

I'll rerun the calc on this machine, and test the output for being the same as the one i posted....

[alexander]

just reran the 2^11520000 calculation.... the answer is exactly the same as the one i posted originally, ran on a different machine, in a different environment, so i think there is no need to question that result.... btw you want me to run the 2^(800*600) to check your math program's math?

 

and i just started on the last calculation check for you Craig, i now also have a system churning with the calc...(the 10^power one)

 

if the program runs correctly, the answer should be the same...

[alexander]

actually, it should be similar

the problem with having logs is ofcourse that the actual answer of log 2 / log 10 is an endless number....and it will be approaching the real result of 2^power

[dellcom]

Ok well we know we have the number of images it will take (a big number that begins with 3 and ends with 6).

 

So lets turn this into a real computer science problem. How to write an efficient algorithm to produce the images, and then test them to find somthing we are looking for.

 

-----i.e.

In the first run through for a proof concept we could generate the range of images [math]2^{800*600*24}[/math] and only store the ones that have a picture of a coke can that would be found from the accual pattern of a coke can that we input. That alone should produce many images with the same coke can in different positions with diffrent backgrounds. (while the can may be in different areas of the screen it would still be the same size/pixel combination). The backgrounds would be interesting to look at, but the proof of concept would be solid.

 

The first step, though, is to figure out how much time it would take at a given computational power. My desktop has 64bit dual core 2.4 ghz amd processor (x2 4200+) 2gb ddr 800 memory. So using that as a baseline we can use 2^{800*600*24} divided by the time it take to generate 1 image and scan it for the coke can we would have an estimate of the time it would take to just find all the coke cans that fit the profile we specify. right?

[alexander]

more then our lifetimes... even on a super computer, given that it will take 1 second to generate one image, it would take [math]\frac{2^{11520000}}{31556926}[/math] years to generate all the images

[dellcom]

more then our lifetimes... even on a super computer, given that it will take 1 second to generate one image, it would take [math]frac{2^{11520000}}{31556926}[/math] years to generate all the images

 

assuming it takes a whole second...

[alexander]

i mean the number is so large that even if it took 0.0000001 of a second for the operation, it will still take over 30000 duotrigintillion years to do... thats 3000 googols

[dellcom]

i mean the number is so large that even if it took 0.0000001 of a second for the operation, it will still take over 3000 googol years to do...

 

guess we'll have to wait for the quantum comuter

[alexander]

thats 30000 duotrigintillion years (i dunno what the multiple of googol would be called)

[CraigD]

just reran the 2^11520000 calculation.... the answer is exactly the same as the one i posted originally, ran on a different machine, in a different environment, so i think there is no need to question that result....

If we’re talking about [math]2^{11520000} \overset{\cdot ?}= 3.5485*10^{3518864}[/math], there’s a very great – on the order of [math]10^{50999}[/math] - need to question it. This isn’t a matter of an absolute precision calculator result (these numbers are approximations, not exact) but of ordinary, calculator-independent arithmetic.

[math]2^{11520000} \dot= 10^{3467865.550049063366}[/math]

[math]3.5485*10^{3518864} \dot= 10^{3518864.550044809565}[/math]

[math]\frac{10^{3518864.550044809565}}{10^{3467865.550049063366}} > 10^{50998}[/math]

, a discrepancy vastly greater than the ratio of the diameter of the observed universe to the diameter of an electron (about [math]10^{41}[/math])! :eek_big:

 

I’m pretty certain alexander’s digit counting is off.

 

The “rule of thumb” value for converting between exponents of 2 and 10 is [math]2^n \dot= 10{0.3n}[/math] – that is, taking [math]0.3[/math] as a reasonable approximation of [math]\frac{\log 2}{\log 10}[math], which is more precisely about [math]0.301029995663981195[/math]. This works pretty well for everyday use - a gigabyte, [math]10^9[/math] bytes, is about the same as a gibibyte, [math]2^{\frac{9}{0.3}} = 2^{30}[/math].

 

Using the rule of thumb conversion, [math] 2^{11520000} = 10^{3456000}[/math]. The small difference between the true and rounded value, [math]\frac{\log 2}{\log 10} – 0.3[/math], results in a huge inaccuracy for a number this large (more than a factor of [math]10^{11865}[/math]), though still not as large as the inaccuracy of alexander’s estimate.

btw you want me to run the 2^(800*600) to check your math program's math?

I tried it myself. I got the same length number, the same beginning and ending digits, but trouble in between:

bc
(((((((((((((2^2)^2)^2)^2)^2)^2)^2)^2)^3)^5)^5)^5)^5)
24998774035993205444433753815033871061600767873722842002210088701961
...
258927383952186313714921056293985697562088229712882680647909376

d BIGNUM^HPMA(800*600),IW^HPMA (.AA)
24998784124998784199892193307271337435454987065508954634521075293423
...
342694337611608076927782930534339981101862341400294936647909376

So my nice new code must not be quite up to the standards of a third grader when it comes to multiplication! :( (why does no code seem to work on the first try?)

 

Interestingly, this more straightforward expression causes trouble for my instance of bc:

bc
2^(800*600)
exp too big 

My unix box is a fairly speedy 8 CPU RS6000, and took 92 sec to do the nested small exponents, vs. my clunky laptop within a MUMPS interpreter’s 500 s. I’m curious to see how quickly bc on the unix box would handle [math]2^{24 \cdot 800 \cdot 600}[/math]

 (((((((((((((((((2^2)^2)^2)^2)^2)^2)^2)^2)^2)^2)^2)^3)^3)^5)^5)^5)^5)

but not quite enough to try it

 

I’ve a feeling that bc, though an “arbitrary precision” calculator, may not be being absolutely precise in calculating integer exponents when the exponents are large (presumably some configurations or uses of it don’t just puke on large exponents the way mine did). Rather than performing a program of absolute precision integer multiplications, which results in an exact integer value, I suspect it generates a high-precision estimated of [math]\ln 2[/math], multiplies it by the exponent (11520000 or 480000), then generates a high-precision estimate of [math]e^{\mbox{result}}[/math]. Unless the precision used by these estimates if very high – more than the 3+ million decimal digits of the result – the result won’t be correct to within [math]\pm 1[/math]. If displayed in its full precision, the result is likely not an integer.

[alexander]

you have to use math standard lib, try bc -l oh also you can find limitation of your computer by typing in "limits" at the bc prompt

 

and its about 5-7 minutes for [math]2^{24*800*600}[/math]

 

BC has been around for so long, and had it's code looked at by so many people, an accusation of bc being innacurate, even with large exponents is quite honestly obsurd, so i propose to test bc

 

so to check arbitrary precision of bc i have devised a rigorous test, such as calculating pi to 10000 places and then comparing it to real calculation of pi, at least first few hundred digits.

 

Oh, right, the "real pi"... here's the basic program that will calculate pi to arbitrary amount of digits, i am running this till 10000:

'PI.BAS 'Prints PI to number of decimal places desired. 19830623tac.
'        Ref: American Mathematical Monthly vol#45,1938 p657-667.
'        Ref: Best of Micro vol.#1 p85-86.
'
'
'             *       ----                      ----
'        *****              16(-1)^k+1                   4(-1)^k+1
'       * * *   ---     >   ------------    --    >    ----------------
'         * *   ---    /    (2k-1)5^2k-1         /      (2k-1)239^2k-1
'         * *         ----                      ----
'        *   *        k=1                       k=1
'
'
'
'
'

main:
TEN = 100
INPUT "Enter number of digits wanted";SIZE:
SIZE = (SIZE + 1) OR 1
PLACES = SIZE - 1

IF SIZE > 200 THEN TEN = 10 ELSE SIZE = (SIZE + 1) / 2

DIM POWER(SIZE),TERM(SIZE),RESULT(SIZE)
K(1) = 25 :K(2) = 239   'Constants
C(1) = 5 :C(2) = 239

'Main loop.
FOR PASS = 1 TO 2

Init:
FOR L = 0 TO SIZE
POWER(L) = 0 :TERM(L) = 0 :IF PASS = 1 THEN RESULT = 0
NEXT L
POWER(0) = 16 / PASS ^2
MODE = 0
DIVISOR = C(PASS)
gosub divide
XPONENT = 1
SIGN = 3 - 2 * PASS
'

copy:
FOR L = 0 TO SIZE :TERM(L) = POWER(L) :NEXT L
'
MODE = 1
DIVISOR = XPONENT
gosub divide

MODE = (SIGN < 0) + ABS(SIGN > 0)
gosub addsub

XPONENT = XPONENT + 2
SIGN = -SIGN

MODE = 0
DIVISOR = K(PASS)
gosub divide

IF PASS = 2 THEN gosub divide

IF ZERO <> 0 THEN goto copy

NEXT PASS
'
'Print result.
PRINT
PRINT
PRINT "The value of PI to";PLACES;" decimal places"
PRINT
PRINT RESULT(0);".";
FOR L = 1 TO SIZE
IF (TEN = 100)*(RESULT(L) < 10) THEN
  PRINT "0";
  PRINT USING "#";RESULT(L);
  GOTO nxt
  end if

PRINT USING "##";RESULT(L);

nxt:
NEXT L
PRINT
end

divide:
'Division subroutine.   mode0 =  Power(x)/Div else mode1 =  Term(x)/Div.
DIGIT = 0 :ZERO = 0
FOR L1 = 0 TO SIZE
 DIGIT = DIGIT + TERM(L1) * MODE + POWER(L1) - POWER(L1) * MODE
 QUOTIENT = INT(DIGIT / DIVISOR)
 RESIDUE = DIGIT MOD DIVISOR
 ZERO = ZERO OR (QUOTIENT + RESIDUE)
 IF MODE THEN TERM(L1) = QUOTIENT ELSE POWER(L1) = QUOTIENT
 DIGIT = RESIDUE * TEN
NEXT L1
MODE = 0
return

addsub:
'Add/Subtract subroutine.       mode - 1 =  Subtract  else mode1 = Add.
CARRY = 0
FOR L1 = SIZE TO 0 STEP  - 1
  SUM = RESULT(L1) + TERM(L1) * MODE + CARRY * MODE :CARRY = 0
  IF (MODE = 1)*(SUM < TEN) + (MODE =  - 1) * (SUM >= 0) THEN goto t1
  SUM = SUM + MODE * -TEN :CARRY = 1

t1:
  RESULT(L1) = SUM
  NEXT L1
  MODE = 0
  return 

 

output will also be tested to be exactly the same, or not the same as the first 10000 digits at piday.org - one million digits of pi and PI to 4 Million (4194304) Decimals

 

So in bc I'm proposing a method of estimating pi used by Tokyo university, when they computed pi to the 1,241,100,000,000 place. by the use of this equasion:

[math]\frac{\pi}{4}=44\arctan{\frac{1}{57}}+7\arctan{\frac{1}{239}}-12\arctan{\frac{1}{682}}+24\arctan{\frac{1}{12943}}[/math]

 

that is 1/4 pi however, so the formula i'm really going to use is

[math]\pi=4\left(44\arctan{\frac{1}{57}}+7\arctan{\frac{1}{239}}-12\arctan{\frac{1}{682}}+24\arctan{\frac{1}{12943}}\right)[/math]

 

since we are a scientiffic community, i will also tell you exactly how i am going to calculate pi with bc.

 

equasion written in bc format

4*(44*a(1/57)+7*a(1/239)-12*a(1/682)+24*a(1/12943))

 

how i'm going to run it (i.e exact command line)

echo 'scale=10000;4*(44*a(1/57)+7*a(1/239)-12*a(1/682)+24*a(1/12943))' | bc -ql > pi.txt

scale=10000 - sets presision after the point (.)

bc -ql = bc + quiet + use standard math lib

 

um, the basic program will take a while to run too :(

so yeah, give me a few hours, for results

[alexander]

ok, basic program generated this attached file, its to 10000 places (or so i think) and i matched a random 30 digit long string, more then 100 places into the file, and it matched both of the websites, now to run the bc computation :D

[alexander]

bc output file.... check it yourself if you don't believe me

 

here is how i checked it aginst the pi to 4194304 file i linked to above

you can calculate yourself what the probability of hitting a 59 digit string in 4 million digits like this:

$ cat pi | grep '62865403603674532865105706587488225698157936789766974220575'
 308407611830130527932054274628654036036745328651057065874882256981579367897669
7422057505968344086973

 

and then hitting another (and only one, just like in the first case) 96 digit long hit like this one.....

$ cat pi | grep '675079812554709589045563579212210333466974992356302549478024901141952123828153091140790738602515'
 7267507981255470958904556357921221033346697499235630254947802490114195212382815309114079073860251522

 

 

Case and point, bc is pretty damn accurate!