Author: Peter McKenzie
Date: 13:20:33 09/19/00
Go up one level in this thread
On September 19, 2000 at 14:34:47, Robert Hyatt wrote: >On September 14, 2000 at 22:41:07, Robert Hyatt wrote: > >>On September 14, 2000 at 18:55:51, José de Jesús García Ruvalcaba wrote: >> >>>On September 14, 2000 at 18:44:03, Robert Hyatt wrote: >>> >>> >>>>>8/8/p2k3p/1P1p1pp1/P1r5/1R1K1PP1/7P/8 b - - >>> >>>> >>>>Yeah, right. Another reason to "love" netscape. When I did a cut and >>>>paste, it somehow didn't copy the entire FEN string. Leaving black with >>>>another pawn on the queenside that changes everything. Without the extra >>>>pawn it isn't hard to see (IMHO)... ie it is exactly what happens after >>>>an outside passed pawn has been used to decoy the enemy king away too far. >>> >>> But what does crafty think of this position? >> >> >>As I mentioned in another post, crafty has a "hole" here. IE if you move >>the black king one square from where it is, and put a white pawn on that >>square, the static eval says "white wins" because of the distant passer. >>But the instant the distant passer evaporates, the term goes away. In >>normal positions, this doesn't hurt a lot as by the time it has to give >>up the passer it can see that it wins pawns on the other side. But here >>it isn't so easy as black has a few horizon moves to throw in at key times. >> >>I almost have this fixed, finally, which will likely let it find a5 almost >>instantly since king moves lose and the axb5 evaporates the queenside with >>white's king too close to stop on the kingside. > > >As promised, I finally found a bit of time to fix this "hole". Here is the >result: > > (3) 7 0.40 -1.01 1. ... axb5 2. axb5 Rc7 3. b6 Rb7 4. > Kd4 h5 5. h4 > (2) 7-> 0.65 -1.01 1. ... axb5 2. axb5 Rc7 3. b6 Rb7 4. > Kd4 h5 5. h4 > 8 0.78 -1.05 1. ... axb5 2. axb5 Rc7 3. b6 Rb7 4. > Kd4 g4 5. fxg4 fxg4 6. Rb5 > 8 1.25 -1.02 1. ... a5 2. b6 Rb4 3. Rxb4 axb4 4. > h4 b3 5. b7 Kc7 6. hxg5 hxg5 > (4) 8-> 1.29 -1.02 1. ... a5 2. b6 Rb4 3. Rxb4 axb4 4. > h4 b3 5. b7 Kc7 6. hxg5 hxg5 > (3) 9 1.52 -1.04 1. ... a5 2. b6 Rb4 3. Rxb4 axb4 4. > Kc2 Kc6 5. a5 g4 6. f4 > (2) 9 1.89 -1.01 1. ... axb5 2. axb5 Rc7 3. b6 Rb7 4. > Kd4 h5 5. Rb5 Ke6 6. h4 > 9-> 2.45 -1.01 1. ... axb5 2. axb5 Rc7 3. b6 Rb7 4. > Kd4 h5 5. Rb5 Ke6 6. h4 > 10 3.02 -1.03 1. ... axb5 2. axb5 Rc7 3. b6 Rb7 4. > Kd4 g4 5. f4 h5 6. Rb5 Ke6 > (4) 10-> 5.93 -1.03 1. ... axb5 2. axb5 Rc7 3. b6 Rb7 4. > Kd4 g4 5. f4 h5 6. Rb5 Ke6 > (3) 11 7.25 -1.01 1. ... axb5 2. axb5 Rc7 3. b6 Rb7 4. > Kd4 g4 5. f4 Kc6 6. Ke5 Rb8 7. Kxf5 > Rxb6 8. Rxb6+ Kxb6 9. Kxg4 > 11 10.12 -0.93 1. ... a5 2. b6 Rb4 3. Rxb4 axb4 4. > a5 Kc6 5. h4 gxh4 6. gxh4 Kb7 7. Kd4 > b3 > (2) 11-> 13.38 -0.93 1. ... a5 2. b6 Rb4 3. Rxb4 axb4 4. > a5 Kc6 5. h4 gxh4 6. gxh4 Kb7 7. Kd4 > b3 > 12 16.39 -0.93 1. ... a5 2. b6 Rb4 3. Rxb4 axb4 4. > a5 Kc6 5. h4 Kb7 6. hxg5 hxg5 7. Kc2 > f4 8. gxf4 gxf4 > (4) 12-> 29.52 -0.93 1. ... a5 2. b6 Rb4 3. Rxb4 axb4 4. > a5 Kc6 5. h4 Kb7 6. hxg5 hxg5 7. Kc2 > f4 8. gxf4 gxf4 > >And for the next 30 minutes, it hever changes from a5. The problem was that >it realized that the outside passer would win, but in this position, the >outside passer disappears as soon as it is created, leaving the black king >in a lost K+P ending position. Crafty now understands what goes on after >the outside passer goes away, where the white king is too close to the black >pawns, even though the search doesn't see it for quite a while. The evaluation >"knows" now... Good stuff Bob. I was very interested in this position too. I tried the original position with LambChop and it stuck with axb5 thru 14ply, so clearly my eval isn't handling this very well. My score for axb5 was about -0.6, while if I force a5 the score is about -0.9 (similar to your score). There are two evaluation issues here, the problem can be solved by resolving either issue, but I think it would be very wise to resolve both issues. The first issue, which you have identified and worked on, involves correctly evaluating the pawn ending which results after all the pawns on the a-d files are swapped off. Whites king is closer to the k-side, and can clearly gobble those pawns first with an easy win. I'm moderately happy with my static eval of +0.6 for white there, but intend to work on it to make it higher. The second issue is that of evaluating pawn endings where both sides have a pair of 'untouchable' passed pawns. We see this after a5 b6 Rb4 Rxb4 ab a5, clearly white can't capture the connected passers. Also black can't capture the white passers because they are separated by a file and on adjacent ranks. Its pretty bad that my static eval says that white is almost a pawn ahead in that endgame, I think its reasonable to expect a lower score (I'd be happy with something in the 0 - 0.5 range). I have some ideas for implementing this, but haven't got around to trying them yet. > >Plenty of other such "holes" are left I am sure, but it has become pretty >dangerous in the endgame over the last couple of years... to the point that >I _never_ mind seeing it trade into an ending vs a GM. It usually knows what >it is doing. > >Sometime when we have nothing else to discuss here I will post a few positions >(without the names of the programs to avoid embarassing the guilty) that shows >just how bad some programs do in classic endings, while being in the top group >of 10 or so on the SSDF list. IE more than one "top" program knows nothing >at all about outside passed pawns. Nor pawn majorities that represent potential >outside passed pawns. I don't believe you can compete with GMs regularly with >that sort of "hole". > >More later...
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.