Who Can Name the Bigger Number?
scottaaronson.com
scottaaronson.com
(7)^(7^(7^(9^(9 ... ))))))
after realizing about second into the challenge that the extra time taken to draw a 9 vs a 7 was worth it.
To my surprise, when we got back from lunch I was told that there was a tie for first place. I thought "how could this possibly be?"
It turned out that the way the teacher phrased the question was "write the biggest number" which to me, and all but one person in the class, meant the furthest number from 0 on a number line while still remaining positive. The other person just drew an ENORMOUS "10" on her piece of paper. The teacher went on to explain out of box thinking about solutions (like mine) and out of box approaches to the question (like hers).
Is it??? Adding one more exponent is huge, while 7->9 feels much smaller. It's all intuition, though. Does anyone know how to tackle such a question?
Limited empirical results say:
CL-USER> (log (expt 9 9))
19.77502
CL-USER> (log (expt 7 (expt 7 7)))
1602540.6
Taking the log of an expt is silly, but it makes it printable.I can do 21 "7"s in 10 seconds (given ok legibility) and 18 "9"s. So it looks like 7 is indeed better.
Great article, worth repeating/re-reading every now and again.
http://www.amazon.com/G%C3%83%C2%B6del-Escher-Bach-Eternal-G...
Having read this book would, in a fair world, be worth more on your CV/resumé than a large proportion of comp-sci degrees.
Even better, go out of your front door to a real bookshop and get them to order you one. Who knows, you might speak to someone! BONUS!
http://news.ycombinator.com/item?id=1539538 (68 comments)
http://news.ycombinator.com/item?id=951095 (1 comment)
http://news.ycombinator.com/item?id=514955 (1 comment)
http://news.ycombinator.com/item?id=492615 (0 comments)
http://news.ycombinator.com/item?id=47408 (0 comments)
Here's a way of classifying some i-trees as "smaller" than others. Say that the following operations make an i-tree smaller: (1) Reducing one of the integers that appear in it. (2) Deleting any subtree. (3) Replacing a node with one of its subtrees. And say that one i-tree is smaller than another if you can transform the latter into the former by a sequence of these basic steps, and not otherwise.
Finally, for any positive integer n, say that an n-tree is an i-tree in which all those positive integers are at most n.
It turns out that the smaller-than relation that I just described is a "well-quasi-order" (don't blame me, I didn't make up the terminology) on i-trees, which means: If you take any infinite sequence of i-trees -- T1, T2, T3, ... -- then there must be i,j with i<j and Ti smaller-than-or-equal-to Tj. This probably sounds like a bizarre and arbitrary notion, but it's useful because when a set is well-quasi-ordered you can do a kind of mathematical induction on it. (Mathematical induction is the thing that's usually described as "if something's true for 1, and true for n+1 whenever it's true for n, then it's true for all positive integers" but generalizes to something like "if something's true about any object provided it's true about all simpler objects, then it's true for all objects"; what's needed for this to work is approximately for "simpler" to be a well-quasi-order. I am skipping many details, but this is just a motivational aside anyway.)
There's a sort of finite version of that theorem, which goes like this: For any n, if you consider n-trees rather than unrestricted i-trees then there's a fixed N such that whenever you have T1, ..., TN there are two for which the earlier is smaller-than-or-equal-to the later.
How big is N, given n? The answer is the TREE function. It's nice and small for n=1 and n=2 but becomes absolutely enormous for n=3.
The very rapid growth of the TREE function is related to another cool fact: In a certain sense that I'm not going to bother making formal here, you cannot prove the theorem without making essential use of infinite quantities. (One can even quantify, kinda, just how much infinity is required.)
If you happen to like this stuff, here's another theorem (Goodstein's theorem, if you want to look it up) with the same sort of flavour. You already know, I take it, how to write a number in base n: one way to say it is that you write it as a sum of terms of the form [smaller than n] times n^k. Well, suppose you do that and then do the same thing to all the exponents, and to all the exponents that that produces, and so on, until you've expressed your number in terms of (1) numbers smaller than n and (2) the operation "a times n ^ b". Let's say that you've then written your number "in superbase n".
OK. Now, consider the following process. Start with any number. Write it in superbase 2. Replace all the 2s with 3s (so you now have something in superbase 3). Subtract 1; if necessary, fix up the superbase-3-ness. Replace all the 3s with 4s. Subtract 1 and fix up. Replace all the 4s with 5s. And so on.
Typically, the "replace n with n+1" operation increases the number enormously, and you might think that your numbers will increase without limit. But, as it happens, you always get down to 1 eventually -- but (1) the number of steps it takes to get there grows outrageously fast and (2) again, you can't prove this without (in some sense) using infinite quantities.
(For any readers who know about infinite ordinal numbers, here's the one-line proof: At each step, when you have the number written in superbase k, replace all the k's with omegas. Then the "add 1 to the superbase" steps do nothing, and it's easy to see that the "subtract 1" steps always strictly decrease your number. But the ordinals are well-founded, so you can't strictly decrease infinitely many times. QED.)
I imagine you could tackle a good subset of the problem though with a symbolic algebra package (mathematica?) if you restricted the form of the number-generating programs to a certain set of mathematical expressions for which it knows enough tactics to reduce the inequalities involved.
The object of the BIGNUM BAKEOFF is to write a C program of 512 characters or less (excluding whitespace) that returns as large a number as possible from main(), assuming C to have integral types that can hold arbitrarily large integers.
See the third line of http://djm.cc/dmoews.html for more, including the (quite interesting, IMO) results.
Googol ! ! ! ! ! ! ! ! ! !