Author: Tom Likens
Date: 08:15:40 06/17/04
Go up one level in this thread
On June 17, 2004 at 05:09:36, Fabien Letouzey wrote:
>On June 16, 2004 at 15:43:29, Tom Likens wrote:
>
>>Another option, which I don't currently use, is to blend (i.e. interpolate) the
>>final
>>score from the middlegame evaluation and the endgame evaluation. I believe
>>Phanlanx, Gothmog and perhaps Fruit all use this technique so you might
>>inquire from them how they apply it. I've always shied away from this idea
>>because it seemed computationally expense, but perhaps not.
>
>>regards,
>>--tom
>
>Fruit does exactly that, in an attempt to reduce the blemish effect described by
>Hans Berliner.
>
>That means two scores are associated with each evaluation feature. The
>"computational expense" can be reduced to near 0 if you feel like it (mixing two
>16-bit values into a single 32-bit integer).
>
>Maybe the main drawback is that features are evaluated regardless of the
>position. Of course you can make exceptions if you like, but that somewhat
>defeats the original goal.
>
>Fabien.
Hello Fabien,
A couple of questions and perhaps a clarification. What do you use for the
x-axis variable of interpolation (I'm guessing the value of material left for
each side, excluding pawns)? Also do you scale the values for black and
white independent of each other or do you simply blend the final value?
My naive assumption about how this would work is as follows:
1. Compute all the common middlegame/endgame terms. Computational
cost zero (they have to be calculated regardless).
2. Calculate the middlegame-only terms *and* calculate the endgame-only
terms. Computational cost not zero, since some terms will be calculated
which may not be needed.
3. Interpolate based on the material (as I mentioned in my previous post,
some of the terms would be scaled based on the opponent's material etc.)
I believe this would go a long way towards making the evaluation function
"continous" at the break between the middlegame and endgame. I've held
off on doing this since I was afraid the computational costs would outweigh
the benefit, but perhaps I should revisit it.
One other item, I'm not sure I understand your 16-bit vs. 32-bit comment.
Are you returning a 32-bit integer from all your evaluation subroutines which
is comprised of a 16-bit middlegame score and a 16-bit endgame? This
makes some sense, because you would only have to interpolate once- but
how would you differentiate terms that needed to be scaled depending on
your material vs. your opponent's material, since this likely needs to be
handled on a term-by-term basis?
regards,
--tom
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.