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

Remove candidate passers w/o feasible lever #2624

Closed

Conversation

Lolligerhans
Copy link
Contributor

Objections from anyone to code style would best be raised now. Specifically regarding

  1. the way I nest operations in lengthy instructions and
  2. the use of const to help readers and compiler to better understand the computations.

Commit message will not show the fancy ASCII if viewed without monospace font. I like including the pictures though - nobody should be bothered reading text or even diff. The text will remain readable. Wrapped at 50/72.

Testing on takes 4 and 5 is ongoing but not promising.

I add a comment in pawns.cpp to remind readers that identification of candidate passers continues in evaluate.cpp.

I use the phrasing "candidate passer" with a meaning distinct from the one used in recent "Retire candidate passed pawns" commit, which abandoned spacial handling of a different form of "candidate passer".

You do not need to edit this commit. Comment here - I will edit the branch as required.

@Lolligerhans
Copy link
Contributor Author

Updated bench.

@Lolligerhans Lolligerhans marked this pull request as ready for review April 12, 2020 19:50
@vondele
Copy link
Member

vondele commented Apr 12, 2020

nice idea... for the formatting, try to blend in the code as much as possible, i.e. use same indentation style (which tends to align near = signs). That's a little more difficult with the const decl, which presumably for variables with such a local scope doesn't bring much neither for the compiler nor for the reader.

@Alayan-stk-2
Copy link

Excellent commit message.

@snicolet
Copy link
Member

@Lolligerhans

Nice idea ! Concerning the formatting, I suggest something like the following version where I used only two bitboards, declaring them at the top of the function as usual -- didn't verified that the bench is the same, however, please double-check -- and put a singular in the comment:

Bitboard b, bb, squaresToQueen, unsafeSquares, candidatePassers, leverable;

...

candidatePassers = b & shift<Down>(pos.pieces(Them, PAWN));

if (candidatePassers)
{
    // Can we lever the blocker of a candidate passer?
    leverable =   shift<Up>(pos.pieces(Us, PAWN))
               &  ~pos.pieces(Them)
               & (~attackedBy2[Them] | attackedBy[Us][ALL_PIECES])
               & (~(attackedBy[Them][KNIGHT] | attackedBy[Them][BISHOP])
                 | (attackedBy[Us  ][KNIGHT] | attackedBy[Us  ][BISHOP]));

    // Remove candidate otherwise
    b &= ~(candidatePassers & ~(shift<WEST>(leverable) | shift<EAST>(leverable));
}

@Lolligerhans Lolligerhans force-pushed the passed-tweaks_pr branch 2 times, most recently from c69c8db to 349c7b7 Compare April 12, 2020 21:25
@Lolligerhans
Copy link
Contributor Author

  • Align at equal sign as suggested by vdv and sn.
  • Squeezed removal &= into 1 expression. Decided to de morgan it (line exceeded 80c).
  • Fixed typo in comment using plural.
  • Removed all const and moved declarations to start.
  • Double-checked: executable remains identical.

@vondele
Copy link
Member

vondele commented Apr 12, 2020

LGTM, will merge in the next round.

The commit message has one more typo (s/althogh/although/g) and maybe you can use the same format (including link location) for the SPRT results as most other commit messages.

@Lolligerhans
Copy link
Contributor Author

  • Fixed altho(u)gh and some bracing in commit message text.
  • Adjusted test report formatting. Found multiple variants, including ones omitting links. Copied what seems the most reasonable.

+-------+
| o . . | o  their pawns
| x . . | x  our pawns
| . x . | <- Can sacrifice to create passer?
+-------+
   yes

    1         2         3         4         5
+-------+ +-------+ +-------+ +-------+ +-------+
| o . . | | o r . | | o r . | | o . b | | o . b |  lowercase: theirs
| x b . | | x . . | | x . R | | x . R | | x . . |  uppercase: ours
| . x . | | . x . | | . x . | | . x . | | . x B |
+-------+ +-------+ +-------+ +-------+ +-------+
   no        no        yes       no        yes

The value of our top pawn depends on our ability to advance our bottom
pawn, levering their blocker. Previously, this pawn configuration was
always scored as passer (although a blocked one).

Add requirements for the square s above our (possibly) sacrificed pawn:
- s must not be occupied by them (1).
- If they attack s (2), we must attack s (3).
- If they attack s with a minor (4), we must attack s with a minor (5).
The attack from their blocker is ignored because it is inherent in the
structure; we are ok with sacrificing our bottom pawn.

LTC
LLR: 2.95 (-2.94,2.94) {0.25,1.75}
Total: 37030 W: 4962 L: 4682 D: 27386
Ptnml(0-2): 266, 3445, 10863, 3625, 316
https://tests.stockfishchess.org/tests/view/5e92a2b4be6ede5b954bf239

STC
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 40874 W: 8066 L: 7813 D: 24995
Ptnml(0-2): 706, 4753, 9324, 4890, 764
https://tests.stockfishchess.org/tests/view/5e922199af0a0143109dc90e

Bench: 4828294
@adentong
Copy link

Really nice commit message! Good stuff.

@vondele vondele closed this in d7a2d5a Apr 13, 2020
@vondele
Copy link
Member

vondele commented Apr 13, 2020

Thanks!

MichaelB7 pushed a commit to MichaelB7/Stockfish that referenced this pull request Apr 14, 2020
+-------+
| o . . | o  their pawns
| x . . | x  our pawns
| . x . | <- Can sacrifice to create passer?
+-------+
   yes

    1         2         3         4         5
+-------+ +-------+ +-------+ +-------+ +-------+
| o . . | | o r . | | o r . | | o . b | | o . b |  lowercase: theirs
| x b . | | x . . | | x . R | | x . R | | x . . |  uppercase: ours
| . x . | | . x . | | . x . | | . x . | | . x B |
+-------+ +-------+ +-------+ +-------+ +-------+
   no        no        yes       no        yes

The value of our top pawn depends on our ability to advance our bottom
pawn, levering their blocker. Previously, this pawn configuration was
always scored as passer (although a blocked one).

Add requirements for the square s above our (possibly) sacrificed pawn:
- s must not be occupied by them (1).
- If they attack s (2), we must attack s (3).
- If they attack s with a minor (4), we must attack s with a minor (5).
The attack from their blocker is ignored because it is inherent in the
structure; we are ok with sacrificing our bottom pawn.

LTC
LLR: 2.95 (-2.94,2.94) {0.25,1.75}
Total: 37030 W: 4962 L: 4682 D: 27386
Ptnml(0-2): 266, 3445, 10863, 3625, 316
https://tests.stockfishchess.org/tests/view/5e92a2b4be6ede5b954bf239

STC
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 40874 W: 8066 L: 7813 D: 24995
Ptnml(0-2): 706, 4753, 9324, 4890, 764
https://tests.stockfishchess.org/tests/view/5e922199af0a0143109dc90e

closes official-stockfish#2624

Bench: 4828294
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

Successfully merging this pull request may close these issues.

None yet

5 participants