Sunday, September 11, 2011

Eight Queens in Clojure Land

Hello again. When time flies and you find yourself with your hands full of books and article to read, finding and writing about some subject can become very hard. In such times I try to look in my bag of things I-always-wanted-to-do-but-never-took-time-to-do (you can breath) . I had a little bit more than two hours to kill yesterday before digging again in Clojure in Action and the new chapter edited by Joshua Suereth in Scala in Depth.
There remain few basic algorithmic problems I want to tackle before switching to distributed algorithms. One of them is the famous eight queen problem. Fortunately Martin Odersky presented a Scala version in his book, in order to expose a nice use of the comprehensions in Scala. So, unfortunately for me Scala was not an option to implement a solution.

I wanted it recursive and having committed myself into the study of Clojure for a few months now, the language was an option. Although I am not at the level of expert Lisp and Clojure developers I took the liberty to try my very first personal implementation.
The result is not the result I expected, but as usual any critic will be welcomed: although being french I do like learning from critics as from failures and retries (really need to embrace a new nationality).
In conclusion a very brief and relaxing exercise today.

As a reminder you can get details about the the eight queen puzzle there. Basically our purpose is to dispatch eight queens on a chessboard so that, none of them can attack the others. Applying the basic rules of chess game, two queens cannot be located on the same rows, nor columns nor diagonals.
Numerous readers must have stopped there finding that too basic.
For the others let's continue. Indulge me and consider that it would more elegant to provide a solution dealing with the dispatch of n queens on a n sized chessboard (the others should not have left).
In order to solve the problem I adopted the same attitude as when solving the Hanoi Tower problem.
Let us consider the problem partially solved - one say - on a four sized chessboard. At step 3, my only partial solutions can be expressed as list of list of ...list:

A tuple represents a queen position.
The adopted rules being to index the upper left corner as (1 1) and the lower right as (4 4), the car of the list being the row number and the cdr being the column number.
A list of positions is a partial solution to be completed
And the list of list of list (:)) is the list of solutions.
No big deal there.

The solutions are to be read from left to right, the first element being the most recent position found. The annoying empty list at the beginning of the solution is due to my choice of starting from no solution.
All I have to do is considering all the possible positions on the fourth row and choose the matching ones that would lead to acceptable solution. The scenario is applicable whatever is the step index value in a n sized chessboard.
In the four cell chessboard the two solutions are:

One should notice that the solutions are symmetric and there might be interesting exercises to implement in order to reduce the number of solution to the reduced forms by symmetry considerations.

Considering the eight queen problem we are to find 92 solutions.

I usually do TDD. And I will present you the unitary tests. But I have to confess that I did not start like that. You generally start implementing some algorithm in pseudo code before writing anything, but the conciseness of Lisp languages (they are homoiconic languages) makes them natural candidates to write the algorithm as-is.

I wrote what came in mind and backwardly tested my methods one after the other adjusting the first shot. Worked nice for me:
I worked both with IntelliJ and Leinengen, with the following project.clj configuration:

The entry point of my algorithm is where I set my intention to match the different positions for a queen at step k , within a n dimension chessboard. Using Abelson and Sussman wishful programming approach lead me to:

This is where the little annoying empty list comes from.
As Martin Odersky, I define my no-solution expression as an empty list. In Clojure the empty list is not a bottom form marking the end of a list like Nil. I learned that during the exercise :), but too late.

At the very top we find the working namespace definition (algorithms.n-queens), so my file is located under some algorithms directory and the code implemented in a n-queens.clj file.
Starting, literally at step 0, I do return a (list(list(list))), otherwise I define my set of solutions as the solutions recursively found for a decremented number of steps and the range of positions to be tested.
I then return a list of the possible new solutions as a result from comparing all possible positions versus already found solutions.
The easier function to be tested is possible-positions in charge to extract all the possible positions in the row at-step. Driven by test we start with something like:

Provided at the top is the namespace definition including the clojure.test namespace.
At step 1, in a two dimensional chessboard I expect ((1 1) (1 2)) as possible positions.
The matching implementation is:

We use a map higher order function in order to apply a #(list at-row %) lambda function taking as parameter all the range from 1 to the boundary limit (upper limit is exclusive so we have to increment the boundary value)
In the placed-queens method the (possible-solutions for-positions) is surrounded by parenthesis because I decided to use a closure. I found more natural to close onto the set of possible positions, and then find a match for each possible solution. That 's the purpose of

(mapcat (possible-solutions for-positions) solutions)

mapcat allowing me to slice a list of list of solutions into recursive list of solution, and I must confess once more that I found it using TDD. No magic, just the good effect of testing. A typical test scenario for the possible-solutions implementation would be:

where starting at row 4 with the already found partial solution ( (3 1) (2 4) (1 2)) we would find ((4 3) (3 1) (2 4) (1 2))
Of course keep warm the test. It won't pass, we do not have the function yet. My function definition can be :

with the help of matching and the help of safe.
The expression (matching solution) defines yet another closure which captures a solution and allows the challenge of a possible position versus all the positions of the captured solution.
This closure is reused in the safe function to filter the possible positions matching, in effect the partial solution. From these filtered positions combined to the en-closed solution we will build new solutions. Take your time, higher order functions and their use is not always simple.

The function possible-solutions rebuild then a list of new solutions from nil, each new solution appending a filtered position to the en-closed solution. From each solution we can have multiple possible new solutions. We return a list of lists (solutions) of ...lists (positions).
The bunch of tests used to qualify this approach are:

trying effective different scenarii on four dimension chessboards...But you can't test'em till the safe? function invoked from matching is implemented.

The safe function basically creates yet (yet) another closure, closing onto a new possible position. This closure will test all the existing positions in a solution in order to ensure that the enclosed position can be appended to form a new solution.
I need tests to challenge the safe? function:

Eight queens is also an exercise given in the text Structure and Interpretation of Computer Programs (which uses Scheme). Try googling "eight queens SICP" for some sample solutions to compare yours too (also good for comparing Clojure to Scheme!).

Thanks. I will do it. I did the exercise before reading an explained solution in the book :) The whole story is that I watched the presentation of the problem by Harold Abelson and was frustrated not to have solved the problem before. Inspired by his description I wrote this solution :)