Re: Kibitz score reporting in server play
Posted: Thu Mar 29, 2007 2:39 pm
CentiPawns? Joker uses Pawn = 256!
Actually, Steven's last post brushes on something that is much more fundamental than just for display purposes: minimax should really be applied to the winning probability, and not to the "woodcounting score".
In the range of small scores, the two are proportional, but above a lead of more than 2 Pawns, it starts to saturate. So it would be more natural to use something like 2*arctan(score/2) (which saturates towards +/- PI, score given in Pawn units).
Now if scores are only compared, such a non-linear but monotonous transformation would not have any effect. But it will have an effect in combination with 'ageing' of future gains: in a discounted-cash-flow manner reduce the value of a gain (=score minus current eval) if it lies in the future. uMax and Joker both use this mechanism to select between fast and slow paths to the same position (e.g. the checkmate) anyway. They just ameliorate scores below current eval a little bit.
In combination with the arctan correction to the score, this would prevent problems of the kind where the computer would 'defeat itself', by sacrificing a Rook now to postpone a checkmate in 25 to one in 30. Such a 'theoretically best' move of course only buys you a 100% certain loss, as even a patzer would take the Rook and have an easy win after that. If the opponent is so poor that he cannot win with the extra Rook, he certainly would not see the mate in 25...
Even with an aging of 5 centPawn per move, the mate in 25 score (which is only the asymptotically high 3.14) would have deflated by 125 cP to 1.89, so that the engine would not give more than a Pawn to delay the checkmate, and at least retain a chance if the opponent does not see it. You could adapt the ageing rate to the expected search depth of the opponent, as a very course method of opponent modelling.
Actually, Steven's last post brushes on something that is much more fundamental than just for display purposes: minimax should really be applied to the winning probability, and not to the "woodcounting score".
In the range of small scores, the two are proportional, but above a lead of more than 2 Pawns, it starts to saturate. So it would be more natural to use something like 2*arctan(score/2) (which saturates towards +/- PI, score given in Pawn units).
Now if scores are only compared, such a non-linear but monotonous transformation would not have any effect. But it will have an effect in combination with 'ageing' of future gains: in a discounted-cash-flow manner reduce the value of a gain (=score minus current eval) if it lies in the future. uMax and Joker both use this mechanism to select between fast and slow paths to the same position (e.g. the checkmate) anyway. They just ameliorate scores below current eval a little bit.
In combination with the arctan correction to the score, this would prevent problems of the kind where the computer would 'defeat itself', by sacrificing a Rook now to postpone a checkmate in 25 to one in 30. Such a 'theoretically best' move of course only buys you a 100% certain loss, as even a patzer would take the Rook and have an easy win after that. If the opponent is so poor that he cannot win with the extra Rook, he certainly would not see the mate in 25...
Even with an aging of 5 centPawn per move, the mate in 25 score (which is only the asymptotically high 3.14) would have deflated by 125 cP to 1.89, so that the engine would not give more than a Pawn to delay the checkmate, and at least retain a chance if the opponent does not see it. You could adapt the ageing rate to the expected search depth of the opponent, as a very course method of opponent modelling.