Author: Peter McKenzie
Date: 16:32:14 08/07/04
Go up one level in this thread
On August 07, 2004 at 17:06:30, Stuart Cracraft wrote:
<snip>
Your code still looks buggy to me, but that may in part be because it is a
mixture of real and pseudo code?! Comments below:
>
>Okay I changed to:
>
>int quiesce(alpha,beta)
>{
> if (repetitioncount()==2 || 50moverule()) return(0); // draw
> if (incheck()) return(mainsearch(depth=1,alpha,beta)); // check extension
This usage of incheck() implies that the incheck function determines if the side
to move is in check. The usage later on is inconsistent with this.
> base = value = eval(); // evaluate
> if (value >= beta) return beta; // cutoff
> if (value > alpha) alpha = value // establish value
> generate capture moves; // get all captures, just captures
> while another capture move available
> {
> value = base + see(destination_square_of_this_capture);
Does your see function take pc-sq value of the captured piece into account? If
not, then you should probably include an error margin term into value. So the
above line would become:
value = base + see(destination_square_of_this_capture) + margin;
> if (value > alpha) {
> if (value > beta) value = beta;
> makemv();
> if (!incheck()) value = -quiesce(...,-value,-alpha);
Here the usage of incheck implies that the incheck function determines if the
side *not* to move is in check. That is inconsistent with the previous usage
and would appear to be a bug. This deduction is based on the assumption that
makemv() changes the side to move, is that correct?
Also, what exactly does the '...' mean in your call to quiesce?
Another thing that looks odd is the way you are changing beta. Why not just call
quiesce with -beta, -alpha? After all, its still an alpha/beta search.
It seems to me that if SEE predicts that the capture will exceed alpha but not
beta then you take this as gospel and adjust beta downwards accordingly. That
seems plain wrong as it will hide mistakes of SEE that would otherwise be found.
For example SEE may think you are winning the exchange but in reality you are
winning a rook because the defender is pinned.
> else value = MINNUM
> unmakemv();
> }
> if (value >= beta) return beta;
> if (value > alpha) alpha = value;
> }
> return(alpha);
>}
>
>Also I discovered a bug in SEE that wouldn't find a pawn attacker
>of the given see(sq)'s sq target for the exchange if the pawn
>attacking was black.
>
>That is fixed and the SEE is verified for both sides in exchanges
>of different types for white and black and saw no problem.
>
>Still, with the above two fixes, the SEE() is doing worse. (Fewer
>nodes searched and less problems solved.)
Fewer nodes searched is better, right? For a fixed depth, SEE will always solve
fewer (or the same number of) problems than non-SEE. It is just another form of
pruning after all!
>
>I put in some code to show me the moves being rejected (see(bd,sq)<0)
>along with a board printout for each and all the moves shown were
>losing exchanges so I am confident it is working.
>
>I still think it is due to my use of material-only/pc-sq and
>an attack-finding routine, in support of see, that is as slow
>as doing a makemv().
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.