Author: Colin Frayn
Date: 02:19:33 08/06/00
Go up one level in this thread
On August 05, 2000 at 06:47:04, Ricardo Gibert wrote: >>This position came up in a game I just played between ColChess (Development >>version) and Sjeng v7.1. >> >>[D]8/R7/8/8/7P/6P1/3k2K1/2q5 b - - >> >>ColChess, as Black, has to move, having just promoted a pawn to a queen, and >>then white played a rook move (Ra5-a7). >> >>This looks like it should be an easy win for black, but in the game ColChess >>just moved its pieces around aimlessly and drew by repetition. This annoyed me >>quite a bit so I tried this position at longer time controls and sure enough it >>still couldn't see anything. Then I tried it with Crafty and still nothing. >> >>Is this one of those positions where it's drawn and humans (if they're better >>than me) can see it easily but a computer can't? If so then I'd better fix >>ColChess' evaluation function before release so that it doesn't exchange off >>(from a stronger position it sac'd its rook to promote the pawn) > >On the other hand, there may be another reason why your program should not have >played into this line that _is_ fixable. Why not post the position before the >sac and see how other programs handle it? OK I couldn't find the game, but I think this was the position 2 moves before, followed by Ra5 Rxa5 c1=Q Ra7. [D]8/8/8/2R5/7P/6P1/r1pk2K1/8 b - - It looks almost better to have a lone rook against the 2 pawns, i.e. by playing c1=Q Rxc1 Rxc1 or something. Crafty certainly prefers this. Of course, I might have the position wrong, but it was certainly very similar. I think, as was said, it may be that ColChess values queens too highly in certain endgame situations. However, in general I value a queen as better than 2 rooks in an endgame, which I think is justified. Cheers, Col
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.