Author: Robert Hyatt
Date: 11:00:29 11/09/01
Go up one level in this thread
On November 09, 2001 at 04:57:20, Guido wrote: >On November 08, 2001 at 17:58:14, Robert Hyatt wrote: > ><snip> >> >> >>How do they avoid it? By not probing if castling is legal? That is a >>solution that is easy to add. But the tiny cost is absolutely wasted as >>no 5 piece position with castling still possible will ever occur in any >>real game... > >I agree with you that castling is so rare in an ending that it is useless to >keep castling into account in EGTBs. > >Moreover I thought a lot about the problem but I didn't find any practical >possibility to solve it. This depends on the fact that generation of EGTBs >considers each position statically without memory of previous or existent rights >(castling and ep). >Also IMHO the best thing to do for castling is to avoid using EGTBs when >castling rights are active. > >For ep the situation is similar, but, first of all, it is not uncommon in an >ending, and secondly it is possible to solve the problem in this way: > >- Generate the EGTBs without ep right. > >- When the chess program sends a request to the function that interrogate EGTBs, >it transmits also an ep flag set to the number of the cell where ep capture can >happen (0 otherwise). I did this with the original kpkp files from Steven Edwards. They didn't support EP. It was necessary to check, before probing, and _never_ probe if EP is possible or ever will be possible, starting from the current position. IE if pawns are on two adjacent files, then if one pawn is on its original square, you can _not_ probe the database until that pawn leaves its original square and no EP is possible after that move... > >- This function calculates the result without ep, then executes the ep move (or >2 moves), evaluates the position and inverts the result, and sends back the best >result. That won't work. Because the mate in N analysis assumes that nowhere in the future, beyond this position, will an EP capture be possible. So you had better not probe unless you force this constraint. > >IMHO this procedure is not theoretically exact and could fail when many pawns >are present, but in practice it works fine because EGTBs cannot have at present >more than 3 pawns (kppkp), and the ep right, unlike castling, disappears after >the execution of the current move. > >How do Nalimov's EGTBs solve this problem? They encode positions with EP possible separately from the same position with no EP possible. And they do understand EP is the result of the previous move advancing a pawn two squares and passing an enemy pawn on an adjacent file. I am not sure, but one way to encode these would be to use some illegal pawn squares (say pawns on the first rank) to indicate positions where an enpassant capture is possible. IE a white pawn on e1 would represent a white pawn on e4 that just advanced two squares. This would let the normal positions with a white pawn on e4 be separated from the special one-move case where the pawn just advanced 2 ranks in one move and is subject to an EP rip. > >Guido
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.