Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Improving the endgame of my engine

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.