Author: Robert Hyatt
Date: 10:59:10 08/06/99
Go up one level in this thread
On August 06, 1999 at 10:58:54, KarinsDad wrote: >On August 06, 1999 at 09:24:40, Robert Hyatt wrote: > >>On August 06, 1999 at 00:55:40, KarinsDad wrote: >> >>>On August 05, 1999 at 23:02:00, Robert Hyatt wrote: >>> >>>[snip] >>>> >>>> >>>>that isn't the case I am looking at. I have a position that is a mate in 220 >>>>plies, or 110 moves. If I play it 'perfectly' I will make only one pawn move >>>>at move 90, but I will draw because at move 50 no pawn pushes have been played. >>>>In this position, I can push a pawn at ply=20, but if I do so, I won't be able >>>>to push it again until ply=130. And that is 10 plies too deep and again I draw >>>>if I push it at 20. But if I wait to ply 40 to push it, I can still push it >>>>again at ply=130, and now I am 'home free' with no chance of a draw, although >>>>the total mate is probably going to be much longer than 220 plies, since I had >>>>to avoid the optimal path to avoid the 50-move draws... >>>> >>>>That is the problem I don't see a way to solve, ever... >>>> >>> >>>Well, this problem cannot be solved with the current tablebases. >>> >>>And, since it cannot be solved with them, the best you can do is attempt to >>>accidentally find a solution. In the case you specify, the program would find a >>>potential solution at ply 20, but as it got further down the search, it would >>>find that this does not solve the problem and a draw will result. >>> >> >> >>maybe or maybe not. Remember that I do a search while probing egtb files. >>And this search is aware of repetitions and 50-move draws. So I won't blindly >>play a mate in N that actually is an instant draw... > >Of course you won't. Didn't mean to imply that you would. The tablebases are >only tools and anyone who blindly follows them without being aware of the >positions that have occured in the game or how many moves since the last capture >or push are begging for a draw. > >> >> >>>The problem you specify could be solved with a tablebase that had win preserving >>>moves (for 50 move rule only) in it. The reason is that a win preserving move by >>>definition is one that resets the counter and leads to mate. It does not matter >>>how many moves down below it the mate occurs since you know by definition that >>>somewhere down the 100 ply you will either mate or you will find another win >>>preserving move. Note: a win preserving move would have the distance to reseting >>>the counter, not the distance to mate. >> >> >>the problem is not "this move preserves a win because there is a useful capture >>in 35 plies from this point"... the problem is that between here and 35 plies >>into the future there are a _lot_ of positions. And any of them could repeat >>a previous position that we have already passed twice... > >Yes, but it is EASY to search down any given path and check this. I bet that you >have Crafty doing that already for mate in n (obviously not for win preserving >moves). > It is a _long_ way from easy. The path has to go at least 100 plies beyond the first capture/pawn push to make sure you won't run afoul of the 50 move rule down that path. And to search that path is just a perfectly normal search, which translates into _impossible_ to do... The databases don't contain trees, they just contain a score for each possible position that can be reached... and I don't see any way to fold in the 50-move rule because of this... hence the other thread and DTC scores... And even that won't work if the computer has to 'take over' a position played by a human, because then you can't assume optimal play since reaching a database win, and at that point, the 50 move rule is death to any sort of probe... >> >>I think the 'path' problem is simply impossible unless the program is able to >>search the game from the beginning, all by itself. If we expect the computer >>to take over a human-played game at some point, it is _always_ going to make >>such mistakes... > >The path problem is virtually identical to the storing the position in 20 bytes >problem in this regard. You need a history to truly avoid the draws. We had a >lot of discussion on draw by rep and 50 move rule here on this forum on the >storing the position issue and someone finally realized that this type of state >information is unrealistic when storing. Suddenly, everyone's algorithms could >store in smaller sizes. > >Well, I guess we beat this horse to death. > >KarinsDad :)
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.