Author: Dieter Buerssner
Date: 01:50:30 12/15/00
Go up one level in this thread
On December 14, 2000 at 20:09:45, Bruce Moreland wrote:
>On December 14, 2000 at 19:02:53, Dieter Buerssner wrote:
>
>>On December 13, 2000 at 22:33:27, Bruce Moreland wrote:
>>
>>>My program was down a couple of pawns against Crafty in an opposite bishop
>>>ending with rooks on the board, when suddenly it traded off a couple of pawns,
>>>traded off the rooks, ran with its king into a corner, and declared the position
>>>equal:
>>>
>>> 8/8/3b4/8/7k/6pp/8/5B1K w - - 0 1
>>>
>>>I couldn't figure out why it was smart enough to have a draw score for this
>>>position, then it occurred to me that Crafty has B + wrong RP :-)
>>
>>Nice story - really. But would you like to elaborate, by which means your
>>program detected the draw. Without the black g pawn, it seems rather easy,
>>but with this pawn ...
>>Or did I totally misunderstand you post, and this was the subject of the bug?
>Actually I am a little confused. There was no bug, the program was correct.
Perhaps I have phrased it badly. You answer is exactly, what I wanted to hear.
>What my code says is:
>
>If we are in an opposite bishop ending, and it's two pawns to zero, if one of
>the pawns is a wrong rook pawn, and the king is in position to block it, score
>it as a draw.
>
>This works great if the white king is on h1, there's a pawn on h4 or so, and
>there's a b-pawn. The white bishop can sacrifice itself for the b-pawn and the
>game is a draw. The program knows this in eval.
>
>I figure that by just doing the opposite B case, it is very safe to score this
>as a draw, since it is very easy for the bishop to sacrifice itself for the pawn
>in all but very freakish cases.
>
>It didn't occur to me that it also works perfectly if the pawns are connected.
>It was really very beautiful to watch, I love it when my program understands
>cases where the opponent says +3.
Thanks. I took the five minutes to try this out. I get an interesting PV
1 0.206 0.00 1t : 1.Be2 {-160}
8 0.207 0.00 1. : 1.Be2 {-160}
32 0.210 0.00 2t : 1.Be2 h2 2.Bc4 {-160}
55 0.218 0.00 2. : 1.Be2 h2 2.Bc4 {-160}
138 0.222 -11.59 3--: 1.Be2 g2+ 2.Kg1 Bc5+ 3.Kh2 g1=Q# {-1081}
189 0.237 -Mat03 3t : 1.Be2 g2+ 2.Kg1 Bc5+ 3.Kh2 g1=Q# {-1081}
A you can see, the position is evaluated as draw. But also, one trap can be
seen. Even after Be2, the position is still evaluated as draw.
Of course this is no problem here at all, because in no time Kg1 will be found
as the correct drawing move. But there will be the fear left, can such a
position occure deep in search, but the win is after the horizont? I think
the answer must be yes. But more interesting: Will this be a practical problem?
Your story shows, that it can work very well in practise.
Regards,
Dieter "collecting little bits of chess knowledge suitable for programs" Bürßner
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.