Author: Robert Hyatt
Date: 21:24:23 01/23/01
Go up one level in this thread
On January 23, 2001 at 13:45:24, Gerrit Reubold wrote: >On January 22, 2001 at 16:02:56, Robert Hyatt wrote: > ><big snip> > >>The problem is endgame knowledge. A program _ought_ to know that if you have >>a passer, then trade pieces to reach a won ending. Only in this case, that >>heuristic back-fires as it is black who ends up winning. This is a _tough_ >>exception to handle... >> >>although a GM would tell you instantly "No I won't trade queens..." > >Hello all, > >I think stating that a GM would know instantly that trading queens lose is >misguiding. One tempo decides whether the queen exchange loses or wins. Both a >GM and a chess engine should calculate here and not simply trust their >evaluation. Of course, "tell you instantly" could mean that the GM did the >calculations unconsciuosly and super-fast, but I don't think it was meant this >way. > I calculated it like this: 1. remove queens. it is now white's move. Can white force those connected passers in? not quickly. 2. what about black's b-pawn? Can white stop it? no. moral: don't trade queens _yet_. Crafty understands how to 'count squares' to see if a pawn can be caught or not. It just doesn't yet know how to apply that to 'candidate passers' since it costs a couple of tempi to make the passer, then more to run it in. >Consider the following changes to the position after blacks 45.th move: > >(a) if the black a-pawn were on a6 instead of a5: 46. Qe6+ wins, but it is not >obvious. >(b) if the white King were on g2 instead on h1: 46. Qe6+ wins, even less >obvious. these are easy (obvious) to me. just ask "can the king reach the queening square of the b pawn or not?" Programs do this all the time. The problem is the tempi lost in producing the passer + the tempi required to actually promote the pawn. But I could visualize lots of other positions with the white king in what looks like a great place supporting those central passers, only it ends up being just out of range to stop the b-pawn. I did spring this on a GM today and asked "what do you think of Qe6?" after a couple of seconds "it loses... white needs to improve his king first or the b pawn is a problem." most of the delay was probably typing delay I'd guess... > >I hope my analysis is OK, I have no chess board or chess engine at hand to check >it, but the variations should be simple (if I remember my analysis of yesterday >night correctly). > >Of course it would be nice when the evaluation "sees" that the black b-pawn is >dangerous, but IMO the search *must* verify that. Too much guessing might be >harmful :-) > >Maybe the evaluation should guide the search, e.g. when the evaluation sees that >there is a dangerous passer in a pawn endgame, it could tell the search to >extend moves of this passer. It would be easy to extend this to candidate >passers, or to the candidate passer's neighbour pawn, or ... >(BTW: in the middlegame: when the eval detects king safety problems, it could >guide the search to exploit them... nice!) > >The "eval-guides-search"-idea is certainly not new and more likely than not just >one of the ideas which *don't* work, but I think I will try it in my engine. > >Now it becomes slightly off-topic: >That "eval-guides-search"-thing seems to be the way humans solve this kind of >position, they know that the b-pawn is dangerous and don't care about black >moves other than moving the dangerous pawn and its helper (the a-pawn). You have >surely seen humans "analyse" these positions: they count 1 (a4), 2 (b3), 3 (b2), >4 (b1=Q) and since white needs more than 4 moves to promote a pawn, black wins. > >Hope this makes sense, > >Greetings, >Gerrit
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.