Author: Vincent Diepeveen
Date: 15:31:25 01/20/01
Go up one level in this thread
On January 20, 2001 at 17:56:51, Robert Hyatt wrote: This is no argument Bob, 6 weeks ago or so i outcommented special passer code so diep doesn't care for anything with regards to passers currently in the far endgame. I'll have it fixed within a few weeks. I solve some tactical shots now fast with diep now with extra extensions. Improving passer code and finding those positions faster is next obviously. Note also one thing in king safety is dead wrong and completely misevaluated in such a way that i can lose games because of it. I wonder why i so far hardly saw games lost because of it. >On January 20, 2001 at 16:54:33, Vincent Diepeveen wrote: > >> >> >>On January 19, 2001 at 21:27:52, Uri Blass wrote: >> >>>On January 19, 2001 at 19:44:49, Vincent Diepeveen wrote: >>> >>>>On January 19, 2001 at 17:23:03, Scott Gasch wrote: >>>> >>>>>Hi all, >>>>> >>>>>Here's a pretty simple test position. This comes from the WAC suite... my >>>>>engine does fairly well on this suite as a whole but seems blind to this >>>>>solution. >>>>> >>>>>[D]8/7p/5k2/5p2/p1p2P2/Pr1pPK2/1P1R3P/8 b - - >>>>> >>>>>The solution is Rxb2 -- black's connected passers are unstoppable after the >>>>>recapture. >>>>> >>>>>My program refuses to find this solution... even at 9 ply it misses it. The >>>>>strange thing is that from the other side after Rxb2 it sees that white is toast >>>>>very quickly... score dropping to -500 or so after about 1 second. >>>>> >>>>>My question is, of course, how this move is missed. I've tried kicking up the >>>>>value of connected passers and passed pawns in general. I've tried adding a >>>>>special rule to eval about connected passers on the 7th, on move, with control >>>>>of a queening square. I've tried cutting back my futility margin in qsearch and >>>>>always extending a full ply for checks (It usually extends only 3/4 ply for >>>>>checks after the iteration depth). And still it does not find Rxb2. >>>>> >>>>>Even stranger is if I run a static eval with the two connected passers rolling >>>>>towards the queening square after the rook exchange the eval puts black ahead! >>>>>I can't seem to figure this out... either my pruning is too aggressive or there >>>>>is some other bug in the engine...? >>>>> >>>>>I hope someone out there can give me a little advice. Thanks! >>>>> >>>>>Scott >>>> >>>>First of all this combination is not 9 ply but something >>>>like 14 ply. >>> >>>The number of plies is dependent on the evaluation function and on the >>>extensions and pruning rules. >>> >>>If the evaluation function knows that the following structure is good for black >>>then you do not need a lot of plies >>> >>>[D]8/8/5k2/8/8/2ppPK2/1R6/8 w - - 0 1 >>> >>>The white pawn at e3 is of course important in this structure because it blocks >>>the white king. >>> >>>The program should know that without the white pawn at e3 the structure is good >>>for white. >>> >>> >>> Most programs solve it incorrectly at small depths as >>>>they don't evaluate kings stopping passers or because they just >>>>give huge scores for doubled passers. >>> >>>I think that most programs do not solve it at small depthes. >>> >>>Uri >> >>You are right about the e3 pawn. This is the ONLY reason why >>it wins for black. See the evaluation for many programs of this position >>without the pawn on e3 and you'll see they statically evaluate it as +2.0 >>for black or something similar. >> >>+3.0 for each passer, 1 pawn more minus rook is +2.0 to roughly >>do the math. >> >>Of course search depth depends upon what you do in qsearch, >>selective search, whether you extend all checks or not >>and whether you have passed pawn extensions not to mention >>threat extensions. >> >>So nowadays i solve this at i think 10 ply or something because of >>the extensions, but i only solve it tactically; so i see >>that i get a queen with black and not evaluation is solving it. >> >>What i find wrong are programs that solve this position positionally. >>No evaluation takes into account the e3 pawn i'm 100% sure of that. >>I don't do it in DIEP either. Because what if it's on e2 and someone >>attacks e3? >> >>There are zillions of possibilities, but a prog simply shouldn't >>solve this without seeing it the pawns promote to a queen! > >You should look at the game last night between crafty and diep before you >say that... If you wait until you see a promotion, you are going to get >killed. I'd rather say two connected passers on the 6th win and be right >90% of the time, rather than not saying that and being wrong 90% of the >time. > >On the other hand, you are evaluating isolated pawns at a ridiculously high >rate. I watched a game where you had pawns on the gh files (2) and Crafty >had pawns on the f and h files (3). You thought you were over a pawn ahead, >and got zapped for thinking that. > >I don't think _any_ evaluation is right 100% of the time. I am pretty >convinced mine is right more often than it is wrong, and getting more accurate >all the time. > > > >> >>Even worse as this is the gs2930 testset, where programs can >>give away pawns for nothing! > >I don't give away pawns for _nothing_. :) > > > >> >>Greetings, >>Vincent
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.