Author: Guido
Date: 01:50:09 11/10/01
Go up one level in this thread
On November 09, 2001 at 14:00:29, Robert Hyatt wrote: >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. > In conclusion we can say that with my procedure are correct: - All the positions where ep is in any way impossible - All the position where ep is immediately possible and no more in future. So remain uncorrect all the position where in future ep capture would be possible. But at this point the correct computation procedure could be the following: - Compute EGTBs considering always ep capture. - If EGTBs are interrogated for a position where ep is apparently immediately possible, chose the EGTB result if ep is actually possible (i.e. last move is a pawn move that authorize ep capture). Differently execute all the possible move without ep capture and chose the best (inverted) result, than return this result if EGTBs with ep capture give a better result. Is this procedure correct? >> >>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. > In this way: - The dimensions of EGTBs with at least two pawns increase, as each pawn would generally require 48+8=56 cells instead of 48 as in my tables. - It seems to me that also in this case the error you found to my argument is maintained. The rule must be the ep capture right, the exception is an ep position where there is no ep capture right. So I would have put in e1 (exception) the e4 pawn when ep capture is not possible, and in e4 in the other case. But this is only a convention: the important thing is the way in which the computation is done in the two cases. I hope not to have said nonsense. Guido Guido (I forgot my signature in the last message to Uri)
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.