eleven wrote:lerxst wrote:Yes, I thought about this but I'd like different grids (i.e. puzzle with different solution grids). I don't care about minimal or not as it won't impact my "dumb" solver! But I need puzzles with one solution only!
Why shouldn't you get different solution grids ? You have 45000 17 clue puzzles with at least 20000 different sulution grids, where you can start the {-1+2}. Also this operation in most cases will bring you to another grid.
Ah, didn't you understand {-1+2} ? You get the same grid, when you just add a clue of the solution grid, but here you first drop a clue and add 2 different ones (not from the solution grid!) in any 2 empty cells.
If you dont mind, that the puzzles are not minimal, your results will be, eh poor.
In this case ALL puzzles will be very simple on average. As you read, 80% of the 17 clues are singles puzzles and - apart from a few ones -, the others are easy too. If you dont mind redundant clues, this relationship will not change with more clues. It depends on your selection, but probably they will become even easier then.
Now who should be interested, if you can solve 1000 easy puzzles with 30 clues 2% faster than with 17 clues ?
I probably explained myself very badly. I don't mind if a puzzle is minimal or not (though minimal ones are more interesting but minimality has no impact in my case) BUT I want puzzles that lead to one and only one solution grid. Difficulty, in my case, has absolutely no impact.
To make a long story short, I'm solving sudoku puzzles in plain SQL (i.e. not PL/SQL, no loops, no functions, no stored procs, no variables, just plain old SQL and just one SQL statement... For what reason you might ask? Just for the fun of it and to write an article on my blog about SQL optimization. I was just looking for a subject/excuse to present a few concepts and ideas (and to shut up someone who told me this solution wouldn't solve any puzzle in a reasonable time)... I've done it in the past but it was more a proof of concept than anything. The whole thing was wrapped in less than 2 hours.
Now, I'm doing it in a more serious way with measures, explanations and a serious test set to investigate and show a few possibilities. So in my very specific case, the more clues I have, the more index hits I get, the more efficient are the joins, more pruning in done in the index cache, the more index merge chances I get, etc... Solving sudoku puzzles with SQL will never be as quick as a C program but that's not my point nor my intentions!
