Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: how to evaluate KRP vs KR

Author: Tord Romstad

Date: 13:53:20 06/05/04

Go up one level in this thread


On June 05, 2004 at 15:26:53, Anthony Cozzie wrote:

>We need to get Nalimov to write some W/L/D tables.

I am not sure I agree.  Implementing simple high-level rules for evaluating
endgames
like KRPKR correctly is a difficult, but very valuable excercise.   The reason
is that you
will sometimes discover principles which are also useful in more complicated
endgames, but which are much more easily noticed when there are just a few piece
left.  If you rely too heavily on bitbases and tablebases in the early phases of
development, you lose the chance to make such discoveries.

This applies to human chess players as well as computers.  I spent a lot of time
studying the KRPKR endgame when I was young.  I cannot remember a single
tournament game I played in which this endgame appeared on the board, but
the heuristic knowledge learned by studying this endgame helped me save a
lot of half points in rook endgames with numerous pawns.  Studying basic
endgames gives you a unique chance to learn about the strengths and
weaknesses of the individual pieces and how they interact.

My experience as a tournament player was that knowledge of basic endgames
decided a much bigger fraction of the games than concrete opening knowledge.
This is one of the reasons I find it hard to understand the FRC enthusiasts.  In
the endgame, of course, FRC and classical chess are identical.  If you want to
reduce the importance of preparation and knowledge in chess, you should
invent a variant where the endgame is radically different, not a variant where
the opening setup is random.

>Preferably in C rather than
>C++, considering that 2/3 of all instructions in Zappa are from tbindex.cpp :)

Here, however, I agree 100%.  :-)

Tord



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.