Centipawns and Millipawns

[Edsel Apostol]

What I mean if that is still undefined in the C standard. I already knew that anything^0 = 1 in my algebra class since I'm 13 years old.

If one we're to base on this deductions, if anything^0=1 is defined in the C standard, therefore a shift by 0 will still produce the same number being shifted. So there is no undefined behavior in it. If there will be problems with other hardware concerning this, it must be the problem of the hardware itself and not in the code.

4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are filled with zeros. If E1 has an unsigned type, the value of the result is E1 * 2^E2, reduced modulo one more than the maximum value representable in the result type. If E1 has a signed type and nonnegative value, and E1 * 2^E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined.
5 The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type or if E1 has a signed type and a nonnegative value, the value of the result is the integral part of the quotient of E1 / 2E2. If E1 has a signed type and a negative value, the resulting value is implementation-defined.

They were pretty careful with the definitions. They standardized everything that was predictable across real hardware (of that era) and avoided specifying behaviours for things that have different behaviour on different hardware (shifting by greater or equal to the number of bits in a word, 1s- and 2s-complement machines, etc.)

"The result of E1 << E2 is E1 left-shifted E2 bit positions". If E2 is zero, it is left-shifted by zero bit positions, and there are no vacated bits to fill.

"The result of E1 >> E2 is E1 right-shifted E2 bit positions." Same thing, except that it is implementation-defined if E1 has a signed type and a negative value. Which means it has to do something consistent for your implementation, but the standard does not specify what. In practice, every implementation you'll ever come across leaves the value of E1 unchanged if E2 is zero (because it is what the underlying shift and rotate instructions do, at least on every platform I've ever heard of).

When this standard was written, they had to contend with 1s-complement math and byte- and word-sizes that were not multiples of 8 bits. We are spoiled nowadays: Every machine made in at least the last 20 years has IEEE floats, 2's complement integers, 8-bits to a byte, and 16 or 32 or 64 bits to a word.

Thanks for clarifying that. This discussion arose from a question by Bob if shifts by zero is legitimate in my code. In the case of my code:

Code: Select all

