New engine: Peacekeeper

[hgm]

If you keep track not only of total mobility, but the mobility of each piece separately, then it is very easy to correct the total for this contribution when the piece gets moved or captured. You then would have to calculate the mobility of the moved piece in its new location.

In addition you would have to account for blocking and discovering of slider moves by the moved piece. The blocking is less of a concern, as it only happens on moves to empty squares, which make up only about 5% of the tree. So it is mainly about discovering of slider moves that would modify the mobility of those sliders (and of course the total).

[Sazgr]

If you keep track not only of total mobility, but the mobility of each piece separately, then it is very easy to correct the total for this contribution when the piece gets moved or captured. You then would have to calculate the mobility of the moved piece in its new location.

In addition you would have to account for blocking and discovering of slider moves by the moved piece. The blocking is less of a concern, as it only happens on moves to empty squares, which make up only about 5% of the tree. So it is mainly about discovering of slider moves that would modify the mobility of those sliders (and of course the total).

The blocking may be less of a concern because normal piece moves would not affect any other mobility, as pieces are not counted as blockers in the first place. I think the only times in which I will have to recompute the total or do more expensive computation is moves or captures of a pawn. I do not know if that is less, maybe about the same.

[Sazgr]

The queen blunder I saw earlier was not unique... After looking at played CCRL 40/15 games

Qxh2+??

[pgn]
[Event "CCRL 40/15"]
[Site "CCRL"]
[Date "2023.02.01"]
[Round "863.5.528"]
[White "Ares 1.003a"]
[Black "Peacekeeper 1.10 64-bit"]
[Result "1-0"]
[WhiteElo "2307"]
[BlackElo "2381"]
[ECO "B40"]
[Opening "Sicilian"]
[Variation "Anderssen variation"]
[PlyCount "47"]

1. e4 c5 2. Nf3 e6 3. d4 cxd4 4. Nxd4 Nf6 5. Nc3 Nc6 6. Ndb5 d6 7. Bf4 e5
8. Bg5 a6 9. Na3 Be7 10. Bxf6 Bxf6 11. Nd5 b5 12. c4 b4 13. Nc2 Rb8 14.
Nxf6+ Qxf6 15. Be2 O-O 16. O-O Rd8 17. b3 Qf4 18. a3 Nd4 19. Nxd4 Qxh2+ 20.
Kxh2 exd4 21. Qxd4 bxa3 22. Rxa3 Bb7 23. Bg4 h6 24. Kg1 1-0
[/pgn]

Qh7+??

[pgn]
[Event "CCRL 40/15"]
[Site "CCRL"]
[Date "2023.02.03"]
[Round "863.5.607"]
[White "Peacekeeper 1.10 64-bit"]
[Black "Cheese 1.4 32-bit"]
[Result "0-1"]
[WhiteElo "2381"]
[BlackElo "2445"]
[ECO "C50"]
[Opening "Giuoco Pianissimo"]
[PlyCount "60"]

1. e4 e5 2. Nf3 Nc6 3. Bc4 Nf6 4. d3 Bc5 5. c3 d6 6. O-O a6 7. a4 Ba7 8.
Re1 O-O 9. Bg5 Bg4 10. h3 Bd7 11. d4 h6 12. Bh4 exd4 13. cxd4 g5 14. Bg3 g4
15. hxg4 Bxg4 16. Qc1 Bxf3 17. Qxh6 Bxd4 18. Bh4 Ng4 19. Qg6+ Kh8 20. Qh5+
Kg7 21. gxf3 Nf6 22. Qg5+ Kh7 23. Qf5+ Kg7 24. e5 Nxe5 25. Bxf6+ Qxf6 26.
Qh7+ Kxh7 27. Rxe5 Qxf3 28. Rh5+ Qxh5 29. Nd2 Qh3 30. Bd3+ f5 0-1
[/pgn]
Nc6??

[pgn]
[Event "CCRL 40/15"]
[Site "CCRL"]
[Date "2023.01.29"]
[Round "863.5.401"]
[White "Peacekeeper 1.10 64-bit"]
[Black "Colossus 2022a 64-bit"]
[Result "0-1"]
[WhiteElo "2381"]
[BlackElo "2757"]
[ECO "D37"]
[Opening "QGD"]
[Variation "4.Nf3"]
[PlyCount "61"]

