Mailbox move gives check routine

[Ras]

No! Where does that idea come from? These are static tables, initialized at engine startup.

Then you're back to square one (or, a1 ) because first, these table don't actually tell you anything about blocked sliders, and second, you have to loop through the pieces.

[hgm]

No again. You only have to do it for the from- and to-square. Other pieces cannot be checking, because they would then already have been checking before the move. And then you would never have tried this move, but captured the king for a beta cutoff. So you test the to-square for alignment of the mover, and the from-square for alignment of a queen.

Point is that 90% of the tests will turn out negative, and no, then you don't have to worry about blocked sliders, because there is nothing to block. Of the other 10% part will be leapers or contact alignment by sliders; no blocking possible there either. So the code to test for blocking is executed so rarely that it doesn't significantly contribute to the execution time.

And when you do have a distant slider alignment, and do the ray scan starting at the king, you would bump into the pawn shield on the very first square, in a typical midle-game position. So the ray scan will be fast as well, in the rare case that it has to be done.

[Sven]

To determine whether a move gives check should never modify any part of the board state so const correctness is not an issue.

It's not necessary but it makes the code much simpler in cases like en passant discovered check for example.

[d]8/4b3/8/3k4/2p5/4Pp2/1K1P1P2/R7 b - - 0 1

So you think of temporarily "patching" the board to analyze whether the ep capture delivers a discovered check, like in the example above (Bf6+ d4 cxd3+)? I can only imagine that you want to do that patch by removing the Pc4 and putting it to d4 so that d4-d3 would be a discovered check ... But that would restrict application of this code to giving diagonal or horizontal check while it would actually hurt when testing for a vertical discovered check.

If you really think that this patching simplifies the code (which I doubt since ep capture is a very rare case and doing straightforward things should be simple enough to address it correctly) then you could always use const_cast<> in C++, e.g.:

Code: Select all

bool Board::ep_capture_gives_discovered_check(Move const & m) const
{
#ifdef _DEBUG
    Board boardCopy = *this;
#endif
    const_cast<Board *>(this)->patch_forward_to_check_ep_capture(m);
    bool result = ...;
    const_cast<Board +>(this)->patch_backward_to_check_ep_capture(m);
#ifdef _DEBUG
    ASSERT(*this == boardCopy);
#endif
    return result;
}

The constness of the ep_capture_gives_discovered_check() method remains intact from the outside viewpoint but internally you do a temporary modification which you verify with an ASSERT() in the debug version. It is certainly a compromise ...

[dangi12012]

If you really think that this patching simplifies the code (which I doubt since ep capture is a very rare case and doing straightforward things should be simple enough to address it correctly) then you could always use const_cast<> in C++, e.g.:

Now i am really confused SVEN?

Code: Select all

const_cast<Board +>(this)

Is the plus in there a typo? How does this compile. Why would you ever ever ever have to cast 'this'?

[R. Tomasi]

Why would you ever ever ever have to cast 'this'?

Well, actually there are quite some situations where you would need to cast a this-pointer (think about CRTP or Barton-Nackman). In the code snippet here, it seems to be totally off, I agree. From the looks of it I would guess that the "patch_..." methods maybe aren't const such that the compiler would complain. The cast would fix the compiler-error, but may be quite dangerous, because the problem the compiler was complaining about hasn't gone away. The compiler was just told to shut up about it...

[R. Tomasi]

The constness of the ep_capture_gives_discovered_check() method remains intact from the outside viewpoint but internally you do a temporary modification which you verify with an ASSERT() in the debug version. It is certainly a compromise ...

Don't use const_cast for that kind of scenario. If from the outside perspective the instance remains constant, then you should investigate using mutable members instead.

[Ras]

Other pieces cannot be checking, because they would then already have been checking before the move.

What about discovered checks by pieces unrelated to the move?

And when you do have a distant slider alignment, and do the ray scan starting at the king

At that point, we are back to square one anyway, and have a lot of complicated code for corner cases like discovered check through en passant where the discovering piece is not even the moving piece, but the captured pawn.

However, I have another idea for a pretty simple speed-up of discovering checks in mailbox. In the middlegame, the kings are usually on the 1st resp. 8th rank so that there cannot be checks from behind. Arranging the check verification so that the "from behind" checks come last allows an early return in that case.

[dangi12012]

Other pieces cannot be checking, because they would then already have been checking before the move.

What about discovered checks by pieces unrelated to the move?

And when you do have a distant slider alignment, and do the ray scan starting at the king

At that point, we are back to square one anyway, and have a lot of complicated code for corner cases like discovered check through en passant where the discovering piece is not even the moving piece, but the captured pawn.

However, I have another idea for a pretty simple speed-up of discovering checks in mailbox. In the middlegame, the kings are usually on the 1st resp. 8th rank so that there cannot be checks from behind. Arranging the check verification so that the "from behind" checks come last allows an early return in that case.

I want to say that with bitboards you get a lot of this stuff for free (Literally a single and instruction). Including resolving all PINS. That is totally impossible with mailslots....

[hgm]

Other pieces cannot be checking, because they would then already have been checking before the move.

What about discovered checks by pieces unrelated to the move?

This must move over the from-square, and can thus only check when the from-square has queen-alignment with the king. This is why you have to test to-square and from-square. In the presence of hoppers (e.g. Xiangqi Cannon) you also have to test the to-square for hopper-alignment (in addition to alignment of the piece that would land there), as the moved piece could have activated the hopper.

At that point, we are back to square one anyway, ...

Sure, but the point is that you almost never reach that point.

..., and have a lot of complicated code for corner cases like discovered check through en passant where the discovering piece is not even the moving piece, but the captured pawn.

Well, this cannot be helped. E.p. capture is an intrinsically more complex move, as it modifies 3 squares instead of 2. Each modified square could in principle cause a check. Evacuated squares can cause discovered checks, occupied squares can either have the occupant check directly or activate a hopper. And squares that change occupant can have an effect, such as a Cannon that gets captured in Janggi, the capturer now acting as mount for another cannon (as Cannons are not allowed to jump over each other there).

Remember that the requested task was to determine whether a move delivers check before that move is made. So however you are going to do that, you would always have to supply code that can handle the case where both evacuated squares are still in the check path.

However, I have another idea for a pretty simple speed-up of discovering checks in mailbox. In the middlegame, the kings are usually on the 1st resp. 8th rank so that there cannot be checks from behind. Arranging the check verification so that the "from behind" checks come last allows an early return in that case.

It still seems you imagine a method of check verification where you scan away from the king in all possible directions. For delivering checks, or testing whether you expose your own king when not in check, this is not very competitive. There are at least 3 directions, and usually 5 or 8. (And then I even ignore knight checks!) So it is better to just test the few directions that lead to modified squares. Only when you start from a position where you already are in check you should account for the possibility that the pieces that were checking are still checking, when testing for legality. (And of course when the moving piece is a king, all these short-cuts are from the table.)

[hgm]

I want to say that with bitboards you get a lot of this stuff for free (Literally a single and instruction). Including resolving all PINS. That is totally impossible with mailslots....

That does sound a bit optimistic. What would you want to AND to determine wheter a move given as (fromSqr, toSqr) delivers a check?