My first nonstandard calculator makes use of sticky pistons and slime blocks. Pistons are capable of pushing and pulling blocks back and forth. Although this calculator is nonstandard, it still technically uses redstone, as redstone is required to power pistons.

The general mechanism to cause chain reactions is that one piston extends, and this changes the position of power sources which power other pistons. Like all of my calculators, this one converts your input from base ten to binary, and then displays the result in base ten.

This calculator takes advantage of two game mechanics: torches break when they come into contact with water, and sand blocks fall if there is nothing directly below them. This whole thing is essentially a very complicated and very unstable fountain, which is why I call it a fountain calculator. You get things started by creating water streams as inputs. From then, some torches break, and sand blocks that they are supporting fall down. This may cause a little packet of water to be released. If you look around in the picture, you can see lots of water sources which are held in place by sand on at least one side. Sometimes, sand also falls in the path of water, preventing it from flowing somewhere.

Although this calculator is completely redstone-free, it has a major flaw: you can't reset it. For this reason, I keep two copies of it, one of which is a template, and it gets copied over using command blocks when you want to reset.

This is the second version of my sand fountain calculator. The biggest improvement is in the binary decoder, which is explained more below. This calculator is capable off adding and subtracting numbers which are each between 1 and 9, provided that the result is positive.

Sadly, both of my fountain calculators are currently broken. They both make a lot of use of the dirt path block. Dirt path is slightly shorter than regular blocks. At the time I built this, that meant sand would actually break when it fell onto a dirt path block. However, it was still tall enough to place torches on top of it. Now, both of these are false. I have an idea for how to fix it, but I haven't implemented it yet.

The most difficult part of this to fix will be the display. I am pretty proud of the current display design. It makes use of concrete power, which, like sand, falls when there is no block underneath it. However, when concrete power gets wet, it becomes concrete, and will no longer fall. In the display area, there is some concrete powder arranged in a 7-segment digit display, supported above the output area by pillars of sand. After a computation, some of the concrete powder is hardened, and then all of the sand supports fall down. What hasn't been dried falls down and displays the output number. Right now, thanks to game updates, the display is incredibly broken.

Here is the compact decoder. The 20 channels which are shown vertically correspond to output numbers between 0 (on the right) and 18 (second from the left. Ignore the leftmost one). The rows of red sand correspond to binary digits, with ones at the bottom and 16s at the topmost row. If a binary digit is present in the output number, the entire corresponding row of sand falls by one block. Sometimes this removes a barrier from the water flowing through the channel, and sometimes it creates a hole in the floor that traps the water. Try to see if you can make sense of the particular arrangement of the red sand blocks.

This one uses cactus, sand, and torches. The key game mechanic used here is that cacti break if any blocks are right next to them. You get this thing started by placing blocks on certain input lines. Then, cacti break and sand blocks that sit on top of them fall down. This can make sand fall next to another cactus, and the chain reaction continues. The cactus calculator can add and subtract numbers between 1 and 9, provided that the output is nonnegative.

Like the fountains, this calculator cannot reset itself, so a template gets copied over whenever you want to reset.

Here is what it looks like when a number is displayed.

This is my only water based calculator which is able to reset itself. The picture above is the main ALU. There are four primary active components: dispensers, water, armor stands, and tripwires. Tripwires activate dispensers, which either dispense water or drink it up. This causes armor stands to move around and trip more tripwires. I originally wanted to use animals in boats for this, but they are harder to control than lifeless armor stands, and they fit in less places.

Every medium of computation has it quirks, and this one was the most challenging to build. Before this, I was used to one of two possibilities: states which represent "on" are easily reversible, or they are not reversible at all. In the latter case, I developed ways either to prevent lines from activating before the system is "sure" that they should be activated, or else I built ways to cut them off later down the line. Water dispensers are an awkward in-between, because they toggle on and off. I can't really explain in more detail why that made it more challenging, but it just did.

Here are a few more pictures of the resettable water calculator. The input binary encoder (top left), binary decoder (top right), and display (bottom). I always try to make the display fit within the theme, so here I used lava dispensers.

The picture above is from the ALU of my favorite calculator ever. It uses pigs which ride around in minecarts. They can send other pigs off on a ride by activating tripwires. Before I made this, I guessed that it would have been one of the easier ones, but it ended up being pretty hard. Like the resettable water calculator, the logic of pigs in minecarts has some weird toggling properties. It is also spatially awkward and difficult to arrange.

This calculator currently has a lot of issues. If I load up the world and try to use this calculator it won't work, because there are some weird block update issues. I have some command blocks set up below this build to carry about those block updates, but those also don't always work. Also, although this design is technically resettable, it is not infinitely reusable, because it kills a lot of pigs. I am currently working on a more self-contained and eco-friendly version of this which gets around those problems.

As I mentioned, I am currently working on a version of the pig calculator which is less buggy and more humane. The display is by far the most challenging part of this. In the previous version, pigs take fall damage as they hit the floor. Then when the display resets, they get washed into a pit of lava with some water. To make the same pigs recyclable, I had to devise a kind of "pig sorter", which takes a bunch of pigs on the same rail and splits them up into a bunch of different rails. I haven't quite figured it all out yet.

The pictures above show the brain of the Nimbot. Here is roughly what each of the circuits does:

Red: used at the beginning of every game to generate piles of random sizes. It then reports these pile sizes to the purple circuit.

Purple: keeps track of the pile sizes throughout the game (in binary).

Blue: computes the "Nim sum" of the sizes of the piles, and determines which pile the Nimbot should take from in order to play optimally.

Lime: determines how many stones (blocks of concrete powder) should be removed from the chosen pile.

Yellow: positions some stuff below the floor under the piles to allow the correct pile to sink by the correct number of blocks.

Orange: detects when someone has won the game, and then plays either a happy sound (the human won) or a sad sound (the Nimbot won). The command blocks in the orange circuit are used to refill the piles of concrete powder which sit above the game.

Black: manages whose turn it is, paces the game, locks player input when it is the Nimbot's turn, etc.

Dark gray: physical mechanism that allows a player to lower the height of a pile by pressing a button. This circuit also locks all of the buttons corresponding to other piles once a given pile has been selected.

Dark green: adjusts the strategy when the game is in Misère mode. This requires remarkably little effort. It reads the pile sizes from the back of the lime circuit and determines how to lie to the blue circuit so that the standard strategy (with wrong data) will result in the Misère strategy.

This one isn't really a mathematical game, but building it gave me a lot of helpful practice. In this game, two players enter an arena and play a few games of rock, paper, scissors. When both players make a selection, the moves are simultaneously displayed. Between rounds, a running score is displayed on the wall. Once a player scores 3 points, the scores reset.