On Wednesday, 15 August 2012 at 20:13:10 UTC, Era Scarecrow wrote:
On Wednesday, 15 August 2012 at 15:39:26 UTC, ixid wrote:
Could you supply your code? Which one are you using as the
hardest? If you're solving the 1400 second one in 12 seconds
that's very impressive, I can't get it below 240 seconds.
Expanded to 225 lines after comments and refactoring for names.
I think it should be fairly easy to follow.
https://github.com/rtcvb32/D-Sudoku-Solver
While an old thread, I decided to try a different approach to
sudoku solving. In no way is this better, just a different
approach. At 200 lines (needs some heavy unittests added, but
appears to work).
Using a sorting method to solve the puzzle. The idea is to take
your puzzle, sort it by weight (how many possible numbers) and
only take guesses with the smallest number of combinations
possible, meaning any puzzle with 1 solution won't take long. The
idea behind this method is to ignore combinations that might
never come up; Afterall if you have a block with 2 possibilities,
why start brute forcing the one with 7? Fewer wasted cycles. Yes
it still uses brute force and built-in backtracking (and also
outputs all combinations of a solution).
Trying the REALLY REALLY hard one from before? (17 numbers)
Well... I had it run in the background for a few hours, and got
69,555,823 answers before the output (610Mb compressed, 11,067Mb
uncompressed) simply filled up the free space on my ramdrive thus
crashing the program.
