En Passent

[cms271828]

Hi, whats the best way of tacking en passent during a search.

I guess its simpler than castling since only 1 pawn at most will be capturable by en-passent for any given position.

Thanks

[sje]

Examine the move that was just made:

If the move was a pawn move, and

The absolute value of the movement distance was two ranks, and

There's at least one adjacent enemy pawn, then

Set the en passant target square to the crossed over square, else

Set the en passant target square to nil (-1).

[Zlaire]

En passant doesn't have anything to do with the search. En passant is a part of your move generation and once it's done you don't have to worry about it in your search.

You really need to separate the different parts a chess engine consists of before moving on... I know you got the same advice when asking about the transposition tables a month or two ago. And you got the same advice. Close one part of your engine before opening the next one.

En passant should be an obvious part of your move generation, and if it's not done, you're not done with your move generation and should not start worrying about the search.

[cms271828]

I think thats probably true when it comes to adding TTs, and other things.
But I don't see any problem with adding castling and en-passent to a basic program (Negamax-using rotated bitboards, without QS, TTs, Killer moves etc.etc.) that runs perfectly fine without them.

For castling, I just made changes to move generator, and then to the make_move and undo_move bits, as well as using a castling value which starts the game at 15 and is modified each move.

For ep, I see I can just do the test for ep by looking at the last move played, theres not much to it, except that in the make_move and undo_move, I will have to write code to deal with it specially as I'm capturing on an empty square.

I personally think if you had to write parts of a chess engine completely before moving on, you would get more problems.
I prefer to build the whole thing up slowly, continuously testing it, then adding parts, then testing.

But I agree that this wouldn't be a good idea when it comes to the more complex matters like TTs.

Thanks

[bob]

En passant doesn't have anything to do with the search. En passant is a part of your move generation and once it's done you don't have to worry about it in your search.

You really need to separate the different parts a chess engine consists of before moving on... I know you got the same advice when asking about the transposition tables a month or two ago. And you got the same advice. Close one part of your engine before opening the next one.

En passant should be an obvious part of your move generation, and if it's not done, you're not done with your move generation and should not start worrying about the search.

there is a search component of this however. One has to make the right kind of move to enable en passant captures, and the right to make the capture exists only on the next move. So the search has to be responsible for setting/clearing this outside of the move generator itself...

[hgm]

My standard Make() and UnMake() use different variable for the ToSquare (where the moving piece goes) and the CaptureSquare (where the enemy piece disappears). Normally the CaptureSquare is set to the same value as the ToSquare.

MakeMove() starts with a code section for treating special moves (recognized by flags set by the move generator), which is normally skipped over, but catches Pawn double moves, castlings, e.p. captures and promotions. For castlings it moves the Rook, for promotions it replaces the Pawn on the board and in the piece list by the new piece. For Pawn double moves it tests if there are enemy Pawns next to the To Square, and if there is it sets the e.p. square variable for passing to the next Search() call and works the e.p. status info into the HashKey. (This is still not fully correct as even though there are enemy Pawns, e.p. capturing with them might be an illegal move. But for rep-draw recognition there are worse problems than this.) The board updates of the other special moves are also reflected in the HashKey.

In the case of an e.p. capture the CaptureSquare is shifted through an XOR operation. (This has no direct effect on the HashKey.)

After that, can apply the same code as for normal moves, to update the HashKey, probe for repetitions and probe the transposition hash, perform the move.

For UnMake, after the normal part, only the castlings and promotion need special undo code. Pawn Double move and e.p. are handled by the standard code.