[WelMac] Sudoku mania

John Crook jmcrook at mac.com
Sat Mar 4 21:52:05 CST 2006


It started innocently enough.  My wife started playing around with 
Sudoku puzzles.  I took a bit of a look at them, but quickly decided 
that they would be boring.  My wife gradually became more adept, moving 
on from easy to medium to hard and then even some "diabolical" puzzles 
although she couldn't always complete the solution for the hardest 
categories.

I said that I couldn't really see the point of these puzzles since they 
only require the repeated application of a few simple logical rules - 
more suited to using a computer rather than a human brain for solving.  
In fact I even went so far as to say that it would be a simple matter 
to write a computer program to solve them.

And then to prove my point, that's what I started to do.  First I had 
to settle on a suitable programming language to use.  Actually, it's a 
very long time since I've done any real programming.  In my past I've 
worked with FORTRAN and PL/I, BASIC and various operations interpreter 
languages.   I've even programmed the early microprocessors in both 
machine code and assembler. More recently I've done a little work in 
Pascal.

But the computing world has changed a great deal since those days.  All 
the same, I thought it wouldn't be too too hard to learn one of the 
modern languages.  What a bewildering array we now have.  I didn't 
really want to spend much money on this exercise, since it was really 
only intended to prove a point - although perhaps I might (re)acquire a 
useful skill in the process.

So I started to look around and see what I already had on my Mac, and 
whether any of it would do the job.  I first tried just using an Excel 
spreadsheet, but found rather quickly that the 'circularity' 
restrictions on spreadsheet cells prevented me from making anything 
other than a sheet that helped a bit in identifying answers for the 
very simplest of Sudoku puzzles - and even then it required manual work 
to enter the found values as the answers for various cells were 
revealed.

I considered using AppleScript but abandoned this idea when I found 
that it didn't seem to possess the capabilities for array variables 
that I felt I needed.

Finally, I settled on VBA (Visual Basic for Applications) since this 
comes included with the Microsoft Office Suite that i already had on my 
computer and it appeared to be quite cable of handling 
multi-dimensional arrays.

The next problem I had was deciding how to start learning the new 
language.  There is an extensive help file system with the program but 
this contains a bewildering mass of information and detail. I couldn't 
tell where to start.  I felt a bit like the apocryphal blind men trying 
to understand what an elephant looked like.  (One had hold of the 
trunk, another its tail, and one had one of the legs.) It was beginning 
to look like it might be a life's work just to understand the language 
before I could start programming to prove my simple point. I decided 
that I needed to get some overall appreciation of the language before I 
could start and then just use the bits I needed, without having to get 
a comprehensive grasp of absolutely everything it could do.

I gave in and decided to sacrifice my pride and spend a little money.  
I bought a book entitled "Absolute Beginner's Guide to VBA" (no prior 
programming experience required).  It sounded like it might have what I 
needed.

Actually the book wasn't too bad.  An evening's reading gave me the 
basics. I guess I cheated a bit.  My prior programming experiences 
would have helped.  I think it would be a a rather steeper learning 
curve for an absolute beginner, but lots of examples helped to quickly 
get the gist of what the language does and how to do it.  One of the 
important things I learned was that you can make "macros" automatically 
by setting the program to "record" a macro while you use the keyboard 
to interact with an MS Office programme such as Excel.  Then you can go 
and look at the resulting code and make any changes you want to make it 
behave in the way you want.

So - a couple of enjoyable evenings were spent figuring out the logic 
to make my program interact with the Sudoku grid, which I entered on an 
Excel spreadsheet.  A little bit more time to get this tested and 
working.

Then the time for the real experiment.  I now had to code those simple 
logical rules that would solve the Sudoku puzzle.  Well first of all i 
decided that perhaps I should try and solve one myself, rather than 
just looking cynically over my wife's shoulder.  I picked a medium 
level one, and actually, it wasn't too bad.  It seemed that only two 
fairly simple logical rules needed to be applied in order to solve one 
of these puzzles - of course proving the point I was trying to make in 
the first place!!!

A couple of days to figure out and program the logic and test it on a 
sample puzzle.  To my joy (and surprise) after a few debugging cycles, 
it actually worked on the sample puzzle that I'd chosen for my previous 
manual exercise on puzzle solution.  A bit slower than I'd expected.  
It took about 3-4 minutes to crank out the completed puzzle.

So far so good - or so I thought.  Let's try another puzzle.  That 
worked too!!!  I was on a roll.  I tried some my wife couldn't solve.  
That was fine too.  OK, now for the real test, let's try some of of 
these diabolical puzzles.

Crash!!!  My wonderful program stopped with the solution only partly 
completed.  Fortunately I had designed it to put all those little 
numbers to show the possibilities in the unsolved cells, just like the 
Sudoku pros use when they're working on the puzzles.  My daughter has 
started as well, so I know all the language ( I don't mean what they 
say when the puzzles don't come out).  I can be an armchair expert, 
without actually have done a puzzle (well OK - only one puzzle).

Well that wasn't too bad.  I managed to figure out a third rule in 
addition to the two, I had programmed into my solver.  That got me by 
in this instance.  (I haven't actually programmed the third rule yet.  
I just used it to solve a single cell and put it back into my program, 
which then completed the solution.)

All right, now the real test.  Let's get some of the real toughies.

I found that my program does solve many of these without complaint, but 
frustratingly, some it doesn't.  What's more, my third rule doesn't 
crack them either.  Two more rules later and I've got one or two more 
cells solved, but still the puzzle(s) won't come out.

I'm stuck now.  At the moment I can't see any more "simple rules" that 
will crack these puzzles.  Maybe there's more to this Sudoku thing than 
than I thought.  Perhaps I'm in danger of getting addicted after all!!

I have some questions both about programming in VBA and about Sudoku.

1.   Does VBA actually compile the program?  It seems very slow for a 
compiled program.
2.   How can I get VBA to show intermediate results while it is 
working?  At the moment, my program "goes away" and doesn't display 
anything happening on my spreadsheet until it has finished the 
computations.  I would really like to watch it filling in the cells 
progressively.
3.   Are there any Sudoku-meisters out there who would like to look at 
the partially completed puzzles that I cannot solve, and tell me what 
other logical rules I might use?  (Actually I can usually solve those 
puzzles on a trial-and-error basis by taking a guess at one of the 
unsolved cells and seeing if it comes out - but that is hardly in the 
spirit of the thing - or is it?)

I'm happy to share my solver with anyone who'd like a copy.  (Please 
ask).  But please be aware that this is still a work-in-progress.

Cheers

John




More information about the WelMac mailing list