return score & ~(&#40;1<<grain&#41;-1&#41;;

where possible values of grain is 0, 1, 2, 3, 4 then I could say that it is legitimate and it has definite value when zero is used as grain.

[rjgibert]

BTW, "return score & ~((1<<grain)-1);" would be simpler as "return score & ((-1)<<grain);"

[BubbaTough]

I have tried this idea just recently. I'm still using my old scoring of centipawns but at the end of the eval I use something like:

Code: Select all

return score &= ~(&#40;1<<grain&#41;-1&#41;;

where grain is a number 0 to 4.

Grain with 0 value means no change in the score, 1 will make it round to 2, 2 to 4 and 3 to 8, and 4 to 16.

I only have tried grain values 0, 2, 3. 0 still gives the best result, though my number of games is only 1200 each and the difference in elo between 0 and 2,3 is only 10. I will test with 1 to see if it performs better.

Using eval grain in Stockfish works because it uses 256 as Pawn value and it is too coarse for the search so it scales it by 4, meaning the finest unit for its search is 1/64. I think this is the optimal value.

I tried variations of that, and for me...even with a scale of 1/1000...it hurt performance.

-Sam

I think the conclusion for that is that your values are probably reasonably tuned.

Hmmm....if you are right about this, perhaps the conclusion is that people who gain (or do not lose) elo using the grain system would gain more ELO by taking out the grain stuff and tuning their Eval better .

-Sam

[Bo Persson]

When this standard was written, they had to contend with 1s-complement math and byte- and word-sizes that were not multiples of 8 bits. We are spoiled nowadays: Every machine made in at least the last 20 years has IEEE floats, 2's complement integers, 8-bits to a byte, and 16 or 32 or 64 bits to a word.

Except that 36-bit, ones complement hardware is still manufactured. "Of course" it has 9-bit bytes and 72 bit non-IEEE floating point. And it is word-addressed.

http://www.unisys.com/clearpath

That's one reason for the "implementation defined" loophole in the standard.

[Tord Romstad]

I believe some of us are decimal guys, who just don't like fractions. We have no idea about how much 7/32 actually is.

Having a pawn be worth either 10, 100, or 1000 units is just obvious and natural.

I think the situation is similar to the problem of foreign currencies. When visiting a country with a foreign currency for a short period of time, you have to convert all prices to some currency you know before you have any idea how cheap or expensive things are. If you stay there for a longer time, you'll gradually start thinking in terms of the foreign currency, and the need to convert to your home country's currency disappears.

Similarly, when you just start writing a chess program, comparing scores to the value of a pawn is a useful way of getting a rough idea of their magnitude. But after a while, this need disappears. I haven't thought in terms of pawns, centipawns or millipawns for years. I've "gone native", and think in terms of Stockfish's evaluation unit. Converting to centipawns is only necessary when communicating with other authors who use bigger or smaller evaluation units.

In the long run, the pawn is really a too fluid value to use as the basis for the evaluation unit anyway. More than any other piece, the value of a pawn depends on the position. It's been stated elsewhere in the thread that a pawn in Stockfish equals 256 units. This isn't really true any more, although that's how it started many years back. Now, even after nothing more than the piece square table evaluation is done, the value of a pawn can vary between 170 (edge pawn in the middle game) to 250 (endgame pawn).

The reason why the unit in Stockfish is so small is that I like to be able to have tiny advantages or disadvantages which by themselves are worth virtually nothing add up to significant amounts. However, I don't trust the least significant bits of the final result, which is why the value returned by the evaluation function is ANDed with ~3. This should also give a few more beta cutoffs, at least in theory. I've never tested whether ~3 is the optimal constant to use; it's quite possible that ~1 or ~7 would be better.

[zamar]

In the long run, the pawn is really a too fluid value to use as the basis for the evaluation unit anyway. More than any other piece, the value of a pawn depends on the position. It's been stated elsewhere in the thread that a pawn in Stockfish equals 256 units. This isn't really true any more, although that's how it started many years back. Now, even after nothing more than the piece square table evaluation is done, the value of a pawn can vary between 170 (edge pawn in the middle game) to 250 (endgame pawn).

It takes time to get used to such a scale. When reading Stockfish's constants I still automatically divide them by 2, to get the approximative value in centipawns.

The reason why the unit in Stockfish is so small is that I like to be able to have tiny advantages or disadvantages which by themselves are worth virtually nothing add up to significant amounts. However, I don't trust the least significant bits of the final result, which is why the value returned by the evaluation function is ANDed with ~3. This should also give a few more beta cutoffs, at least in theory. I've never tested whether ~3 is the optimal constant to use; it's quite possible that ~1 or ~7 would be better.

I don't believe that changing this "Grainsize" could have measurable effect in playing strength (I could well be wrong though).

[bob]

In the long run, the pawn is really a too fluid value to use as the basis for the evaluation unit anyway. More than any other piece, the value of a pawn depends on the position. It's been stated elsewhere in the thread that a pawn in Stockfish equals 256 units. This isn't really true any more, although that's how it started many years back. Now, even after nothing more than the piece square table evaluation is done, the value of a pawn can vary between 170 (edge pawn in the middle game) to 250 (endgame pawn).

It takes time to get used to such a scale. When reading Stockfish's constants I still automatically divide them by 2, to get the approximative value in centipawns.

The reason why the unit in Stockfish is so small is that I like to be able to have tiny advantages or disadvantages which by themselves are worth virtually nothing add up to significant amounts. However, I don't trust the least significant bits of the final result, which is why the value returned by the evaluation function is ANDed with ~3. This should also give a few more beta cutoffs, at least in theory. I've never tested whether ~3 is the optimal constant to use; it's quite possible that ~1 or ~7 would be better.

I don't believe that changing this "Grainsize" could have measurable effect in playing strength (I could well be wrong though).

It _must_ have a measurable effect. Otherwise you could set the grainsize to 1.0 pawns and not see a difference, yet we know this will ruin the evaluation.

[Sven]

There may be one more small issue to be considered. When storing evaluation results as an integer we have to care about the range of possible values. With a unit of 1/100 pawn, a 16 bit integer allows to store values up to roughly 320 pawns which is definitely sufficient in any possible case. However, with a unit of 1/1000 pawn, a 16 bit integer allows up to roughly 32 pawns only which is not sufficient in some very rare cases (e.g. material advantage of 4 queens where one queen is worth more than 8 pawns). Therefore a 32 bit integer would be better to be on the safe side even for these rare situations.

While the size of an integer variable usually does not matter very much, it may be important when designing optimized implementations for memory consuming data structures like hash table entries or move list entries. In both of these example cases you might be interested in the solution with the smallest memory consumption. This might serve as an argument against the 1/1000 pawn unit.

What do others think about this issue, is it necessary to care about huge material advantages like 4 queens? (In my opinion: yes.)

Sven

[Bo Persson]

What do others think about this issue, is it necessary to care about huge material advantages like 4 queens? (In my opinion: yes.)

Sven

Not really.

If you are a couple of queens up, you should focus on mating the opponent, not capture additional pieces.

[Harald]

What do others think about this issue, is it necessary to care about huge material advantages like 4 queens? (In my opinion: yes.)

When you set up a board (fen command) there could be a material
advantage of 9 queens, 2 rooks, 2 bishops and 2 knights.
With a standard material evaluation (Q=9, R=5, B=3, N=3, P=1)
this is 9*9+2*5+2*3+2*3 = 103 pawns or 10300 centipawns.
There is a little reserve for positional evaluation that you will have
with such a position. The mate values could start outside
+-15000 centipawns. May be infinity=immediate_mate=16000.
That way you can have the score in 15 bit. Or you can double all values
and still be happy with a signed short int score.

A chess engine should support these extreme situations.
A crash with values out of range should not be tolerated.

Harald