What is the best approach ?
SEE being a classic swap list building
SEE_GE being the stockfish like null window loop
I faced a possible issue with SEE_GE recently, being unable to come up with a good treatment of promotions inside the loop.
Early exits based on threshold are not working if the value of a queen in inserted inside the process.
SEE versus SEE_GE
Moderators: hgm, Rebel, chrisw
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
-
- Posts: 178
- Joined: Wed Nov 13, 2019 1:36 am
- Full name: Jonathan Kreuzer
Re: SEE versus SEE_GE
I would assume early out without a swap list must be quicker, if you don't need the final value, which I don't.
I handle promotions with code like this :
isPromoSquare is set at beginning of the function if dst is any rank8 square, color doesn't matter since pawns can only go to their own.
value is always from the point of view of the SEE calling color.
Never measured what is worth it to do or not, but I did add code that can store exception boards where SEE & qsearch signs don't match then browse them which helped to fix some SEE innaccuracies. Other issues that helped me notice and fix were need of en-passant handling, pin handling, and an early out bug.
I handle promotions with code like this :
Code: Select all
// update overall value & pieceOnSqValue for this capture
value += (c == stm) ? pieceOnSqValue : -pieceOnSqValue;
pieceOnSqValue = PieceValue[ movedPiece ];
if (movedPiece == PAWN && isPromoSquare) {
value += (c == stm) ? (QUEEN_VALUE - PAWN_VALUE) : -(QUEEN_VALUE - PAWN_VALUE);
pieceOnSqValue = QUEEN_VALUE;
}
value is always from the point of view of the SEE calling color.
Never measured what is worth it to do or not, but I did add code that can store exception boards where SEE & qsearch signs don't match then browse them which helped to fix some SEE innaccuracies. Other issues that helped me notice and fix were need of en-passant handling, pin handling, and an early out bug.
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: SEE versus SEE_GE
This is what I did before but is you try to use this with a high threshold knowing a queen will be made and the promotion is not the first move, you will face early exit.
[d] 3N4/2P5/2n5/1k6/8/8/8/4K3 b - - 0 1
Here the see value is S=N-(N-P+Q). But using see_ge with S+1 and S-1 as threshold won't lead to what we want because first capture piece is far from queen value.
[d] 3N4/2P5/2n5/1k6/8/8/8/4K3 b - - 0 1
Here the see value is S=N-(N-P+Q). But using see_ge with S+1 and S-1 as threshold won't lead to what we want because first capture piece is far from queen value.
-
- Posts: 178
- Joined: Wed Nov 13, 2019 1:36 am
- Full name: Jonathan Kreuzer
Re: SEE versus SEE_GE
Yeah that's true, to be correct you would need to know if there is a promo capture before doing an early out. An extra line for promoVal makes the position you posted return the correct value for me according to margin (instead of returning true that N x N is even capture, only starts returning true on -QUEEN_VALUE + PAWN_VALUE.)
But I only have this at the top of my SEE function, so only initial capture and recapture are correct, in the recap loop I'm not handling the case, so will be a few positions that aren't fully correct.
Code: Select all
const int promoVal = (isPromoSquare && IsPawnDefended(stm, dst)) ? QUEEN_VALUE - PAWN_VALUE : 0;
if (value - pieceOnSqValue - promoVal >= 0) {
return true; // if recapture isn't enough to tip the balance, we win
}
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: SEE versus SEE_GE
Like this
[d] r2n3r/2P1P3/4N3/1k6/8/8/8/4K3 w - - 0 1
[d] r2n3r/2P1P3/4N3/1k6/8/8/8/4K3 w - - 0 1