BB(2,6): Difference between revisions
(→Top Halters: top 10 2x6 halter) |
(2x6 filtering Phase 2 progress) |
||
| Line 53: | Line 53: | ||
All decimal places are truncated. Discoverers are asterisked where it is unclear if the TM had been found but unreported by someone previously (namely Shawn Ligocki). | All decimal places are truncated. Discoverers are asterisked where it is unclear if the TM had been found but unreported by someone previously (namely Shawn Ligocki). | ||
== Filtering == | |||
Starting from Terry Ligocki's holdout list of 22,302,296 TMs, Andrew Ducharme has performed the following filtering to get the holdout count down to 18,054,938. | |||
{| class="wikitable sortable" | |||
! colspan="2" |Holdout TMs | |||
! rowspan="2" |% Reduced | |||
! rowspan="2" |Compute Time | |||
(core-hours) | |||
! rowspan="2" |TMs Processed | |||
per s per core | |||
! rowspan="2" |Description | |||
! rowspan="2" |Source | |||
|- | |||
!Input | |||
!Output | |||
|- | |||
|22,302,296 | |||
|20,778,101 | |||
|6.8% | |||
|274.6 | |||
|22.56 | |||
|Enumerate.py with --no-sim and --lin-steps=10_000 | |||
| rowspan="5" |[https://drive.google.com/drive/folders/1TsSpW27x3LBlu5qmk-cjzCJzgo_3ehyT?usp=share_link Google Drive] | |||
|- | |||
|20,778,101 | |||
|19257876 | |||
|7.3% | |||
|~200 | |||
|~28 | |||
|lr_enum_continue 1M steps | |||
|- | |||
|19,280,508 | |||
|19,004,377 | |||
|1.4% | |||
|2174.6 | |||
|2.46 | |||
|Enumerate.py with --block-multiple=1, max-loops=20_000, and --time=1 | |||
|- | |||
|19,005,529 | |||
|18,952,159 | |||
|0.3% | |||
|1952.7 | |||
|2.70 | |||
|Enumerate.py with --block-multiple=2, max-loops=20_000, and --time=120 | |||
|- | |||
|18,952,159 | |||
|18,054,938 | |||
|4.7% | |||
|4168.4 | |||
|1.26 | |||
|CPS_Filter with --block-size=7 | |||
|} | |||
A far more efficient pipeline would immediately apply lr_enum_continue out to 1M steps to Terry Ligocki's holdout list. lr_enum_continue, written in C++, is about 400x faster than Enumerate.py at checking for Lin Recursion. Using Enumerate.py meant its Reverse Engineering decider was applied to all holdouts, and solved 74,089 TMs (0.33% of holdouts)...at the cost of roughly 274.1 hours of compute. | |||
[[Category: BB Domains]] | [[Category: BB Domains]] | ||
Revision as of 07:43, 2 September 2025
The 2-state, 6-symbol Busy Beaver problem, BB(2,6), is unsolved. With cryptids like Hydra in the preceding domain BB(2,5), we know that we must solve a Collatz-like problem in order to solve BB(2,6).
The current BB(2,6) champion 1RB3RB5RA1LB5LA2LB_2LA2RA4RB1RZ3LB2LA (bbch) was discovered by Pavel Kropitz in May 2023, proving the lower bound:
Top Halters
The highest known scoring machines are:
| TM | Approximate sigma score | Discoverer |
|---|---|---|
1RB3RB5RA1LB5LA2LB_2LA2RA4RB1RZ3LB2LA (bbch)
|
10 ↑↑↑ 3 | Pavel Kropitz |
1RB3LA4LB0RB1RA3LA_2LA2RA4LA1RA5RB1RZ (bbch)
|
10 ↑↑ 91 | Pavel Kropitz |
1RB2LA1RA4LA5RA0LB_1LA3RA2RB1RZ3RB4LA (bbch)
|
10 ↑↑ 70 | Shawn Ligocki |
1RB2LB0RA2RA5RA1LB_2LA4RB3LB2RB0RB1RZ (bbch)
|
10 ↑↑ 54.90 | Andrew Ducharme* |
1RB3RB1LB5LA2LB1RZ_2LA3RA4RB2LB0LA4RB (bbch)
|
10 ↑↑ 42.17 | Andrew Ducharme* |
1RB3LB0RB5RA1LB1RZ_2LB3LA4RA0RB0RA2LB (bbch)
|
10 ↑↑ 40.07 | Andrew Ducharme* |
1RB3LB3RB4LA2LA4LA_2LA2RB1LB0RA5RA1RZ (bbch)
|
10 ↑↑ 21.54 | Andrew Ducharme* |
1RB2LB3LA1RA0RA1RZ_1LA2RB1LB4RB5RA3LA (bbch)
|
10 ↑↑ 20.58 | Shawn Ligocki |
1RB0RA3RB0LB1RA2LA_2LA4LB1RA3LB5LB1RZ (bbch)
|
10 ↑↑ 17.53 | Andrew Ducharme* |
1RB0RA3RB0LB5LA2LA_2LA4LB1RA3LB5LB1RZ (bbch)
|
10 ↑↑ 17.53 | Andrew Ducharme* |
All decimal places are truncated. Discoverers are asterisked where it is unclear if the TM had been found but unreported by someone previously (namely Shawn Ligocki).
Filtering
Starting from Terry Ligocki's holdout list of 22,302,296 TMs, Andrew Ducharme has performed the following filtering to get the holdout count down to 18,054,938.
| Holdout TMs | % Reduced | Compute Time
(core-hours) |
TMs Processed
per s per core |
Description | Source | |
|---|---|---|---|---|---|---|
| Input | Output | |||||
| 22,302,296 | 20,778,101 | 6.8% | 274.6 | 22.56 | Enumerate.py with --no-sim and --lin-steps=10_000 | Google Drive |
| 20,778,101 | 19257876 | 7.3% | ~200 | ~28 | lr_enum_continue 1M steps | |
| 19,280,508 | 19,004,377 | 1.4% | 2174.6 | 2.46 | Enumerate.py with --block-multiple=1, max-loops=20_000, and --time=1 | |
| 19,005,529 | 18,952,159 | 0.3% | 1952.7 | 2.70 | Enumerate.py with --block-multiple=2, max-loops=20_000, and --time=120 | |
| 18,952,159 | 18,054,938 | 4.7% | 4168.4 | 1.26 | CPS_Filter with --block-size=7 | |
A far more efficient pipeline would immediately apply lr_enum_continue out to 1M steps to Terry Ligocki's holdout list. lr_enum_continue, written in C++, is about 400x faster than Enumerate.py at checking for Lin Recursion. Using Enumerate.py meant its Reverse Engineering decider was applied to all holdouts, and solved 74,089 TMs (0.33% of holdouts)...at the cost of roughly 274.1 hours of compute.