Author: Ed Schröder
Date: 15:13:40 04/08/04
Go up one level in this thread
On April 08, 2004 at 17:36:15, Tord Romstad wrote: >On April 08, 2004 at 12:33:06, Ed Schröder wrote: > >>On April 08, 2004 at 12:07:13, Tord Romstad wrote: >> >>>On April 08, 2004 at 07:58:31, martin fierz wrote: >>> >>>>On April 08, 2004 at 04:51:01, Albert Bertilsson wrote: >>>> >>>>>Hi! >>>>> >>>>>I'm about to start coding on my engine again and have thought about improving >>>>>the endgame play. I don't like using egtb so I'm thinking about using special >>>>>evaluation cases when there are few pieces left on the board. Is this a good >>>>>idea or is special evaluation cases a dead end? >>>> >>>>i do the same. my problem is that i have only covered a couple of special cases >>>>up to now, and not in much detail. another problem is that many things are still >>>>the same for all endgames; e.g. it is nearly always good to have a centralized >>>>king, and it is always good to have passers and candidates and so on. however, >>>>for example the value of a passer depends on the endgame type. so you need some >>>>kind of strategy for computing common things for all endgames, and only doing >>>>some special stuff for the special cases. because if you want to write an entire >>>>eval for every type of ending, your code will get HUGE :-) >>>> >>>>i still haven't figured out a really good way to do this myself, my code is a >>>>bit of a mess in this respect :-( >>>> >>>>but in principle, i believe that you need special knowledge for different >>>>endings. there *are* huge differences between different types of endgames, and >>>>this leads to eval discontinuities - but i'm pretty certain that you shouldn't >>>>worry about this. there is the "eval discontinuity = evil" fraction here with >>>>bob as spokesperson. but as a chess player i can assure you that these >>>>discontinuities are absolutely real, and IMO a good evaluation should know about >>>>them... >> >>>The discontinuities are definitely real, but the problem is that when you have >>>several >>>sub-evaluation functions for different classes of endgames, it becomes painful >>>to make >>>the jumps in the eval have the right magnitude, or even the right sign. In >>>principle >>>it is always possible to make it work well, but in practise the job of tuning it >>>all is a nightmare. >>>The worst thing of all is that it is not possible to solve the problem once and >>>for all. When >>>you tune some weights in your eval for one particular class of endgames, you >>>will often be >>>forced to tune the weights in many related endgames as well. >>> >>>Tord >> >>There is an easy way out, just classify them suitable for an "indirect call" >>using "switch-case", see: >> >>http://members.home.nl/matador/chess840.htm#INTRO > >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. If so, create a 2-dimensional translation table that converts the present material to an unbroken and continuous string of characters (0,1,2,3,4,5.....) and then use the result with switch-case. I have such an endgame table with over 30 entries (KPK, KRK, KBNK, KQKR, KNKPP, KBKPPP, KRPKR etc.) and instead of doing 30 expensive compares I just have to do 2 initialization instructions, get the value of the translation table and then the switch-case will move me with just one assembler instruction to the right place (label). Imagine the speed gain. switch (val) { case 0 : goto KPK; case 1 : goto KRK; case 2 : goto KNBK; case 3 : goto KQKR; ................... case 99 : goto whatever; } Again, the compiler will translate this to just *one* instruction, even if you have 200 entries and thus save 200 compares. Ed
This page took 0.01 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.