Quote Originally Posted by dukuso
@Brick1: the 0-line is the time needed for the easiest sudoku relative to average.
How could you solve number 943 in 0.003 ms ?
I have to wonder if it was some kind of error with the timer? 3 us is very fast, and the next fastest one was 20 us.
Quote Originally Posted by dukuso
@xxyzzy: thanks for the .csv file ! That makes it a lot easier.
and for the confirmation of the correlations.
Isn't it surprising that the programs need so different times
for special sudokus ? E.g. bpd's program is pretty fast but completely
unrelated to others ! So, how did he solve them ? Must be some weird
strange technique...
I'm sure you've noticed how the same sudoku turned upside down or rotated can end up taking much longer? Usually we have in a code something that goes "for Row 1 to 9 ; for column 1 to 9", etc. Maybe all there is to it, is that bpd started at row 9 and went to 1? ie. if bpd's program was fed the same samples upside down or transposed it might correlate with all the other fast programs?

Quote Originally Posted by dukuso
the 100%-line being close to 1 does not necessarily reflect 'smartness'
just means, that some further optimizations for some hard cases
seem possible/promising and yes, that xyzzy's and Merri's programs
look good also for 16*16 etc.
What I'm thinking is that an algorithm that's fast for SOME sudokus is easy. e.g. just fill in the missing cells at random, sometimes you get it right on the first try! Designing one that is fast for all sudokus is harder. The smarter your algorithm, the larger fraction you can do quickly. The 100% quantile isn't the best, I think 95% would be better. But I'd classify the programs, using mean speed + 95% quantile like this:

slow speed + high quantile = naive algorithm and poor implementation
fast speed + high quantile = simple efficient algorithm and good implementation
slow speed + low quantile = smart but slow algorithm and/or poor implementation
fast speed + low quantile = smart and efficient algorithm and good implementation