SEE versus SEE_GE

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Post Reply
User avatar
xr_a_y
Posts: 909
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

SEE versus SEE_GE

Post by xr_a_y » Tue Jan 21, 2020 8:33 am

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.

jonkr
Posts: 12
Joined: Wed Nov 13, 2019 12:36 am
Full name: Jonathan Kreuzer

Re: SEE versus SEE_GE

Post by jonkr » Wed Jan 22, 2020 3:05 am

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 :

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;
	}
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.

User avatar
xr_a_y
Posts: 909
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: SEE versus SEE_GE

Post by xr_a_y » Wed Jan 22, 2020 6:22 am

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.

jonkr
Posts: 12
Joined: Wed Nov 13, 2019 12:36 am
Full name: Jonathan Kreuzer

Re: SEE versus SEE_GE

Post by jonkr » Wed Jan 22, 2020 8:57 am

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.)

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
	}
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.

User avatar
xr_a_y
Posts: 909
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: SEE versus SEE_GE

Post by xr_a_y » Wed Jan 22, 2020 10:23 am

Like this

[d] r2n3r/2P1P3/4N3/1k6/8/8/8/4K3 w - - 0 1

Post Reply