Brute force sudoku cracker

I came across some of these online sudoku games and thought after
playing a game or two that I'd better waste my time writing a solver
than play the game itself any longer. I managed to write a pretty dumb
brute force solver that can at least solve the easy cases pretty fast.

It basically works by listing all 9 possible numbers for all 81 fields
and keeps on striking out possibilities until it is done.

#define horizontal lines, vertical lines and 3x3 blocks
groups = [range(9*i,9*i+9) for i in range(9)] + \
[range(i,81,9) for i in range(9)] + \
[range(0+27*i+3*j,3+27*i+3*j) + range(9+27*i+3*j,12+27*i+3*j)
+ \
range(18+27*i+3*j,21+27*i+3*j) for i in range(3) for j in
range(3)]

def display(fields):
for i in range(9):
line = ''
for j in range(9):
if len(fields[9*i+j]) == 1:
line += ' ' + str(fields[9*i+j][0])
else:
line += ' '
print line

def all(seq, pred=bool):
"Returns True if pred(x) is True for every element in the iterable"
for elem in ifilterfalse(pred, seq):
return False
return True

def product(seq):
prod = 1
for item in seq:
prod *= item
return prod

def solve(problem):
fields = [range(1,10) for i in range(81)] #fill with all
posibilities for all fields
for i,line in enumerate(problem):
for j,letter in enumerate(line):
if letter != ' ':
fields[9*i+j]=[int(letter)] #seed with numbers from
problem
oldpos = 0
while True:
pos = product(len(field) for field in fields)
if pos == oldpos: #no new possibilities eliminated, so stop
break
display(fields)
print pos,'possibilities'
oldpos = pos
for group in groups:
for index in group:
field = fields[index]
if len(field) == 1: #if only number possible for field
remove it from other fields in group
for ind in group:
if ind != index:
try:
fields[ind].remove(field[0])
except ValueError:
pass
else: #check if field contains number that does not
exist in rest of group
for f in field:
if all(f not in fields[ind] \
for ind in group if ind!=index):
fields[index] = [f]
break

Advertisements

Guest

Bas ha escrito:
> Hi group,
>
> I came across some of these online sudoku games and thought after
> playing a game or two that I'd better waste my time writing a solver
> than play the game itself any longer. I managed to write a pretty dumb
> brute force solver that can at least solve the easy cases pretty fast.
>
> It basically works by listing all 9 possible numbers for all 81 fields
> and keeps on striking out possibilities until it is done.
> [snip]

