10 years back, I could have made a splash by adjusting Knuth’s and mine to dance in parallel. More exactly, start with pure python implementations of both, instrument them at least enough to verify sync if it happens, and then tweak them towards performing a parallel detailed dance on identical input. The timely reward of success with it: perhaps evolving the intelligence of the name of algorithm — very much vanished.

]]>on the top95 set I get

|gss | 697.5 | 1,433.7 | N/A | N/A |

|gss1 | 2,395.8 | 417.4 | N/A | N/A |

So less logic is quite a bit faster. When I see the fast solvers here it seems they all do only logic that can be evaluated very fast and do the rest with backtracking. The grid is not so big and if you choose fields with few candidates, this is not all that expensive. Obviously, it also depends on how well the logic is implemented and if you have larger sudoku grids backtracking will quickly limit your performance.

Isn’t it strange that less logic performs better in your case if I understood it correctly? My general constraint solver solves about 200 per sec (on the Top95 dataset…) (as much logic as possible without backtracking and the rest with if not solved yet)

Ongoing series about it: http://opensourc.es/blog/constraint-solver-1

I wrote gss (https://github.com/bartp5/gss). It is a bit more generic solver that can do many types of sudokus like jigsaw, X, NRC, etc. You can look at the bottom of https://bartp5.github.io/gss/ to see examples of what it can do. It certainly is not as optimized as these solvers and I suppose it is a bit harder to optimize as my solver does not only deal with one specific sudoku topology. I thought is was interesting to see how my solver compares so I added it to the benchmark tool from t-dillon. My solver implements “levels” of logic it can apply from 1 till the blocksize-1 (i.e. 8 in a standard sudoku). If logic fails it resorts to backtracking. Here are some results:

|puzzles5_forum_hardest_1106 | puzzles/sec| usec/puzzle| %no_guess| guesses/puzzle|

|————————————–|————:|————:|———–:|—————:|

|gss | 35.7 | 28,009.4 | N/A | N/A |

|gss1 | 414.2 | 2,414.3 | N/A | N/A |

|fast_solv_9r2 | 852.5 | 1,173.1 | 0.0% | 372.40 |

|kudoku | 684.8 | 1,460.2 | N/A | N/A |

|jsolve | 2,889.5 | 346.1 | 0.0% | 389.12 |

|tdoku | 8,205.3 | 121.9 | 0.0% | 113.13 |

Here gss is my solver with the maximum level logic and gss1 only applies basic elimination.

Obviously, my higher levels of logic are not so efficient as they slow down the solution of hard puzzels by more than a factor of 10. However, I find (unsurprisingly) that backtracking scales very very poorly so higher levels of logic are required for larger sudokus (gss can do blocks sizes up to 128 when compiled with 128 bit integers, i.e. up to 100×100 sized sudokus with the standard topology).

Cheers,

Bart

I have developed a number junctions game that’s similar to Sudoku in which a

number can not be used more than once in any column or row. I have called it

Sudoku Octangles:

Android:https://play.google.com/store/apps/details?

id=air.Ganaysa.SudokuOctangles

iOS: https://itunes.apple.com/app/id1480851707

Amazon: https://www.amazon.com/dp/B081VVC1G9/

I hope you like it.

]]>Maybe some of you are interested in the different approach and maybe the full constraint solver: https://opensourc.es/blog/constraint-solver-alldifferent ]]>

Thanks for the update. Very interesting!

]]>