The automated solution of logic puzzles

Information Processing Letters 24 (1987) 317-324 North-Holland

16 March 1987

THE AUTOMATED SOLUTION OF LOGIC PUZZLES

Mark VALENTINE and Robert H. DAVIS

Department of Computer Science, Heriot-Watt University, 79 Grassmarket, Edinburgh EH1 2HJ, Scotland (United Kingdom)

Communicated by W.L. Van der Poel Received 22 May 1986

Keyword: Logic puzzle

1. Introduction

1.1. The class of problems to be solved

This paper describes an attempt to automate the solution of the class of logic puzzles such as those appearing in "Logic Problems" (published by B.E.A.P., Ltd. and widely available through newsagents).

The general problem is as follows. We are given a number of objects (say m) from each of a set of (say n) domains, such that objects from one domain have some relation to objects in others (for example, a set of cars, their colours and owners). In addition, there is a set of constraints (clues) which enable us to determine which objects are related to each other (i.e., we deduce from the clues a partitioning of the total set of objects such that each set in the partition contains one member from each domain).

The clues are of two types: (a) definite statements of objects that are or

are not related, (b) a relation on the values of elements of a

domain in different partition sets. As a small example, the following is a problem

over the domains 'first name', 'surname' and ' age'. 1

Example (see Fig. 1). Three children live in the same street. From the two clues given below, can you discover each child's full name and age?

First names: Anne, Brian, Mary. Surnames: Brown, Green, White. Ages: 7, 9, 10. Clues: (1) Miss Brown is three years older than Mary. (2) The child whose surname is White is 9

years old.

1.2. Representing the problem and its solution

The conventional means of solving this type of problem involves maintaining a grid of possible relationships between all the domains, and ticking or crossing off the possibilities as the deduction proceeds (for example, knowing that Miss Brown cannot be Brian, we can enter an " × " in the Br ian/Brown box).

It is difficult to keep track of an exhaustive method by this means, and a heuristic approach is normally used to avoid the many levels of recur- sion that would result otherwise.

Our approach is to view the partitioning process as the generation of n-tuples, such that a tuple exists representing the power set of possible final partitions containing each element of every domain, thus:

1 From "Logic Problems" No. 22, September 1984.

For each tuple T k = (Aia, Ai2 , . . . ,Ain) , at least one A ij represents a single element e,

0020-0190/87/$3.50 © 1987, Elsevier Science Publishers B.V. (North-Holland) 317

Volume 24, Number 5 INFORMATION PROCESSING LETTERS 16 March 1987

S u r n a m e Age

First Name

Age

Anne

B r i a n

Mary

10

0 • .,.~

7 9 10

Fig. 1. Three children named Anne, Brian, and Mary live in the same street. Their ages are 7, 9, and 10 and they have surnames Brown, Green, and White. Can you discover each child's full name and age if:

(1) Miss Brown is three years older than Mary. (2) The child whose surname is White is 9 years old.

and the other Aij's represent possible values of elements in the same partition.

For example, the tuple

T = ((a , b, c}, (d}, {g, h ) )

on the domains

D l = {a, b, c}, O2= {d, e, f}, D 3 = { g , h , i }

represents the powerset of partitions for the element d, possible partitions including (a, d, g}, {a, d, h} and {b, d, g}. Thus, initially (before we take any clues into account), the set of tuples is

Tk = (Akl, Ak2 . . . . ,Ak , ) , l ~ k ~ m n ,

where

eij i f k = ( j - 1 ) m + i ,

Akj = Dj otherwise.

We use the clues to cut down on these initial possibilities. For example, if we are told that e13 has nothing to do with e21 (denoted e13 R e2~,

where R denotes a relation), we can deduce tuples

T x = ((el3 }, D 2 - e21,...)

and

T, = ( D x - e13, {e21), . . . )

( i f m = 3, D 1 - e l 3 = {ell , e12 )) .

Here, T x and Ty are said to be disjoint, i.e., at least one corresponding pair of component sets A x~ and Ay i are disjoint (two sets A and B are said to be disjoint if they have no elements in common, i.e., A n B =~).

Similarly, if in the above example we were told that in addition el3 R e33 , then we would have

T x = (( el3 ), ( e22, e23 ), ( e33 ))

and