This problem is desperately begging for backtracking. The cost is still
exponential but it works nicely with small problems. Fortunately, a 9x9
grid is small enough. I programmed this about two months ago, it's not
really pretty but it works perfectly. Beware, some variable names are
in spansih...
[let's hope the tabs are kept...]
Regards,
Al

from sets import Set

class sudoku:
def __init__(self,cadena):
self.numeros=Set(range(1, 10))
self.m=[['X']*9 for i in range(9)]
for fila in range(9):
for columna in range(9):
if cadena[fila*9 + columna].isdigit():
self.m[fila][columna]=int(cadena[fila*9+columna])
self.posiciones=[(i,j) for i in range(9) for j in range(9) if
self.m[j]=='X']
def __repr__(self):
res=""
for fila in range(9):
if fila%3==0: res+= "-------------------------\n"

def fila(self,fila, columna):
return self.numeros-Set(elem for elem in self.m[fila] if
elem!='X')
def columna(self,fila, columna):
return self.numeros-Set(self.m[columna] for i in range(9)
if self.m[columna]!='X')

def cuadro(self,fila, columna):
s=Set()
f_ini=3*(fila/3)
c_ini=3*(columna/3)
for f in range(f_ini, f_ini+3):
for c in range(c_ini, c_ini+3):
if self.m[f][c]!='X' and self.m[f][c] not in s:
s.add(self.m[f][c])

Advertisements

Bas enlightened us with:
> I came across some of these online sudoku games and thought after
> playing a game or two that I'd better waste my time writing a solver
> than play the game itself any longer. I managed to write a pretty
> dumb brute force solver that can at least solve the easy cases
> pretty fast.

I've got a solver too - I'm joining the Linux Format programming
contest. My program can solve and create Sudoku puzzles - and not only
9x9 ones. Check http://www.unrealtower.org/sodoku. In the LFX
programming contest they call the puzzle Sodoku, not Sudoku, so that's
why I'm sticking with the name Sodoku for now.
> -any improvements possible for the current code? I didn't play a lot
> with python yet, so I probably missed some typical python tricks,
> like converting for-loops to list expressions.

It all depends on what you want to do. My program can create & solve
puzzles from any size, load and save them to disk, check them for
validity and rank them ('easy', 'medium', 'hard', 'near impossible').
It also implements a puzzle in a class, so it can be used in an OOP
fashion.
> def all(seq, pred=bool):

What's this? What is bool?

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa

of course, you have to deal with guessing wrongly, and it helps if you can
make good guesses!

i wrote a solver based entirely on guessing and backtracking a few months
ago; it's fairly simple, although i wrote it in fairly fine-grained java,
so there's actually quite a lot of code. i had a very different program
structure to you, since i was only doing guesswork; i had a recursive
function that looked like this:

def solve(grid):
"""Solves a grid.

The solution is written in the grid; if no solution can be found, does
nothing to the grid. Returns True if a solution was found, False if not.
"""
x, y = pick_an_empty_cell_to_try(grid)
letters = letters_which_can_be_written_in_this_cell(grid, x, y)
if (letters == []):
return False # there are no legal moves; give up
for letter in letters:
grid.write(x, y, letter) # try a move ...
if (solve(grid)):
return True # we win!
grid.erase(x, y) # ... undo it if it didn't work
return False # none of the legal moves work; give up

the implementation of the grid class is pretty straightforward - it's just
a two-dimensional matrix with some bells and whistles.
letters_which_can_be_written_in_this_cell is also fairly simple, although
it can be made a lot faster by keeping summary information in the grid
object: i had a set for each row, column and region saying which letters
had been written already, so the set of available letters was the inverse
of the union of the sets relevant to the cell; the sets were implemented
as bitmaps, so this was all very fast.

the only tricky bit is pick_an_empty_cell_to_try; you can have fun trying
different heuristics here! the nice thing is that it's okay to use quite
computationally expensive heuristics, since a modestly better choice can
save huge numbers of recursions.

there are a number of much, much more advanced algorithms out there, doing
all sorts of clever stuff. however, my algorithm solves any sudoku i can
throw at it (barring seriously unreasonable stuff) in under a second, so
i'm happy with it.

tom

--
I content myself with the Speculative part [...], I care not for the Practick. I seldom bring any thing to use, 'tis not my way. Knowledge is my ultimate end. -- Sir Nicholas Gimcrack

Well, that's true, but most of the sudoku puzzles can be solved in
linear time ! And also having a linear time solving algorithm allows you
to really reduce the time used when you need backtracking.

BTW, the three given examples can be solved without backtracking.

I made one very recently (mmhh ... first complete version made
yesterday, still need a little bit of debug on the backtracking part),
and it's pretty quick (made in Ruby but well, I suppose timing are
similar), it never get stuck for long even if it fails, it fails quickly ...

I came across Soduko puzzles recently too and had the same reaction:
why waste my time solving the things when it would be much more fun
to write a Python program to do so?

I've enclosed my script and four puzzle files. The puzzle files are
text files containing nine lines of text, and containing nine digits
or spaces. Your puzzle 3 is the one in the file puzzle4.txt.
Interestingly, the file puzzle3.txt is the first one I ran across
that my earlier version couldn't solve. You must pass in the puzzle
file path as a single parameter to the script.

