Author: Oliver Roese
Date: 11:19:38 01/24/01
Go up one level in this thread
On January 24, 2001 at 14:13:22, Oliver Roese wrote: >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. This diagram shows a problem with counting squares, however is her at the wrong place. >[D]8/8/5p2/8/8/2k5/K6P/8 w - - 0 1 This is the famoust study of the world (at least i think so) i supposed to post. [D]7K/8/k1P5/7p/8/8/8/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.