> My guess is that if I changed the way the solve functions picks the square to start with it could greatly change the time. Right now it just takes the first open square found scanning right to left and top to bottom. Maybe something like giving priority to squares in small constraint groups would be more effective.
Your guess is correct. Take a look at my backtracking solver linked from another comment; one of the optimizations I added after the fact was to select a square with the "smallest" constraint for the next placement, with the motivation of avoiding a rathole. (The 2025-09-15 puzzle with the =63 constraint is a good test case, FWIW.)
My Rust solver running on an M3 Max Macbook Pro is often under a second and never more than about 30 seconds. (I did pull down all of the past puzzles using an observation from Evan Matthews in his solver: https://github.com/ematth/pips)
Your guess is correct. Take a look at my backtracking solver linked from another comment; one of the optimizations I added after the fact was to select a square with the "smallest" constraint for the next placement, with the motivation of avoiding a rathole. (The 2025-09-15 puzzle with the =63 constraint is a good test case, FWIW.)
My Rust solver running on an M3 Max Macbook Pro is often under a second and never more than about 30 seconds. (I did pull down all of the past puzzles using an observation from Evan Matthews in his solver: https://github.com/ematth/pips)