Mailbox move gives check routine

[Sven]

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.

It compiles without the typo ...

[Sven]

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...

Yes, I wrote in the text above my code snippet that there might be a desire to patch the board before testing whether an en passant capture gives check. I also wrote that I would not solve it like that since I think that it can be solved in a straightforward way that does not modify the board. But regarding const-correctness it would be "correct" in the sense that the method that internally does a temporary modification of the board by "const-cast" still guarantees to its users that it leaves the board intact in the end. Yes, dangerous, but chess programming is intrinsically dangerous

[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...

Yes, I wrote in the text above my code snippet that there might be a desire to patch the board before testing whether an en passant capture gives check. I also wrote that I would not solve it like that since I think that it can be solved in a straightforward way that does not modify the board. But regarding const-correctness it would be "correct" in the sense that the method that internally does a temporary modification of the board by "const-cast" still guarantees to its users that it leaves the board intact in the end. Yes, dangerous, but chess programming is intrinsically dangerous

It's probably more a matter of style than anything else, but you can get rid of the need for the const_cast by using mutable members. It's not less dangerous, though. For the sake of argument let's assume you have a board class with a method that determines if the position is a check. That might be expensive to calculate and be called multiple times on the same instance. An idea might be to store the result of that function internally in the class, along with a flag indicating whether the "cached" result is valid. From outside of the class this is a constant operation (checking for check does not change the board state). But since the result is cached in class members, it's not a constant operation from the compiler's perspective. Declaring the flag and the cached result as mutable will allow to still declare the method as const without the compiler complaining.

[dangi12012]

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?

That comment was about "discovered check". Which is the same as a pin. But allowed.

[hgm]

Even so, I still don't see how you would determine whether a given (fromSqr, toSqr) would deliver a discovered check with a single AND.

[Ras]

Remember that the requested task was to determine whether a move delivers check before that move is made.

Ah, that's what I got wrong.

It still seems you imagine a method of check verification where you scan away from the king in all possible directions.

Yeah, that's what I do - after doing the move. Makes the coding much easier. However, this thread got me thinking, so I implemented it with mostly before-verification. Perft speeds up by 30%, and the overall speedup is around 4%. Where it really hits in is the mate searcher mode, that gains 20%.

I want to say that with bitboards you get a lot of this stuff for free

Yeah, but when I originally started out, there wasn't even a single bitboard engine that would have had any hope of being ported to a microcontroller with 192kB RAM. I think it's mostly because of the attack tables.

[hgm]

I can still add that in the case where a neighbor table is available, the ray scan can be replaced by a distance lookup to see if the to- or from-square actually connect to the king. In that case you would tabulate a direction number instead of a unit step in the static table.

Code: Select all

int direction = dirNr[toSqr - king];
int nearest = neighbor[king][direction];
int dist = distance[nearest - king];
inCheck = (distance[toSqr - king] <= dist);

For the discovered check you would not even have to look up distances, but just test whether the from-square was the neighbor:

Code: Select all

int direction = dirNr[fromSqr - king];
int nearest = neighbor[king][direction];
if(nearest == fromSqr) {
  nearest = neighbor[nearest][direction]; // next-nearest neigbor
  int piece = board[nearest]; // look what it is
  inCheck = (piece & sideToMove) && (captFlags[piece] & captMask[nearest - king]);
}