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.
Over the last three weeks, we’ve played some Turing Machine in Classic mode, using two key principles:
PRINCIPLE 1: NO VERIFIER CAN BE REDUNDANT
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
An important implication of principle 2 is that each colour must be uniquely definable.
This week, we’re going to go crazy and make the jump to Expert mode. Now, let me be clear, three solid games of Turing Machine does not an expert make. So, if you’re scared about this jump, you should be. This mode is going to be difficult, because it is, in fact, for experts. But although it’s going to be hard, it’s also going to be great fun. And I’ll be here with you every step of the way.
If you genuinely don’t think you’re ready for Expert mode yet, that’s not a problem. Go and play some more Turing Machine! Play it with your friends, play it solo so you can take as long as you need to practice, play it online and see if you can slowly start to amaze people with your ability to solve the easier problems in one or two tests. This article will still be here when you get back.
Okay, now that those suckers have gone, strap yourself in for a brilliant but bumpy ride! For our first Expert mode game, we’re going to use 4 verifiers, but since this is Expert mode that means we’ll have 8 cards. Here are the verifiers we’ll be using, and if you want to play along at home, use game code #D4B IDV on the Turing Machine website.
Up until now, we’ve been able to refer to each verifier using the card number, but that’s going to get tricky now. So, I’ll still refer to cards as verifiers, and use the card number, but if I need to refer to a column of cards, I’ll use the standard letters from Turing Machine i.e. verifier A for the first column up to verifier D for the fourth column.
Let’s start by looking at verifier 8. We can say something about this verifier using Principle 1, which holds across all game modes in Turing Machine. Verifier 8 cannot be testing for three 1s, since that would make all other verifiers redundant.
We need to pause here and note a very important difference between Classic mode and Expert mode. Last week, we saw that some verifier cards have options which are not mutually exclusive, which means that ruling out a test from a verifier doesn’t necessarily prevent that condition being true in the final code.
However, verifier 8 is an Easy/Standard card, with mutually exclusive options, which means that we can see there are not three 1s in the code, right? Sadly not. That assumption that we made previously is based on a fundamental fact for Classic mode, which is that each verifier is active, and this is not true for Expert mode. If verifier D is actually set to verifier 20, and verifier 8 is essentially a red herring, the code could still contain three 1s, provided that this wouldn’t require an active verifier to make another active verifier redundant.
For now, though, we can still note that verifier 8, if it is active, is not testing for three 1s. This is still useful information, it’s just not as useful as it would have been in Classic mode. We can also rule out that verifier 8 is testing for two 1s; if it is, this would make both verifiers 21 and 16 redundant.
Let’s look now at verifier 20. If verifier 20 is testing for a triple number, verifiers 21 and 24 will both be redundant, meaning verifiers 16 and 5 would both be active. But since a triple number requires that each number is the same parity, we could use verifier 16 to obtain the parity of blue, making verifier 5 redundant. So this is impossible, and verifier 20 is not testing for a triple number.
Now, let’s look at verifier 24. If this is testing for 3 numbers in ascending order, we know that blue is less than yellow which is less than purple. This means that whichever verifier is being tested for verifier C will be redundant, so we can immediately remove this as an option.
Okay, we’ve probably done as much as we can here in terms of initial analysis. We’re nowhere near as far along as we were in Classic mode, but that’s to be expected, because Expert mode is called that for a reason.
The question is, what code should we test, and where should we test it? And, now, brace yourself, because I’m not sure you’re going to like the next bit.
We need to talk about intuition. Turing Machine is a logical deduction game, and so intuition can feel like a bit of a dirty word while you’re playing it. But intuition is, actually, very important in Turing Machine, particularly as you approach higher levels of play. And my intuition is telling me that I think verifiers 16 and 5 might both be active.
Where is that intuition coming from? It comes mainly from having played hundreds of games of Turing Machine. But what is the basis of the intuition? It’s largely the difference between verifier 16, which is in this game, and verifier 17, which isn’t. Verifier 17 tests for the number of evens, and the distinction between these two verifiers is vitally important.
You see, verifier 16 can only tell us that at least two of the numbers in the code are even or odd, but it can’t tell us about the parity of the third number. This means that it often appears with another verifier which can tell us about the parity of a specific number, and it’s usually the different parity, so that each number can be defined uniquely.
Now note that we’re not relying on this intuition to solve the code; I’m not arguing that because these usually occur together, therefore they are definitely active. But we absolutely can use that intuition to identify which cards to test.
So, with this in mind, I’m going to test the code 123, and test against verifier B. Since we know that verifier 24 can’t be 3 numbers in ascending order, I’m hoping for a tick here, since it will tells us for sure that blue is even. Testing that verifier, we do get a tick, so with a bit of intuition and a bit of luck, we’ve solved one of the verifiers. We’ve managed to identify that verifier B is set to verifier B, and that it’s testing for an odd blue.
Let’s look again at verifier 20. If verifier 20 is active, verifier 21 will be redundant and verifier 16 will be active. If verifier 16 is testing for more evens, this will tell us that both purple and yellow are even, but if it’s testing for more odds, it will only tell us that at least one of yellow and purple are odd.
We’ve already shown that verifier 20 isn’t testing for a triple number.
If verifier 20 is testing for a double number, more evens means purple must be equal to yellow, which would make verifier 13 redundant, and verifier C would be set to verifier 11. But we’d have no way of uniquely defining the code. If blue is less than yellow we could have blue 1 with yellow 2 and purple 2 or yellow 4 and purple 4, or we could have blue 3 with yellow 4 and purple 4. By symmetry, if blue is greater than yellow, we could have blue 5 with yellow 4 and purple 4 or yellow 2 and purple 2, or we could have blue 3 with yellow 2 and purple 2. And blue equal to yellow is out straight away since blue is odd and yellow is even.
If verifier 20 is testing for no repetition, we have the same problem for slightly different reasons. If verifier 16 is testing for more evens, since there is no repetition, yellow and purple must both be different evens. In this case, we will need verifier 13 to solve purple and yellow, but then there will be no further verifiers to define blue. So again, the code will not be uniquely defined. This means verifier 20 cannot be active.
So we now know that verifier D is set to verifier 20, and it’s testing for zero 1s or one 1. Let’s go back to verifier 21. If it’s testing for a pair, we are not going to be able to uniquely define the code: if verifier C tests for equality, we won’t be able to identify the value of the pair. If verifier C tests for an inequality and there is a 1 this will be the lower of the inequality but we won’t be able to define the value of the pair. If verifier C tests for an inequality and there is not a 1, since we still have two odds and two evens left as options, there will be too many possibilities.
If verifier 21 is not testing for a pair, we will either have no repetition or we will have a triple number. If verifier C is testing for an equality we will have a triple number, which is odd from verifier B, but again it could be three 3s or three 5s. If verifier C is testing for an inequality we will have no repetition, with blue odd and possibly a 1 defined by verifier D. But with or without a 1, there will still be too many possibilities.
This means that verifier 21 cannot be active. With verifier 16 active, more odds would leave too many options again for us to be able to define the code uniquely. So verifier 16 is testing for more evens, meaning we have purple and yellow as even. The only way to define them uniquely will be if verifier 13 is comparing them to each other (and they are not equal), with one of them as a 2 and the other as a 4. This means verifier 8 must be testing one 1, since testing zero 1s would leave blue as either a 3 or a 5, and therefore undefined.
So, we can actually do this with just a second test. We have the code 123 for round 1 already, so we test against verifier 13, and we get a negative result. Since we know this must be comparing yellow and purple, we have that yellow must be larger than purple, and the final code is therefore 142.
Note that even though we’re playing on Expert, we needed only two tests. The machine took a massive eight tests to solve this. In general, my experience has shown that the machine is not bad at using Principle 1 (no verifier can be redundant) and not quite as good at using Principle 2 (the code must be uniquely defined). It’s therefore no surprise that we beat the machine by a good margin, since we’ve relied quite heavily on principle 2 for this puzzle.
Next week, in our last article for this series, we’ll be moving on to the dreaded Nightmare mode, where we don’t know which lettered verifier is connected to which verifier card (eek!). If the thought of that doesn’t fill you with existential dread, you can take an early look at the puzzle we’ll be using with the game code #G48 H0D on the Turing Machine website.
