14.07.2010, 13:31
Hallo StefanSch
1)
Stimmt,
der mittlere Mehraufwand als Summe aller (n+1)/(k+1) ist besser. Ist wohl
mehr das Integral ueber den ganzen Spielverlauf, als mein vorgeschlagenes
Maximum. Der Vorteil ist auch, dass man die Mehraufwendungen am Spielende
nicht ausblenden muss. Sudokus mit weniger Ausgangsziffern wuerden
im Mittel schwieriger bewertet werden, da mehr Summanden beitragen. Ich wuerde
trotzdem eher n/k anstatt (n+1)/(k+1) aufsummieren (Anzahl der Tests durch
Anzahl der gefunden HS). Ist bei einem Spielstand kein HS vorhanden,
ist die Schwierigkeit sowieso nicht nicht ueber HS definiert.
2)
Stimme ich dir ebenfalls zu. Ich hatte urspruenglich einen rekursiven
Loesungsweg programmiert, der alle moegliche Reihenfolgen der HS
ausprobiert, mit einem Vorzug von HS Reihenfolgen mit Kandidaten der
selben Art, um z.B. den Loesungsweg auszugeben mit der geringensten
Anzahl von Kandidatenwechseln. Ein HS-Sudoku, in dem nur noch die
6er fehlen, haette dann null Kandidatenwechsel, Ein HS-Sudoku, in dem
ein 3 und zwei 5er fehlen, koennte theoretisch mit einem oder zwei
Kandidatenwechel geloest werden (3, 5, 5 gegen 5, 3, 5). Wenn die
zuletzt geloeste Ziffer eine 5 war, wurde ein HS in der 5 als naechster
Loesungsschritt forciert. Wegen des dennoch grossen Paramerraums, war
die Rechenzeit extrem gross, sodass ich das Thema irgendwann ad acta
gelegt habe.
Auch die Idee nur die drei Einheiten Z/S/B zu testen in denen die letzte
Ziffer als HS gesetzt wurde bedeutet doch noch etwas Programmieraufwand.
1)
Stimmt,
der mittlere Mehraufwand als Summe aller (n+1)/(k+1) ist besser. Ist wohl
mehr das Integral ueber den ganzen Spielverlauf, als mein vorgeschlagenes
Maximum. Der Vorteil ist auch, dass man die Mehraufwendungen am Spielende
nicht ausblenden muss. Sudokus mit weniger Ausgangsziffern wuerden
im Mittel schwieriger bewertet werden, da mehr Summanden beitragen. Ich wuerde
trotzdem eher n/k anstatt (n+1)/(k+1) aufsummieren (Anzahl der Tests durch
Anzahl der gefunden HS). Ist bei einem Spielstand kein HS vorhanden,
ist die Schwierigkeit sowieso nicht nicht ueber HS definiert.
Code:
n=40 k= 0: # nicht definiert, Sudoku ist kein HS Sudoku, vielleicht eins mit X-wing, nice loops, ...
n=40 k=20: 2 (leichter Schritt)
n=40 k= 1: 40 (schwieriger Schritt)
n=6 k= 6: 1 (leichter Schritt bei der zweitletzten einzutragenden Ziffer)
n=6 k= 2: 3 (etwas schwierigerer Schritt bei der zweitletzten einzutragenden Ziffer)2)
Stimme ich dir ebenfalls zu. Ich hatte urspruenglich einen rekursiven
Loesungsweg programmiert, der alle moegliche Reihenfolgen der HS
ausprobiert, mit einem Vorzug von HS Reihenfolgen mit Kandidaten der
selben Art, um z.B. den Loesungsweg auszugeben mit der geringensten
Anzahl von Kandidatenwechseln. Ein HS-Sudoku, in dem nur noch die
6er fehlen, haette dann null Kandidatenwechsel, Ein HS-Sudoku, in dem
ein 3 und zwei 5er fehlen, koennte theoretisch mit einem oder zwei
Kandidatenwechel geloest werden (3, 5, 5 gegen 5, 3, 5). Wenn die
zuletzt geloeste Ziffer eine 5 war, wurde ein HS in der 5 als naechster
Loesungsschritt forciert. Wegen des dennoch grossen Paramerraums, war
die Rechenzeit extrem gross, sodass ich das Thema irgendwann ad acta
gelegt habe.
Auch die Idee nur die drei Einheiten Z/S/B zu testen in denen die letzte
Ziffer als HS gesetzt wurde bedeutet doch noch etwas Programmieraufwand.