I have finished my thesis which is on the Busy Beaver problem and it is now available at the downloads page.

A few new downloads are accessible from the downloads page. I have posted a paper on a manual analysis of the B5 holdouts in an attempt to fully verify the numbers for n = 5. In addition, there is a brief presentation by Selmer on logicizing the attack on the holdouts.

I've run some additional tests on the original 76425 holdouts for the n=6 run. These tests included a pass through the updated backtracking routine, the updated counter routine, as well as the multisweep detection routine checking for 6 sweeps, 7 sweeps, and 8 sweeps. In addition, I ran any holdouts from these tests for 10,000,000 steps to see if any of them halted. Unfortunately, none of them halted. However, nearly half of them were identified as belonging to one of the aforementioned categories. The updated numbers can be found on the status page.

The run for n=6 has finished! After about 3 months we finally have some updated numbers for BB(6). When all was said and done, 76425 holdouts remained. However, I have recently discovered an inefficiency in the backtracking detection routine that allowed some backtrackers to escape the detection algorithm. The problem was related to a too strict of a base case in a recursive function call. In any case, I've fixed the problem and re-run the search for n = 2 through 5. Not only did the distribution numbers change slightly for the lower order searches 2 through 4, but the number of holdouts for n=5 is now less than 100! Only 98 holdouts remain to explicitly confirm BB(5). In terms of the remaining holdouts, I have explicitly defined several different types of counter variation behaviors. While the behaviors are relatively simple to define, the most difficult task is proving to be the extraction of the components that contribute to these behaviors. The most hopeful is higher order counters which I still hope to have working soon.

Well the run for n=6 that was started back on November 20 is still going. It has however turned up some new records in the process! We have newer records for the O6 and P6 formulations that respectively generate 239 and 240 1's on the tape after completing 41606 and 41607 steps. In addition, there is also a new P6 champion that generates 163 consecutive 1's on the tape! Refer to the status page for all the information on these new records. In other news, a minor optimization in the counter detection routine has identified four holdouts from the n=5 holdouts as counters. Significant progress is being made on the detection process of higher order counters (base 3, base 4, etc.) and I hope to incorporate those into the official code soon.

After many, many changes to the code, tweaks to the routines, and some major reworking of a few of the non-halt detection algorithms, the number of B5 holdouts has now been officially reduced to 225. The most notable addition to the non-halt detection arsenal is the new multi-sweep christmas tree detection routine which generalizes the behavior of multi-sweep machines. Now it is no longer necessary to code and debug additional quadruple-sweep, quintuple-sweep, etc. algorithms because this new routine takes a "number of sweeps" argument and checks for any n-sweep christmas tree pattern. Also, the code has gone through some major changes in the past few days and is now capable of testing for all 4 formulations (B,P,O,R) in one run. The B6 and O6 runs that were running have now been restarted on the uber-mac to encapsulate all of the types at once. It will finish someday...

Another O(6) and o(6) champion has been found! This new machine prints out 162 1's on the tape after 33,526 steps! Also, status on the latest B(5) run is still pending. If all goes well, the number of holdouts should be officially reduced to around 284. Refer to the Status page for the updates and information on the new record!

Curiously, the most recent B(5) run has revealed 303 holdouts instead of the expected 284. In addition, it is reporting 0 empty tape machines. Clearly something is wrong here. Further investigation reveals that the one variable which is keeping track of the non_blanks for the empty tape check is not being reset when the machine is reset for the additional non-halt routines. The bug has been fixed and a new B(5) run is currently fighting for CPU time.

Triple sweep christmas trees are now added to the list of implemented non-halt detection routines. They're basically the same idea as alternating christmas trees, except these machines take three sweeps across the tape instead of two before a repeating pattern appears. Another 472 of the holdouts are eliminated by this routine bringing the number down to 284. From this routine the mechanisms for quadruple sweep, quintuple sweep, etc.... routines can be trivially derived. The shear volume of code that must be manipulated, however, is not trivial. Nevertheless, these routines will most certainly need to be repetitively derived to continue the attack for 6, 7, etc..

The leaning christmas tree non-halt detection routine is completed and now in place. These machines are similar to standard christmas trees except they "lean," meaning both the left and right boundaries of the tree progressively move in the same direction as additional interior components are added. Initial runs on the B(5) holdouts picked up 89 machines. Unofficially this brings the holdout count down to 781.

A new O(6) champion has been found!!! This new champion for the quadruple, implicit halt, non-standard formulation of the problem prints out 160 1's on the tape after 31,877 steps! Also, with this new champion comes a new R(6) champion which would be the exact same machine except it prints a one as it transitions to the halt state rendering 161 1's on the tape.

Discovery of this champion became possible because of the increasing number of holdouts that are eliminated by the non-halt detection routines. Because of the enormous percentage which are eliminated, only the few holdouts are actually run to the arbitrarily specified step limit. As a result, raising the step limit to 100,000 steps does not significantly add to execution time allowing us to reveal the above machine.