Author: Guido
Date: 14:00:32 11/09/01
Go up one level in this thread
On November 09, 2001 at 07:58:00, Uri Blass 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). >> >>- 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. >> >>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. > >castling right also disappear after execution of the current move if the castler >has only king and rook. > >> >>How do Nalimov's EGTBs solve this problem? >> >>Guido > >I think that the simpler solution is simply to build special tablebases for >positions when castling is legal. > >It seems to me to be simple when you can use the existing tablebases because the >number of relevant positions is small and future positions when castling is >illegal are in the tablebases. > I think that in this case it is necessary to have files where each position, when castling is legal, must be transformed in an hash value, used as an ordering key, because indexing algorithm is no more possible, or alternatively one must keep the complete file and make positions illegal where castling is not allowed. Moreover in the most general case 2^4 = 16 different files are necessary as 16 are the different castling possibilities (one file is obviously without castling). But IMHO the more difficult problem is the connection between positions in the files, where castling is legal, with positions in the normal file, where castling is not allowed. Files must be generated in a precise order: for example if both players have castling rights in krkr ending, when white moves the new positions must be searched in the file where only black has castling right, so this file must have been generated before. This order in the generation is similar to that required for usual EGTB, where in the easiest example of kpk ending generation, it is necessary to have before generated kqk and krk. I never tried to write any instruction about this problem, so I don't know if this idea is right. >I suspect that building all the 4 piece tablebases may take more time then >building the 5 piece tablebases when castling is legal and writing the program >that generates the tablebases for positions when castling is legal may take more >time than really generate the tablebases. It seems that you agree with me about the difficulties to write a similar program... > >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.