Author: Sune Fischer
Date: 04:38:39 02/26/04
Go up one level in this thread
On February 26, 2004 at 07:11:24, Uri Blass wrote: >On February 26, 2004 at 06:59:37, martin fierz wrote: > >>On February 25, 2004 at 12:30:38, Robert Hyatt wrote: >> >>>On February 25, 2004 at 12:09:16, Daniel Clausen wrote: >>> >>>>On February 25, 2004 at 10:52:27, Robert Hyatt wrote: >>>> >>>>>On February 25, 2004 at 05:56:16, martin fierz wrote: >>>> >>>>[snip] >>>> >>>>>>i don't know whether i should believe the eval discontinuity thing. i know >>>>>>somebody recently quoted a paper on this, but it's just a fact: exchanging any >>>>>>pieces necessarily changes the evaluation. sometimes not by very much. big >>>>>>changes are usually the exchange of the queen, the exchange of the last rook, >>>>>>the exchange of the last piece. these eval discontinuities are *real*. i don't >>>>>>believe in smoothing them out. perhaps if you write an eval with >>>>>>discontinuities it's harder to get it right that everything fits in with each >>>>>>other, and that's why it's supposed to be bad?! >>>>> >>>>>No. When you have a discontinuity, you give the search something to play with, >>>>>and it can choose when to pass over the discontinuity, sometimes with >>>>>devastating results.. >>>> >>>>The arguments of you two could be combined to this: >>>> >>>> Eval discontinuities are _real_ but it hurts the search too much and >>>> therefore it's better to be a tad less realistic in eval here in order >>>> to get maximum performance out of the search+eval. >>>> >>>> >>>>Does that make any sense? >>>> >>>>Sargon >>> >>> >>>That is not quite the issue. Consider the following X-Y plot of your >>>eval function (Y axis) against some positional component (X-axis): >>> >>> | >>> | >>> | >>> | * >>> E |* * * * * >>> V | * * >>> A | * * >>> L | >>> | >>> | >>> | >>> | >>> | >>> | >>> | * * * * * * * * * * * * * * * * * * * * * * * >>> |_________________________________________________________________ >>> some feature you are evaluating >>> >>>Notice the sudden drop to zero. If you start off in a position where the score >>>is non-zero for this term, and you can search deep enough to drive over the >>>"cliff" for this term and hit zero, strange things happen. The search can use >>>this as a horizon-effect solution to some problem. And it will be able to use >>>that sudden drop (when something goes too far) as opposed to the big bonus just >>>before it goes too far, to manipulate the score, the path, the best move, and >>>possibly the outcome of the game. >>> >>>This is what Berliner's paper was about. I suspect that anybody that has worked >>>on a chess engine for any length of time has run across this problem and had to >>>solve it by smoothing that sudden drop so that there is no "edge condition" that >>>the search can use to screw things up. >> >>another reason for not believing this stuff: your above graph shows *exactly* >>what happens when you go from a non EGTB position to an EGTB position (or, for >>that matter, what happens when you go into any position your program can >>recognize as a draw whether it has tablebases or not): your eval thinks it's >>doing great, but the exchange of something leads to a drawn position in your >>tablebases. are you going to claim that crafty plays better without TBs? >>:-) >> >>cheers >> martin > >I do not know about crafty but it is certainly possible that a program does >better without tablebases. > >Without tablebases it can capture a pawn and get KR vs KPP that is drawn when >with tablebases it may prefer to get an endgame when KR is losing against KPPP. > >Uri This is only possible with draw scores, right? I mean you can't be on the wrong side of a mate score, so TB mates should be safe despite the discontinuity. -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.