Centipawns, (Centi-pawns)
a score unit which corresponds approximately to one hundredth of a pawn unit. Fixed point representation with centipawn fractions allows a smooth relation of all piece values with a reasonable granularity to distinguish positional scores. 16 or even 15 bits are sufficient to store signed centipawn ranges in hash tables, while sign extension to the common 32-bit integer range is convenient to avoid overflows in scaling terms like in the tapered eval, even with an internal finer granularity used inside the evaluation ^{[1]} .

Having done all three, my take on the issue is this:

Decipawns (0.1) is too coarse. Not every positional consideration is worth 0.1 pawns, so you either have to round the score up to 0.1, or else throw it out since it would be zero.

Millipawns (0.001) is too fine. I do not believe that my evaluation has any .001 accuracy ideas in it. As you spread the evaluation scores out, your tree search becomes less efficient (for example, compare a program with no positional scoring to one with, with respect to tree size).

Centipawns (0.01) is reasonable. One could make the argument that maybe .05 is better (1/20th of a pawn). Or some other number. But my intuition after trying all three during the development of Crafty is that the right value lies in the interval {0.01, 0.1}. Whether it is on one end or the other, or somewhere in the middle, is a point for conjecture. It is too hard to test the idea, although I suppose I could just do a normal eval and then at the end, reduce it to the accuracy needed. But it is not easy to test for smaller than .01 increments since no increments in crafty would be smaller than .01...

The coarser the grain of eval, the less passes MTD(f) has to make to converge to the minimax value. Some programs have a fine grained evaluation function, where positional knowledge can be worth as little as one hundredth of a pawn. Big score swings can become inefficient for these programs. It may help to dynamically increase the step size: instead of using the previous bound, one can, for example, add an extra few points in the search direction (for failing high, or searching upward, adding the bonus, and for failing low, or searching downward, subtracting the bonus) every two passes or so. (Don Dailey found that a scheme like this works well in a version of Cilkchess.) At the end, if you overshoot the minimax value, you have to make a small search in the opposite direction, using the previous search bound without an extra bonus, to make the final convergence. Also, it can be quite instructive to experiment with different evaluation function grain sizes. Sometimes coarse grain functions work better than fine grain, both for NegaScout and MTD(f).

Home * Search * Score * CentipawnsCentipawns, (Centi-pawns)a score unit which corresponds approximately to

one hundredthof a pawn unit. Fixed point representation with centipawn fractions allows a smooth relation of all piece values with a reasonable granularity to distinguish positional scores. 16 or even 15 bits are sufficient to store signed centipawn ranges in hash tables, while sign extension to the common 32-bit integer range is convenient to avoid overflows in scaling terms like in the tapered eval, even with an internal finer granularity used inside the evaluation^{[1]}.^{[2]}## Table of Contents

## Quotes

## Robert Hyatt

Robert Hyatt on score grain in Crafty^{[3]}:Having done all three, my take on the issue is this:Decipawns(0.1) is too coarse. Not every positional consideration is worth 0.1 pawns, so you either have to round the score up to 0.1, or else throw it out since it would be zero.Millipawns(0.001) is too fine. I do not believe that my evaluation has any .001 accuracy ideas in it. As you spread the evaluation scores out, your tree search becomes less efficient (for example, compare a program with no positional scoring to one with, with respect to tree size).Centipawns(0.01) is reasonable. One could make the argument that maybe .05 is better (1/20th of a pawn). Or some other number. But my intuition after trying all three during the development of Crafty is that the right value lies in the interval {0.01, 0.1}. Whether it is on one end or the other, or somewhere in the middle, is a point for conjecture. It is too hard to test the idea, although I suppose I could just do a normal eval and then at the end, reduce it to the accuracy needed. But it is not easy to test for smaller than .01 increments since no increments in crafty would be smaller than .01...## Aske Plaat

Aske Plaat's implementation tip on MTD(f)^{[4]}:The coarser the grain of eval, the less passes MTD(f) has to make to converge to the minimax value. Some programs have a fine grained evaluation function, where positional knowledge can be worth as little as one hundredth of a pawn. Big score swings can become inefficient for these programs. It may help to dynamically increase the step size: instead of using the previous bound, one can, for example, add an extra few points in the search direction (for failing high, or searching upward, adding the bonus, and for failing low, or searching downward, subtracting the bonus) every two passes or so. (Don Dailey found that a scheme like this works well in a version of Cilkchess.) At the end, if you overshoot the minimax value, you have to make a small search in the opposite direction, using the previous search bound without an extra bonus, to make the final convergence. Also, it can be quite instructive to experiment with different evaluation function grain sizes. Sometimes coarse grain functions work better than fine grain, both for NegaScout and MTD(f).## See also

## Forum Posts

## External Links

feat. Keith Tippett, Ian Carr, Karl Jenkins, John Marshall, Roy Babbington, ...

## References

## What links here?

Up one level