1. d4 Nf6 2. c4 e6 3. Nf3 d5 4. Nc3 dxc4 5. e4 Bb4 6. Bxc4 Nxe4 7. O-O Nxc3
8. bxc3 Be7 9. Qc2 O-O 10. Bf4 Nd7 11. Rad1 Nf6 12. Ne5 Nd5 13. Nc6 bxc6
14. Bg3 c5 15. dxc5 Bxc5 16. Bb3 Qf6 17. Bxd5 exd5 18. Rxd5 Qc6 19. Rfd1
Bg4 20. R1d2 Rae8 21. h3 Be6 22. Re5 f6 23. Rh5 g6 24. Rh6 Bf5 25. Qd1 Rb8
26. Qf1 Be4 27. Kh2 Rb1 28. Rd1 Rxd1 29. Qxd1 Bxg2 30. Rh4 Be4 31. a4 0-1
[/pgn]

Even though my engine is not that good, I cannot see how it would fail to see those simple one-move blunders. Since opening it up from scratch gives different results, maybe it is the TT problem's fault. The blunders are not even that rare, and it loses terribly stupidly sometimes.

[Ras]

Even though my engine is not that good, I cannot see how it would fail to see those simple one-move blunders.

Maybe it's the stalemate detection in main search: if all moves get pruned, the move counter stays 0, and without being in check, that's misclassified as stalemate. The solution is to only score stalemate if also the legal-but-pruned move counter is 0.

[lithander]

Even though my engine is not that good, I cannot see how it would fail to see those simple one-move blunders. Since opening it up from scratch gives different results, maybe it is the TT problem's fault. The blunders are not even that rare, and it loses terribly stupidly sometimes.

Sometimes the sequence of moves leading to the position matters when reproducing a bug. E.g. for the first position what the engine get's from the GUI is actually:

position startpos moves e2e4 c7c5 g1f3 e7e6 d2d4 c5d4 f3d4 g8f6 b1c3 b8c6 d4b5 d7d6 c1f4 e6e5 f4g5 a7a6 b5a3 f8e7 g5f6 e7f6 c3d5 b7b5 c2c4 b5b4 a3c2 a8b8 d5f6 d8f6 f1e2 e8g8 e1g1 f8d8 b2b3 f6f4 a2a3 c6d4 c2d4

But if Peacekeeper still replies with the right move e5d4 I'd also take a closer look at your TT implementation.

[Sazgr]

Even though my engine is not that good, I cannot see how it would fail to see those simple one-move blunders. Since opening it up from scratch gives different results, maybe it is the TT problem's fault. The blunders are not even that rare, and it loses terribly stupidly sometimes.

Sometimes the sequence of moves leading to the position matters when reproducing a bug. E.g. for the first position what the engine get's from the GUI is actually:

position startpos moves e2e4 c7c5 g1f3 e7e6 d2d4 c5d4 f3d4 g8f6 b1c3 b8c6 d4b5 d7d6 c1f4 e6e5 f4g5 a7a6 b5a3 f8e7 g5f6 e7f6 c3d5 b7b5 c2c4 b5b4 a3c2 a8b8 d5f6 d8f6 f1e2 e8g8 e1g1 f8d8 b2b3 f6f4 a2a3 c6d4 c2d4

But if Peacekeeper still replies with the right move e5d4 I'd also take a closer look at your TT implementation.

Yes the bugs have never been replicated when starting a new instance of the engine.

But I found the bug essentially!

In an effort to replicate the stupid blunders, I looked at my TT code, and nothing seemed wrong. So I ran a hundred games against MinimalChess (chosen as a trusty, pretty normal engine) at 5+0.05 with 64mb hash. Peacekeeper beat MinimalChess pretty convincingly, by +80 elo or so. But then I ran another match with 1mb hash for each engine instead, it lost by 90 elo, and when I looked at some of the short games, there were queen blunders. And I looked closer at the pgns too, and saw that Peacekeeper thought that the blunders were Mate in 1! Obviously they weren't, but looking back on the games and my code, the checked side had only one response (namely to capture the queen). Because I always search at least one move in every node (ruling out something like Ras said), I was puzzled at the checkmate detection. And then I saw this

Code: Select all

