Author: blass uri
Date: 02:58:16 04/04/00
Go up one level in this thread
On April 04, 2000 at 01:32:29, Jeremiah Penery wrote: >On April 04, 2000 at 00:00:41, KarinsDad wrote: > >>It occurs to me that the example that Jeremiah gave us in that thread could >>still result in a loss for the KNP side of KNNPKNP. For example (and I did not >>check this with tablebases, I am making an illustration here and hopefully, I >>set it up correctly): >> >>[D]8/n1PK3p/k6N/8/6N1/8/8/8 w - - >> >>Now, even though this may result in a mate for white after c8(Q)+, it may take >>more than 50 moves to do it. However, the idea is that the knight at h6 could >>blockade the pawn until about move 40 or so, then it could come attack the king, >>then when the pawn is pushed, it could go back and blockade again for a moment. >>The 50 move counter would be reset since the pawn was pushed and then the knight >>could come back to attack the king again. >> >>Now, this probably does not work for this particular example. I just put it here >>to illustrate the idea. >> >>But it seems to me that the BEST play would take into account the 50 move rule >>COMBINED WITH the shortest mate, even if that takes longer due to reseting the >>50 move rule counter. >> >>If there are examples of this occuring within the tablebases (and I do not know >>that for a fact since I do not have them), it would appear that the tablebases >>are in reality a good tool, but a partially flawed tool (since it would be >>extremely difficult for a program to determine that it is time to attack the >>king with the knight, and oops, it is time to head back and blockade the pawn >>again). >> >>KarinsDad :) > >I really need to try and find the relevant position from the game... > >Anyway, I know the Nalimov TBs do _NOT_ take into account the 50-move rule. I >remember when someone posted a game and asked for analysis, to show whether >black had a win or not, it would end up in a KNNKP which would be won in ~80 >moves. However, the 'optimal' mate fell victim to the 50-move rule. > >It's possible that the program could simply be programmed that once it got near >the 50-move barrier in a TB endgame, it would resort to search, trying to find a >move that resets the counter while still remaining in a won position. Such a >thing may not bee all too difficult to program, and it could help a lot, >especially when _very long_ mates are possible, as in the new 6-piece TBs. I do not think that it can help a lot because cases when there is a very long mate are not common except endgames with a pawn advantage like KQP vs KQ but in these cases the shortest mate usually has some pawns pusehes so there is no 50 move rule problem. Very long mates are possible in the new 6-piece TBs but I do not think that they are common because 6 piece endgames with no pawns are not common. I think the right way is to do a different tablebases of distance to conversion and not distance to mate. Starting to search after almost 50 moves with no pawn move is not going to help much because I think that in most of the cases it is going to be too late and often the problem is in the first place when the mate in 100 is practically a draw by the 50 move rule. 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.