pin-aware see

[Ronald de Man]

I'm adding the pin-aware see improvement to my rewrite of see() and I noticed something which seems interesting. I couldn't get my see() functionally the same, so I decided to print out the positions where mine returns a different result.

Example:
s1 = 0, s2 = 1

 +---+---+---+---+---+---+---+---+
 | r |   |   | q | k |   |   | r |
 +---+---+---+---+---+---+---+---+
 | p | p | p | b |   | p | p | p |
 +---+---+---+---+---+---+---+---+
 |   |   | n | p |   |   |   |   |
 +---+---+---+---+---+---+---+---+
 |   | B | b |   |   |   |   |   |
 +---+---+---+---+---+---+---+---+
 |   |   |   |   | n |   |   |   |
 +---+---+---+---+---+---+---+---+
 |   |   |   |   |   | N |   |   |
 +---+---+---+---+---+---+---+---+
 | P | P | P |   |   | P | P | P |
 +---+---+---+---+---+---+---+---+
 | R | N | B | Q | R |   | K |   |
 +---+---+---+---+---+---+---+---+

Fen: r2qk2r/pppb1ppp/2np4/1Bb5/4n3/5N2/PPP2PPP/RNBQR1K1 b kq - 1 1
Key: F88D2602D22EF907
Checkers:
from = 34, to = 13, value = 0

SF's see says Bxf2 has negative see. Mine says it is non-negative (>= value).

I'd say mine is right.

If the capturing piece is a king, I am checking whether the opponent has any attackers left WITHOUT first removing pinned pieces. Here the knight on e4 makes the king capture invalid even though it is pinned.

How about this:

   do {
      assert(slIndex < 32);

      // Add the new entry to the swap list
      swapList[slIndex] = -swapList[slIndex - 1] + PieceValue[MG][captured];

      // Locate and remove the next least valuable attacker
      captured = min_attacker<PAWN>(byTypeBB, to, stmAttackers, occupied, attackers);
      stm = ~stm;
      stmAttackers = attackers & pieces(stm);
      if (captured == KING) // Stop before a king capture
      {
          slIndex += !stmAttackers;
          break;
      }
      if (   (stmAttackers & pinned_pieces(stm))
          && (st->pinnersForKing[stm] & occupied) == st->pinnersForKing[stm])
          stmAttackers &= ~pinned_pieces(stm);

      ++slIndex;

  } while (stmAttackers);

The slIndex += line is cryptic and could use a better comment.

There may be a better way to do this; I just want to point out a possible further improvement.

[guenthe...@hotmail.com]

Thank you for this valuable hint. We will try it for sure.
Marco, which bounds should be used for such a test?

[guenthe...@hotmail.com]

Hi Ronald,

your discovery is, expressed in another words, the realization that although a piece is pinned it still can give check. Nice finding!

[Joachim Müller (JojoM)]

Or, to put it still differently: If that is true, as of yet, the chess rules have not been implemented correctly.

[Ronald de Man]

On Wednesday, September 14, 2016 at 9:15:03 AM UTC+2, guenthe...@hotmail.com wrote:

Hi Ronald,  

your discovery is, expressed in another words, the realization that although a piece is pinned it still can give check. Nice finding!

Yes, I thought it was funny to find this while hunting a bug.

What bounds to use is indeed a good question. If someone wants to try a test or perhaps add this to another test (I think the pin-aware see is still being perfected in other ways), then please do so.

[Adam Herwis]

 The first one to capture he king wins, even if the other gets exposed. These are right chess rules, or I misunderstood your point.

[Stephane Nicolet]

@Adam : SF will never play a king capture during a game, what is discussed here

 is an internal heuristic to value the moves during the search.

@Ronald : your version seems equivalent (same long bench) to

      // Locate and remove the next least valuable attacker

      captured = min_attacker<PAWN>(byTypeBB, to, stmAttackers, occupied, attackers);

      stm = ~stm;

      stmAttackers = attackers & pieces(stm);

       if (    captured != KING

           && (stmAttackers & pinned_pieces(stm))

           && (st->snipersForKing[stm] & occupied) == st->snipersForKing[stm])

           stmAttackers &= ~pinned_pieces(stm);

      ++slIndex;

I will push a SPRT[-3..1] test with both this fix and the correct pinners fix at the same time. Thanks :-)

[guenthe...@hotmail.com]

> I will push a SPRT[-3..1] test with both this fix and the correct pinners fix at the same time. Thanks :-)

Is it ok and allowed to test 2 bugfixes at once with a single test?

[Nabil Danial]

I don't think so.

[Stephane Nicolet]

Le mercredi 14 septembre 2016 16:02:21 UTC+2, guenthe...@hotmail.com a écrit :

> I will push a SPRT[-3..1] test with both this fix and the correct pinners fix at the same time. Thanks :-)

Is it ok and allowed to test 2 bugfixes at once with a single test?

It ok because in fact it is even stricter : with consecutive SQRT[-3..1]

each could pass with probability 50% if each fix is a 0.6 Elo loss, while by

doing a single SPRT[-3..1] test I check that the two fixes together don't

lose more than 0.6 Elo points.

[guenthe...@hotmail.com]

Ok, did you see the latest code proposal on https://github.com/mcostalba/Stockfish/commit/ad7d2bdeedd2b0021e459297f3ddeaf6f8e07d87 ?

[bernhar...@gmail.com]

Before latest patch "go depth 22" from startpos gave
nodes ...... time
9322636 19,5 sec
After
15734384 34,9 sec
Only change was positin.cpp
Just FYI
Kind regards
Bernhard

[damasc...@gmail.com]

Nice finding, Ronald.

Thank YOU very MUCH for pointing this!

[and...@spyingeyes.ca]

> SF's see says Bxf2 has negative see. Mine says it is non-negative (>= value).
>
> I'd say mine is right.
>
> If the capturing piece is a king, I am checking whether the opponent has any attackers left WITHOUT first removing pinned pieces. Here the knight on e4 makes the king capture invalid even though it is pinned.

Before and after the patch my SF still sees the score as negative (~ -3). You're saying yours doesn't and it's right?

[guenthe...@hotmail.com]

-3 isn't a possible return value for a SEE-call.
With the patch SF now returns value 188 which corresponds to constant PawnValueMG and this is correct, because White can't take back at f2 and just looses the pawn.

[and...@spyingeyes.ca]

On Thursday, September 22, 2016 at 2:04:06 AM UTC-4, guenthe...@hotmail.com wrote:
> -3 isn't a possible return value for a SEE-call.
> With the patch SF now returns value 188 which corresponds to constant PawnValueMG and this is correct, because White can't take back at f2 and just looses the pawn.

I guess I'm confused as to what exactly the SEE call is.