Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Draw due to lack of blockade detection...

Author: Vincent Diepeveen

Date: 13:46:22 10/04/02

Go up one level in this thread


On October 04, 2002 at 14:53:09, Sune Fischer wrote:

>On October 04, 2002 at 14:31:16, Vincent Diepeveen wrote:
>
>>On October 04, 2002 at 12:28:54, Sune Fischer wrote:
>>
>>>On October 04, 2002 at 12:14:18, Omid David wrote:
>>>>>>Wrong. I've conducted hundreds of tests, and in no single case has my heuristic
>>>>>>returned an inaccurate result. There exist blockades that it fails to detect,
>>>>>>but it never declares a false draw.
>>>>>
>>>>>Perhaps this is too restrictive too.
>>>>>You could have some confidence variable, if you draw detector cannot say with
>>>>>100% certainty that it's draw, then interpolate the evaluated score with the
>>>>>confidence level: score=eval()*(100-confidence)/100.
>>>>>
>>>>>It might help the engine to steer clear of those drawish positions?
>>>>
>>>>But as Vincent pointed out, such heuristics have an overriding nature. Even the
>>>>slightest inaccuracies can result in a total disaster.
>>>
>>>Yes I know, you have to be careful, right now I don't even score KRKR as draw,
>>>because what if the one to move can give a check and take the other rook hiding
>>>behind the king...
>>>
>>>If there is a high probability of a draw, eg. a risk of perpetual check because
>>>your king is exposed and his queen is near by, then be less optimistic in your
>>>score even if you are way ahead in material. It is probably easier to win
>>>without the queens on the board if you have an extra knight, for instance. At
>>>least you have eliminated the risk of perpetual check.
>>
>>One of the things we are talking about here is that black is a pawn
>>down. Not about KR KR or something.
>
>Yes, I know that, it was just an example of why it is dangerous to score
>accurate, as you said yourself.
>
>>KR KR is not a 'blocked position'. He talks about recognizing something
>>as blocked and therefore giving a pawn up. In that 'easy' to recognize
>>draw from kramnik you put the black king on a7 and dang it's a zero.
>>
>>see my position example elsewhere. So your engine exchanges to a position
>>with pawn down to reach somewhere in far horizon a draw score from eval.
>
>I saw your position, and you are assuming his detector ignores the position of
>the kings. Had the king been within the square it would have been draw, right?

there is another zillion ways to avoid detection by the 'perfect'
function from Omar of course.

Obviously human is completely superior in such things. the problem is
just a heuristic that's as good as 'pawn up' isn't enough here. A human
isn't 10000x better in smelling when a pawn up is better than not a pawn
up. However a human is completely superior compared to computer to
detect when a blocked position is a draw and when it is an easy win,
because the problem i saw was that either a blocked position is a simple
win for human or it is a simple draw. There is no clear rule. it's all
the details that matter. GMs can do such things up to the tempo exact.

In fact many players qualify for this. Some things here i can see lots
of moves in advance coming too to the tempo precise.

I do not understand why Omar is crying victory here that he has a function
that is 100% exact. it's a lie.

Already years ago v/d Herik concluded very correctly that the problem
of software versus humans is not the quantity in the end, but the
quality of which pattern must get positively discriminated. Here human
is unbeatable.

In DIEP i try to make up for it by simply having a lot of patterns.

Chance that the result of them goes wrong is like real small when compared
to when 1 pattern is doing all the work.

Omar seems to want to get back to the 80s :)

>>then when you get near that position it is simply a pawn down as it sees
>>that position is tactical lost completely. This happens to be a lot of times
>>the case in blocked positions.
>
>What I was suggesting was to use a confidence score, in your position it would
>evaluate (staticly) white as +1 up, then it would say "but there is a 30% chance
>of a draw for black because of a lot of blocked pawns", the score would then be
>+1*(1-0.3)=+0.7 and not 1.0.
>So black wouldn't sac a pawn here because +0.7 is still worse for black than
>0.0, which might have been the material score had it not sacrificed a pawn.
>
>I don't see anything wrong with this, as long as your draw detector is
>reasonably accurate of course. The idea is the program might choose a different
>more secure way to the win, rather than entering a type of position where the
>opponent has a lot of drawing chances.
>I would like to get this "there is a danger of draws here, so pick a different
>variation if possible" knowledge into my program.
>
>>GMs are world champion winning blocked positions, let me tell you that...
>>...blocked positions that Omar scores of course each time as a draw :)
>
>Yes, which is why it is all the more important to remove this human advantage :)
>
>-S.



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.