Ty = ({ e13 }, { e21 , e22 , e23 }, (e33 } ).

Two tuples can be joined into one if they convey information about the same element, as do T x and Ty above. This is done by creating a new tuple

318


whose components are the intersection of the corresponding sets in the existing tuples, and by deleting the original tuples. Thus, joining T x and Ty would yield a tuple identical to T x since

{ e 1 3 } N ( e 1 3 } = { e 1 3 } ,

{e22 , e23 } A {e21, e22, e23 } = (e22, e23 },

{e33 } ~ (e33 } = {e33 }.

As mentioned previously, we can be given two types of clue. With the first type (a), the clue can be regarded as having a subject e~, a number of objects e i s.t. e i R e~ (the IN-list), and a number of objects e 0 s.t. e 0 R es (the OUT-list). We use the tuple notation to express such clues (which we shall call ' tuple' clues), for example (following our previous example), given

el3 R e33, el3 ~ e21

we write

T i = ( ( e 1 3 ) , - {e21 }, {e33 })

(where - (e2i } means D 2 - (e21), i.e., (e22, e23 )). The subject of this tuple is el3 , the IN-list

contains the single object e33, and the OUT-list contains e2r

The second type of clue (b) gives information about relationships of some kind between the values of corresponding tuple elements. To express these relationships, we introduce the notation Dk(eij ) to denote the element in D k of the tuple concerning % (to illustrate, if T x = ({el3), (e22 , e23 }, (e33)), then D3(e13 ) = e33 and D2(e13 ) can be either e22 or e23 ). Also, Dk(Tx) is the set of possible objects for the domain D k of tuple T x. Thus, we can express "Miss Brown is three years older than Mary" which we shall call a 'relation' clue) as

Age(Brown) = Age(Mary) + 3.

(Note: Since the same element may be a member of more than one domain, we should disambiguate such object descriptions by giving both the element name and domain name, i.e.,

Age(Brown, Surname)

= Age(Mary, First Name) + 3.

Further, to permit such clues as

Surname(Brown, Surname)

is longer than Surname(Mary, First Name)

(" the length in characters of the element in the Surname domain of the tuple containing Brown is greater than that of the corresponding element in the tuple containing Mary") which describe relationships between the values of some attribute of elements, we should be more explicit and write

value(Age(Brown, Surname))

= value(Age(Mary, First Name)) + 3.

However, for convenience we shall use the less strict form whenever the meaning is clear.)

A 'relation' clue thus consists of: a domain on which the relation operates (the relation domain), a list of objects which define the relation (the relation-list, which is sorted in ascending values of the relation domain element of their tuples), and the numerical difference in values between elements defined by successive members in the list.

2. The logic problem solver

This section describes a program written in C which solves the class of puzzle described above. The program consists of a central 'solver' unit attached to a number of interfaces which enable the user to specify the problem in a number of ways, including via an interactive question-and- answer session and by a written specification.

2.1. An algorithm for problem solution

The following is a description of the method developed to generate the solution of size m × n (i.e., n domains with m elements each).

(1) We start off with the initial set of tuples

Tk, l~<k~<nm.

(2) For each ' tuple ' clue we perform the following: (a) to the tuple containing the subject of the

clue, join each of the tuples corresponding to elements of the 1N-list--if this

319


results in a change in the subject tuple, try it against other tuples in order to deduce further relationships (see below for an explanation of exactly which other tuples to try),

(b) eliminate each object in the OUT-list from the tuple containing the subject, and try the subject tuple against the others if this results i n a change.

(3) For each 'relation' clue, we mark each pair of related objects as having the appropriate rela- tionship, ensure they can never jo in (the difference in values defined by the relation is not permitted to be zero), and try the objects against other tuples.

(4) When trying tuples against each other, we may find that:

(a) they concern a mutual object, in which case we can join the tuples,

(b) they are disjoint, and we can eliminate the member of any singleton component sets in one tuple from the corresponding set in the other (for example, if Mary's surname is Green, then we know that Anne's is not),

