This article is part one of a series of articles on advanced play for the game Turing Machine. You can find a list of all the articles along with some important disclaimers here.
Well, you’ve made it. Welcome to the culmination of this Turing Machine Masterclass, as we finally arrive at the most challenging way of playing Turing Machine: Nightmare mode.
Everything we’ve covered in the previous articles is still going to be important as we move into this scary new world. As a reminder, we’ve been using two key principles to sharpen our skills:
PRINCIPLE 1: NO VERIFIER CAN BE REDUNDANT (could this be in a box or something)?
An important implication of principle 1 is that no verifier is allowed to tell us all the information that another verifier would.
PRINCIPLE 2: THE CORRECT CODE WILL BE UNIQUE (could this be in a box or something)?
An important implication of principle 2 is that each colour must be uniquely definable.
In Nightmare mode, these principles still hold, and they’re going to be just as vital for us. Here’s the puzzle we’ll be looking at; if you want to play along at home, you can use the code #G48 H0D on the Turing Machine website.
Now, before we start making some deductions, we should just pause and make sure we understand how this mode works. In Nightmare mode, there is still one unique code which will meet all verifiers. When we were playing in Classic mode, I referred to the verifiers using their card numbers instead of the Turing Machine verifier letter A, B, C, D, E, or F.
In Expert mode, since each lettered verifier could be one of two cards, we used both the verifier card number and the verifier letter.
In Nightmare mode, the fundamental difference is that we don’t know which lettered verifier is connected to which verifier card. So, we’re not going to be able to simply test a verifier card; we can only test lettered verifier, until we have managed to connect them up by ourselves.
Now, that probably sounds quite difficult, and it is; it’s called Nightmare mode for a reason. But we’re not going to panic; we’re going to remember our principles, we’re going to go step by step, and we’re going to do our best not to waste tests.
So, where do we start? Well, we start by looking at verifier 8. Since this is a mutually exclusive verifier, we can immediately remove the option of three 1s. We can also remove the option of two 1s, since this would make verifier 16 redundant.
Now we’re going to ask the question, what do we know about purple and yellow? Verifier 2 cannot tell us anything about purple or yellow. Verifier 8 can tell us whether or not they are 1, although we already know they are not both 1. Verifier 16 can tell us whether they are odd or even, but it can only tell us the parity of both of them if they have the same parity and it’s different to the parity of blue (and blue’s parity can be determined elsewhere).
Hopefully, from the work we’ve done on previous articles, you’re starting to spot something very helpful here. Defining either yellow or purple as 1 from verifier 8 isn’t going to help; since we can have at most one 1, verifier 13 would tell us the other colour is larger, and all we could do is find out its parity, but we’d still have two options either way. Equally, defining yellow and purple as being of opposite parity would make them undefinable, and we’re not ever even going to be able to do that because of the way verifier 16 works.
So, verifier 16 is going to have to define yellow and purple as being of the same parity with blue being defined elsewhere as the opposite parity.
What are our options? We could have blue defined elsewhere as odd, with verifier 16 telling us that purple and yellow are both even, and then we would require them to be different in order to have a unique code, with verifier 13 telling us which is a 2 and which is a 4.
The other option is that we could have blue defined elsewhere as even, with verifier 16 telling us that purple and yellow are both odd and again different in order to define a unique code. Usually, this wouldn’t be enough to get a unique code since there are three odd options (1, 3, and 5), but since we have verifier 8, if it is telling us that there are no 1s, this would then work.
So, let’s consider if blue is being defined as odd. This could happen if verifier 2 is testing for blue 3. But in this case, more evens from verifier 16 would make verifier 8 redundant, so this isn’t possible.
If blue is less than 3 and there is one 1, this would allow for a blue 1. But the problem is that it doesn’t define blue as 1; it just tells us that blue is less than 3 and that there is a 1. It doesn’t tell us that blue is that one. In this case, more evens actually leaves us way too many options. Yes, we could have blue 1, yellow 2/4 and purple 4/2 defined by C. But we could also have blue 2 with the lower of purple and yellow being the 1, and the other being a 2 or a 4 in order to have more evens. This leads again to a non-unique code.
If verifier 2 is testing that blue is greater than 3, then there is no way for us to define blue as odd, and we’re definitely going to end up with too many options.
The upshot of all of this is that blue needs to be defined as even, with verifier 16 defining purple and yellow as odd and verifier 13 defining them as not equal and telling us which way round they are. We’ll also need zero 1s for that, but that is actually a perfect fit since zero 1s is the only way we can define blue as even anyway; if verifier 2 is testing for blue greater than 3, we can’t get any closer to an answer than that.
So, we now know that blue is 2, yellow and purple are 3 and 5 between them, and we just need to test against verifier 13 to do that. So, maybe we choose a code like 235 and test against verifier C….. oh, hang on a minute. This is Nightmare mode. And here, I thought we were nearly finished!
Well, the only way we’re going to be able to find out which verifier is which is by testing them. And since they are randomly allocated, there’s no intuition at work here, it’s just working systematically.
But first, let’s just make sure we’re happy with our choice of code. Have a look at all of the verifiers. If we test this code against verifiers 2, 8, or 16, we’ll get a positive result. This means that as soon as we obtain a negative result, we know we’ve found verifier 13. Of course, it’s possible that verifier 13 will give us a positive result, if purple really is higher than yellow. If that’s the case, we’ll know in a maximum of four tests.
We could pick a code using the opposite method, where every other verifier should give us a negative result. I know a code like that, obviously, but I’ll let you see if you can come up with one by yourself.
What we really don’t want to do, though, is choose a code where two of the verifiers will be true and two of them will be false. This would mean we’d have to go down the route of further testing to separate them out. Often in Nightmare mode we can’t get it down to this neat position this early; it’s a function of the way the cards have fallen, but we’re certainly not going to say no to the opportunity.
It turns out, after testing, that we chose badly here, since this code will take all four tests to find four successes and show that we have the right code already; if we’d chosen 253, we would have hit the correct verifier on our very first test against verifier A by luck, and we would have completed an Expert mode in one test with a little bit of luck!
Still, the machine took eight tests, so we’re pretty happy with four. This is Nightmare mode after all!
Well, we’ve reached the end of our Turing Machine journey together, but I sincerely hope this isn’t the end of your Turing Machine journey. I can honestly say that I’ve taught you everything I know about this deep, complex, fascinating game. I hope that you’ve had as much fun following along and playing at home as I have writing this article series, and if you love Turing Machine as much as me, I’d recommend that you pick up an extra copy now while it’s on sale, and gift it to a friend, family member or colleague. They might just love the game as much as we do!
