Author: Uri Blass
Date: 04:11:24 02/26/04
Go up one level in this thread
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 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.