Is centipawn the right unit for measuring the score?

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Uri Blass
Posts: 8526
Joined: Wed Mar 08, 2006 11:37 pm
Location: Tel-Aviv Israel

Re: Is centipawn the right unit for measuring the score?

Post by Uri Blass » Tue Aug 09, 2016 7:52 am

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
Posts: 55
Joined: Sat Feb 20, 2016 5:11 am

Re: Is centipawn the right unit for measuring the score?

Post by Rochester » Sun Aug 14, 2016 2:46 am

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

syzygy
Posts: 4446
Joined: Tue Feb 28, 2012 10:56 pm

Re: Is centipawn the right unit for measuring the score?

Post by syzygy » Sun Aug 14, 2016 12:00 pm

Uri Blass wrote: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.

User avatar
Kempelen
Posts: 620
Joined: Fri Feb 08, 2008 9:44 am
Location: Madrid - Spain
Contact:

Re: Is centipawn the right unit for measuring the score?

Post by Kempelen » Sun Aug 14, 2016 3:03 pm

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....
Fermin Serrano
Author of 'Rodin' engine
http://sites.google.com/site/clonfsp/

Henk
Posts: 5713
Joined: Mon May 27, 2013 8:31 am

Re: Is centipawn the right unit for measuring the score?

Post by Henk » Sun Aug 14, 2016 4:11 pm

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
Posts: 1327
Joined: Sun Jul 17, 2011 9:14 am

Re: Is centipawn the right unit for measuring the score?

Post by ZirconiumX » Sun Aug 14, 2016 4:16 pm

Henk wrote: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.
Some believe in the almighty dollar.

I believe in the almighty printf statement.

Henk
Posts: 5713
Joined: Mon May 27, 2013 8:31 am

Re: Is centipawn the right unit for measuring the score?

Post by Henk » Sun Aug 14, 2016 10:45 pm

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
Posts: 9894
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

Re: Is centipawn the right unit for measuring the score?

Post by Dann Corbit » Sun Aug 14, 2016 10:58 pm

syzygy wrote:
Uri Blass wrote: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.
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.

Post Reply