The New Sudoku Players' Forum

[blue]

By "2x(6/6/5)" I just meant 6+6+5 (in some order) in both bands and stacks.
Yes, though for the "other part", there are 6 passes through 27+x+y code.
For the 6/5 part, six "27+x+y" inputs are passed to the lower levels.
Except in very rare cases, 4 of them are ignored, one of { 27+5+6, 27+6+5 } is done for one, and both are done for the other.

About the timing, I don't quite know now.
There may be something wrong with my hack to use "random grids" on the fly.
I'm running it as I write, with a fixed grid list, and something fishy is happening.

The 6/5 part just finished, at 348 seconds.
The other part was going to take more like 1000 seconds, which doesn't make sense.
I'll look into it.

[blue]

OK, I had done something stupid ... typing too fast, trying to write here and run tests at the same time.
The "other part", for the same 1000 grids, took 153 seconds, for 501 seconds total.
There's a lot of variation in the timing, and 1000 grids isn't really enough to get an accurate average.

Switching back to "random on the fly" grids, where I get better (output) timing statistics,
I got for the two parts:

For 4096 grids: "avg. time per grid: 0.322499s +/- 0.010664"
For 4096 (different) grids: "avg. time per grid: 0.143095s +/- 0.003328"

~7 hours later, it's:

For 85984 grids: "avg. time per grid: 0.314241s +/- 0.002291"
For 186368 grids: "avg. time per grid: 0.141329s +/- 0.000487"
Two 17s hit: (both known)
7........59...2.........6..8..3.......6....4......7..9...1...........7.5..246....
4.....1.....9.....2.........3...6..71....5........4......3..2..8.....46..9.7.....

Final update at 31h for each mode:

For 356328 grids: "avg. time per grid: 0.313155s +/- 0.001128"
For 791808 grids: "avg. time per grid: 0.140936s +/- 0.000235"
Only one more 17: (also known)
.8.3...........5.6.1....7.........2...6.7.......5.......7.....1...2......2.4.3.8.

[blue]

The 2826 grids with MC3T = 8 were checked for 17s too.

This subgrid appears, which should have imbalanced UA distribution.

Code: Select all

123456789456789123798132564275813496381964257964527318539671842617248935842395671
...4..........9.2.7.............3.9...1..........................................


From the perspective of the given solution grid, this subgrid generated 3,230,330 low-clue puzzle candidates. For all other grids that were ever scanned using this tool (> 4000) the candidates were < 200,000.
Most of the candidates were discarded by the secondary low-quality UA filter and for the whole grid 1,116,669 solver calls were made which isn't unusual. The scanning time was 1790 seconds and isn't unusual too.

The "< 200,000" number is very impressive
I've been meaning to ask: can you give a brief outline of how you achieve such low counts ?

[dobrichev]

< 200,000 per 7 clues placement.
The counter is reset on next 7-clue combination.
I followed the logic that calling the solver within the main loop pollutes the CPU cache and decided to buffer the candidates and later, when updating the 7th clue, to apply the secondary filter and call the solver in a separate loop over the buffered candidates. This saves few percents.

From your latest posts I can only guess that you successfully applied your 27+x+y scanning techniques to single-grid scanning with improved or with insignificant dropping in performance.

[blue]

< 200,000 per 7 clues placement.

I see now ... thanks.

From your latest posts I can only guess that you successfully applied your 27+x+y scanning techniques to single-grid scanning with improved or with insignificant dropping in performance.

Long ago improvements + have now let it run long enough to get accurate stats.
Also fixed the bug from 2 days ago, where if I told it to run 1000 random grids, it stopped after 167 !