Wow.
@ubdip 's response must mean it's coming soon!
@MessyAnswer: I don't know. I have implemented the antichess rules into the engine only on Saturday (after we have fixed a few bugs it seems to work) and since then we have only commited very few changes to the search and evaluation function.
I was completely surprised that with these few changes it can already find such a long sequence within seconds. However, it is probably not that surprising considering the long forced sequences of captures in Antichess and especially in the position after 1. d3.
However, I have no idea how strong or weak the Antichess engine currently is. I have only played one game against it and lost. But I am a weak Antichess player, so it does not mean much.
I was completely surprised that with these few changes it can already find such a long sequence within seconds. However, it is probably not that surprising considering the long forced sequences of captures in Antichess and especially in the position after 1. d3.
However, I have no idea how strong or weak the Antichess engine currently is. I have only played one game against it and lost. But I am a weak Antichess player, so it does not mean much.
#13 Occasionally it blunders in positions involving stalemate, although I don't understand why.
One thing that might help diagnose it would be having it analyze a variety of games (or test positions) & checking whether its evaluations are accurate.
One thing that might help diagnose it would be having it analyze a variety of games (or test positions) & checking whether its evaluations are accurate.
The atomic sf was also mentioned to have bugs with stalemate, weird ^^
@Toadofsky: Indeed, the first position I came up with already shows a bug:
setoption name UCI_Anti value true
position fen 8/8/6p1/p7/7p/8/P6P/8 w - - 0 1
go depth 10
info depth 1 seldepth 1 multipv 1 score cp 189 nodes 3 nps 1000 tbhits 0 time 3 pv h2h3
info depth 2 seldepth 2 multipv 1 score cp 190 nodes 10 nps 2500 tbhits 0 time 4 pv h2h3 g6g5
info depth 3 seldepth 3 multipv 1 score cp 173 nodes 23 nps 3833 tbhits 0 time 6 pv h2h3 g6g5 a2a4
info depth 4 seldepth 4 multipv 1 score mate 3 nodes 48 nps 8000 tbhits 0 time 6 pv a2a4 g6g5 h2h3 g5g4
info depth 5 seldepth 5 multipv 1 score cp -52 nodes 92 nps 15333 tbhits 0 time 6 pv a2a4 g6g5 h2h3 g5g4 h3g4
info depth 6 seldepth 6 multipv 1 score cp -122 nodes 119 nps 17000 tbhits 0 time 7 pv a2a4 g6g5 h2h3 g5g4 h3g4 h4h3
info depth 7 seldepth 7 multipv 1 score cp -86 nodes 149 nps 21285 tbhits 0 time 7 pv a2a4 g6g5 h2h3 g5g4 h3g4 h4h3 g4g5
info depth 8 seldepth 8 multipv 1 score mate 4 nodes 205 nps 29285 tbhits 0 time 7 pv a2a3 g6g5 a3a4 g5g4 h2h3 g4h3
info depth 9 seldepth 8 multipv 1 score mate 4 nodes 231 nps 28875 tbhits 0 time 8 pv a2a3 g6g5 a3a4 g5g4 h2h3 g4h3
info depth 10 seldepth 8 multipv 1 score mate 4 nodes 247 nps 30875 tbhits 0 time 8 pv a2a3 g6g5 a3a4 g5g4 h2h3 g4h3
bestmove a2a3 ponder g6g5
Look at depth 4, it's strange. It should not be a problem with move generation, since the variation continues on higher depths. Could it be a problem with qsearch?
setoption name UCI_Anti value true
position fen 8/8/6p1/p7/7p/8/P6P/8 w - - 0 1
go depth 10
info depth 1 seldepth 1 multipv 1 score cp 189 nodes 3 nps 1000 tbhits 0 time 3 pv h2h3
info depth 2 seldepth 2 multipv 1 score cp 190 nodes 10 nps 2500 tbhits 0 time 4 pv h2h3 g6g5
info depth 3 seldepth 3 multipv 1 score cp 173 nodes 23 nps 3833 tbhits 0 time 6 pv h2h3 g6g5 a2a4
info depth 4 seldepth 4 multipv 1 score mate 3 nodes 48 nps 8000 tbhits 0 time 6 pv a2a4 g6g5 h2h3 g5g4
info depth 5 seldepth 5 multipv 1 score cp -52 nodes 92 nps 15333 tbhits 0 time 6 pv a2a4 g6g5 h2h3 g5g4 h3g4
info depth 6 seldepth 6 multipv 1 score cp -122 nodes 119 nps 17000 tbhits 0 time 7 pv a2a4 g6g5 h2h3 g5g4 h3g4 h4h3
info depth 7 seldepth 7 multipv 1 score cp -86 nodes 149 nps 21285 tbhits 0 time 7 pv a2a4 g6g5 h2h3 g5g4 h3g4 h4h3 g4g5
info depth 8 seldepth 8 multipv 1 score mate 4 nodes 205 nps 29285 tbhits 0 time 7 pv a2a3 g6g5 a3a4 g5g4 h2h3 g4h3
info depth 9 seldepth 8 multipv 1 score mate 4 nodes 231 nps 28875 tbhits 0 time 8 pv a2a3 g6g5 a3a4 g5g4 h2h3 g4h3
info depth 10 seldepth 8 multipv 1 score mate 4 nodes 247 nps 30875 tbhits 0 time 8 pv a2a3 g6g5 a3a4 g5g4 h2h3 g4h3
bestmove a2a3 ponder g6g5
Look at depth 4, it's strange. It should not be a problem with move generation, since the variation continues on higher depths. Could it be a problem with qsearch?
@ubdip Probably slightly off topic for this thread but are there any plans to teach stockfish crazyhouse?
I think a strong crazyhouse engine will definitely benefit humans as it is a complex variant and its understanding of humans is still quite primitive. (to quote Jann Lee). All the currently available engines are outdated and weak.
I think a strong crazyhouse engine will definitely benefit humans as it is a complex variant and its understanding of humans is still quite primitive. (to quote Jann Lee). All the currently available engines are outdated and weak.
@Naughty_Bishop: Basically, yes, and I would really love to do that (I literally have to keep me from starting right now), but currently I do not have the time to do it. Furthermore, crazyhouse will probably be more difficult than other variants, because of the pieces in hand and the high branching factor.
@Naughty_Bishop: If you're interrested by a crazyhouse engine, join this team: fr.lichess.org/team/crazyhouse-engine-development-and-game-analyses
We should ask Dr.Mark Watkins for permission to incorporate his entire line.
This topic has been archived and can no longer be replied to.