Observables and agency in the EM Sudoku model

This workshop revisits the Sudoku model environment that you met in the introduction, but focuses on the model as a whole, rather than on how it was put together. It first introduces you to the third key concept of Empirical Modelling that complements observables and dependencies: the agent. By linking the model to "thinking about solving Sudoku", it then brings together the principal themes from Workshops 1 and 2.

Revisiting the model

To begin the workshop, you can load the model by pressing the buttons from top to bottom to bring in each of the components of the model in turn, reflecting as you do so on how your understanding of your actions in relation to the model has changed. (I hope it has !) Though it isn't obvious from the interface, pressing a button is like introducing a whole block of redefinitions at once. This is jumping from one state to another, rather than walking (cf. travelling by air).

A reminder

What we have explored so far in Workshop 2 has touched on the part of the model that is introduced by pressing the first four buttons. The fourth "Add colour" button brings in the definitions for background colour similar to those discussed in Workshop 2C. The fifth button actually introduces definitions that were already present in the model before the "Add colour" was brought in. These restore the previous definitions of background colour.

Exercise 1: Agency in the EM Sudoku model

In Empirical Modelling, an agent is "something that we regard as capable of changing state". You can think of yourself as an agent that can change the model. Focus on the Sudoku model in its current state in the Web Eden environment. Close the Input Window . Now ask yourself the question:

What ways are available to me to change the current state of the model?

Before turning to the next page, take a few minutes to identify the different things you can do to change the current state.

Programmed agency

As users of electronic gadgets, the agency that most naturally comes to our mind when we interact with a computer is what we suppose the executing program is designed and programmed to do. Because we've called this the EM Sudoku model, you expect to be able to carry out state changes connected with solving Sudoku puzzles. What you can do with the EM Sudoku model without using the Input Window is very similar to what you can do with the Colour Sudoku program that we introduced in Workshop 1.

Exercise 2: More agency in the EM Sudoku model

Focus on the Sudoku model in its current state in the Web Eden environment. Now Open the Input Window (using the Windows tab on the Web Eden tool bar) and ask yourself the question:

What ways are available to me to change the current state of the model?

Before turning to the next page, take a few minutes to identify the different things you can do to change the current state. You may find it helpful to recall the kinds of redefinitions that we explored in Workshop 2.

Hint for Exercise 2

By using the Input Window, you can do anything that I and the other developers of the Sudoku model can do. At least, in principle!

... and whilst we normally develop a computer program like the Colour Sudoku program used in Workshop 1 by first identifying what kind of gadget it has to be, and designing it to do exactly that, we developed the EM Sudoku model by modelling the sorts of observables, dependencies and agency that are required to make sense of Sudoku, then introduced an interface to make it convenient to make those changes of state that are most routinely useful.

Exercise 3

Fix your attention on one of the possible Sudoku puzzles only. For each of the following redefinitions that can be introduced into the Input Window, say whether or not it can be made through the display and button interface (i.e. without using the Input Window).

1. a_1 = 8;

2 . b_1 = 7;

3 . c_1 = 10;

4 . d1 = "";

5 . a_1 is i_9;

6 . e4_focus = 1; ## the e4_focus observable says whether or not the cell E4 is currently selected

7 . F3_bgcolour = "lightblue";

... more about Exercise 3 on the next page.

More about Exercise 3

In order to be able to answer Exercise 3 without interacting with the EM Sudoku model at all, you need to be very familiar with the model as well a having a good understanding of its nature. When interacting with the model, remember to apply the Empirical Modelling maxim of thinking about what is going to happen before you make a definition, making the redefinition, then reflecting on what has happened. Bear in mind that in order to appreciate the effect of a redefinition you may need to do some further experimental interaction to check that the behaviour of the model is unchanged. Before you refer to the answer overleaf, consider whether your answers would be any different if you allowed for the possibility of changing the Sudoku puzzle.

Answer to Exercise 3

Whichever puzzle you select using our menu, the redefinition

a_1 = 8;

can always be made through the interface, since this cell doesn't have a fixed value in any of the five given puzzles. The redefinition

b_1 = 7;

can only be made through the interface when the cell B2 isn't fixed.

It might look as if you can make the redefinition

d1="";

through the interface in a puzzle for which D1 is blank - but try typing a digit back into that square afterwards!

c_1 = 10;

is certainly not possible via the interface, but unless cell C1 is predefined it sort of works, and doesn't actually affect the subsequent behaviour of the model.

a_1 is i_9;

might be a useful definition to use in the improbable event that you know that whatever digit you put in cell I9 also goes in cell A1.

e4_focus = 1;

has the effect of making the background colour of the cell E4 light blue - as if it had been selected with the mouse - but remains that way when you select another cell. And whilst clicking the cell F3 with the mouse certainly makes its background colour light blue, it doesn't redefine the background colour to be explicitly equal to "lightblue".

To summarise ...

- Redefinitions 1 and 2 are the only ones that can sometimes be done through the interface. In general, taking account of completely general Sudoku puzzles, rather than just the five selected puzzles, none of the redefinitions given on p7 can be made through the interface!
- The way to be sure of getting the right answers to Exercise 3 is to query the existing definitions of the observables being redefined before you redefine them, and see whether you're changing that definition. If you are, then most likely you are subverting some normal behaviour of the model.
- Exercise 3 gives you a glimpse of the richness and complexity of the relationships between values of variables that have to be maintained in creating software. Particularly difficult to handle, and especially relevant to the topical failures of ambitious software development projects is the difficulty of ensuring that your programs cope with changes in context.

