[quote="Ingo Bauer"]
Nach so einer heftigen Reaktion mußte ich das natürlich mal ausprobieren.
BN6/K7/8/8/8/8/7k/8 w - -
Ich werde jetzt nicht Betatesten aber ich würde mal auf einen Fehler in der UCI-Implemenstation tippen.
[/quote]
Ahhh, ich kann es leider nicht lassen:
Das ist es was Fire (ohne Bases) so bekommmt und sendet:
to FireBird 1.2 x64 (1): position fen BN6/K7/8/8/8/8/7k/8 w - - moves b8d7 h2g3 a7b6 g3f4Tue Mar 30 09:41:38 2010: to FireBird 1.2 x64 (1):
go movetime 30000Tue Mar 30 09:41:38 2010: from (11): info nps 2373152 cpuload 960 nodes 963500 hashfull 744
Tue Mar 30 09:41:38 2010: from (11):
bestmove b6c5 ponder f4f5Tue Mar 30 09:41:38 2010: from FireBird 1.2 x64 (1): info multipv 1 time 375 nodes 4296075 nps 11456000 score cp 680 depth 1 pv
a7b6 h2g3 b6c5 g3f4 c5d4 f4f5 a8e4 f5e6 b8c6 e6f6 d4d5 f6g5 d5e5 g5g4 c6d8 g4g3 e5d4 g3g4 d8f7 g4f4 d4d3 f4g3 d3e3 g3g4 e4c2 g4g3 c2d1 g3h3 d1f3 h3h4 e3f4 h4h3 f7e5 h3h4 f3e2 h4h3 e2g4 h3g2 g4f3 g2f2 e5c4 f2g1 f4e3 g1h2 e3f4 h2g1
... bla bla bla
Tue Mar 30 09:42:08 2010: from FireBird 1.2 x64 (1): info multipv 1 time 30000 nodes 351190346 nps 11706000 score cp 740 depth 41 pv
a7b6 h2g3 b6c5 g3f4 c5d4 f4f5 a8e4 f5e6 e4d5 e6f5 b8d7 f5g5 d4e5 g5g4 d5e4 g4g3 e5d4 g3f2 d7e5 f2e1 e5f3 e1e2 f3h4 e2f2 h4f5 f2e1 d4e3 e1d1 e3d3 d1c1 d3c3 c1d1 f5d4 d1e1 c3d3 e1d1 d4b3 d1e1 e4f3 e1f2 b3d4 f2g3 d3e3 g3h4 e3f4 h4h3 d4e6 h3h4 f3e2 h4h3 e6d4 h3g2 f4e3 g2h2 e2f3 h2g1 d4f5 g1f1 f3e2 f1g2 e2d3 g2h3 e3f4 h3g2 d3e2 g2f2 e2f3 f2e1 f4e3 e1f1
Tue Mar 30 09:42:08 2010:
from FireBird 1.2 x64 (1): bestmove a7b6 ponder h2g3Das wichtige mal in
fett.
Oben eine Zugfolge,
Erste Zeile an FB: Firebird hat darin SELBER (vorher) schon a7b6 gezogen, und ich antortete für Schwarz mit g3f4.
Zweite Zeile bekommt Firebird ein GO für 30 Sekunden
Letzte Zeile: NAch 30 Sekunden kommt FIREBIRD selbst mit dem sagenhaften Zug a7b6! Leider steht auf a7 nichts mehr, insofern ein illegaler Zug.
So jetzt wird es aber noch komplizierter:
In Zeile 2 bekommt FB gesagt das er 30 Sekunden suchen soll, in Zeile 4 sendet FB SOFORT eine (korrekte) Antwort ... macht dann aber in der Analyse weiter und sendet nach 30 Sekunden noch eine (falsche) Antwort. BEIDES, also das sofortige senden als auch der illegale Zug sind nicht UCI konform. Es ist weiterhin unlogisch von FB b6c5 als bestmove z senden f4f5 zu pndern, in der danach gesendeten HV aber viel früher im Spiel weiterzurechnen. Kurz: Buggy!
Das folgende ich eine Vermutung: Ich nehme mal an das das den FB/IPPO/ROBBO-Jungs nicht auffällt weil die CB-GUI
fälschlicherweise den ersten bestmove nimmt und nicht den zweiten. Warum ist das falsch, weil der "go movetime 30000" String die Engine GANZ KLAR anweist 30 Sekunden zu rechnen.
(Hier die UCI definition:
* go
start calculating on the current position set up with the "position" command. * movetime
search exactly x mseconds
)
Gruß
Ingo