mcostalba wrote:UncombedCoconut wrote:Heh, makes sense that TrappedBishopA1H1Penalty isn't tuned. That one is only relevant at all in FRC games.
Yes
, also TrappedRookPenalty it doesn't make a lot of sense to tune you just need an high enough value to say to the engine "don't do that".
Larry Kaufman made a remark about that when he was still testing Rybka values with very fast games, something like that it was much too high. But I don't know if this was an actual test of Stockfish or the equivalent in Rybka. Both would be interesting I think
Another story is the InitKingDanger table, in this case tuning would be good but being king safety it is very sensible to TC so that we should tune at long time control and it will take forever....I have tried in the past to manually tune, changing a bit the table values, but never come with something better than what we have now.
I think if you do it right that it would mainly change the playing style, but not necessarily add a lot of "knowledge" Something more aggressive might work against weaker engines but not against stronger, so the pool of adversary engines would also play a role.
I am not expecting much of it and just making some casual observations but right now there is an experiment where not only all the attacks and attackers are counted, but if the opponent has enough attacking material, in principle also all the defenders are counted in much the same way as the attackers.
The idea is that sometimes there are enough especially heavy pieces for instance, defending the King position so that the opponent will have a hard time breaking through. But the only way that is taken into account (in Stockfish' eval right now) is by the "undefended" bitboard which is a pretty small parameter. So I do think there might something missing there.
So I now have
Code: Select all
namespace {
// Struct EvalInfo contains various information computed and collected
// by the evaluation functions.
struct EvalInfo {
// Pointer to pawn hash table entry
PawnInfo* pi;
// attackedBy[color][piece type] is a bitboard representing all squares
// attacked by a given color and piece type, attackedBy[color][0] contains
// all squares attacked by the given color.
Bitboard attackedBy[2][8];
// kingZone[color] is the zone around the enemy king which is considered
// by the king safety evaluation. This consists of the squares directly
// adjacent to the king, and the three (or two, for a king on an edge file)
// squares two ranks in front of the king. For instance, if black's king
// is on g8, kingZone[WHITE] is a bitboard containing the squares f8, h8,
// f7, g7, h7, f6, g6 and h6.
Bitboard kingZone[2];
// kingAttackersCount[color] is the number of pieces of the given color
// which attack a square in the kingZone of the enemy king.
int kingAttackersCount[2];
// kingDefendersCount[color] is the number of pieces of the given color
// which attack a square in the kingZone of the own king.
int kingDefendersCount[2];
// kingAttackersWeight[color] is the sum of the "weight" of the pieces of the
// given color which attack a square in the kingZone of the enemy king. The
// weights of the individual piece types are given by the variables
// QueenAttackWeight, RookAttackWeight, BishopAttackWeight and
// KnightAttackWeight in evaluate.cpp
int kingAttackersWeight[2];
// kingDefendersWeight[color] is the sum of the "weight" of the pieces of the
// given color which attack a square in the kingZone of the own king. The
// weights of the individual piece types are given by the variables
// QueenAttackWeight, RookAttackWeight, BishopAttackWeight and
// KnightAttackWeight in evaluate.cpp
int kingDefendersWeight[2];
// kingAdjacentZoneAttacksCount[color] is the number of attacks to squares
// directly adjacent to the king of the given color. Pieces which attack
// more than one square are counted multiple times. For instance, if black's
// king is on g8 and there's a white knight on g5, this knight adds
// 2 to kingAdjacentZoneAttacksCount[BLACK].
int kingAdjacentZoneAttacksCount[2];
// kingAdjacentZoneDefenceCount[color] is the number of defending moves to
// squares directly adjacent to the king of the given color. Pieces which defend
// more than one square are counted multiple times. For instance, if black's
// king is on g8 and there's a black knight on g5, this knight adds
// 2 to kingAdjacentZoneDefenceCount[BLACK].
int kingAdjacentZoneDefenceCount[2];
};
And things like
Code: Select all
template<Color Us, bool HasPopCnt>
void init_eval_info(const Position& pos, EvalInfo& ei) {
const BitCountType Max15 = HasPopCnt ? CNT_POPCNT : CpuIs64Bit ? CNT64_MAX15 : CNT32_MAX15;
const Color Them = (Us == WHITE ? BLACK : WHITE);
int count;
Bitboard b = ei.attackedBy[Them][KING] = pos.attacks_from<KING>(pos.king_square(Them));
ei.attackedBy[Us][PAWN] = ei.pi->pawn_attacks(Us);
// Init king safety tables only if we are going to use them
if (pos.non_pawn_material(Us) >= QueenValueMidgame + RookValueMidgame)
{
ei.kingZone[Us] = (b | (Us == WHITE ? b >> 8 : b << 8));
b &= ei.attackedBy[Us][PAWN];
if (b)
{
count = count_1s<Max15>(b);
ei.kingAttackersCount[Us] = count;
ei.kingAdjacentZoneAttacksCount[Us] = count_1s<Max15>(ei.attackedBy[Them][KING]& ei.attackedBy[Us][PAWN]);
ei.kingAttackersWeight[Us] = ei.kingAttackersCount[Us] * KingAttackWeights[PAWN];
}
else
ei.kingAdjacentZoneAttacksCount[Us] = ei.kingAttackersWeight[Us] = ei.kingAttackersCount[Us] = 0;
ei.kingAdjacentZoneDefenceCount[Them] = ei.kingDefendersWeight[Them] = ei.kingDefendersCount[Them] = 0;
} else
ei.kingZone[Us] = ei.kingAttackersCount[Us] = 0;
}
Sorry the indents are a mess, whenever I post something modified in the MSVC editor here, and I have to change everything to get rid of some invisible tabstops. But I hope the idea is straightforward enough. Well whenever anybody wants to test it in Stockfish as well, it is easy enough to code because the basic structure is already there.
All I can say now (the code was added in Rainbow Serpent eval only today) is that it will lower the evals a lot, because there will be less attackUnits whenever there are defenders and you value them about the same as the attackers. Even in Rainbow Serpent that has a lot higher weight for King Safety in principle, I think I can already see that the evals are much tamer. But I don't know if this adds much "knowledge". I don't think it is basically wrong though.
Just an idea, it is not an official proposal for a patch or anything
No results that I have for it either. If anyone wants to test actual eval.cpp that is in use in Rainbow serpent in Stockfish for a patch I could post it.
Eelco
