PK wrote:
[..]
However, I might claim some small successes with generalizations, for example not awarding fianchettoed bishop directly, but giving a bonus for a bishop that defends squares near own king. I don't know if it still counts as a "slow", "knowledgable" approach, but it seems better than trying to copy human knowledge on 1 to 1 basis.
I also have this general knowledge to give small bonus to own pieces (not pawns) that attack opp pawns not defended by opp pawn
(does not care if this opp pawn is defended by opp pieces).
I see the engine trying to place pieces piling up on those weak pawns, there is no need to do SEE in every squares .
yes, this also my experience. So the mentioned isolated d-pawn I try to capture with a small bonus for minor pieces still on the board. I'm still in the process of tuning it, so not sure whether it really works.
The point is, all the chess knowledge written about the subject comes down to 1 or 2 lines of code at the end.
It might be worthwhile to collect such non-obvious examples of engine-digestible knowledge in one thread. for starters:
- attacks on completely undefended pieces (or pawn attacks on any pieces) evaluated as about 1/32 of attacked piece value (DiscoCheck)
- marginal bonus, below 5 centipawns, for minor pieces defended by pawns
- the above can be replaced by penalty for undefended minors (Stockfish)
- rooks defending each other, piece/square bonus, higher on 1st, 7th and 8th rank (Rebel has it, doesn't work for Rodent though)
- rook gets a bonus for enemy queen on the same file, regardless of pawn structure (this takes into account pawn lever possibilities, but fails in totally closed positions)
- pieces, especially minors, defending own king's vicinity (Pawny; I regard it as a generalization of human patterns such as fianchetto or Bf8/Kg8)
Just wondering, has anyone ever tried out some kind of "second-order" mobility, whereby mobility is scored not only by the number of accessible squares (which may or may not be weighted according to which particular squares they are, e.g. central squares or squares near the opposite King score higher), but also on what the piece's mobility would be if it were moved to that square.
Hmm, not sure how readable that is.
If a Bishop (say) is on b2, it will obtain a mobility score based on the squares it can reach from b2, weighted by some criterion. Perhaps the closer the square is to the centre, the more it will score. But on top of this, a score is given based on how mobile the Bishop would be if it moved to any of those squares accessible from b2.
It's almost like a two-move look-ahead. It would obviously be very expensive and perhaps not worth the effort, but I wonder if it's been tried and there's an opinion on this out there.
Michael Neish wrote:Just wondering, has anyone ever tried out some kind of "second-order" mobility, whereby mobility is scored not only by the number of accessible squares (which may or may not be weighted according to which particular squares they are, e.g. central squares or squares near the opposite King score higher), but also on what the piece's mobility would be if it were moved to that square.
Hmm, not sure how readable that is.
If a Bishop (say) is on b2, it will obtain a mobility score based on the squares it can reach from b2, weighted by some criterion. Perhaps the closer the square is to the centre, the more it will score. But on top of this, a score is given based on how mobile the Bishop would be if it moved to any of those squares accessible from b2.
It's almost like a two-move look-ahead. It would obviously be very expensive and perhaps not worth the effort, but I wonder if it's been tried and there's an opinion on this out there.
Cheers.
I use some king of second order variable for mobility. I calculate the safe squares the piece con go (not attack by enemy pawns), and then I calculate it again, but I before remove own pieces (the idea is that own pieces, not pawns, dont interfere the mobility of they piece, as they are temporary blocker). Then I average those two variables to get same king of aproximate mobility.
In my test this gave me some elo points, not remember how much now.
regards
Fermin
Thanks Fermin. Your result says it's worth a try. It's always seemed to make sense to reward a piece for where it could go in a couple of moves rather than just one.
It seems to me it needn't be an exclusive or (i.e. "fast" xor "smart"?).
My program (still under development) does its static eval a couple ply above the nominal search depth. That allows you to do an expensive positional eval (since you're doing this in interior nodes of the tree, not the leaves). Then you do the search to the leaves with a fast search that is only doing incremental material eval plus looking for mate or stalemate. So (for example), if your nominal search depth is 16 ply, I apply the positional eval at 14 ply, then an additional 2 ply of full-width searching for tactics only, plus extensions for captures/recaptures/checks/check-evasions up to some limit.
This idea of "lifting" the detailed static eval up to interior nodes to reduce the cost is simple and obvious. So, although I have not seen it explicitly mentioned in chess programming literature, my guess is top programs are doing this, or something equivalent (or even better), to achieve both fast and knowledgeable search.
I do agree with the point made earlier that positional chess knowledge above ~1500 level is not easy to express in a chess program. If you look at annotations of top players like Kasparov, the comments are often of the form "in this type of position, the bishop belongs on g5", leaving the chess programmer the problem of figuring out what "this type of position" means. The above is just an example; my general point is that figuring out the "rules" of positional evaluation above a certain level of play is not straightforward because the rules often depend on position. But I think top programs are doing it.
evaluating in interior nodes, as opposed to leaves, is bound to introduce some nasty side-effects. For example, king safety score can change enormously after a queen exchange. IIRC early versions of Fritz or Mephisto did that and played some embarassing moves because of that.
I once tried something like that for mobility evaluation in Fairy-Max. The idea was to let the move generator also count the number of moves it generated for each piece, and store it (after multiplication by a type-dependent weight) on a separate board, as well as calculate the total. That would give you the one-sided mobility for almost free, as moves would have to be generated anyway. Of course you would need it for the other side as well to get a meaningful mobility eval, but in full-width nodes Fairy-Max always does a null-move search, and this then produces the opponent mobility as an almost free side effect. The incrementally updated material evaluation was then corrected with this mobility term before passing it to the QS daughters, so that it would end up in all the evaluations made in QS.
To avoid the engine counting itself rich by highly mobile pieces that would be traded away in QS, I used the piece-wise recorded mobility values on the auxiliary board as a bonus on the piece values in QS: when pieces moved the mobility was moved with them, and when they were captured, it disappeared with them.
Intuitively this 'static mobility' seemed a quite good approximation to the real thing; it would not just calculate the eval term in an internal node and propagate it from there to the leaves, but it would really assign the term to individual pieces according to their contribution, and thus correct it for their occasional capture. What it would fail to detect is the change in mobility a piece would suffer because it moved to another square in order to capture something there. But usually the decision to capture something is dominated by the value of the piece you capture, and not so much to optimize mobility.
This 'static mobility', however, did not work at all, and caused a double-digit drop in Elo. This is still hard to swallow for me; I like to believe that this was caused by a major error in the implementation (which, in Fairy-Max, was of course rather obfuscated).
PK wrote:evaluating in interior nodes, as opposed to leaves, is bound to introduce some nasty side-effects. For example, king safety score can change enormously after a queen exchange. IIRC early versions of Fritz or Mephisto did that and played some embarassing moves because of that.
A classic example of what Hans Berliner termed a "score discontinuity". If there is some magic point where on one side the score is X and on the other side the score is Y, where X-Y is a large number, you are playing with fire. The exhaustive search can finagle the move ordering to make that jump at a place where it is most favorable. For example, committing to a line to trade queens when your king is exposed, but giving up two pawns to do so, which might trade into an even easier position for the opponent to have to play to win.
That was the main thing that convinced me to go to the interpolated scoring, although there are still obvious discrete jumps in the score since it is not a floating point value.
.
