Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: How many programs make use of more than one evaluation function?

Author: Vincent Diepeveen

Date: 08:13:55 05/25/02

Go up one level in this thread


On May 24, 2002 at 15:38:52, Russell Reagan wrote:

>On May 24, 2002 at 09:29:50, Vincent Diepeveen wrote:
>
>>On May 24, 2002 at 03:09:21, Russell Reagan wrote:
>>
>>>The topic pretty much says it. How many programs make use of more than one
>>>evaluation function? Is it more common to have more than one or not? What about
>>>if you sampled the top commercial programs? Would you find them using more than
>>>one?
>>>
>>>Russell
>>
>>I am not sure what you mean. You refer to a 'quick and rude' evaluation
>>and a slow and long evaluation, or do you refer to special evaluatoins
>>for special cases like KBN versus K ?
>
>I am speaking of a program that would have multiple evaluation functions. For
>example, a program that does some pre-analysis of the position, then determines
>that the position is of "type A" (or whatever), and then sets it's evaluation
>function for positions of type A. Type A might be "open" positions, with more
>tactical information. Type B evaluation function might be for closed positions
>where it has information about how to manuever or break the position open, at
>which point it would switch back to the type A evaluation function once the
>position becomes "open".

But if you take the programming manual into your hands, you will
see that there are several ways to do this.

According to the above definition of yours i have a couple of hundreds
of evaluation functions.

For me most interesting is not so much how much evaluation functions
one is using, but the sheer quality and complexity of the code.

>I am wondering about programs that have more than one function that produces the
>score for the position. So I do not consider a function that analyzes a passed
>pawn to be an evaluation function. That function aids in the overall evaluation
>function.
>
>So basically if a function produces the score for the position, then I consider
>that the evaluation function, so I supposed that an evaluation function that was
>only for a KBN vs K endgame would indeed qualify as an evaluation function.

but real impossible to realize for most non-programming chessplayers is
the fact that there is a huge difference with the KBN vs K endgame
versus the original question.

In DIEP the KBN vs K evaluation completely *replaces* the score.

This where in all the hundreds of evaluation functions, the score is
getting build up to some extend.

Like majority of code doesn't modify material score, but they add or decrease
something in the score.

This is true for all engines.

Basically the summation of penalties and patterns make the evaluation
of the position. Only a subset of the score is at most reevaluated in
*some* engines. From which DIEP is one.

Reevaluating scores is *real* dangerous. Because just a few hard rules
determine then the final evaluation, whereas otherwise thousands of
patterns potentially might correct that value.

>Russell





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.