So, I have a rough search, with unrefined Null-move, LMR, PVS and SEE move sorting (along with a material, PST and mobility eval), but the scores I'm getting are making root move ordering based on the search scores very difficult, with bad results:
int Eval(struct Board * b)
{
int i, sq, tmp, value;
int mask;
value = 0;
mask = b->piecemask[KNIGHT] | b->piecemask[BISHOP];
for (i = 0; i < 64; i++) {
sq = i;
if (b->index[i] != INVALID) {
tmp = 1 << b->index[i];
if (tmp & b->sidemask[b->side]) {
if (b->side == WHITE) sq ^= 56; /* PSTs are rank 8 - 1, so flip the square */
if (tmp & b->piecemask[PAWN]) {
value += PawnValue;
value += PawnPST[sq];
}
if (tmp & b->piecemask[KNIGHT]) {
value += KnightValue;
value += KnightPST[sq];
}
if (tmp & b->piecemask[BISHOP]) {
value += BishopValue;
value += BishopPST[sq];
}
if (tmp & b->piecemask[ROOK]) {
value += RookValue;
value += RookPST[sq];
}
if (tmp & b->piecemask[QUEEN]) {
value += QueenValue;
value += QueenPST[sq];
}
if (tmp & b->piecemask[KING]) {
value += KingValue;
value += KingPST[sq];
}
} else {
if (b->side == BLACK) sq ^= 56; /* PSTs are rank 8 - 1, so flip the square */
if (tmp & b->piecemask[PAWN]) {
value -= PawnValue;
value -= PawnPST[sq];
}
if (tmp & b->piecemask[KNIGHT]) {
value -= KnightValue;
value -= KnightPST[sq];
}
if (tmp & b->piecemask[BISHOP]) {
value -= BishopValue;
value -= BishopPST[sq];
}
if (tmp & b->piecemask[ROOK]) {
value -= RookValue;
value -= RookPST[sq];
}
if (tmp & b->piecemask[QUEEN]) {
value -= QueenValue;
value -= QueenPST[sq];
}
if (tmp & b->piecemask[KING]) {
value -= KingValue;
value -= KingPST[sq];
}
}
}
tmp = b->bitlist[sq] & mask;
/* Safe Mobility */
if (!(tmp & b->sidemask[!b->side]))
value += MobilityPoint * __builtin_popcount(tmp & b->sidemask[b->side]);
if (!(tmp & b->sidemask[b->side]))
value -= MobilityPoint * __builtin_popcount(tmp & b->sidemask[!b->side]);
}
if (b->side == BLACK)
value = -value;
return value;
}
The Mobility code looksa bit weird, I know, but I use attack tables, so get the luxury of it being (almost) free.
ZirconiumX wrote:So, I have a rough search, with unrefined Null-move, LMR, PVS and SEE move sorting (along with a material, PST and mobility eval), but the scores I'm getting are making root move ordering based on the search scores very difficult, with bad results:
Is this a side-effect of my evaluation being rough, or do I have a bug somewhere?
Matthew:out
I think you have a bug. When you compute a score, it is generally done in a white-centric way since that's the most natural way to do it, + = good for white, -=bad for white or good for black. But when you call eval, you need to correct the sign to make it match the side on move. something like:
ZirconiumX wrote:So, I have a rough search, with unrefined Null-move, LMR, PVS and SEE move sorting (along with a material, PST and mobility eval), but the scores I'm getting are making root move ordering based on the search scores very difficult, with bad results:
Is this a side-effect of my evaluation being rough, or do I have a bug somewhere?
Matthew:out
I think you have a bug. When you compute a score, it is generally done in a white-centric way since that's the most natural way to do it, + = good for white, -=bad for white or good for black. But when you call eval, you need to correct the sign to make it match the side on move. something like:
return (white_on_move) ? score : -score;
Yes, Martin raised this point, and it appears that I have an asymmetry in my PSTs (which I don't quite understand, since the PSTs that I was using - found here - don't appear to be asymmetrical down the middle).
if (b->side == WHITE) sq ^= 56; /* PSTs are rank 8 - 1, so flip the square */
if (b->side == BLACK) sq ^= 56; /* PSTs are rank 8 - 1, so flip the square */
you flip the square with the same value for the two colors?
the pst you found (I use it too ) are "white (or black) point of view "
ZirconiumX wrote:So, I have a rough search, with unrefined Null-move, LMR, PVS and SEE move sorting (along with a material, PST and mobility eval), but the scores I'm getting are making root move ordering based on the search scores very difficult, with bad results:
Is this a side-effect of my evaluation being rough, or do I have a bug somewhere?
Matthew:out
Something else that should have been pointed out is that your move ordering is clearly either not working or not hooked up properly. The first move being chosen at every depth (but only after depth 2, for some reason) is a2a4, which implies that you're searching moves in the order that they are being generated. However, your first move searched (and therefore reported) at depth N should always be the best (and last) move reported at depth N-1.
So, I'm afraid to say, you have another problem to solve. (and don't we all!)
if (b->side == WHITE) sq ^= 56; /* PSTs are rank 8 - 1, so flip the square */
if (b->side == BLACK) sq ^= 56; /* PSTs are rank 8 - 1, so flip the square */
you flip the square with the same value for the two colors?
the pst you found (I use it too ) are "white (or black) point of view "
if (tmp & b->sidemask[b->side]) {
if (b->side == WHITE) sq ^= 56; /* PSTs are rank 8 - 1, so flip the square */
...
} else {
if (b->side == BLACK) sq ^= 56; /* PSTs are rank 8 - 1, so flip the square */
...
}
Switching the code to be b->side == WHITE for the second bit would flip the PSTs for Black
JVMerlino wrote:
Something else that should have been pointed out is that your move ordering is clearly either not working or not hooked up properly. The first move being chosen at every depth (but only after depth 2, for some reason) is a2a4, which implies that you're searching moves in the order that they are being generated. However, your first move searched (and therefore reported) at depth N should always be the best (and last) move reported at depth N-1.
So, I'm afraid to say, you have another problem to solve. (and don't we all!)
jm
My root move ordering is sorted by score - when the score is negative, the sort will sort the least negative scoring moves first, resulting in bad move ordering. Thus, if I fix the score flipping bug, I will also fix my root move ordering bug.
I should also add that the score sorting only kicks in after depth 1, when we have move scores to sort on - it before sorts by SEE, which is not very useful most of the time.
) are "white (or black) point of view "