if (movelist[i] == entry.bestmove) continue; //continuing if we already searched the hash move

which has less conditions than the part of staged move generation which searches the hash move

Code: Select all

if (entry.type != tt_none && entry.full_hash == position.hashkey() && entry.bestmove.not_null() && position.board[entry.bestmove.start()] == entry.bestmove.piece() && position.board[entry.bestmove.end()] == entry.bestmove.captured()) {//searching best move from hashtable
        position.make_move(entry.bestmove);

so apparently the only check evasion was not searched because it was the same as the best move in (a possibly completely different) TT entry. I am very dumb sometimes.

So I fixed that and ran a selfplay test with 1mb hash still, and my engine lost 20 elo!! I do not understand why pruning random moves can gain 20 elo, but I am inclined to fix the bug anyways for correctness' sake.

[Sazgr]

New stupid thing that seems to gain elo.

Yesterday I tried putting the first generated move (after sorting) into the TT entry in a cut-node instead of leaving the entry blank (i.e. inserting a null move as the bestmove). I think maybe I saw this somewhere in talkchess, but I'm not sure where it was, and not sure if I even saw it instead of my brain creating illusions.

Anyway, after some games, it seems to be testing pretty well compared to all the common-sense features that I've tried (pawn structure, mobility, killers)

Code: Select all

   # PLAYER              : RATING  ERROR   POINTS  PLAYED    (%)
   1 peacekeeper-more    :   47.2   21.7    283.5     500   56.7%
   2 peacekeeper-less    :    0.0   ----    216.5     500   43.3%

Does anyone also do this or know whether it is a valid thing to do? Thanks a lot for everybody who answers this and all of my previous dumb questions.

[lingfors]

New stupid thing that seems to gain elo.

Yesterday I tried putting the first generated move (after sorting) into the TT entry in a cut-node instead of leaving the entry blank (i.e. inserting a null move as the bestmove). I think maybe I saw this somewhere in talkchess, but I'm not sure where it was, and not sure if I even saw it instead of my brain creating illusions.

Anyway, after some games, it seems to be testing pretty well compared to all the common-sense features that I've tried (pawn structure, mobility, killers)

Code: Select all

   # PLAYER              : RATING  ERROR   POINTS  PLAYED    (%)
   1 peacekeeper-more    :   47.2   21.7    283.5     500   56.7%
   2 peacekeeper-less    :    0.0   ----    216.5     500   43.3%

Does anyone also do this or know whether it is a valid thing to do? Thanks a lot for everybody who answers this and all of my previous dumb questions.

I do it in my engine as well. The move was the best one found in the position, and it was good enough to cause a cut-off. Sounds like a good idea to keep around and try first in case we come back to the same position again on a deeper depth.

[Sazgr]

New stupid thing that seems to gain elo.

Yesterday I tried putting the first generated move (after sorting) into the TT entry in a cut-node (SHOULD BE ALL-NODE ) instead of leaving the entry blank (i.e. inserting a null move as the bestmove). I think maybe I saw this somewhere in talkchess, but I'm not sure where it was, and not sure if I even saw it instead of my brain creating illusions.

Anyway, after some games, it seems to be testing pretty well compared to all the common-sense features that I've tried (pawn structure, mobility, killers)

Code: Select all

   # PLAYER              : RATING  ERROR   POINTS  PLAYED    (%)
   1 peacekeeper-more    :   47.2   21.7    283.5     500   56.7%
   2 peacekeeper-less    :    0.0   ----    216.5     500   43.3%

Does anyone also do this or know whether it is a valid thing to do? Thanks a lot for everybody who answers this and all of my previous dumb questions.

I do it in my engine as well. The move was the best one found in the position, and it was good enough to cause a cut-off. Sounds like a good idea to keep around and try first in case we come back to the same position again on a deeper depth.

I just realized the "cut-node" was a typing mistake and should actually be all-node. Sorry for that misunderstanding, it happens often with me.

[lingfors]

It's okay, I mix upp the terms as well. ^^

For an all-node, i.e. fail-low node, you have no clue which move is the best one, all you know is that no move managed to exceed alpha (the lower bound), so what are you even accomplishing by saving any move in the TT?

But in the end, the only thing that matters is if a code change increase the playing strength or not. And the only way to find that out is to let the new version play against the old version for a few (hundred) games.