Part Two: Embedding The Principles
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.
Last week, we started off learning two key principles for advanced Turing Machine play. You can check out the article here, but here’s a reminder of those 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.
Now, I’m going to let you in on a secret. This article series doesn’t really have much more to say than the two principles above. The focus is now going to be on embedding those principles. We’ll do that this week by looking at another puzzle in Classic mode, but this time using six verifiers on the Standard setting. In following weeks, we’ll move on to considering the other game modes, Extreme and Nightmare.
Here’s a picture of the six verifiers we’ll be using, and if you want to play along at home, use game code #B63 YQ1 N on the Turing Machine website.
This time, you might’ve had a bit of a headstart, as I gave out the game code at the end of last week’s article. So we won’t look at an average play, and we’ll just get straight down to using our key principles to analyse the setup and see how quickly we can solve the puzzle.
The key point I’ll be trying to show through this example is the necessity of returning to verifiers that you’ve already considered. With more verifiers in play, often we’ll need to consider one verifier to make logical deductions about another, and then, using the information we gain, return to verifiers we’ve already considered using that new information to make further deductions.
We’ll begin by looking at verifiers 22 and 14. If verifier 22 is testing for the numbers being in ascending order, this will immediately tell us that blue is lower than both yellow and purple, and verifier 14 will be redundant. By symmetry, if verifier 22 is testing for the numbers being in descending order, this will immediately tell us that purple is the unique lowest, and again, verifier 14 would be redundant. So by principle 1, there must be no order, and we have solved verifier 22.
But we can also make a deduction the other way; looking at verifier 14, if yellow is the unique smallest, blue and purple will both be larger, meaning the numbers will dip down from blue to yellow and back up to purple. This means yellow as the unique lowest would make verifier 22 redundant, and so we can remove this as an option again by principle 1.
So now we know that blue or purple are the unique lowest but also that there is no order to the correct code.
Now we consider verifiers 2 and 5. If verifier 2 is testing for blue equal to 3, this will make verifier 5 redundant, so this is not an option. So blue is either less than 3 or greater than 3, and we could test verifiers 2 and 5 to uniquely define blue.
Switching to verifier 8, we saw previously that three 1s is immediately out since that would make all other verifiers redundant. However, since verifier 14 tells us that there is a unique lowest number, we can also remove two 1s as an option, meaning we have at most one 1.
Let’s assume that verifier 14 is telling us that blue is the unique lowest, and then look at verifier 2 again.
We’ve already removed blue equal to 3 as an option. If blue is greater than 3, it must be 4 with yellow 5 and purple 5. This makes many other verifiers redundant, so this is impossible.
But if blue is less than 3, we’ll be able to use verifier 8, which is testing either zero 1s or one 1, to tell us whether blue is equal to 1 or 2. Since verifier 5 only tests for blue, it would be made redundant. So if blue is the unique lowest, blue isn’t equal to 3, greater than 3, or less than 3. This means blue cannot be the unique lowest, and since we’ve already eliminated the possibility of yellow as the unique lowest, purple must be less than both blue and yellow.
Looping back to verifier 2 again, if we now assume that blue is less than 3, we must have purple as 1 and blue as 2, since purple is lower than blue. However, this would mean verifiers 2 and 14 between them are enough to tell us that there is exactly one 1, so this would make verifier 8 redundant. This means blue cannot be less than 3, and since we’ve already eliminated blue equals 3 as an option, we have blue greater than 3 i.e. blue is either 4 or 5.
Let’s recap the information we have so far:
- We know that blue is equal to 4 or 5, and can be defined uniquely using verifier 5
- We know that purple is the unique lowest
- We know that there is no order to the correct code
Using the last two bullet points above, we can make some further deductions. Purple as the unique lowest means that yellow must be greater than purple, but in order to maintain no order within the code, we then cannot have yellow less than blue. So yellow must be greater than or equal to blue.
Now, we’re getting close to running a test, but we’re not quite finished yet. We can consider both possible options under verifier 5, and hopefully make some logical deductions or at least identify which tests we should make and therefore which code we should use for round 1.
First, let’s consider if blue is odd. This would naturally mean blue is 5, and to maintain no order within the correct code, yellow would also be 5. Since we then know that the sum of blue and yellow is even, we could use verifier 18 to determine whether purple was even or odd. We actually wouldn’t need to test verifier 18 though; if it showed purple as even, there’d be no way for us to define purple uniquely, since we would have blue 5 and yellow 5 and there would be two options (2 and 4) for even numbers which are the unique lowest. So we’d know that verifier 18 would tell us that purple is odd, and we could use a second test on verifier 8 to identify whether that odd number is 1 or 3.
Now, let’s consider if blue is even, and stick with me here, because we’re going to go circles within circles now.
If blue is even, it would be equal to 4. This would give us two options for yellow: either yellow is 4 or 5. Now we look again at verifier 18. The interesting thing about this verifier is that the parity (evenness/oddness) of a sum of three numbers is usually less helpful than the parity of a sum of two numbers.
For example, if the sum of all three numbers is even, we either have three even numbers and one odd number, or three odd numbers, and if the sum is odd, we have three odd numbers or two even numbers and one odd number.
But with the sum of two numbers, if the sum is even, this means both numbers have the same parity, while if the sum is odd, it means both numbers have a different parity. Just keep that in your brain for a moment while we consider if blue is even AND the total sum is even.
With an even blue, this would mean both yellow and purple are the same parity. If verifier 8 tells us that there is one 1, we are finished: purple is that 1, and since yellow is 4 or 5 and also odd, it is 5. If verifier 8 tells us there are no 1s, we cannot finish; we’ve tested all verifiers, and we could either have yellow 4 and purple 2, or yellow 5 and purple 3.
What about if blue is even and the total sum is odd?
Well, this situation is very similar to the previous, but with slightly different permutations. If verifier 8 tells us there is one 1, again we’re finished with a purple 1 but this time a yellow 4. And if verifier 8 tells us there are no 1s, again we cannot finish, since we could have purple 2 and yellow 5 or purple 3 and yellow 4.
In other words, if blue is even, the code can only be uniquely definable if there is one 1, regardless of the parity of the sum of the numbers. This means we could solve purple as 1 and use a second test on verifier 18 to identify yellow.
Putting all of this together, we develop the following approach for our testing:
– First we test verifier 5 to find out if blue is even or odd. So far we could use any code for this since we’ll get our answer either way.
– If the result of the first test shows that blue is even, then blue is 4, and we know that we have a purple 1, since this is the only way for the code to be uniquely definable. So then we make a second test against verifier 18 to determine whether yellow is 4 or 5. Again, we could use any code for this since we’ll get our answer either way.
– If the result of the first test instead shows that blue is odd, then blue is 5, and we know that yellow is 5 to maintain no order in the code. Moreover, we know that the sum of all three numbers must be odd, since if it was even purple could be either 2 or 4 and all verifiers would still be correct. So we make a second test against verifier 8 to determine whether purple is 1 or 3. Again, we could use any code for this since we’ll get our answer either way.
At the end of last week’s article, I asked you to see if you can identify how to solve the puzzle using only two tests, and the code that you should pick for round 1 to be able to do it. But note the interesting thing about the algorithm above: we can literally pick whichever code we like! This won’t always be the case, but it will be true more often than you might realise, essentially whenever you’re able to logically reduce each verifier that needs testing down to two possible options.
We happened to choose 235, and the first test was a negative result so we knew that blue was 5 and yellow was also 5. This meant the sum of all three numbers had to be odd in order to define purple, and testing against verifier 8 showed that purple was not 1, giving a final code of 553.
Next week, we’ll be moving into Hard mode, which uses a wider set of verifier cards and comes with some important distinctions from Easy/Standard. If you want to get a headstart, the game code we’ll be using is #C52 H0G P.
