This week's book giveaway is in the Other Open Source APIs forum. We're giving away four copies of Storm Applied and have Sean Allen, Peter Pathirana & Matthew Jankowski on-line! See this thread for details.
I'm working on a sudoku solver that solves sudoku like a novice human sudoku solver would.
I start off by making a candidate list for each of the 81 boxes, a 2d array of arralylists (ArrayList candidates).
Then I strip away candidates from the lists, and insert the element if there's just one candidate. I think the code is correct for this(?)
Then I check for hidden singles, which is a lot harder. I think the code for rows and columns should be okay, but I don't really know how to handle it for boxes.
Any help would be greatly appreciated, also, please let me know if this method is completely retarded.
I once wrote a sudoku solver using a boolean. Each single boolean is an indicator whether a value can be in that position. For instance the checking if 9 can stand on the first row, second column would be if(options). This allows you to search for patterns. In your design I don't really see how you can find these patterns (especially the more complicated onces). Maybe you should rethink your design.
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." --- Martin Fowler
Please correct my English.
Joined: Sep 09, 2010
It turns out the puzzle I was trying to solve was actually too hard, and couldn't be solved with just these techniques. I switched to a different puzzle, and it solved it right away. I'm still interested too see if anyone has any clever ideas for finding hidden singles in a sub-box though, so I'm going to leave the thread open for a while
This may be out the scope of the discussion, but I once solved the hidden single in a much more general way. Hidden singles aren't necessarily "singles". With blocks, they are actually "triplets".
My theory is that if all the candidates of a group (row, column or block) for a particular digit are also candidates for one other group (I use the word "intersect"), you can eliminate that digit as a candidate for all other cells in the two intersecting groups. For an intersecting block and row/column, this usually leaves a triplet of candidates.
In the example, you can eliminate 2, 4 and 6 as candidates from the cells marked by *. Each of these digits is a candidate of a cell where the column intersects with one other group, so you can eliminate them in the remainder of the two groups, which is trivial for the column, but gives you new information about the block.
You can extend this theory to all sorts of soduku types. It works really well on X-sudokus and the sudokus which have the 4 grey blocks. You just need to determine in which cells two groups intersect, if at all.
Granted, I tested my strategy using a functional language, which may be much easier than in Java. Heed Wouter's suggestion of using a boolean array to check for patterns.
Actually, sorry. I got confused by the terminology here. The suggestion I made has nothing to do with hidden singles. It's just a general strategy for elimination. It may be useful regardless.
Joined: Sep 09, 2010
Thanks for the input guys
I'm not familiar with patterns, and I don't want to sound stubborn, but I -really- want to solve it the way I started. This solver is not supposed to be able to solve every single sudoku-puzzle, just the ones with naked singles and hidden singles. I've updated the code, but my mind is a bit tired. If anyone knows a puzzle with just naked singles and hidden singles, please show it to me so I can test it.
david, you sound so determined that i am sure you will come up with a great solution. i have also thought a sudoku solver would make a good project but i never tried it. another great idea for a project would be a sudoku generator.