Author: Vincent Diepeveen
Date: 16:24:33 10/06/02
Go up one level in this thread
On October 04, 2002 at 17:24:05, Sune Fischer wrote: I never evaluate positions when one side is in check. But i understand this idea very well. in fact to admit what i did a few years ago, that's scoring this position with king on g3 and black to move as near to draw... However then diep lost so fucking much games because the pattern sometimes was NOT correct, that sincethen i hope search finds it :) Sure the white king safety is getting evaluated very bad here, but i'll never again in my life let 1 pattern dominate. Something i found out already short after start of diep was that in such positions 3 checks in a row should not be evaluated as a draw :) I had criteria: "if king has received 3 checks in which nothing is captured and only the king runs getting checked by the same piece, then evaluate position as a draw" that's the first thing to try here. that failed of course miserably. years later i did some drastic evaluation experiments and i've come back completely from that. Note that still some older parts of my code get sometimes dominated by some bonuses/penalties. Especially endgame. >On October 04, 2002 at 16:46:22, Vincent Diepeveen wrote: > >>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. > >Yes, but I'm not 100% opposed to having one pattern dominate the rest, take this >positions: > >[D]8/RRQ3pk/7p/4B3/4PPPP/8/4q1K1/8 w - - 0 1 > >All the bean counting programs are going to score super high (staticly) for >white here. If you add the draw detector to scale down the score when chances of >a draw are high, then the score should be more realistic and white will probably >try and trade queens before this position occurs. > >IMO you don't need to score things exactly right, just to get a feel for the >danger will be all you need to avoid it, it's not like static evaluations are >deadly accurate anyway. > >-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.