Is centipawn the right unit for measuring the score?

[Karol Majewski]

Hi,

I am newbie to programming world. I write my UCI engine from scratch. Currently I work on evaluation function and came to the conclusion that using centipawn as a base unit to measure the score has one drawback: I can't write 1/8 pawn as 12.5 cp; I have to round it to 12 or 13 cp. So, a single factor that is worth e.g. 1/8 pawn will always be more or less than two factors worth 1/4 pawn each.

My idea to get rid of this is to use diffrent value for a pawn. Instead of 100 I'd give 64 or 128. Of course, one can argue that it won't allow you to use values such as 1/5 pawn, but still I think that in chess we generally use values like 1/8, 1/16 rather than 1/5, 1/7.

If I am not mistaken, Deep Thought team used 128 for a pawn, but later, while creating Deep Blue, they switched to 100.

How do you guys solve these issues? Do you give 12 or 13 pawn for 1/8 pawn and allow for round-off error?

[cdani]

Hi! I use 1/100th and I hardly need more precision. But anyway is a good idea to have more, especially for when the engine is stronger. Stockfish has 1/256.

[Vinvin]

Diep used millipawn too : https://chessprogramming.wikispaces.com ... elling.jpg

But the UCI protocol prescribes centipawns

Code: Select all

* score
		* cp <x>
			the score from the engine's point of view in centipawns.
		* mate <y>

You can round the value.
Current top engines are not reliable to a precision of 0.01 eval ...

[PK]

If You prefer to have 1/8th, 1/12th, 1/16th and 1/24th of a pawn (at the expense of not having 1/10th), try using pawn value of 96.

[AlvaroBegue]

Will your engine be stronger if you make the feature worth 1/8 of a pawn than if you make it worth 0.12 or 0.13 pawns? I seriously doubt it.

You could also give up on the integer-only scores and use a float. If you want to be able to store the score in just a few bits (for the transposition tables, mainly), transform it at the end of the evaluation function (to a half-precision number, for instance).

[Robert Pope]

How do you guys solve these issues? Do you give 12 or 13 pawn for 1/8 pawn and allow for round-off error?

Perhaps the bigger question is, why do you think that a feature is more accurately represented by 12.5/100 and not 12/100 or 13/100? And what will you do when you find a feature that is worth 13/73 of a pawn, because you are going to have to round that no matter what representation you pick.

I think you are confusing precision with accuracy.

[hgm]

What the engine uses internally is your business. In Joker I use units of 1/256 pawn. In Shokidoki and HaQiKi D I use units of 1/25 Pawn.

To be compliant with the protocol you would have to convert tocenti-Pawn, however. So in Joker I divide by 2.56 before printing, in Shokidoki and HaQiKi D I multiply by 4.

[Karol Majewski]

Thank you. I think I'll use 128 for a pawn and then convert to cp at the output (-21.875%).

[elcabesa]

In vajolet I'm using 1/10000 of pawn as base. But I don't think I really need that precision.

[Cardoso]

The Deep Blue team had the same idea.
Their basic pawn value was 128.
But I don't know if later they switched back to 100.

Keeping it at 128 is ok, but don't go to something like 1000 because in this case the finner the grain of the evaluation function is the bigger the search trees are and so the search becomes less efficient.

Alvaro