My script originally used two strategies, which I called solve-by-
needed and solve-by-possible. I found that neither strategy used by
itself completed as much of the difficult puzzles as alternating
between both strategies. However, even both together didn't
completely solve my puzzle 3 (or yours). I found I wasn't even able
to solve it myself unless I narrowed one space down to two
possibilities and took a guess. Of course, sometimes I would guess
wrong and have to keep track of where I was to be able to go back to
that state and make the other guess. Obviously a computer program can
do this more easily than I can, so I incorporated that as a third,
last resort strategy. This, so far, has always worked, and I can't
imagine it not working on a solvable puzzle. It seems like cheating,
though. I wrote it recursively, as making one guess can lead to
another situation where the puzzle is still solvable but strategies
one and two get stuck. I've never seen it recurse more than twice
with a real puzzle. With a really gross test I call "ones test", a
puzzle in which only nine ones are filled in (which obviously has
many possible solutions), it recursed very deeply and still succeeded
in producing a possible solution.

David

On Sep 16, 2005, at 3:45 PM, Bas wrote:
> I came across some of these online sudoku games and thought after
> playing a game or two that I'd better waste my time writing a solver
> than play the game itself any longer. I managed to write a pretty dumb
> brute force solver that can at least solve the easy cases pretty fast.
>

On 16 Sep 2005 13:45:24 -0700, "Bas" <> declaimed the
following in comp.lang.python:
>
> It basically works by listing all 9 possible numbers for all 81 fields
> and keeps on striking out possibilities until it is done.
>
> -any ideas how to easily incorporate advanced solving strategies?
> solve(problem1) and solve(problem2) give solutions, but solve(problem3)
> gets stuck...
>
My version doesn't handle the really ugly ones either.

I never incorporated back-tracking, and the "level 3" puzzles in my
book are full of such ... (watch out for line wrap) {I've just converted
the input logic, it isn't fully tested, and should have a way to "erase"
prior rows for correction}

Given a set like that, the next approach would be to add recursion:
clone (deep copy) the tableau, find the first empty cell, pick the first
available number for it (saving a list of those tried), then recursively
try to finish the puzzle after using that number... Next deadlock,
clone, pick next empty cell, pick candidate... If you get to a deadlock
where there is an empty cell and NO viable candidates, pop back to the
previous saved tableau and try the next candidate at that location. If
all candidates fail, pop back yet again...

As everyone posts his, I'll do the same It uses some constraint based
solving techniques - but not too complicated ones. When stuck, it
backtracks. So far it never failed me, but I haven't tested it too
thouroughly.

Guest

Had the same reaction as everyone when I saw theses puzzles a month or
so ago, so here is my solution...
the solve function is recursive, so it can also solve the 'deadlock
set' (example3). find_cell looks for an empty cell with the most filled
cells in it's row and column, so the search tree doesn't grow too
'wide'.

def find_cell(field):
"""Returns coords of an empty cell or None if all cells are filled.
Returns cells with most row and column 'neighbours' first."""
def count(row):
return len([x for x in row if x is not None])

Diez B. Roggisch wrote:
> As everyone posts his, I'll do the same It uses some constraint based
> solving techniques - but not too complicated ones. When stuck, it
> backtracks. So far it never failed me, but I haven't tested it too
> thouroughly.

Thanks to all for sharing. I like to program sudoku and review such
code. So below here is my current file, I think it uses some techniques
not yet posted here. It also has a difficult 16x16 puzzle which I know
to be solvable (barring typing mistakes) but which my file can't solve
before I get tired of waiting, this might draw some heavyweights in the
ring

which was very helpfull and interesting (especially the link to Knuths
paper about dancing links was nice, even though I think (but maybe
wrongly so) that we don't need dancing links now that we've got sets,
but it's still a very very interesting paper)

I think the first important step is to realize that some variations
have fewer values so that it is possible to reduce the search space
early. Currently I'm exploring ideas about contigengies as explained in
the wiki above which seems promising, but I haven't found a nice way to
implement them yet. Maybe an easy optimization would be to find values
that don't come up often and choose variations containing those. And
maybe I should switch to an approach that has possibility values inside
the cells instead of computing them on the fly each time, that could
make contigency elimination easier.

My current solver does 1 level of backtracking (i.e. constant space, and
bounded time) only, and it has been able to solve every puzzle I've
thrown at it. It's based on the usual logic and book-keeping for the
most part. (It also explains how it comes up with each answer step as
it goes, which is handy...)

Once it gets to the stage where it needs to guess, it arranges all the
unknowns then tries them in some arbitary order. It saves the state,
applies the guess (square x,y is N) and then re-applies all the logic
rules. There are 3 possible outcomes from here:

- We can't solve it using this guess (so ignore this possibility,
restore the state & try the next guess)

