coloin wrote:I do hope that searching for a 14 clue solution in 72 clues [with less UA] is more than 18x quicker than searching for a 17 in 81 clues ... is it ?
That is difficult to answer.
I can say something about my "hack" to Gary McGuire (et al.)'s code, but how relevant it is, who's to say (?).
For the same 100 random grids as in my earlier post(s), the average time was ~24.09s per grid.
[ That was keeping the clues in the top row, as the "9+", and looking for 14 more clues in the remaining cells. ]
The average time, was severely impacted by two grids in particular ... one that took 268 seconds, and one that took 819s.
Tossing those two out, the average time dropped to ~13.40s/grid, or ~60% of the time to search for 17's in the same grids.
The code was only looking at UA sets with size <= 12, though, and going to "size <= 14", could help.
[ By "size <= 12" UA's, I mean all minimal UA sets with size <= 12, that don't include a cell in the top row. ]
I say that because for the two bad grids, there were "many many" ways to hit all of the "size <= 12" UAs, with only 11 clues -- leaving the code in a situation where it needed to add every combination of 3 additional ("undead") clues, to get (its interpretation of) all of the "potentially valid" 9+14's.
For the worst case, that lead to ~32
billion (9+)14-clue sets, that (
likely) hit all of the UA's with size <= 12.
[ Oddly enough, for the two bad cases, no 9+14 puzzles were produced. In the remaining grids, 367 were found. ]
coloin wrote:For example
say we postulated that all 17s have been found whitch begin with max lex {x..x......} or {xx......} I think we have ...
which means that all non-found 17s have max lex {x..x..x..] or more
This avoids a search for 9+15 puzzles, of course, but why else would one assume such a thing ?
