Sudoku Programmers Forum Index

 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister   ProfileProfile   Log inLog in          Games  Calendar

Log in to check your private messagesLog in to check your private messages   

Help! My solver is fast when linear and broken when random!

 
Post new topic   Reply to topic    Sudoku Programmers Forum Index -> Solving sudoku
View previous topic :: View next topic  
Author Message
sswift

Joined: 16 Feb 2006
Posts: 21
:

Items
PostPosted: Thu Feb 16, 2006 5:30 am    Post subject: Help! My solver is fast when linear and broken when random! Reply with quote

I wrote a very clean implementation of a recursive brute-force solver for Sudoku, but I'm having a problem.

My solver, as first written, started at 0,0 and looped through each square.

It used a fast method of determining which numbers do not appear in the same row, column, or box to figure out which numbers are allowed for that square.

Then it tries each number in the square and calls the function again for each, and resets the square to empty if it finds no number which leads to a solution or the function call returns false telling it that it hit a dead end somewhere down the tree.

The function worked great like this. Very fast, less than 80 milliseconds on some of my test puzzles, and it's not even coded in C, it's coded in Basic.

But I hit a major snag. As soon as I started to randomize the empty tile the function would select on the next run through to try different possibilities on, suddenly, the program just sits there calculating for forever.

I thought maybe something was going on in the function that would cause a problem if the calls were randomized like this... Because a tile might try a 6 and then try to next fill in square 1,3 but when that fails, it would try a 7 and try to fill in square 4,5. And I thought that might cause problems.

So instead, I tried storing all the empty tiles in an array before I call the recusrive function. Then I increment a number passed to the function each time I recurse. This array of empty tiles was shuffled, so now it should step through the entire puzzle in a random order, visiting each cell once, very fast. But not visiting them in a linear order, like when I would just keep incrementing X and Y which ALWAYS started at 0 every time I called the function, until I hit an empty square.

But this didn't work either!

I've read here that another way of getting a random result with an empty input puzzle is to randomize the order in which I try each possiblity for a square, but I really didn't want to do shuffling in the recusrive function itself.

So is there something wrong with how I am thinking about this? Why would stepping through the empties in a snuffled, but fixed for the duration of finding the solution, order not work, when stepping through them from top lef tto bottom right works fine and fast?
Back to top
View user's profile Send private message
Miles

Joined: 29 Dec 2005
Posts: 30
:

Items
PostPosted: Thu Feb 16, 2006 8:27 am    Post subject: Reply with quote

Debug your code. Figure out what you want him to do and debug it to see if it does what it should do.
Back to top
View user's profile Send private message Visit poster's website
sswift

Joined: 16 Feb 2006
Posts: 21
:

Items
PostPosted: Thu Feb 16, 2006 9:27 am    Post subject: Reply with quote

Debugging it was the first thing I tried. But there's a lot of data there to examine!

I'm not asking you to debug my program here. I'm asking if there is a known problem with solving sudokus using random squares like this. If there is not, then the problem is likely in my implementation. If there is, then I need to try a new algorithm.
Back to top
View user's profile Send private message
sswift

Joined: 16 Feb 2006
Posts: 21
:

Items
PostPosted: Thu Feb 16, 2006 1:43 pm    Post subject: Reply with quote

Just to let you know, I've solved the problem by swithcing from shuffling empty squares, to shuffling candidate values.
Back to top
View user's profile Send private message
Agent Allen

Joined: 01 Oct 2005
Posts: 34
:

Items
PostPosted: Fri Feb 17, 2006 9:26 pm    Post subject: No you didn't Reply with quote

Or may be you did.

To obtain a more even distribution without bias, the method I implemented shuffles the empty cells once at the beginning and then also goes through the possibles in Random order.
Suppose you try to randomly solve the puzzle I posted with 5 solutions (see Library).
You will get one of these solutions:
Code:

834671925125839647796524318957318462241956873368247591682793154519482736473165289
834671925125839647796524318957318462241965873368247591682793154519482736473156289
834671925125839647796425318957318462241956873368247591682793154579184236413562789
814637925325149687796825314957318462241956873638274591462793158579481236183562749
814637925325941687796825314957318462241569873638472591462793158579184236183256749
                                                                         ^                                                                                                     

If you select the second cell first, (1 or 3) you will end up with an 8 in cell 2,9] (marked with a caret) half the time (i.e. if you picked 3).
But if you picked cell [2,9] first, you'd get 8 in that cell 1/3rd of the time - because it could be a 1,7 or 8.
Now given that we can see in a uniform distribution that 2/5 of the puzzles have an 8 there, we can see that neither start leads to a true uniform distribution. Although fully randomising the tour helps, I don't know that we lead back to a uniform distribution on the solutions - which would be nice.

I'm saying you didn't because it wasn't a mistake randomise the 'tour' - it was a good idea - so removing it didn't fix it.
I'm saying unless you did, because you may have 'accidentally' removed a bug in your modifications and unwittingly fixed your code BUT not for the reasons you may think. It happens to the best of us.

One bear trap I do know about, is that although a recursive method with a simplifier at each step to reduce the field is great, be careful in the simplifier.
If it actually puts singletons in, you might find it puts contradictions in during a single iteration of the simplifier and sends the poor old recursion down a long and winding tour of a dead branch of the tree.
Nasty.
I got a massive ncrease in reliability by only setting cells during recursion. That is simplify the 'possibles' but don't reduce the singletons except during a recursion trial. Of course having 1 candidate means singletons get picked straight away as the pivot and force single branching which is itself very cheap.
_________________
Agent A
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Sudoku Programmers Forum Index -> Solving sudoku All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Sudoku Programmers topic RSS feed 


Powered by phpBB © 2001, 2005 phpBB Group

Igloo Theme Version 1.0 :: Created By: Andrew Charron