Author: Robert Hyatt
Date: 17:33:38 10/13/98
Go up one level in this thread
On October 13, 1998 at 19:22:14, Roberto Waldteufel wrote: > >On October 13, 1998 at 17:42:25, Robert Hyatt wrote: > >>On October 13, 1998 at 16:14:41, Tim Mirabile wrote: >> >>>On October 13, 1998 at 12:13:21, Bruce Moreland wrote: >>>> >>>>Why did Crafty allow KQ vs KR against any of these? Didn't it see this as a >>>>forced mate and try to do something to avoid getting into it? >>>> >>>>The only time I can remember being on the weaker side of KQ vs KR was one of the >>>>rare cases that really is drawn (queen stalemates my king, so my rook goes wild >>>>checking their king from one square away). >>> >>>This is bad practice vs. humans though. A couple of days ago I had a better R+P >>>ending against one of the crafty clones on ICC, and the only way to try to win >>>was to go into a Q vs. R ending, which I would likely not have been able to win >>>at blitz. But then the thing just refused to take my rook, giving me a Q+R vs. >>>R ending instead. Has anyone thought of a way to fix this kind of thing yet? >> >> >> >>yes... you need KQRKR database, which I have. :) then that just pushes this >>nonsense off a little further. The opposite is to be in a KRPPP vs KR and >>*force* the opponent to take two pawns leaving a won KRP vs KR. :) > >I wonder to what limits we might push the tablebases. Suppose you have, say, the >stronger side of KRPPKR, and suppose that you construct two simpler positions by >removing in turn each of your pawns. These two simpler positions are KRPKR >positions, so you can look up a score for each of them in the KRPKR tablebase. >Suppose that one (or both) of them is winning for you. How often is it then the >case that the additional extra pawn can change this result. I am exploiting an >underlying assumption that if you take any winning KRPKR position and give >yourself an extra pawn on an arbitrary square, the position is still winning. If >I push this a stage further, I might guess that the best move in the KRPKR won >position would, if it is legal, also win in the KRPPKP position as well. If this >were the case, the program could extend the tablebases beyond their actual >scope, and at the same time perhaps cure the problem of the silly moves where a >program throws away material, albeit to reach a won tablebase position, as these >moves are inefficient and have a rather bad asthaetic effect. > >The big question is how often the above hypotheses hold. If they fail often, my >proposal is rubbish! How could the addition of an extra friendly pawn, or it >could even be a piece, spoil an otherwise winning position? Possibly due to >introducing stalemate possibilities, or by blocking a square necessary for one >of the other pieces perhaps. It would be interesting to know how rare (or >frequent) such cases are. If they are very rare, it might pay off to take the >risk and terminate the search in such positions. > >I can think of a test for this kind of reasoning you could easily do if you have >all 4-piece endings. Try, for example, comparing KPPK and KPK tablebases (like >the orriginal example, but without the rooks). Since you have all the data for >both cases, you could search through all KPK positions, and for those that are >wins, try adding another pawn on all possible legal squares. Can you find any >drawn KPPK positions in this way? If there are none, then you could make >inferences about the outcome of many KPPK positions from the KPK tablebase. >Maybe we could score many KPPKP positions bases on KPKP database. If you try >this, please let me know the results. > >Roberto interesting idea of course.. although crafty solves it by tossing the pawn when it can convert to a won KRP KR, which still wins. It will also toss a queen in KQRP vs KR to reach a won KRP KR ending. It will even toss *two* queens... etc.. :)
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.