Author: Robert Hyatt
Date: 07:04:39 11/10/01
Go up one level in this thread
On November 10, 2001 at 04:50:09, Guido wrote: >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? > NO. You are still missing the key case. Is an EP possible in the future, not just right now? But what about positions where white has a pawn on e2, and black has a pawn on d7. Any mate-in-N will be wrong if your generator didn't do any EP captures, because there will be many positions where an EP will be possible _somewhere in the future_. And yet your generator produced scores think that if it gets the black pawn to d4 and white plays e4, that black can't take the white pawn. That greatly changes the position. And means any analysis based on positions where EP is _ever_ possible will be wrong. >>> >>>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. Your explanation of my "encoding" was correct. It makes the tables bigger since there are now more possible pawn states. ie e4/d4 no EP possible and e4/d4 where EP is legal. Castling introduces the same problem. But it can trivially be ignored since it just doesn't figure in when you get down to 5 pieces left. > >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.