Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overlapping comparison in syzygy #394

Closed
atg opened this issue Aug 12, 2015 · 6 comments
Closed

Overlapping comparison in syzygy #394

atg opened this issue Aug 12, 2015 · 6 comments

Comments

@atg
Copy link

atg commented Aug 12, 2015

Clang found this.

if (v1 >= 0 || v1 < 100)

which doesn't seem entirely intentional.

@syzygy1
Copy link
Contributor

syzygy1 commented Aug 17, 2015

Correct, it should be "v1 >= 0 || v1 < -100".

This is part of en passant handling. v1 is the DTZ score after the en passant capture, v is the DTZ score of the position assuming no ep is possible (the tables don't store en passant positions). The code then takes the "best" of v and v1 (unless the position without ep is stalemate!).
We are in the case that v indicates a loss (-100 <= v < 0). That means v1 is "better" if it is a draw or (cursed) win (>= 0) or a "cursed(/blessed) loss" (< -100).
If v1 is also a loss, it is never better than v, because the ep capture is a zeroing move so the ep capture loss is never better than any other loss in terms of DTZ. (As you can see from the code, v1 is one of -101,-1,0,1,101. So the condition could also be replaced by "v1 != -1".)

The probing code of my private engine has the same typo / bug.

mstembera pushed a commit to mstembera/Stockfish that referenced this issue Sep 2, 2015
official-stockfish#394
Credit and thanks to syzygy1 and lantonov !
peterosterlund2 added a commit to peterosterlund2/droidfish that referenced this issue Sep 3, 2015
@mstembera
Copy link
Contributor

@syzygy1 and @lantonov
Could you please confirm Joonas understanding of the patch here?
#415
Thank you!

@syzygy1
Copy link
Contributor

syzygy1 commented Sep 5, 2015

Yes, 100 should be changed to -100:
if (v1 >= 0 || v1 < -100)

@mstembera
Copy link
Contributor

Thank you! But does Joonas explanation of the logic here
#415
make sense?

@syzygy1
Copy link
Contributor

syzygy1 commented Sep 6, 2015

I already gave an explanation on github.

  From: mstembera <[email protected]>

To: official-stockfish/Stockfish [email protected]
Cc: syzygy1 [email protected]
Sent: Sunday, September 6, 2015 1:47 AM
Subject: Re: [Stockfish] Overlapping comparison in syzygy (#394)

Thank you! But does Joonas explanation of the logic here
#415
make sense?—
Reply to this email directly or view it on GitHub.

@lantonov
Copy link

lantonov commented Sep 6, 2015

Below is the RdM's explanation for "cursed win" and "cursed loss" in syzygy which are indeed connected with the 50-move rule.

"Anyway, this is all not a problem for my tablebases. If the engine wants to ignore the 50-move rule for tablebase positions, it can ignore the 50-move rule when using my tablebases. This is because my tablebases do not store a draw by the 50-move rule as a draw, but as a "cursed win" or "cursed loss". The engine can simply treat "cursed wins" as real wins and "cursed losses" as real losses. Or it can honor the 50-move rule and treat both of them as draws. Or it can bluff and treat cursed wins by the engine as wins and cursed losses as draws."

So, RdM's explanation for what this patch does:

"This is part of en passant handling. v1 is the DTZ score after the en passant capture, v is the DTZ score of the position assuming no ep is possible (the tables don't store en passant positions). The code then takes the "best" of v and v1 (unless the position without ep is stalemate!).
We are in the case that v indicates a loss (-100 <= v < 0). That means v1 is "better" if it is a draw or (cursed) win (>= 0) or a "cursed(/blessed) loss" (< -100)."

is indeed correctly understood by Joona who describes it more clearly.

I wanted to test this patch on the framework but it does not test syzygy at present. Another option is to find positions close to endgame that include en passant moves and test with or w/o syzygy.

@zamar zamar closed this as completed in 46b5a5f Sep 6, 2015
mstembera pushed a commit to mstembera/Stockfish that referenced this issue Sep 23, 2015
v = value without ep capture being considered
v1 = value of the ep capture

The correct logic is:
if without e.p. capture we are losing, and the value of e.p is either draw, or win or "loss, but 50 move rule saves us", then we should use the value of ep capture.

Credit and thanks to syzygy1 and lantonov !

No functional change (except with syzygy bases)

Resolves official-stockfish#415
Resolves official-stockfish#394
niklasf pushed a commit to niklasf/Stockfish that referenced this issue Aug 20, 2017
Fix pawn evaluation for horde with inverse colors
peterosterlund2 added a commit to peterosterlund2/texel that referenced this issue Feb 2, 2019
git-svn-id: file:///home/petero/vc/svnrepos/texel/trunk@545 4abc0a36-5a1e-4bec-8e7d-414f7125f69d
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants