MC Teaser

[The Grand Nudger]

An overhead of two mathematical circuits.


The one on the right is pretty much a standard ripple carry adder. Leveraged a little Big O and found that my carry line was slowing me down. So, reworked her (exploiting game mechanics..after finding that a real carry look ahead was a wiring nightmare -due- to game mechanics) and got the circuit on the left. It's much faster (even at just 4 bits - and of course the more bits we need to carry the faster the design becomes compared to the one on the right). Also, as a bonus, the design was much more compact, allowing me to add a module to the front to handle subtraction in roughly the same amount of space. So, faster, more powerful, similar footprint. A much more elegant design.

For internet video game science!

---

You might notice the adder on the right still has the tool I put together to measure the delay between lines. It's the long, thin red line just to the right of the solid black one that runs between the two circuits. Essentially, that line is hooked up to an input which (when the A line is set to the binary equivalent of 15) turns on two outputs. One output is a piston with three "repeaters" in front of it, serving as an adjustable timing device. The other output is the input for the B lines binary equivalent of 1. This causes the circuit to carry a bit (because this machine, being 4 bits, can only represent the decimal numbers 1-15..and 15+1=16). That carry output is then wrapped back around to another piston set alongside the first. The way this works, is that when you hit the input for the testing device it simultaneously engages the piston behind "adjustable timing device" and causes the circuit to carry-engaging the piston behind the entirety of the circuits function. When the pistons both rise simultaneously the test device is "zero'd" and you simply count the ticks of delay you had to add to the input line, and that gives you the speed of the carry line. In this case, the carry is effectively instant - because the number returned by the testing device was equal to the number returned by the same testing device when it was applied one gate further "back" along the process. Now, I could have built a more complicated (and exact) tool out of actual clocks to determine the speed of either, but all I wanted to know was their speed relative to each other - so this dead reckoning sort of approach was sufficient for that. Had I not observed any difference between the two I would have started to wonder...and I probably would have built better instrumentation..lol.

This device was used on both designs in multiple places, the XOR gates were roughly equivalent (both XOR designs are 3 "ticks"- the ingame unit of measurement for redstone signals) but the carry line for the circuit on the right added 3 ticks, for a total of 6 ticks. The circuit on the left tested out at 3 ticks regardless of the addition of the carry line, all of this at 4 bits mind you. We might extend the circuit to 8, then 16, then 32 to see if anything changes - but for now, we'll call it "instant". As a minor aside the inclusion of the subtraction module didn't add any extra ticks because it relies on the same XOR gate with a re-routed B input.

Another interesting aside, if this sort of design could be used IRL it would amount to magic...lol. Making it effectively useless as an exercise in craft but hilariously fun as an exercise in exploiting game mechanics. The way the pistons work means that for the purposes of simulating a circuit they are instantaneous. They update immediately (before you can even see it occur) travelling even faster than the redstone signal which triggers them (which simulates signal carry speed- no less). Effectively, it causes a signal to teleport - with no demonstrable means of doing so in-game-, to a place exactly 1 meter away -in exactly the direction you choose- in a span of time that is too small to be calculated in-game.

Now......the reason any of this is useful at all (for me anyway) is that I want to ensure that each circuit I build to perform a given function is as fast as I can possibly make it, because MC computers are already dismally slow. In both designs I actually used the built in redundancy of XOR gates to speed up some tasks (by being built from universal gates, NOR or NAND - so why build another to handle either function when you can simply isolate their outputs?). Right now I'm toying with whether or not I should place the modules in-line with the input (perhaps above or below it) or wether I should bus the inputs to all modules set beside the input line (effectively performing all functions simultaneously) and the creating a command line to choose the output from the next ALU I want to build. One the one hand (inline) we have complicated but shortened input lines (redstone signals carry down the line at a set speed), and on the other we have straightforward architecture and simple input lines (but they'll have to travel farther and there is a limit to how far they can go before the game stops giving a shit and they don't work anymore). Being able to handle the inputs simply and quickly, or being able to execute quickly while possibly having input and timing issues. Decisions decisions.

---