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 (insert link).
Over the last two weeks, we’ve tried to embed two key principles for advanced Turing Machine play:
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
An important implication of principle 2 is that each colour must be uniquely definable.
This week, we’re going to do one last puzzle in Classic mode, using the Hard setting so that any of the verifier cards can be used. Since we’ve used four verifiers and six verifiers in our previous puzzles, we’ll use five verifiers this time around.
The reason we’re taking a whole week just to cover the Hard setting is because Easy/Standard mode only use verifiers 1-25, while Hard can include verifiers from verifier 26 onwards, and there’s an important distinction for these, which we’ll see as we work through the puzzle.
Here’s the setup for this puzzle; if you’d like to play along at home, you can use code #C52 H0G P on the Turing Machine website.
Let’s start by thinking about verifier 42. If yellow is the unique lowest or highest, the code is going to either have a ‘peak’ (with yellow as the unique highest) or a ‘dip’ (with yellow as the unique lowest). This will make verifier 22 redundant, so we know that verifier 42 isn’t testing for yellow as the smallest or the largest.
Now, this is the point where we need to pause and think about mutual exclusivity. Let’s dig back in the box and pull out verifier 15, which is quite similar to verifier 42 but not exactly the same.
Although these look quite similar, there is one massive difference between them, which is that all of the possibilities on verifier 15 are mutually exclusive. That is to say, if one of them is true, all of the others are by definition false.
If blue is larger than purple and yellow, it should be immediately obvious that yellow cannot be larger than blue and purple, and that purple cannot be larger than blue and yellow.
However, if you look closely at verifier 42, you’ll notice that this is not true. If yellow is the unique lowest, we can rule out the corresponding bottom row option (yellow cannot be the unique lowest AND the unique highest), and the other top row options (blue and purple cannot also be the unique lowest). But it still might be the case that blue or purple is the unique highest.
In other words, in hard mode, a code might satisfy more than one condition on a given verifier card.
Now this fact has a couple of massive implications:
A. A success doesn’t necessarily ‘rule in’ an option
For example, let’s pretend we test code 234 against verifier 42, and we get a tick. This tells us that yellow is not the unique lowest or highest, blue is not the unique highest, and purple is not the unique lowest. But we still haven’t solved the verifier. Getting a tick from a single test is not always enough to solve a verifier in Hard mode.
This takes a bit of a mindset shift from Easy/Standard mode to get your head around, but with a bit of time you’ll get used to it.
However, there’s a flipside implication which, for some reason, I find much harder to keep in my head:
B. A non-tested option doesn’t necessarily ‘rule out’ an option
This sentence is game-changing in Hard mode, and if you want to be able to succeed at Turing Machine in this mode, you have got to make sure you understand this properly. Note that this statement is more emphatic than implication A; we’re not referring only to getting a cross on a test here, but even removing the option as being tested entirely.
To try and illustrate the true impact of this implication, let’s go back to our initial deduction at the start of this puzzle. We stated that if verifier 42 is testing for yellow as the unique lowest or the unique highest, it would make verifier 22 redundant, and therefore we know that verifier 42 is not testing for yellow as the unique lowest or unique highest.
In Easy/Standard mode, the next step would be to make the implicit assumption that in the true code, yellow cannot be the unique highest or unique lowest. But we absolutely cannot do this here, because the options on verifier 42 are not mutually exclusive. All we know is that verifier 42 cannot be testing for yellow as the unique highest or lowest. When all options are mutually exclusive, this tells us information about the code itself, but in Hard mode, that isn’t true.
Let’s say for example that verifier 42 is actually testing for blue as the unique lowest. This would rule out yellow as the unique lowest, but yellow could still be the unique highest. In that case, verifier 42 isn’t failing at its job, because the only thing it’s doing is telling us that blue is the unique lowest. That’s what it’s programmed to do, and it won’t do anything else.
So, with that in mind, let’s get back to what we know. Right now, we only have that verifier 42 cannot be testing yellow as the unique highest or lowest.
However, if we look the other way at verifier 22, you’ll see that there is a (small) flipside to the issue of mutual exclusivity. If verifier 22 is testing for ascending order, it would reduce verifier 42 to testing one of two options: either blue as the unique lowest or purple as the unique highest. However, whichever of these options verifier 42 would be testing, it still wouldn’t tell us anything that verifier 22 hadn’t already. So the verifier is made redundant without reducing the possible options to 1.
Now we know that the code has no order, and that blue or purple is the unique highest or lowest. This is helpful, since it tells us that we either have the ‘peak’ or ‘dip’ shape that we mentioned earlier, or that yellow is equal to one of the other two numbers.
Let’s look at verifier 8. We know that we cannot have three 1s, since this would make all the other verifiers redundant. Also, if there are two 1s, this would make verifier 22 redundant, so we can reject that option as well.
Now, let’s spend a bit of time with verifier 36. The possible sums of the three numbers are all whole numbers between 3 and 15 (inclusive). Since we know that one of these conditions must be true, we can immediately rule out the numbers 7, 11, 13 and 14 as the sum of the three numbers. We can also rule out 3, since this would require three 1s, and 4, since this would require two 1s.
If verifier 36 is testing for the sum as a multiple of 3, we have three possibilities: 6, 9, and 12. If it’s testing for a multiple of 4, we have two possibilities: 8 and 12. If it’s testing for a multiple of 5, we have two possibilities: 10 and 15.
If there are zero 1s, none of these possible sums disappear. However, if there is one 1, we end up with 2 possible multiples of 3, but only 1 possible multiple of the others. Based on this, if we’re going to do a test, the likelihood is that the sum will be a multiple of 3 just by the laws of probability.
I think we’ve done enough initial analysis for now, so let’s test a code. We’ll make sure the sum is a multiple of 3, but we’ll avoid 12, as that could also be a multiple of 4. Looking at verifier 33, we’ll also choose the numbers to all have the same parity so we can keep verifier 33 tidy in our head.
Let’s use the code 135. This might seem like a bad choice at first, since we know the code has no order, but there are several reasons we’ve chosen this code: it has a sum of 9, it has one 1 so we can test against verifier 8 if we need to, and it also covers two of the four options on verifier 42 so that we can reduce our options if necessary.
We test against verifier 36, and we get a positive result, so the sum is a multiple of 3. We also test against verifier 8 just to get a straight answer either way, and another positive result tells us there is a single 1 in the code. This removes the possibility of 12 as the total sum, meaning the total sum is either 6 or 9.
Okay. It feels like we’re getting somewhere, but I don’t think we’re quite there yet. There are slightly too many options to remove still, so we’ll test against verifier 42 and finish up the round. We test it and we get a cross, which means verifier 42 is either testing for blue as the unique largest or purple as the unique lowest.
Let’s recap and then see how far we can get with that new information. We know that there is one 1 in the code, the sum is a multiple of 3 (so 6 or 9), and that there is no order in the code.
Let’s assume that verifier 42 is testing for blue as the unique largest. If that’s true, blue can’t be 1, and neither can purple since this would create order, so yellow is the 1. Since this would define yellow without ever needing verifier 33, this means verifier 33 couldn’t be testing for yellow.
It would also mean the sum of blue and purple would have to be 5 or 8. If blue is the unique largest, the only options are blue 3 and purple 2 or blue 5 and purple 3. Since blue is odd for both of these options, this would mean verifier 33 would have to be testing for purple as odd or even.
However, if verifier 33 was testing for purple as even, we could use verifier 8 (there is one 1), verifier 42 (blue is the unique largest) and verifier 33 (purple is even) to identify yellow uniquely as 1, which would mean we would be guaranteed no order, and verifier 22 would be redundant.
So, if verifier 42 is testing blue as the unique largest, we’ve actually solved the code and we have blue 3, yellow 1, purple 2.
How about if verifier 42 is actually testing purple as the unique lowest? If that’s the case, purple will be the 1. In this case, blue and yellow must add up to 5 or 8, and we end up with blue 2 and yellow 3, or blue 3 and yellow 5, or blue 4 and yellow 4. The only ways to uniquely define the code using verifier 33 will then be if it’s testing yellow even or blue odd.
So, now we can see a way to solving the puzzle in at most 5 tests:
- We’ll choose a code where blue is the unique highest but purple is not the unique lowest.
- If we get a tick, blue is the unique highest number, and the code is 312.
- If we get a cross, we’ll test against verifier 33. This is going to mean we need the code that we test to also have blue and yellow both even or both odd so that we can separate the two possibilities of yellow even and blue odd.
The code we’ll use is therefore 423. We test against verifier 42 and we get a negative result, which annoyingly means we’ll need that fifth test. Still, we now know that purple is the unique lowest, making it a 1. We test against verifier 33 and get another negative, so this verifier must be testing for an odd blue.
Since purple is 1, blue and yellow must add up to 5 or 8, and the only way we can do that with an odd blue without creating order is the code 351.
The machine took 8 tests across 3 rounds to solve this, so we should still be very pleased with 5 tests. Hopefully this example has given you a flavour of how much harder Hard mode can be, just by introducing verifiers with options that are not mutually exclusive.
Come back next week, if you dare, when we’ll be moving from Classic mode to Expert mode. If you want to get a head start, the game code we’ll be using is #D4B IDV.
