jblog
toc

Maze Solving

2017-02-27, post № 161

programming, Python PIL, #amazing, #labyrinth, #Minotaur, #solver

Mazes have been a subject of human interest for thousands of years. The Greeks used them to trap a bull-man hybrid, the French built them to show how they could impose order on nature, and even nowadays people enjoy wandering around corn mazes.
The algorithmic art of using computers to solve mazes — and even to find the shortest path through a maze —, however, has only emerged in the last couple of decades.

I was inspired by a recent Computerphile video in which Michael Pound talks about implementing different path finding algorithms for use in maze solving. And as he used Python — one of my favourite languages out there [1] —, I thought I could give it a try and came up with this maze solver.

maze-solving_normal_solved_enlarged.png

The mazes given to the solver (through a .png file) have to have a specific form. The maze needs to have a border all around (painted black) with two holes at the top and bottom, marking the maze’s start and exit (all path pixels are white).
Then the solver — using PIL — reads in the maze file, determines start and exit and starts at the maze’s start, labelling each maze path according to its shortest distance to the start. After it has found the exit, it stops looking at the maze and traces its origins back from the exit, marking the path it goes along as the maze’s optimal solution (highlighted in red).
The different hues of blue indicate the tile’s distance to the start, the white tiles are tiles the solver did not even look at.The different shadings also reveal information about the maze. Mazes with only one solution tend to have sharp changes as there are parts of the maze separated by only one wall, yet separated by a huge walk distance through the maze. The one maze with multiple solutions (see upper right image below) — in contrast — has only gradual changes in hue.

To solve a 𝟦 megapixel maze, the solver takes around 𝟥 seconds, for a 𝟣𝟨 megapixel maze around 𝟣𝟦 seconds and for a 𝟤𝟤𝟧 megapixel maze around 𝟩 minutes and 𝟤𝟤 seconds.
Performance was measured on an Intel Core i7 (𝟦.𝟢𝟢 GHz).

All mazes shown were downloaded from Michael Pound’s mazesolving GitHub repository, which were mostly generated using Daedalus.

The solver’s source code is listed below, though you can also download the .py file.

maze-solving-1_perfect2k_solved.png
maze-solving-2_braid2k_solved.png
maze-solving-3_perfect4k_solved.png
maze-solving-4_perfect10k_solved.png
maze-solving-5_perfect15k_solved.png
Source code: maze-solving.py

4096

2017-02-25, post № 160

games, Java, programming, #2016, #clone, #exponents, #jar, #powers of two

4096 is a Java-based clone of the well-known web and mobile game 2048, which itself clones 1024 and is similiar to THREES. The naming trend is quite obvious, though note that 2^{12} is a power of two where the exponent is divisible by three, further connecting to the aforementioned game.

In the game, you are faced with a 𝟦 ⨉ 𝟦 matrix, containing powers of two. By swiping in the four cardinal directions (e. g. pressing the arrow keys), you shove all the non-empty cells to that side. When two equal powers of two collide, they fuse together, adding. Once you shoved, an empty tile pseudo-randomly transforms to either a two-tile (𝟫𝟢%) or a four-tile (𝟣𝟢%).
Your objective at first is to reach the tile 4096, though the real goal is to achieve the highest score. Your score is the sum of all the collisions you managed to cause.

To play 4096, you can either download the .jar file or review and compile the game for yourself, using the source code listed below.

Controls

  • Up, down, left or right arrow key shoves the tiles,
  • ‘Escape’ restarts the game upon a loss,
  • ‘F11’ toggles fullscreen.
4096-1.png
4096-3.png
4096-4.png
Source code: Main.java

Slitherlink Solver

2017-02-11, post № 159

programming, Python, #2016, #puzzle, #shell

Slitherlink is a neat puzzle in which you are presented with a number matrix and the goal is to draw one connected, not interlooping line in between the cells. The number in each cell determines exactly how many line segments must be drawn around each cell (𝟢, 𝟣, 𝟤 or 𝟥). When a cell does not contain any number, the number of line segments adjacent to this cell are unrestricted.

*  *  *  *  *  *          *--*  *  *--*--*
     2  1  3              |  | 2  1| 3   |
*  *  *  *  *  *          *  *--*  *--*  *
        2  2  2           |     | 2  2| 2|
*  *  *  *  *  *          *--*  *--*  *  *
     2              ->       | 2   |  |  |
*  *  *  *  *  *          *  *--*  *--*  *
  1  3  1     1             1  3| 1     1|
*  *  *  *  *  *          *--*--*  *--*  *
  3     2     3           | 3     2|  | 3|
*  *  *  *  *  *          *--*--*--*  *--*

A sample 5x5 Slitherlink with solution.

Slitherlink was invented by the Japanese publisher Nikoli in 1989. It has many other names than “Slitherlink”, yet I prefer this descriptive name. Imagining a snake slithering along the board, seeking to link up with itself is a bit charming.

As with most of these puzzles that have simple rules and are fairly easy to work out by hand — on small scales that is —, writing a solver for them can prove to be more difficult than one may expect.

The first solving strategy I tried out was to brute force the problem. Using the Slitherlink from above as an example, there would be 5\cdot 5=25 different cells with 2\cdot 5\cdot 5+5+5=60 line segments. With each line segment either being drawn or not, there are 2^{60}\approx 1.15\cdot 10^{18} different boards to check. With one board being checked per nanosecond the solver would take \frac{2^{60}}{10^9}\approx 1.15\cdot 10^9 seconds or 𝟥𝟨.𝟧𝟨 years. Brute force is definitely not a viable way to conquer Slitherlink.

After this harsh discovery, I needed a better way to approach solving a given Slitherlink puzzle. Doing some research, I even discovered that Slitherlink is an NP-complete problem (see this paper [1] by Stefan Herting), whereby it — assuming \text{P}\neq\text{NP} — is not even possible to write a solving algorithm which takes polynomial time.
However, solving small Slitherlink puzzles is fortunately possible in a reasonable time frame.

The strategy I used in the solver consists of pre-programmed rules — figured out by humans — which determine parts of the board based on special arrangements and enforcing the puzzle’s rules (such as that there must only be one line). Using those clues, the solver partly solves a given Slitherlink until there are no more known rules to advance. At that point the solver guesses for a given line segment to be either crossed (marking it cannot be drawn) or drawn, building a tree.
Conflicting attempts (where the solver wrongly guessed, then later — through applying the given rules — determines the attempt as flawed) are thrown away, only leaving possible solved scenarios. Because each Slitherlink has one unique solution, this process ultimately results in one surviving attempt, which then is checked for correctness and printed out as the solution.
A list of Slitherlink rules can be found in this Wikipedia article.

Using the above described method, my solver takes roughly 𝟢.𝟢𝟧 seconds on an Intel Core i7 (𝟦.𝟢𝟢 GHz) to solve the example 𝟧 ⨉ 𝟧 Slitherlink. A 𝟣𝟢 ⨉ 𝟣𝟢 Slitherlink takes around 𝟣.𝟨 seconds whereas it takes 𝟥𝟤 seconds to solve a 𝟣𝟧 ⨉ 𝟣𝟧 Slitherlink. The non-polynomial time is clearly recognisable. [2]

My solver best runs in a bash shell [3], as it uses ANSI escape sequences to give the solved line a vivid blue and is entirely written in Python as well as fully text-based. The source code is listed below.

Other people also have written solvers, including puzzle generators, such as kakuro-online or appspot. The latter even supports different polygons as the Slitherlink base.

Source code: slitherlink-solver.py
Jonathan Frech's blog; built 2021/04/16 20:21:20 CEST