Author: martin fierz
Date: 05:17:59 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 well, this may happen once in a while; but overall everybody seems to believe that tablebases are good, because most everybody uses them. eval discontinuities (ED) are not bad in TBs, at least that seems to be the vote of the vast majority of top programmers. so how should EDs be bad in general then? i just don't believe it. i can see clearly how EDs can cause problems, because they are hard to fit together. you have to be sure that for a position A which is better than B eval(A) > eval(B) is true; else you stop your program from making progress in good positions. which IMO becomes harder to do once you introduce large eval terms which may pop up and maybe even disappear again. i think the problem with EDs is a practical one, not a theoretical one. cheers martin
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.