# The Puzzle

One Tough Puzzle is a physical jigsaw puzzle made up of nine square pieces. Each side of the square as either a tab or a blank in the shape of one of the four card suits. The goal is to put them all together so they fit, like any jigsaw puzzle.

I will use this post as a tour of some cool Haskell features I’ve been enjoying for the past few months doing Project Euler problems.

## The Problem

We number the spaces like so:

+-----------+
| 0 | 1 | 2 |
+-----------+
| 3 | 4 | 5 |
+-----------+
| 6 | 7 | 8 |
+-----------+


Nine pieces in nine slots gives us $9! = 362880$ positional combinations, and nine pieces which can be rotated any of four ways gives us $4^9 = 262144$ rotational combinations, for a total of just over $23\times 10^9$ combinations (accounting for rotational symmetry). Too many to brute force.

# The Solution

We can instead try to solve the problem a little bit at a time. Our algorithm will be as follows:

• For position n:
• generate all possible options for position n
• validate position n with regard to the pieces around it
• repeat for position n+1 until done

This has the advantage of trimming the search space as quickly as possible, to avoid having to validate all twenty-three billion possible grids. We will check in at the end and see how many grids or fractions thereof we actually did have to validate.

My language of choice for this is Haskell, mostly because I’ve been doing Project Euler problems in it recently and I really like the custom data types and flexibility.

## data

Haskell has the ability to define custom data types, and compose and define them in interesting ways. In this puzzle we want to be able to inspect and compare tabs and blanks, puzzle pieces, etc.

deriving after a custom data type tells Haskell to infer how to print (show), read, or compare variables of that type. Comparisons can be

• Eq, which lets us tell whether or not two things are equal.
• Ord, which lets us tell whether one thing is bigger than another.

In our case, we don’t really have a way to decide whether one Suit or Sex is “bigger” than another, but we do want to check equality.

We define Side and Piece with named fields, which lets us extract those fields with generated getters:

For two puzzle pieces to be able to meet at an edge, they need to have the same Suit and opposite Sex es. This makes it convenient to define a custom instance of Eq for Side variables. This lets us redefine a == b to check whether two sides are compatible, rather than equal.

## Input

I defined the nine pieces in plaintext as follows:

where each character is the tab or blank on the North, East, South, and West faces of a piece. Each letter stands for Heart, Diamond, Spade, or Club, and is uppercase if the side sticks out rather than in.

We have to write a bit of parsing code to turn this a list of Piece objects.

Later, we can call

## explore

### Theory

At the core of this solution is a function I named explore, which takes a known grid and a list of candidates and generates a list of potential grids and their remaining candidates. We represent a grid as a list of pieces [Piece].

Here is an example of explore in action.

One caveat here is that we don’t just append all the items in the candidates pool to the known grid; because these are puzzle pieces, we need to append all possible rotations of each candidate. So a closer approximation with lower- and upper-case letters might be:

Once we have this explore function, we can validate the list it generates, and then call explore on every remaining grid again. We can repeat this until we are left with complete, valid grids.

### Practice

Here’s what the real explore function looks like:

We define a few helper functions which are pretty useful.

• pluck i implicitly takes the list pool, and returns a list of tuples of the form(newList, newPool), where
• the newList is the old list plus the selected candidate (at index i), and
• the newPool is the old pool minus the selected candidate. The whole thing is wrapped in a list comprehension so that rather than returning a tuple, pluck actually returns a list of all four rotations for a selected rotation. concatMap applied pluck to every item in the pool.
• excise i xs returns the xs minus the element at the ith index.
• rotate takes a piece and rotates it 90 degrees. take 4 $iterate rotate returns a list of the piece at (xs!!i), that piece rotated once, that piece rotate twice… etc, four times. This serves the list comprehension, and then concatMap flattens it into a normal list. ## validate We need to validate each grid or portion of a grid which is generated in an efficient way. If we add pieces in slots zero through nine in order, then each new piece only needs to be compared against the pieces above or to the left of it (if they exist). Thus: matchLeft and matchAbove both take advantage of our custom instance of Eq for Sides. The getters north, east, south, and west were also generated implicitly from the named fields above. OK. Let’s put it together. # Finding the solution Cool. We can get our list of potential position 0 s easily with step 0 allPieces. We can then get our list of potential position 1 s with: This recursion means we validate a list of potential grids before returning it. So, step 8 allPieces generates the list of all potential 8th-poisition grids, which requires Haskell to generate the list of all potential 7th-position grids first, and so on and so on. ## Filtering How much does this save us? Let’s look at the numbers. One note – some of these numbers will be off by a factor of four, since a solved grid is the same across any rotation. That’s why there are$4$valid solutions in the last row – it’s all the same solution across four rotations. This means there were 36 valid pieces in position 0 (makes sense, since$9\times4\$), but only 138 valid pairings for slots 0 and 1 adjacent, far less than the 1152 potentials. We peak at 1350 potential three-in-a-row combinations, and then filter down steadily.

Summing across these numbers, we see that validate must have been called something like 2800 times. Much, much better than validating all 23 billion grids.

## Printing

Finally, we define a solution grid like so:

Unfortunately this gives us an output like this:

Hard to read and inspect visually. I wrote a prettyprinter which turns that into this:

Which is much easier to inspect and validate. Here’s the prettyprinter:

Understanding this particular function is left as an exercise to the reader.

# Full Code

You can see the full code here, in a gist.

• View the source code on Github.