Author: Robert Hyatt
Date: 09:33:29 10/14/98
Go up one level in this thread
On October 14, 1998 at 09:08:16, Robert Hyatt wrote: >On October 14, 1998 at 08:22:53, Moritz Berger wrote: > >>On October 14, 1998 at 05:09:20, Bruce Moreland wrote: >> >>> >>>On October 13, 1998 at 20:30:03, Robert Hyatt wrote: >>> >>>>ok... what I missed is that the game wasn't ended where the pgn/analysis >>>>ended... it ended in KRN vs KR... can you post the complete PGN? This >>>>would certainly have been handled differently with that database handy as >>>>it would have avoided trading down to a draw if possible... >>>> >>>>whether it could have won is another question entirely, of course... >>> >>>The PGN is all there, and there is analysis all the way out to the end as far as >>>I can tell. >> >>Maybe you had problems to import the PGN linebreaks from CCC into Crafty? The >>PGN was complete, as Bruce pointed out. >> >>Moritz > > >I think I imported from the wrong post here... Crafty can read that annotated >kludge ok, but the last move in the file I grabbed was where the eval went from >+2 to +6. There were *many* moves after this, but not (apparently) in the post >I snipped from... which is why I was confused... > >Bob Here's where this magic +6 comes from in KRN vs KR. I count the knight as +3, plus some positional stuff, probably .5. My trade bonus is in full force here, which adds 1.5 pawns to the score for being ahead a piece and having almost all material off the board (there is a penalty factored into the +1.5 already because it wants to keep pawns on the board). The reason I haven't taken the step of calling this a draw in the eval is that I've not seen this, because I have had KRB vs KR and KRN vs KR for as long as I have had tablebases, so that I *never* get to evaluate these positions. I would be most hesitant to evaluate this at interior nodes and stop the search outright, because there are wins in this position, and the recognizer would have to understand all the special cases and check for them. So my "Drawn position" recognizer doesn't touch this one (although it will, now) since I never get to see this in the evaluator. In Crafty, I catch such positions in the eval, because it makes life easier (ie KR vs KR is not *always* a draw.) because I can let the deep search find if it is possible to win the opponent's rook, and if it can't by the time I reach the endpoints, I can safely say "draw" there. Ditto for KBP* vs K where the king reaches the queening square first when all the pawns are on the same rook file. I don't recognize this at interior nodes because it is tricky, and at times there is exactly one path to the drawing square, along a diagonal, and the opponent's rook covers one square making the draw just unreachable. So I let my search have a crack at getting the king to the right square where I can trivially say "this is a draw." But, there are many such positions where crafty will likely screw up without tablebases, because if I have 'em, I don't see the results without 'em and leave an occasional hole. This is why I don't solve KB vs KB for those oddball positions where it is a mate, because I do catch these with the interior recognizer, and it doesn't even look at potential mates. I'll likely move this from interior to leaf recognizer to solve this one...
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.