←back to thread

BusyBeaver(6) Is Quite Large

(scottaaronson.blog)
271 points bdr | 2 comments | 28 Jun 25 16:53 UTC | HN request time: 0.544s | source
Show context
tromp ◴[28 Jun 25 19:42 UTC] No.44407552[source]▶
People on the bbchallenge Discord server are keen to speculate on how many Turing Machine states are needed to surpass Graham's Number, which is vastly larger than the 2^^2^^2^^9 achieved by the latest BB(6) champion.

We know from the functional busy beaver [1] that Graham behaviour can come surprisingly early; a 49-bit lambda term suffices. There are only 77519927606 closed lambda terms of at most that size [2], compared to 4^12*23836540=399910780272640 unique 6-state Turing Machines [3].

With the achievement of pentation in only 6 states, several people now believe that 7 states should suffice to surpass Graham's. I would still find that rather surprising. A few days ago, I made a large bet with one of them on whether we would see proof of BB(7)>Graham's within the next 10 years.

What do people here think?

[1] https://oeis.org/A333479

[2] https://oeis.org/A114852

[3] https://oeis.org/A107668

replies(1): >>44407834 #
gpm ◴[28 Jun 25 20:18 UTC] No.44407834[source]▶
I can't pretend to be an expert, but I'll argue BB(7) is probably larger than Graham's number.

BB has to grow faster than any computable sequence. What exactly that means concretely for BB(7) is... nothing other than handwaving... but it sort of means it needs to walk up the "operator strength" ladder very quickly... it eventually needs to grow faster than any computable operator we define (including, for example, up-arrow^n, and up-arrow^f(n) for any computable f).

My gut feeling is that the growth between 47 million and 2^^2^^2^^9 is qualitatively larger than the growth between 2^^2^^2^^9 and graham's number in terms of how strong the operator we need is (with gramah's number being g_64 and g here being roughly one step "above" up_arrow^n). So probably we should have BB(7)>Graham's number.

replies(2): >>44409272 #>>44411034 #
pinkmuffinere ◴[29 Jun 25 00:18 UTC] No.44409272[source]▶
Apologies if this feels adversarial, but I think your informal proof has an error, and I think I can explain it!

Your proof rests primarily on this assertion:

> BB has to grow faster than any computable sequence.

This is almost true! BB(n) has to grow faster than any computable sequence _defined by an n-state Turing machine_. That last part is really important. (Note that my restatement is probably incorrect too, it is just correct enough to point out the important flaw I saw in your statement). This means that up-arrow^f(n) _can_ be larger than BB(n) — up-arrow^f(n) is not restricted by a Turing machine at all. As an easy example, consider f(n) = BB(n)^2.

You may still be right about BB(7) being bigger than Graham’s number, even if your proof is not bulletproof

replies(3): >>44409291 #>>44409715 #>>44410452 #
adgjlsfhk1 ◴[29 Jun 25 00:21 UTC] No.44409291[source]▶
one of the things that does come out of BB is that BB(n)^2>>BB(n+c) for some very small constant c (I would be surprised if c>2)
replies(1): >>44409413 #
1. pinkmuffinere ◴[29 Jun 25 00:45 UTC] No.44409413[source]▶
Sure, but the example I'm providing is just meant to illustrate that BB(n) is not greater than arbitrary f(n). I'm not trying to provide the biggest number, I'm trying to illustrate that the sketched-out proof is incorrect. If you want me to provide a bigger number, I suppose another easy example is to define f(n) = BB(BB(n)).

Edit: Oh sorry, I see I misread the direction of your greater than signs. Leaving comments as-is though, hopefully that results in the least confusion

replies(1): >>44409494 #
2. adgjlsfhk1 ◴[29 Jun 25 01:00 UTC] No.44409494[source]▶
oops, my greater than signs are in the wrong direction. specifically, for any computable function f, there exists some constant c such that f(BB(n))<<BB(n+c)