Author: KarinsDad
Date: 07:58:54 08/06/99
Go up one level in this thread
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). > >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.