Is centipawn the right unit for measuring the score?

[Uri Blass]

I think that the basic unit that you calculate is not important for the size of the tree because you can always later round the final result that you get.

You can decide that you round evaluation of 0.1242323 to 0.12 pawns and round evaluation of 0.125 to 0.13 pawns.

[Rochester]

The one centipawn is 1 elo. Elo is good. Higher is more better. Otherwise use 1/60.

[syzygy]

I think that the basic unit that you calculate is not important for the size of the tree because you can always later round the final result that you get.

I agree. Finer than 1 centipawn probably is not necessary in the search where you only work with the score that is the sum of all the evaluation factors. But for the individual evaluation factors one centipawn might be too coarse.

I could imagine the use of floating point numbers within the evaluation function. Or perhaps 4-byte fixed point (or 2x4 for midgame / endgame). But it seems fine to return such scores in just 2 bytes, which will fit nicely in the ttable.

[Kempelen]

I use 100, but round to 4. This way I have measured a little elo gain: Search became a bit more efficient in my case....

[Henk]

Maybe the coarser the better (to some extent of course). Why trigger a research if you find a move which is only a tiny bit better ? Only costs time.

For instance I get deeper search when only counting material.

[ZirconiumX]

Maybe the coarser the better (to some extent of course). Why trigger a research if you find a move which is only a tiny bit better ? Only costs time.

Because that tiny bit better could get you a fail high.

For instance I get deeper search when only counting material.

You might as well just use the pawn as your evaluation grain then.

[Henk]

No that does not work. See game below. Perhaps positional play suffering too much.

[pgn]
[Event "Computer Chess Game"]
[Site "HP"]
[Date "2016.08.15"]
[Round "-"]
[White "Fairy-Max 4.8S"]
[Black "SkipperWinb"]
[Result "1-0"]
[TimeControl "120"]
[Annotator "1. +0.07 1... +0.00"]

1. Nf3 {+0.07/8} a6 {+0.00/19 2.1} 2. c4 {+0.12/8 2.8} a5 {+0.00/17 2.0} 3.
Nc3 {+0.12/8 2.7} Nc6 {+0.00/15 2.0} 4. d4 {+0.03/8 1.4} Ra7 {+0.00/16 2.0}
5. Be3 {+0.15/9 2.4} Nb8 {+0.00/15 2.0} 6. Qa4 {-0.05/8 3} b6
{+0.00/15 1.9} 7. O-O-O {+0.07/8 2.2} Nf6 {+0.00/16 1.9} 8. Ne5
{-0.05/8 2.4} h5 {+0.00/14 1.9} 9. f4 {-0.03/8 3} Rh7 {+0.00/15 1.9} 10.
Rg1 {-0.04/8 3} h4 {+0.00/14 1.8} 11. g4 {+0.02/8 1.7} hxg3 {+0.00/14 1.8}
12. hxg3 {-0.03/9 2.3} Na6 {+0.00/15 1.8} 13. Bg2 {+0.01/8 2.3} c6
{+0.00/13 1.7} 14. Qb3 {+0.19/8 4} g6 {+0.00/11 1.7} 15. d5 {+0.48/9 6} c5
{-1.00/10 1.7} 16. d6 {+0.96/9 1.1} exd6 {-1.00/11 1.6} 17. Nb5
{+0.88/9 1.5} dxe5 {-1.00/11 1.6} 18. Nxa7 {+1.41/9 1.7} Qc7 {-2.00/10 1.6}
19. Nxc8 {+2.75/10 2.1} Qxc8 {-2.00/11 1.6} 20. Qxb6 {+2.70/10 4} Ng4
{-2.00/10 1.5} 21. Bd2 {+2.67/9 1.0} exf4 {-3.00/10 1.5} 22. Bb7
{+3.71/9 1.0} Qc7 {-3.00/11 1.5} 23. Qxa6 {+3.90/9 1.5} fxg3 {-4.00/11 1.5}
24. Qa8+ {+5.01/9 2.4} Ke7 {-5.00/11 1.4} 25. Bxa5 {+6.80/9 1.9} Qf4+
{-5.00/10 1.4} 26. Kb1 {+7.72/8 4} Ne3 {-5.00/10 1.4} 27. Rxd7+
{+9.25/8 2.4} Ke6 {-7.00/9 1.4} 28. Qxf8 {+10.55/8 1.7} Nxc4 {-9.00/8 1.4}
29. Bd5+ {+16.90/8 1.3} Kxd7 {-3.00/10 1.3} 30. Qd8# {+79.99/28 0.1}
{Xboard adjudication: Checkmate} 1-0
[/pgn]

[Dann Corbit]

I think that the basic unit that you calculate is not important for the size of the tree because you can always later round the final result that you get.

I agree. Finer than 1 centipawn probably is not necessary in the search where you only work with the score that is the sum of all the evaluation factors. But for the individual evaluation factors one centipawn might be too coarse.

I could imagine the use of floating point numbers within the evaluation function. Or perhaps 4-byte fixed point (or 2x4 for midgame / endgame). But it seems fine to return such scores in just 2 bytes, which will fit nicely in the ttable.

Earlier versions of Yace used floating point eval. Deiter changed it because it made reproducing exact results more difficult.

It seems floating point eval might be a nice fit for using GPU cards.