- The Resulting puzzle is badly formed / inconsistant (represented by
a python exception, naturally!) In this case, we know the guessed
square/number is not valid, so we backtrack (restore the state before we
made this guess), remove that possibility (x,y is N) and then apply all
the logic rules again. Often times, this is enough to solve, but it
usually progreses things a little even if it doesn't solve it.

I've not yet found a (9x9) puzzle that this cannot solve. The downside
is that it cannot detect cases where there are multiple solutions.

Op 2005-09-16, schreef <>:
>
> Bas ha escrito:
>
>> Hi group,
>>
>> I came across some of these online sudoku games and thought after
>> playing a game or two that I'd better waste my time writing a solver
>> than play the game itself any longer. I managed to write a pretty dumb
>> brute force solver that can at least solve the easy cases pretty fast.
>>
>> It basically works by listing all 9 possible numbers for all 81 fields
>> and keeps on striking out possibilities until it is done.
>> [snip]
>
> This problem is desperately begging for backtracking.

I don't think so. I regularly solve one and I never needed
to try something out, to see if it worked or not except
when there were muliple solutions.

I think it is a beautifull problem, to make people think of
how they could code some of their thought processes, which
would be a more fruitfull experience as programming this
with backtracking.

Very interesting that sudoku solving appears on the python group - there
is a programming competition at mathschallenge.net (euler) where one of
the puzzles is developing a sudoku solving algorithm...

Actually the python entrants are giving the C guys a good run!

On Mon, 19 Sep 2005 09:12:54 +0200, Antoon Pardon
<> wrote:
> Op 2005-09-16, schreef
> <>:
>>
>> Bas ha escrito:
>>
>>> Hi group,
>>>
>>> I came across some of these online sudoku games and thought after
>>> playing a game or two that I'd better waste my time writing a solver
>>> than play the game itself any longer. I managed to write a pretty dumb
>>> brute force solver that can at least solve the easy cases pretty fast.
>>>
>>> It basically works by listing all 9 possible numbers for all 81 fields
>>> and keeps on striking out possibilities until it is done.
>>> [snip]
>>
>> This problem is desperately begging for backtracking.
>
> I don't think so. I regularly solve one and I never needed
> to try something out, to see if it worked or not except
> when there were muliple solutions.
>
> I think it is a beautifull problem, to make people think of
> how they could code some of their thought processes, which
> would be a more fruitfull experience as programming this
> with backtracking.
>

"Some Sudoku generators skip the step of generating a board altogether.
It's enough to place some random numbers in the board and see if it has a
solution. For a backtracking solver, which can solve puzzles very quickly,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
the time wasted analyzing impossible sets of clues will be minor. For a
human-style solver, it seems reasonable to exclude the possibility of
self-contradictory clues by first generating a consistent underlying
board."

He seems to think that backtrackers are faster than reasoners. That's
somewhat counter-intuitive; i wonder if it's really true. It would
certainly be rather sad if it was.
> You won't find any better solver than this:
> http://sudoku.sourceforge.net/

That's a fairly straightforward backtracker. In fact, it's the solver
which inspired me to write mine - which i believe has a more sophisticated
heuristic (i haven't compared them formally, but my heuristic
sophistication estimation heuristic - which is itself, of course, fairly
sophisticated - suggests that it is). Clearly, what we need is a sudoku
solver shootout.

tom

--
everything from live chats and the Web, to the COOLEST DISGUSTING PORNOGRAPHY AND RADICAL MADNESS!!

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!