Thinking about solving Sudoku

This final section of Workshop 3A will illustrate one way in which the extended agency that you have via the Input Window can be exploited in solving a Sudoku puzzle. For this purpose, you should first restore the full set of buttons to the menu that we displayed originally. To do this you can enter the Eden definition:

%eden

buttonMenu is [button1, button2a, button2, button3, button4, button5, button6, button7, button8, button9];

This introduces elements to the model that are more experimental and exploratory in character.

Automating simple steps in solving a Sudoku puzzle

The simplest deductions we can make when solving a Sudoku puzzle involve checking (a) whether there is only one plausible digit for a cell, and checking (b) whether there is only one location for a particular digit in a given row, column or region. Imagine that we are focusing on one row r of the puzzle, and that we can see the number of plausible digits that there are for each cell in that row. Now suppose that one of the digits x that we need in order to complete the row is discounted, and that we recalculate the number of plausible digits there are for each cell in the row.

Exercise 4

Explain how you may be able to determine where to put the digit x in row r according to criterion (a) and (b) by inspecting the values of the counts for the row r before and after we discount the digit x.

Hint for Exercise 4

If either you can't come up with an answer, or want to confirm that you're correct, then focus for a moment on a simple puzzle, such as puzzle 1, and consider the first row, to which you can readily see that both these deductions apply. Write down the counts of plausibles for the five empty cells before and after you discount one of the relevant digits. If you don't want to calculate the counts yourself you can just refer to Workshop 2C, where you'll find a formula for the number of plausible digits for any cell.

Automating our technique

The Sudoku model contains all the observables that we need to carry out the process that we have described on the page 14. The counts of plausible digits for every cell are already defined within the model. For the cell B3 (say) this can be found in the observable cntposs32. This is in turn defined in terms of possdig32. From Workshop 2A, you may recall that this observable has the definition:

possdig32 is (all - all32) - (region1digits + (row3 : digit>0 0igit) + (col2 : digit>0 0igit))

How do we interpret this definition? - see Ex 2.5 on p16 of Workshop 2A.

Interpreting the definition ...

possdig32 is (all - all32) - (region1digits + (row3 : digit>0 0igit) + (col2 : digit>0 0igit));

In words, this states that the possible digits for the cell B3 comprise all possible digits (stored in the observable all ) with alll the digits specified in a particular subtable all32 removed, and with all those digits that appear either in region 1 or row 3 or column 2. You can check the current values of all these observables by querying the associated Eddi tables.

Automating the checks for (a) and (b)

To carry out the check on rows (columns / regions) to see how the counts of plausible digits are affected by discounting a digit, you can now use a sequence of redefinitions and queries of the following form:

%eden

all=[[["int"],"digit"],[1],[2],[3],[4],[5],[6],[7],[8],[9]];

? rowcounts;

all=[[["int"],"digit"],[1],[2],[3],[4],[5],[6],[7],[8]]; ## discounting 9

? rowcounts;

being sure to restore the original value of the table 'all' subsequently:

%eden

all=[[["int"],"digit"],[1],[2],[3],[4],[5],[6],[7],[8],[9]];

Try using this to find instances of where you might be able to place a 9 in one of the given puzzles, applying the criterion you came up with in Exercise 4.

Rough and ready automation of the manual procedure

The manual technique for filling of the grid according to criteria (a) and (b) can be simply applied automatically to rows, columns and regions by computing the plausible counts for all cells with and without each digit in turn, and applying the criterion of Exercise 5. This principle can be illustrated by clicking the "Prototype Automation" button: as set up this applies specifically to regions, and produces the results (if any!) displayed in the Output Window after the output "Region check" is shown.

Using the Sudoku model to record hidden knowledge

Applying the basic criteria (a) and (b) to a simple Sudoku puzzle such as puzzle 1 , as described on p19, is very productive. The same criteria when applied to a puzzle such as puzzle 5 yield no results - the rules (a) and (b) do not apply in this case. This is what you experienced in Workshop 1, when you found that the Colour Sudoku was little assistance in solving that puzzle. Can we overcome this problem?

An illustrative example

To show that, with the Sudoku model, we can make use of information that doesn't directly translate into a digit we can enter in the grid, consider puzzle 5. Though running the prototype solving routine doesn't give any result, we are able to input some extra information to the model. For instance, it is possible to see that the cells A6, B6 and C6 must contain the digits 1, 4 and 7, from which we can conclude that the cell D6 cannot contain the digit 1. How can we embody this information in the model?

Adding "hidden" information to the model

The solver who recognises that the cell D6 doesn't contain a 1 would like to remove this possibility from the set of plausibles. By referring to the definition of possdig64, it is clear that this can be done by introducing a digit into the table all64, which is currently empty. You can of course do this by direct definition through the interface (cf. p18, where we redefined the table 'all' in Eden). In fact, the button interface beneath the grid has been supplied for this important role. You can check this by clicking on the digit 1 in this array, and querying the Eddi table all64 to see that it now contains the digit 1. Having made this update, you can re-run the region check on the puzzle, and it will reveal that the cell F4 necessarily contains the digit 1.