(c) domains within the tuples are related, and we may be able to make further eliminations on this basis (for example, if Miss Brown is older than M a r y , we know that Mary's surname is not Brown, and she is not the oldest ch i ld- -her age is not 10).

In any case, whenever we further restrict the possibilities in any tuple (i.e., change a tuple, since at no point we can proceed 'backwards' and invert a decision), we once again try the tuple against the others, so that this process continues until no further changes are made.

2.2. Data structures used in the automated solver

The title and domains of the problem being solved are held in the problem structure, as well as the names and values of elements of each domain. The value component represents a single value which may be assigned to each element. A default value is provided which is simply the ordinal value (position) of the element in the domain. The cur-

rent clue is held in the clue structure, which holds: • the type of clue (tuple or relation), • for a tuple clue:

- the subject--like all objects, held as a pair (domain number, element number within domain),

- the IN-list, - the OUT-list,

• for a relation clue: - the relation domain- -he ld as the domain

number, - the difference (step) between adjacent ele-

ments in the relation list, - the relation l i s t - - in ascending order of value. The tuple table contains tuples explicitly gener-

ated by the solver; tuples are generated only when they are required. Tuples which have not yet been generated are assumed to be one for each object not yet described by an explicit tuple. For each generated tuple we keep: • a 'dirty' bit, which enables the ' try' mechanism

(see below) to tell whether a tuple has been changed and thus whether it requires to be compared with other tuples,

• for each domain of the problem: - the set of possible elements to which that

domain of the tuple may be instantiated (the possibilities remaining),

- any relations with the same domains in other tuples (i.e., is this domain a 'relation domain' for any relation?)--relations in which a domain of a tuple takes part are held as a list of relation identifiers, which point to a relation in the relation table.

The relation table contains the list of active relations. For each relation we keep: • the objects "It" and "gt" whose tuples are

related, such that

rel_dom(lt) + diff = rel dom(gt)

(actually, the values of . . . ) , • the magnitude of the difference "diff" between

the values of the appropriate elements (a magnitude of zero denotes that there is no fixed difference, but that the values are simply ordered ). The try stack represents comparisons to be

made between tuples. Initially, when we decide a

320


tuple has changed, we want to compare it against all other tuples (not i tself)--we may also know of one other tuple which we do not need to try, and we may exclude it. However, if in the middle of trying one tuple against the rest we make changes to another tuple, we may wish to try that tuple against others before we continue. Thus, the tuple stack is pushed down each time we ' t ry ' a tuple. The contents of an element of the tuple stack are: • the tuple being tried, • a list of tuples still to be compared against this

tuple. Obviously, doing this recursively the tuple may

be due to be compared against some others any- way, and so we only push those which are not due to be tried against it. Also, at some point (as a result of joining tuples) we may delete a tuple. In this case we go through the try stack and delete any scheduled comparisons involving that tuple.

The comparison list of the try stack is pre- sented as a bit m a p - - o n e for each possible tuple. This saves time and speed, as long as the tuples will not outnumber the 32 bits in the long integer used to hold the map. The sets comprising the domain components of each tuple are also repre- sented by a bit map (since these problems do not usually involve more than four or five domains, each consisting of five elements, we only need in t ' s (16 bits) to hold an entire domain of elements); also there will be at most 25 tuples (1 per element per domain).

2.3. H ow it works

The main ' command processor' simply consists of a big switch statement which reads a 'canonical control stream' fed to it by one of the program's interfaces. It is the interface's job to structure this control stream so that the program solves any given puzzle; how this is done is described in the next section.

The solver itself accepts a number of instructions outlined as follows: • define the title of the problem, • add a domain to the problem, • add an element to the current domain, • give the current element an explicit value, • start defining a new tuple or relation clue,

• add an object to the IN-list of the current clue (assuming it is a tuple clue),

• add an object to the OUT-list of the current (tuple) clue,

• start defining a new relation clue, • define the 'step' (difference between values in

the relation list) of the current (relation) clue, • add an object to the relation list of the current

(relation) clue, • give the current clue (see the explanation be-

low), • view the tuple table in its current state (explicit

tuples only). The work is done when a clue is given. At this

stage, the previous information in the current clue is used as described in previous sections to generate tuples and eleminate possibilities from their constituent domain sets.

2.4. Giving a "tuple" clue

The function get_tuple( ) returns the tuple containing an object; if this tuple has not been explicitly generated, it will be created by the function new_tuple( ) and tried against all other tuples to see if it can be reduced on that basis. Once the tuple contains the subject of the clue and a member of the IN-list, the tuples can be joined. This is done for each object in the IN-list. Also, each object in the OUT-list is eliminated from the appropriate domain of the subject tuple (note that it is necessary to continually call get_tuple( ) for each object, since the original tuple may have been joined to another).

2.5. Giving a "relation" clue

Relation clues involve operating on adjacent objects in the rel-list (relation list). For each such pair, we assert the relation by creating a new entry in the relation table and marking the 'rel- dom' (relation domain) of the appropriate tuple with an index into this table. We then 'align' the domain sets of the tuples so that no combination of possible elements from each set may violate this relation, and since we know that the tuples are disjoint, we can perform the operation "disj( )" on them, which rules out singleton members of one set from the other.

321


2.6. Join( ) and Try( )

Join( ) operates by copying information from one tuple to the other by intersecting corresponding sets and adding any relations from one tuple to the other before deleting the redundant tuple. Thus, d(eij) and d(eke) may be the same for different e's.

Try( ) stacks the tuples to be compared, and (while there is still a comparison between two tuples to be made from the top of the stack) checks whether any pair of corresponding domain sets in the tuples indicates further reduction of possibilities. As mentioned above, it may be found that:

(i) the tuples concern the same object (two singleton domain sets are equal) and may be joined,

(ii) corresponding domain sets of two tuples are related (they have a common relation index in their domain relation list), in which case we may be able to reduce the possibilities by 'aligning' the domain sets,

(iii) the domain sets have become disjoint, in which case we can perform the "disj" operation on them.

3. Interfacing with the human user

The core 'solver' is designed to take its input from independent interface programs which can supply a suitably structured canonical control stream. Two such interfaces are described below. A shell script has been written to invoke an appropriate interface and link them as appropriate. Given a file argument, this script will employ a parser which treats the named file as a written specification (the specification language is described below) and passes a parsed stream to the solver. With no arguments, the script will invoke the interactive question-and-answer interface to prompt the user for a problem.

3.1. Interactive question-and-answer session

The interactive interface is a rudimentary program which simply prompts the user for ap-

propriate information in a fixed order (see below for suggestions for a more sophisticated user interface).

Firstly, the user is asked to give the problem a title. As with other string information, this may contain any characters preceding a carriage return.

The user is then prompted for the name of a domain. If there are no more domains to give, a single carriage return terminates the domain list. For each domain, the user is prompted for the name of its elements (again, a single carriage return terminates this list)--all domains must have the same number of elements. For each element, a value is requested--this value is expected to be numerical and is terminated by a carriage return. If no explicit value is given, a default (the element's position in the domain) is assumed.

Once all domains have been specified, the user is prompted for a command. Possible commands are: • Give a tuple clue (type "t"). The user is prompted for the subject, IN-list, and OUT-list. Such objects are specified by giving their names, though the names may be abbreviated to the shortest prefix which identifies the object. The two lists are terminated by a carriage return in response to the prompt. • Give a relation clue (type "r"). The user is prompted for the relation domain, step size, and relation list. The relation domain and objects in the rel-list are identified as in tuple clues by the shortest prefix of their name which specifies them (actually the domain/element lists are scanned until the first one which matches the prefix). Again, the rel-list is terminated by a carriage return. The step size is a numerical value (the difference in values between successive members of the rel-list). If it is omitted or given as zero, the list is simply assumed to be ordered (i.e., there is no explicit difference in values, but they are to be considered ordered--lowest value first in the tel-list). • Print a summary of the commands available

(type "?"). Invalid commands will give an abbreviated summary in any case. • Give the solution to the problem and quit (type

,,Q,,).

322


This command prints the tuple table in its current state and exits. If t h e problem has not actually been solved (i.e., there are m tuples, where m is the number of elements per domain, and every domain set is singleton and unique), this will be reflected by too many tuples and nonsingleton domain sets.

Names of domains and elements in the display are truncated if necessary to 20 characters.

3.2. Written specification

The noninteractive specification employs a parser generated by YACC to interpret the contents of a named file as follows.

The specification is in free format (blanks, tabs, newlines ignored, except within domain and element names where a sequence of whitespace is converted into a single blank). Names are made up from any character other than the set

< + =

which serve as separator tokens as described below. The specification consists of a title enclosed in square brackets ( " [ . . . ]"), a number of domain specifications (below) terminated by the separator " - - ", and a number of tuple a n d / o r relation clues.

A domain specification consists of the domain name, followed by a brace-enclosed ( " { . . . }"), comma-separated list of element names, each element name optionally followed by a value-speei- tier of the form " = (number)" .

A tuple clue is given as a parenthesis-enclosed ( " ( . . . ) " ) , comma-separated list of object names. The first object is taken as the subject of the tuple, the rest as members of the IN-list or OUT-list depending upon whether it is preceded by the token . . . . . , which specifies the OUT-list.

Objects in both tuple and relation clues are specified by their names, which can be abbreviated by the shortest prefix as in the interactive interface.

A relation clue is given in one of three forms each consisting of the relation domain name (pos- sibly abbreviated) followed by a parenthesis-enclosed ( " ( . . . ) " ) component. This component is one of:

• a comma-separated list of objects, the objects make up the rel-list, and are considered to represent values in sequence (i.e., implicit step size of 1); • a list of objects separated by " < ", again the objects make up the rel-list, but there is no explicit step size (this represents an ordering of values ); • (object)" + " ( s t e p ) " = "(object) , this results in the rel-list for the clue consisting of the two objects (entered in the order given) with the explicit step size given. Obviously, it would be possible to give all relation clues in this form, as long as sequences and orderings were broken up so that each rel-list contained only two objects.

The tuple clues are gathered and fed one by one into the solver; the interface passes on the necessary 'give' instructions after each clue specification. Once all clues have been given (end of the specification file), the 'view' instruction is passed on, so that the program prints out the tuple table (which hopefully represents a solution) before exiting.

4. Conclusions and further work

The logic problem solver performs well for most of the problems given to it, i.e., all the 4 × 5 ones tried resulted in correct solutions. However, the two 5 × 5 pn771es given to it were not solved completely; the solver did not make any wrong eliminations, but it did not manage to restrict all domain sets so that they were singular. It is doubt- ful that these problems actually exceed the size limitations of the program (5 tuples, 5 domains, 4 objects per IN-list, 10 per OUT-list, 5 per rel-list, 25 tuples, 10 relations, 5 relations per tuple domain and a try stack of depth 25) since checks are made in the program for this occurrence. The problem is probably a bug which happens only rare ly-- the larger problems producing enough work to stretch the program beyond its tolerance of these bugs.

4.1. Generalising the "value" of an element

The 'value ' of an element as defined above provides a fairly flexible way of specifying most

323


problems. However, an even more general method would be to assign any number of attributes (our 'value ' is really just an a t t r ibu te - - the only one we cater for), and allow the user to define values for these attributes. In fact, it is feasible to allow predefined attributes such as lexical ordering and string lengths (two examples used in some problems) for which the program can generate the attribute values for each element. Relation clues can then refer to specific attributes of objects.

4.2. Nonunique elements

As mentioned in Section 1, it may be necessary to disambiguate object references by specifying the domain. This is the case in a problem such as one concerning a race where domains may be 'winner ' , ' runner-up ' , etc. where the domains have common elements. This is an easy extension to the current program.

the domains and their elements were displayed on the screen, and the user moved a cursor around them 'point ing ' to the objects with a key that specified, for example, which list the object was to be in. Wasserman's system could be used as a two-way communicat ion interface to provide this high degree of interaction.

4. 4. A natural language interface

Of course, there is no reason why we should not be able to just type in the problem as it is described originally in English! This may prove an interesting and useful exercise, since to make a start at this task one needs only consider a rela- tively small number of grammatical structures (enough to understand at least a few natural language clues).

4.5. A Prolog implementation

4.3. Two-way communication with the interface

At present, the interfaces simply feed the solver with a sequence of instructions. Making the communicat ion two-way would allow the user to, say, ask for a list of the domains and their dements , instead of having to remember them. This would allow more highly interactive interfaces such as one with which I experimented using Wasserman's R a p i d / U S E Dialogue Management System, where

Of course this type of puzzle is a 'natural ' one for implementat ion in Prolog, since the structures are just the kind which fit into the language, and the problem space has in common with Prolog a high degree of expressability in first-order predicate logic (indeed the original ground-work for this project was done within the framework of predicate logic). Prolog (or some other suitable AI language) is also a must if natural language interfaces are to be considered.

324

Documents

The automated solution of logic puzzles