pin-aware see

830 views
Skip to first unread message

Ronald de Man

unread,
Sep 13, 2016, 8:22:21 PM9/13/16
to FishCooking
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

unread,
Sep 14, 2016, 2:26:42 AM9/14/16
to FishCooking
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

unread,
Sep 14, 2016, 3:15:03 AM9/14/16
to FishCooking, 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)

unread,
Sep 14, 2016, 3:23:28 AM9/14/16
to FishCooking
Or, to put it still differently: If that is true, as of yet, the chess rules have not been implemented correctly.

Ronald de Man

unread,
Sep 14, 2016, 3:36:06 AM9/14/16
to FishCooking
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

unread,
Sep 14, 2016, 8:42:57 AM9/14/16
to FishCooking
 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

unread,
Sep 14, 2016, 9:54:20 AM9/14/16
to FishCooking
@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

unread,
Sep 14, 2016, 10:02:21 AM9/14/16
to FishCooking
> 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

unread,
Sep 14, 2016, 10:10:21 AM9/14/16
to FishCooking, guenthe...@hotmail.com
I don't think so.

Stephane Nicolet

unread,
Sep 14, 2016, 10:14:02 AM9/14/16
to FishCooking, guenthe...@hotmail.com


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

unread,
Sep 14, 2016, 10:17:19 AM9/14/16
to FishCooking, guenthe...@hotmail.com

bernhar...@gmail.com

unread,
Sep 21, 2016, 4:33:02 AM9/21/16
to FishCooking
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

unread,
Sep 21, 2016, 10:06:50 AM9/21/16
to FishCooking

Nice finding, Ronald.

Thank YOU very MUCH for pointing this!

and...@spyingeyes.ca

unread,
Sep 22, 2016, 12:29:37 AM9/22/16
to FishCooking
> 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

unread,
Sep 22, 2016, 2:04:06 AM9/22/16
to FishCooking, and...@spyingeyes.ca
-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

unread,
Sep 22, 2016, 2:07:10 AM9/22/16
to FishCooking, and...@spyingeyes.ca, guenthe...@hotmail.com
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.

Reply all
Reply to author
Forward
0 new messages