Another Crafty Castling Concern: Implicit Castling Direction

[GothicChessInventor]

From the code segment below, doing some tests of my own (through Gothic Vortex) I found out something unusual:

Code: Select all

    if &#40;WhiteCastle&#40;ply&#41; <= 0&#41; &#123;
      if &#40;File&#40;WhiteKingSQ&#41; >= FILEE&#41; &#123;
        if &#40;File&#40;WhiteKingSQ&#41; > FILEE&#41;
          tree->w_safety += tree->pawn_score.white_defects_k;
        else
          tree->w_safety += tree->pawn_score.white_defects_e;
      &#125; else if &#40;File&#40;WhiteKingSQ&#41; <= FILED&#41; &#123;
        if &#40;File&#40;WhiteKingSQ&#41; < FILED&#41;
          tree->w_safety += tree->pawn_score.white_defects_q;
        else
          tree->w_safety += tree->pawn_score.white_defects_d;
      &#125;
    &#125;

It is conceivable for White to have castled kingside, yet the identifying condition "if (File(WhiteKingSQ) >= FILEE)" could be false.

Example: Castle early in the search, some extension triggering is reached, the King goes from (in 8x8 chess) g1 to f2 to e2 to d1 due to being checked, and the "if" statement fails despite castling having occured.

Now in a vast majority of the cases you castle kingside and your File(king) will be greater than FILEE. But, the faster computers become, and the deeper you search, the more often this will fail (in terms of nodes misevaluated, not in terms of percentage of occurances.)

I have toyed with adding some "WhiteDefinitelyCastledKingside(ply)" structure, but setting and resetting this during Move/Unmove, yet having it "inherit" the data where applicable seems to be a bit of trouble.

Any comments?

[bob]

From the code segment below, doing some tests of my own (through Gothic Vortex) I found out something unusual:

Code: Select all

    if &#40;WhiteCastle&#40;ply&#41; <= 0&#41; &#123;
      if &#40;File&#40;WhiteKingSQ&#41; >= FILEE&#41; &#123;
        if &#40;File&#40;WhiteKingSQ&#41; > FILEE&#41;
          tree->w_safety += tree->pawn_score.white_defects_k;
        else
          tree->w_safety += tree->pawn_score.white_defects_e;
      &#125; else if &#40;File&#40;WhiteKingSQ&#41; <= FILED&#41; &#123;
        if &#40;File&#40;WhiteKingSQ&#41; < FILED&#41;
          tree->w_safety += tree->pawn_score.white_defects_q;
        else
          tree->w_safety += tree->pawn_score.white_defects_d;
      &#125;
    &#125;

It is conceivable for White to have castled kingside, yet the identifying condition "if (File(WhiteKingSQ) >= FILEE)" could be false.

Example: Castle early in the search, some extension triggering is reached, the King goes from (in 8x8 chess) g1 to f2 to e2 to d1 due to being checked, and the "if" statement fails despite castling having occured.

Now in a vast majority of the cases you castle kingside and your File(king) will be greater than FILEE. But, the faster computers become, and the deeper you search, the more often this will fail (in terms of nodes misevaluated, not in terms of percentage of occurances.)

I have toyed with adding some "WhiteDefinitelyCastledKingside(ply)" structure, but setting and resetting this during Move/Unmove, yet having it "inherit" the data where applicable seems to be a bit of trouble.

Any comments?

I don't see the problem you are describing. That code doesn't care about anything other than (a) white has lost the castling rights and (b) whether it is on the king-side, queen-side, or stuck in the middle. It doesn't use the "castled king-side and > fileE as you are thinking....

All I care about is that white can no longer castle, then I look at the king position (queenside, center or kingside) to decide which pawn structure I need to study...

[GothicChessInventor]

I don't see the problem you are describing. That code doesn't care about anything other than (a) white has lost the castling rights and (b) whether it is on the king-side, queen-side, or stuck in the middle. It doesn't use the "castled king-side and > fileE as you are thinking....

All I care about is that white can no longer castle, then I look at the king position (queenside, center or kingside) to decide which pawn structure I need to study...

I see. If you can no longer castle to a particular side, and the king is in that region of the board, independent of whether or not castling occured, you award or remove points based on the pawn structures.

I was trying to do something like:

Code: Select all

if(castled_kingside)
{
    ...check some pawn conditions....
    ....award kingside castle bonus if "safe" position...
}
else
if(castled_queenside)
{
    ...check some pawn conditions....
    ....award queenside castle bonus if "safe" position...
}
else
{
    ...other stuff...
}

It seems there is no way to make an explicit castling determination this way, so my premise was faulty

[GothicChessInventor]

Actually, I get a little more granular now.

I examine the 3 pawns "in front of" the king, ex: f2,g2,h2 if the king is on g1, as well as the next row of pawns, f3,g3, and h3.

I use 1-bit per pawn, = a 6-bit precompiled index. If a pawn is there, set the bit, if not, set a 0.

So, it creates an array of [64][64] (in chess) or [64][80] in Gothic Chess, if you created such an array for each square. In reality, I only check for 3 ranks worth of squares, ranks 1-3 for white, ranks 6-8 for black.

Shifting the pawn bitboard by the appropriate amount after Oring them together creates the index into the first dimension. The KingSquare is the second dimension.

I can assign "ad hoc" values to any pawn configuration (like missing the g-pawn when castled kingside would be "bad", but f2,g3,h2 could be "good".)

By giving the king dimension on [pawn index][g1] and [pawn index][c1] higher values than [pawn index][e1], castling can be "encouraged" in this fashion.

I'll have to benchmark the overhead and see if all of this granularity has too large of a negative impact.