Author: Oliver Roese
Date: 11:13:22 01/24/01
Go up one level in this thread
On January 24, 2001 at 00:24:23, Robert Hyatt wrote: >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_. > Sure, but is this a feasable start to implement knowledge? I dont think so. A human knows, that the above rule can be applied here, but nobody understands under which circumstances to do it in general. The famous Reti-Study is a convincing example. [D]8/8/5p2/8/8/2k5/K6P/8 w - - 0 1 Anotherone: -Draws with f- or h-pawns against Queens are known exceptions to the rule, but there are many variations of this theme, you cant catch with tablebases. I currently dont have access to my chessliterature to show such positions, but could do it later (and some more). Moral: If two passers are involved there is not much you can count on. Let me further state, that GMs can calculate much, much faster forced lines than normal players, so that they seem to "see" the solution sometimes. But as others already ponted out, it is unlikely that they feel the solution here. Oliver >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.