[d]3r1k2/4npp1/1ppr3p/p6P/P2PPPP1/1NR5/5K2/2R5 w - - 0 1
Code: Select all
4 +5.15 321 0:00.00 e5 g6 exd6 Rxd6
3 +5.15 229 0:00.00 e5 g6 exd6
2 +5.64 155 0:00.00 e5 b5
1 +1.31 90 0:00.00 e5
0 #
Moderators: hgm, Rebel, chrisw
Code: Select all
4 +5.15 321 0:00.00 e5 g6 exd6 Rxd6
3 +5.15 229 0:00.00 e5 g6 exd6
2 +5.64 155 0:00.00 e5 b5
1 +1.31 90 0:00.00 e5
0 #
Stockfish calculates something at low depths. BK #2 has already been analyzed to death, but this analysis of SF8 is absurd.hgm wrote:That is what you get when you prune a lot. Low depths with Stockfish mean nothing. The idea is that it will always reach high depth exactly because it prunes so much.
Indeed. Perft 4 from the position is 622,922. Although, to be fair, I checked several other strong engines, and all of them reported <1K nodes at depth 4, and none of them had the rook hanging in the PV.hgm wrote:Sure, it calculates with the moves it doesn't prune. But if you then prune all reasonable moves...
What can you expect from a search of only 321 positions?
I am not totally sure about the comparison with perft values: perft(1) of that position is 33 but depth 1 reports 90 nodes... of course I do not know exactly how a chess engine works.JVMerlino wrote:Indeed. Perft 4 from the position is 622,922. Although, to be fair, I checked several other strong engines, and all of them reported <1K nodes at depth 4, and none of them had the rook hanging in the PV.hgm wrote:Sure, it calculates with the moves it doesn't prune. But if you then prune all reasonable moves...
What can you expect from a search of only 321 positions?
But, to also be fair, of course SF would never actually hang the rook in a game, even if it was depth limited, and who only gives an engine a couple of milliseconds before scrutinizing the PV?
Code: Select all
JetChess 1.0.0.0:
perft(1) = 33
perft(2) = 793
perft(3) = 26,013
perft(4) = 622,922
perft(5) = 20,077,998
perft(6) = 486,503,398
perft(7) = 15,329,960,358
perft(8) = 376,726,075,275
positions(1) = 33
positions(2) = 793
positions(3) = 13,668
positions(4) = 198,137
positions(5) = 2,108,657
positions(6) = 23,173,657
SF doesn't do any pruning at the root, but it does do qsearch after making all 33 root moves. So searching 90 nodes at depth 1 makes sense.Ajedrecista wrote:Hello John:
I am not totally sure about the comparison with perft values: perft(1) of that position is 33 but depth 1 reports 90 nodes... of course I do not know exactly how a chess engine works.JVMerlino wrote:Indeed. Perft 4 from the position is 622,922. Although, to be fair, I checked several other strong engines, and all of them reported <1K nodes at depth 4, and none of them had the rook hanging in the PV.hgm wrote:Sure, it calculates with the moves it doesn't prune. But if you then prune all reasonable moves...
What can you expect from a search of only 321 positions?
But, to also be fair, of course SF would never actually hang the rook in a game, even if it was depth limited, and who only gives an engine a couple of milliseconds before scrutinizing the PV?
Otherwise, I fully agree on the fact that very aggressive pruning of SF shows this behaviour, not considering it relevant. SF will not hang the rook with reasonable depths.
Just checking perft values and number of unique positions of Bratko-Kopec #2:
I hope no typos.Code: Select all
JetChess 1.0.0.0: perft(1) = 33 perft(2) = 793 perft(3) = 26,013 perft(4) = 622,922 perft(5) = 20,077,998 perft(6) = 486,503,398 perft(7) = 15,329,960,358 perft(8) = 376,726,075,275 positions(1) = 33 positions(2) = 793 positions(3) = 13,668 positions(4) = 198,137 positions(5) = 2,108,657 positions(6) = 23,173,657
Regards from Spain.
Ajedrecista.
The problem with this is that it often is difficult to identify the true threat from the line that refuted the first move. This because of the default move ordering, which performs captures in victim-value order. This masks the real threat by trading higher victims. E.g. if your Knight gets attacked by a Pawn, you would like to search moves that withdraw the Knight. But if the same position contains a QxQ, RxR or BxB capture, there are two problems. In the first place you would play the QxQ or RxR yourself as first move, and the opponent would first have to recapture the Q or R before he can take the Knight. This could be avoided by looking at the null-move refutation. (But you might not try null move in PV nodes.) But the second problem is that to refute the null move (or any other move that does not move away the Knight or capture its attacker) the opponent would now start with the QxQ, RxR, and only play out the PxN threat after you recapture the Q or R. This would mis-identify the threatened piece as the Q or R, and you would waste time by trying to withdraw those. This would avoid their trading, but it would still lose you the Knight!mjlef wrote:One method to avoid this is after you search the first move, you note if the opponents response is the rook being captured. You mark the rook as a threatened piece, and make sure you include some quiet "safe" moves to see if the rook can escape capture. I have experimented with this in the past...and it is a close call to say if it helps or not.