Author: Ricardo Gibert
Date: 13:36:40 08/03/99
Go up one level in this thread
On August 03, 1999 at 16:00:21, Dann Corbit wrote: >On August 03, 1999 at 15:33:10, Ricardo Gibert wrote: >[snip] >>1. Instead of >> distance to: mate >> >>2. Better is single number representing >> distance to: mate OR win preseving capture OR win preserving pawn move >> (whichever comes soonest) >> >>The 2nd way you ALWAYS win a winnable position. I find it hard to believe >>Nalimov did his EGTB the way you assert (The 1st way). There is nothing I can >>think of that would make the 2nd way listed above significant more difficult to >>do. There is no good reason, I can think of, for using the 1st way in preference >>to the 2nd one. >> >>I hope this is more clear, otherwise, I give up. >How can this be done without the state of the current game information? E.g., I >may have gone 49 moves without a capture -- but we clearly can't make the >tablebase files 50 times their current size and still have them be practical. >Further, I may have repeated an exact position twice already. The number of >ways this can be permuted is nearly infinite [well, *really, really* big >anyway]. Obviously, that data cannot exist in the tablebase, since it will be >different for each game. Hence, it should be the calling program's >responsibility to make any such resolutions. In computer chess games, I think >it is less of an issue, since they don't have to adjourn very often. Example: I prefer to have the information that I can win by capturing a rook in 3 moves to mate in 10. It handles the 50 move rule problem just fine, since it seeks to play winning pawn moves or captures as soon as possible. The real problem case is 3-fold repetition, which is always a problem whichever way (1 or 2) you use. As you said, "it should be the calling program's responsibility to make any such resolutions." The EGTB should be used by the computer as a tool to that end. "Part" of eval. Yes? > >A possible solution: >Upon rejoining the game, load the current PGN into memory and look for move >count since last capture and also every board position that has been achieved. > >Then, trace through the suggested trajectories in the tablebase and see if they >violate the moves without capture rule or the repeated position rule. If they >do violate one or the other rules, then search for a position that still wins, >is achievable, and does not violate the rule. Trajectory may be very long. > >Again, this would have to be the responsibility of the program because this much >possible state information data could not be stored in a tablebase using current >technology. >IMO-YMMV. >[snip]
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.