Author: Larry Coon
Date: 13:29:20 11/12/98
Go up one level in this thread
On November 12, 1998 at 14:34:16, Robert Hyatt wrote:
>your approach is a complicated way of thinking about it, but it
>ought to work.
I wouldn't want to do things the easy way... :-)
>An easier way is to simply play out the captures
>and save the material score after each one, just as you suggested,
>until one side can't make a capture. Then you simply back up
>thru this list to see what the material score before the capture
>and after the capture is...
In implementation I'd probably play through them, as you
said, since I already have code to *make* moves, and would
otherwise have to worry about things like discovered checks.
But if you always play through the entire sequence, do you
lose the opportunity to cut off the search in the way I
suggested, and thus save time? Or is the gain not worth
the effort?
>but the score after the capture is
>the score that happens at the end of the sequence, or somewhere
>along the way... here is a simple bit of code:
>
>
> next_capture--;
> if(next_capture&1) sign=-1;
> else sign=1;
> while (next_capture) {
> if (sign < 0) {
> if(swap_list[next_capture] <= swap_list[next_capture-1])
> swap_list[next_capture-1]=swap_list[next_capture];
> }
> else {
> if(swap_list[next_capture] >= swap_list[next_capture-1])
> swap_list[next_capture-1]=swap_list[next_capture];
> }
> next_capture--;
> sign=-sign;
> }
>
>next_capture tells me how many entries are in swap_list... notice that
>at each step along the way, I compare the current to the next entry and
>if the next is "better" from my point of view, I back this up to the
>previous entry.. then the side on there can choose to accept my value,
>or the value he would have if he chooses to not make a capture at all
>and stand pat...
>
>Pretty simple idea, pretty difficult to explain it.
No kidding! That one took some walkthroughs with pencil
& paper....
>The above can be
>written a bit shorter because the two comparisons can be done like we
>do with negamax... but this one is probably easier to understand...
BTW, I always seem to make a mistake when I try to type
in a position from my head. I really should write them
down on paper first. I said:
1kq5/3n2p1/5p2/8/6N1/5R2/5RK1 w
I meant:
1kq5/8/3n2p1/5p2/8/6N1/5R2/5RK1 w
Another question: How does SEE handle cases where the series
of exchanges has multiple branches? Maybe I'd better give an
example (I'll write it down first):
1k6/8/3nq1p1/4np2/8/6N1/5R1Q/4RK2 w
This is a slight modification of my first position. Now
when white does NxP, he opens up the h2-e5 diagonal for
the queen, so white now attacks e5 twice, and the combinaion
now continues at e5 rather than f5. A way of solving it
would be to generate the captures each step of the way and
do a tree search through them, but that seems more like a
selective extension than a static evaluation. In fact, it
even seems to contradict the name *static* exchange
evaluation. Does a static evaluation, by its very definition,
miss this kind of combination?
Thanks for the response,
Larry Coon
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.