I’ve implemented Norvig for a couple languages as a learning tool.
One thing I do that he didn’t before dropping to brute force though is the m squares with m possibilities check. If two squares in a row, column or group only have two possible values, then you can eliminate those possibilities from all of their siblings. Same for 3:3, 4:4 and 5:5.
As someone who has played Sudoku every day for years, I find it fascinating that there’s no need to unlock any secret. The beauty of Sudoku lies in exploring its simple rules, not in solving some hidden mystery.
I play sudoku enough to have explored it fully. One interesting thing I sometimes do is estimate probabilities and guess key pieces in order to get the fastest time. Often, of course, you guess wrong and lose… but that’s like tripping on the 100 yard dash. It doesn’t invalidate your best times. I have learned more about intuitive probability than I learned about logic by playing this way.
So the first solution seems like an obvious brute-force approach that definitely does not require any fancy graph theory. I have thought of this but never used it because it seems so tedious and like it defeats the point of the game.
I like Norvig's approach, I'm in the process of porting it to my Lisp.
https://norvig.com/sudoku.html
https://github.com/codr7/eli-java/blob/main/examples/sudoku....
I’ve implemented Norvig for a couple languages as a learning tool.
One thing I do that he didn’t before dropping to brute force though is the m squares with m possibilities check. If two squares in a row, column or group only have two possible values, then you can eliminate those possibilities from all of their siblings. Same for 3:3, 4:4 and 5:5.
As someone who has played Sudoku every day for years, I find it fascinating that there’s no need to unlock any secret. The beauty of Sudoku lies in exploring its simple rules, not in solving some hidden mystery.
I play sudoku enough to have explored it fully. One interesting thing I sometimes do is estimate probabilities and guess key pieces in order to get the fastest time. Often, of course, you guess wrong and lose… but that’s like tripping on the 100 yard dash. It doesn’t invalidate your best times. I have learned more about intuitive probability than I learned about logic by playing this way.
So the first solution seems like an obvious brute-force approach that definitely does not require any fancy graph theory. I have thought of this but never used it because it seems so tedious and like it defeats the point of the game.