Turing Tumble Community

How Many Balls Can You Count?

Alternate Title: What is the biggest binary counter you can squeeze onto the board?

Assuming an infinite supply of balls, design a device that counts (in binary) a single color of balls and stops when it cannot count any higher. What is the largest number of balls you can count using a standard-size board?

I found a few solutions, with varying degrees of faithless to the prompt and to the rules of Turing Tumble:

127: 7-Bit Counter

This is the highest I could count without breaking any rules. As in the workbook, I use the convention that a bit pointing left = 0 and pointing right = 1.

255: 8-Bit Counter

This time I’m counting blue balls. This solution technically satisfies the prompt, as long as you don’t mind red balls in your blue balls. Every 16th blue ball will cause the lower four bits to overflow, which is carried over to the upper four bits by a red ball. Thus, 16 red balls will be require to count 255 blue balls. Incidentally, the total number balls collected at the bottom will be equal to the count read off the full 8-bit register plus the count read off the upper four bits (e.g. if the register reads 01100100, there are 100 blue balls + 6 red balls = 106 balls the bottom).

511: 9-Bit Counter

This is where things get sketchy. To make this work, you need a real board so that (a) the 512th ball will be captured against the side of the board and (b) you can tape of the blue chute so that all the balls trigger the red lever.

1023: 10-Bit Counter

For this to work, you again need to tape over the blue chute. Also, the uppermost for bits will need to be read as the opposite of the direction they are pointing (I used gear bits for these as a reminder).

1 Like

While browsing the forums I discovered an 11-bit counter that works on the same principle as my 8-bit counter above, but with way less wasted space. Great work, @Randy!

2048: 11-Bit Counter*

This one counts red balls. Every 64th red ball causes the lower six bits to overflow, which is carried over to the upper five bits by a blue ball. Thus, 32 blue balls are required to count 2048** red balls. The number of red balls collected at the bottom will be equal to the binary value stored in the full 11-bit register, and the number of blue balls will be equal to the value stored in the upper five bits (e.g. if the register reads 01111101000, there are 1000 blue balls and 15 red balls at the bottom).

*I’ve only loaded 4 blue balls and 256 red balls because that’s about how far you can get before the simulation really starts to bog down. To count all the way to 2048, whenever you run out of balls, just click reset (NOT restart) and pull the red lever again. You will have to pull the red lever eight times in total to reach 2048.

**Yes, I do mean 2048: the weird thing about using both colors for counting like this is that the 2048th ball will make it to the bottom, whereas with a single-color counter the 2048th ball would be caught in the interceptor. (Note: The same principal applies to my 8-bit counter above: it actually counts 256 blue balls)


I believe I have found a way to make a 17-bit counter which can count to over 131,000 blue balls. The concept is that every 511th blue ball triggers exactly one red ball to go through another counter. The 255th red ball that goes through will be caught, stopping the counter. Here is the design I came up with: https://lodev.org/jstumble/?board=001r1rl0l0lr1r1rel0l0lr1r1rel0l0lr1r1lel1lxerlxliex_99_99

(Btw, this is my first time posting so I’m not exactly sure if I did everything correctly with creating the digital example and everything)

(also, there are only 99 blue balls in the counter currently as an example even though it can count much higher)

Astounding! I concur: your design will count 131,072 blue balls. However, I believe your math is off by one: every 512th blue ball will trigger a red ball, and the 256th red ball will be intercepted. Also, your design reveals a new record for single-color counters:

511: 9-Bit Counter, Single Color

This counter will count to 511 before overflowing, and the 512th ball will be intercepted. Note that the carry path is through the center of this register, so if a bit points inward it represents 0, and if it points outward it represents 1.

(protip: you can set more than 99 balls in a simulation by editing the url manually)

I just figured out how to modify my previous design to count up to 324,609 blue balls (assuming my math is correct): https://lodev.org/jstumble/?board=001r1rl0l0lr1r1rel0l0lr1r1rel0lalr1r1xel1rxbrl1lbgix_400000_400000

First of all, I was able to add another bit in place of an orange crossover piece. Secondly, I added a mechanism to the lower right of the board that allows some of the bits to count twice. Every time a red ball comes out of the right side of the second-to-last bit (the one I replaced with a gear), it “checks” if the mechanism has been toggled. If not, the red ball will merely pass through. However, once a red ball goes through the final switch, it will toggle the mechanism by switching the lower gear. Now, the next time a red ball enters the mechanism, it will be caught instead.

(I know this is rlly confusing, so if you have any questions please ask. Also, thanks for the url tip)

Wow, that is really janky, but I agree with your math:

Every 1024th blue ball will trigger a red ball. However, not every red ball will trigger a blue ball: the 64th, 192nd, and 256th red ball will trigger another red ball, so only 317 red balls will be released as a result of the blue register overflowing. Thus, the total number of blue balls collected at the bottom when the 320th red ball is intercepted is 1024 * 317 = 324,608. (looks like you made a typo, there’s no way your math could’ve been off by just 1)

Well done! I wonder if there are more tricks to count even higher!

First of all, welcome wyrm_slayr to the community!

These are some incredible examples of how constraints fuel creative solutions!

Thank you both for sharing your counting machines and pushing each other to count higher.

1 Like