# 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

- generate all possible options for position

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.

# Using Haskell

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.

- the newList is the old list plus the selected candidate (at index
`excise i xs`

returns the`xs`

minus the element at the`i`

th 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 `Side`

s. 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.