From Sudoku Solver to Program Synthesis
synthetic-minds.com
synthetic-minds.com
Why was I disappointed? Because initially I wanted to write a solver that inferred more, that used the inferences that I made when solving Sudoku.
Sadly once the solver worked, I kinda lost interest.
I hate backtracking myself and it should only be necessary at a certain Sudoku hardness level - every puzzle below that level of hardness should be solvable without backtracking.
Might make it more interesting? And maybe even bias it towards human-abilities. I think intuitively we're better at solving when the possibilities are more than 1 (just a conjecture.)
It's just not that hard of a problem compared to the speed of computers.
All that said, it's all still pretty mechanical. So if you're looking for something more inferential, then another game would be better.
Check out http://sudokuwiki.com/sudoku.htm
This solver (and the whole site) is the best one I know of, and it will solve a puzzle by using rules in order of difficulty, to guarantee it tries the simple rules you know before resorting to backtracking.
The benefits of this are that you can grade the difficulty of a sudoku board. You can also solve a puzzle up to the "crux" and then work on only the hard moves manually. I like doing that so I can skip the hours of boring stuff and practice doing the more tricky inferences. Andrew's site is a window into how big of a rabbit hole Sudoku can be...
- "Sudoku Programming with C" [https://www.apress.com/de/book/9781484209967] where a Sudoku solver and grader is implemented.
- "A to Z of Sudoku" [https://www.wiley.com/en-us/A+to+Z+of+Sudoku-p-9781847040008] where many human solving techniques are described and rated by their difficulty.
That said, it is just a fun problem. PTime specialized solutions are even more intriguing.
We are not front-end people :) and it wasn't an active choice. Let me know if you see anything else. Sincerely appreciate the help.
So 1. the initial specification is still a formal constraint
2. the domain complexity is low
3. Use well known solvers to generate code in a DSLYou are right about about "2." and part of "3.". For "2." yes, the smart contracts are indeed simpler (small code, gas limits, closed systems). So we can skip some major hurdles that more general techniques need -- case in point the FB abstract interpretation framework Sparta here yesterday. For "3." we use Z3 (as should everybody :)!) but the target language for synthesis is Solidity. [ Hope you didn't mean Solidity is a DSL, coz that would be a generous interpretation of that word. ]
The initial spec is another smart contract (call it IN), so code and not a formal constraint. We synthesize another smart contract (call it OUT), such that the combination (IN + OUT) behaves well. See work on synthesizing program inverters for the background ideas (http://saurabh-srivastava.com/pubs/pldi11-pins.pdf)
Good luck with this.