Live data from Hacker News

BB(3, 4) > Ack(14)

sligocki.com

41–50 of 114 posts

Re: BB(3, 4) > Ack(14)

#41
There are only so many Turing machines that we can possibly describe with a not too large amount of symbols such as 1RB3LB1RZ2RA_2LC3RB1LC2RA_3RB1LB3LC2RC. The fact that some of these can make such a crazy large number of steps before halting to me is mind blowing.

Re: BB(3, 4) > Ack(14)

#43

Earlier quoted context omitted.

I understand the complaint here, but a lot of recent impressive progress in mathematics has been by rapid collaboration + iteration (e.g. the project to improve Zhang's prime gap bound), and it may be the case that different communication tools are not easily fungible with Discord in this regard. You have to go where the people actually are.

But Discord isn't citable . Somebody needs to archive the Discord and make that available through the proper channels (e.g. a website, a book, the Internet Archive).

There are a ton of "personal communication" cites out there that are dead ends. The point of the cite isn't to provide a handy link, though it's nice if it is one, but to hand the credit where the credit is due.

Re: BB(3, 4) > Ack(14)

#44

Can someone point me to some resources as to how to interpret the table, which I assume is some sort of description for a Turing machine?

I've made a small repository with current record holders that also shows examples of running these machines with Wolfram Language: https://datarepository.wolframcloud.com/resources/The-Busy-B.... I guess I also need to update it now.

Re: BB(3, 4) > Ack(14)

#45

It is sometimes thought that extremely long-running Turing machine programs must be deeply complicated, or "spaghetti code". This new reigning champion program is a counterexample. All things considered, it is relatively simple. There are three states: A, B, C. (States are just like goto targets in C.) State B passes control to A and C, but states A and C don't "know about" each other; they only pass control back to…

There is some debate in the bbchallenge project regarding the current long-running champions: do their properties reflect those of the actual longest-running machine of that size, or are their properties just the easiest to automatically search for and prove things about, as a kind of streetlamp effect? There's no way to know, until the entire search space has been ruled out, either definitely or heuristically. (Ever…

> streetlamp effect

I agree completely, all of these kinds of conjectures are shaped by what is detectable. If there are any "dark matter" programs out there, they by definition will be difficult to find. That said, I find it entirely plausible that the champions will win by exploiting complex and exotic mathematical facts, while the implementations of the math do not themselves need to be complex or exotic at the code level.

More rambling thoughts about this: https://nickdrozd.github.io/2021/09/25/spaghetti-code-conjec...

Re: BB(3, 4) > Ack(14)

#46
post #10

The new BB(3,4) record holder is 0 1 2 3 A 1RB 3LB 1RZ 2RA B 2LC 3RB 1LC 2RA C 3RB 1LB 3LC 2RC with the triple (t',d, s') in row s column t specifying the transition from state s with symbol t under the tape head. the machine overwrites symbol t with t', moves the tape Left/Right according to direction d, and changes state from s to s', halting if s'==Z. This is 3*4*log2(4*2*log2(4+1)) or about 64 bits of information…

Can you help me understand the log2(4+1) term? I calculate 3*4*log2(4*2*log2(4+1)) ≈ 51. I (a layperson) would have thought the calculation would be 3*4*log2(4*2*4) = 60. Is it perhaps 3*4*log2(4*2*log2(3*3*4-1)) ≈ 64?

I miscalculated. It should be 3*4*log2(4*2*(3+1))= 60 bits of information.

Re: BB(3, 4) > Ack(14)

#47

Can someone point me to some resources as to how to interpret the table, which I assume is some sort of description for a Turing machine?

The "states" (A, B, C) correspond to goto targets. The "colors" (0, 1, 2, 3) are runtime data. At each state, the current color is read, and an instruction is executed (print some color, move left or right, goto some state) based on which color is there. Transliterated into C it looks like this: #include "machine.h" int main(void) { A: switch (SCAN) { case 0: WRITE(1); RIGHT; goto B; case 1: WRITE(3); LEFT; goto B; c…

> Question: are there any opportunities to rewrite this logic in a more "structured" style, or to make any other optimizations?

Because A and C only jump to B it is possible to structure this using only loops and one boolean. Let us use Rust to demonstrate as it lacks GOTO:

    let mut a = true;
    loop {
        loop {
            if a { // state A
                match scan() {
                    0 => { write(1); right(); break }
                    1 => { write(3); left(); break }
                    2 => { write(1); right(); return }
                    3 => { write(2); right() }
                }
            } else { // state C
                match scan() {
                    0 => { write(3); right(); break }
                    1 => { write(1); left(); break }
                    2 => { write(3); left() }
                    3 => { write(2); right() }
                }
            }
        }

        a = loop { // state B
            match scan() {
                0 => { write(2); left(); break false }
                1 => { write(3); right() }
                2 => { write(1); left(); break false }
                3 => { write(2); right(); break true }
            }
        }
    }
Of course it is possible to rewrite this as a single loop if you are willing to accept two bits of extra state rather than one.

Re: BB(3, 4) > Ack(14)

#48

Earlier quoted context omitted.

There is some debate in the bbchallenge project regarding the current long-running champions: do their properties reflect those of the actual longest-running machine of that size, or are their properties just the easiest to automatically search for and prove things about, as a kind of streetlamp effect? There's no way to know, until the entire search space has been ruled out, either definitely or heuristically. (Ever…

At a high level, wouldn’t you expect Champions to be chaotic in the limit? As in, the halting problem tells us that any increasing sequence of Champions is not computable.

Yes, for a busy beaver properly defined in information theoretic terms, like BBλ2 [1], one can prove that its champions must be incompressible up to some constant. Mikhail Andreev's article "Busy Beavers and Kolmogorov complexity" [2] explores these connections.

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

[2] https://arxiv.org/pdf/1703.05170

Re: BB(3, 4) > Ack(14)

#49
post #41

There are only so many Turing machines that we can possibly describe with a not too large amount of symbols such as 1RB3LB1RZ2RA_2LC3RB1LC2RA_3RB1LB3LC2RC. The fact that some of these can make such a crazy large number of steps before halting to me is mind blowing.

There are 2^60 such 3 state 4 symbol Turing machines. A 49-bit lambda term whose output (normal form) exceeds Graham's Number should blow your mind even more.

Re: BB(3, 4) > Ack(14)

#50
post #46

Earlier quoted context omitted.

Can you help me understand the log2(4+1) term? I calculate 3*4*log2(4*2*log2(4+1)) ≈ 51. I (a layperson) would have thought the calculation would be 3*4*log2(4*2*4) = 60. Is it perhaps 3*4*log2(4*2*log2(3*3*4-1)) ≈ 64?

I miscalculated. It should be 3*4*log2(4*2*(3+1))= 60 bits of information.

You also need to subtract some bits from symmetries right?

Like you can mirror the tape. You can relabel states B and C. And you can relabel symbols 1, 2, 3. Though the analysis is complicated a little bit by the fact that some (combinations) of those operations may yield the exact same machine.

Post reply on HN