Author: Tord Romstad
Date: 05:02:57 04/09/04
Go up one level in this thread
On April 09, 2004 at 07:06:14, martin fierz wrote: >On April 09, 2004 at 04:57:21, Tord Romstad wrote: > >>On April 08, 2004 at 18:13:40, Ed Schröder wrote: >> >>>On April 08, 2004 at 17:36:15, Tord Romstad wrote: >>> >>>>Hi Ed, >>>> >>>>Did you intend to link to some other section of your pages? Perhaps I'm just >>>>too tired, but >>>>I can't see that the link you provide has any relation whatsoever to the topic >>>>under >>>>discussion. >>>> >>>>Tord >>> >>>I think I misread, I thought one of your worry was all the time-consuming >>>compares and jumps to go to the relevant parts of eval depending of the material >>>on the board. >> >>Ah, I see. We were discussing the high-level problem of big discontinuities in >>the score >>returned by the evaluation function. > >...but if ed has this kind of switch statement in his code, that probably means >he is going to do some eval based on the material situation, and have such >discontinuities too - even if he didn't explicitly state this. >and once again, i don't think it's really a problem. It most definitely *is* a real problem, but of course it is not impossible to solve. In case it is not clear, I think it is absolutely necessary to have lots of specific code for various material situations in order to play the endgame well. What I was trying to say was just that this is much more difficult to do than it seems at first glance. >all you need to do is to >move away from an eval that is based on material values to one which gives you a >winning probability. e.g. being a pawn up in a pawn ending should not be >evaluated as +1. But this is not easy to do. Except for very basic endgames, it is difficult to accurately estimate the probabilities for win/loss/draw. And you still face the problem of transition from the middle game with a centipawn eval to the endgame with a probability-based eval. >if you do this fairly consistently, then the eval discontinuity >problem should be no larger than it already is if you have a normal >material-value type evaluation: there you have real discontinuities that are not >reflected in your eval. i really wonder why nobody ever worries about these... I am not quite sure I understand what you mean here, but I repeat: You can't avoid the problem of discontinuities if you want to evaluate the endgame well. The problem is not impossible to solve, but you cannot just ignore it. I tried not to worry about it in the beginning, but the results were ugly. A few months ago I was tired of seeing my engine constantly misplaying KRPKR endgames, and spent a few days writing a special KRPKR eval, enabling my engine to play almost perfectly in KRPKR endgames even without tablebase access. When I tried the version with the new KRPKR eval against the old version, I discovered to my surprise that the new version was playing very slightly worse. The problem was that it had difficulties deciding when to exchange to a KRPKR endgame. I had to spend a couple of days more tuning the weights of the KRPKR eval to be consistent with my normal endgame eval. You could argue that this problem would disappear if I wrote a *perfect* KRPKR eval, which could always decide whether a position were won or drawn. But even in this simple endgame, this is not easy to do. There are many positions which are clearly won or drawn, but also a huge grey area between. After some experimentation I found out that positions where my KRPKR eval returned scores bigger than a pawn were usually won, while positions evaluated to less than a pawn were usually drawn. I ended up "stretching" scores bigger than a pawn by doing something like if(score>P_VALUE) score += (score-P_VALUE)*8; This worked OK, but it still isn't perfect. When you add special code for many different classes of endgames, this problem keeps appearing again and again. Usually, of course, it will be much trickier to solve than for KRPKR. In KRPKR, it is often easy to be 100% sure whether the position is won or drawn, but in more complicated endgames this is rarely the case. >> I never worry about low-level >>optimization. My engine >>is still very weak, > >oh, just shut up :-) >if gothmog is very weak, what are all the engines that are EVEN weaker than >gothmog (like mine and about 90% of all others posting here)??? >modesty is a good thing, but i think you are really overdoing it ;-) But I was talking to Ed. From his perspective, my engine is a complete joke. :-) And by the way, what I said applies to all the engines which are weaker than mine as well. Like me, they would do well to concentrate on other tasks than low-level optimization. If it's really true that my engine is stronger than 90% of the others, one of the reasons is that a significant fraction of those 90% thinks that the major factor which determines the strength of an engine is the speed of the move generator (I'm exaggerating a bit, but not very much). Tord
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.