Ralph Stoesser wrote:@Sven
I think your approach to remove this line
Code: Select all
ebonus += Value(square_distance(theirKingSq, blockSq) * 6 * tr);
will not work in general. It would work for the special cases though. I have played 5000 very fast self play games and the default version was *far* ahead.
After many fruitless tries in that direction (I tried to replace the constant 6 with 5 or 4 and other minor tweaks), right now I try something completely other
replace this ugly special case
Code: Select all
// Rook pawns are a special case: They are sometimes worse, and
// sometimes better than other passed pawns. It is difficult to find
// good rules for determining whether they are good or bad. For now,
// we try the following: Increase the value for rook pawns if the
// other side has no pieces apart from a knight, and decrease the
// value if the other side has a rook or queen.
if (square_file(s) == FILE_A || square_file(s) == FILE_H)
{
if ( pos.non_pawn_material(Them) <= KnightValueMidgame
&& pos.piece_count(Them, KNIGHT) <= 1)
ebonus += ebonus / 4;
else if (pos.pieces(ROOK, QUEEN, Them))
ebonus -= ebonus / 4;
}
with a new one at the same place in the code
Code: Select all
if (pos.pieces(ROOK, QUEEN, Them) && !pos.pieces(ROOK, QUEEN, Us))
ebonus /= 4;
That somehow seems to work better in general and it's also ok for the special cases, but not yet enough test games at reasonable time control.
I just wanted to tell you. Maybe you somehow can be successfull with your approach though.
That would be very nice, because what I test right now looks *very* ugly.
The first code fragment (Case 1) is about passed pawns on the Rook file, or edge files, the second code suggestion (Case 2) seems to be just about Rook and Queen support but Ralph is not very clear about this. They are certainly both related I think, but need not be excluding each other. Especially the H-file/A-file code is very rudimentary and probably could/should be made more complex. It is just the testing that would be the major hurdle, as always.
Case 2: more rules about Queen and Rook support are in Rainbow Serpent, what Ralph seems to propose is okay. (Interpreting this as just for A- and H-pawns, then it becomes the suggestion No. 1 below.) Interpreting it as a general rule, there is already code for enemy Rook or Queen behind our passed pawn but why not add a condition that there is a
bonus with own Rook and Queen support behind the passed pawn. Also because the opposite case for enemy Rook/Queen behind the pawn is already in place.
Case 1: Rainbow Serpent has very messy code for Rook-file pawns, it can give wrong answers when for instance own King support or King oppostion to enemy passed pawn is not needed, because the passed pawn is already controlled by your Queen, or by your Bishop for instance. It is just a stopgap measure to direct the King toward the edge files, from both sides, which was not in Tord's rule. I don't think this is good enough to test fully, maybe it is even wrong, maybe there are other ways of coding something like this.
Rainbow Serpent code:
Code: Select all
if (true)
{
// Rook pawns are a special case: They are sometimes worse, and
// sometimes better than other passed pawns. It is difficult to find
// good rules for determining whether they are good or bad. For now,
// we try the following: Increase the value for rook pawns if the
// other side has no pieces apart from a knight, and decrease the
// value if the other side has a rook or queen.
if (square_file(s) == FILE_A || square_file(s) == FILE_H)
{
if ( pos.non_pawn_material(Them) <= KnightValueMidgame
&& pos.piece_count(Them, KNIGHT) <= 1)
ebonus += ebonus / 4;
else if (pos.pieces(ROOK, QUEEN, Them))
ebonus -= ebonus / 4;
if (r >= 2)
{
int kingDistancebonus = tr + ((pos.non_pawn_material(Them) <= BishopValueMidgame) && !pos.opposite_colored_bishops()) * tr;
ebonus -= Value(((4 - square_distance(theirKingSq, qsq)) + (4 - theirKingDistance))* kingDistancebonus);
}
}
}
Reading Ralph's post again, I think it is a little unclear which part of the code Ralph wants to replace, are you suggesting something like:
Code: Select all
// Rook pawns are a special case: They are sometimes worse, and
// sometimes better than other passed pawns. It is difficult to find
// good rules for determining whether they are good or bad. For now,
// we try the following: Increase the value for rook pawns if the
// other side has no pieces apart from a knight, and decrease the
// value if the other side has a rook or queen.
if (square_file(s) == FILE_A || square_file(s) == FILE_H)
{
if (pos.pieces(ROOK, QUEEN, Them) && !pos.pieces(ROOK, QUEEN, Us))
ebonus /= 4;
}
Or replacing just this single line
Code: Select all
else if (pos.pieces(ROOK, QUEEN, Them))
ebonus -= ebonus / 4;
So it becomes something like
Code: Select all
// Rook pawns are a special case: They are sometimes worse, and
// sometimes better than other passed pawns. It is difficult to find
// good rules for determining whether they are good or bad. For now,
// we try the following: Increase the value for rook pawns if the
// other side has no pieces apart from a knight, and decrease the
// value if the other side has a rook or queen.
if (square_file(s) == FILE_A || square_file(s) == FILE_H)
{
if ( pos.non_pawn_material(Them) <= KnightValueMidgame
&& pos.piece_count(Them, KNIGHT) <= 1)
ebonus += ebonus / 4;
if (pos.pieces(ROOK, QUEEN, Them) && !pos.pieces(ROOK, QUEEN, Us))
ebonus /= 4;
}
Regards, Eelco
).
