Evaluation functions. Why integer?

[oysteijo]

Hi,

I've started to browse a lot of computer chess code from several different engines. What puzzles me a bit is that "all" engines uses an evaluation function that returns an integer value.

From my ignorant point of view: Would it be more natural to return a floating point value?

Since the answer to the above question is probably "No", can someone explain "why not" ?

-Øystein

[Roman Hartmann]

Hi,
if the value of a pawn in your system would be 1 then you would have to use fractions of a number or just live with the fact that you can't show an advantage of 1/2 pawn.

The other solution is to use a value of 100 (or 1000 if 100 shouldn't be enough) for a pawn which leaves you a lot of room for evaluating positions without the need for any floating point values.

best regards
Roman

[Sven]

Hi,

usually the evaluation unit is centipawns, so if eval() returns +200 it sees the side to move as being two pawns ahead, and if it returns -25, it sees the opponent as being 0.25 pawns ahead.

Today's hardware is faster in processing integers than in processing floating point numbers, and since up to now there seems to be no strong request to have a higher resolution than 0.01 pawns (one might as well define a unit of millipawns, but AFAIK nobody, or only very few engines, do that), returning an int seems to be most appropriate for now.

Sven

[Harald Johnsen]

1) chess engines are older than arithmetic co-processors
2) in todays cpu there is two integer computing unit and only one floating point computing unit

Short answer, integer is faster than floating point.

HJ.

[sje]

My old program Spector used millipawn units with 16 bit scores, and Symbolic uses micropawn units with 32 bit scores.

Are micropawn units useful? Well, they don't add to the cost of computation as far as I can see. With 32 bit scores, micropawns give a range of about +/- 2147 pawns, and that's plenty. There is a slight storage penalty over 16 bit scores, particularly in the transposition tables that contains score values, but memory is cheap.

[sje]

One problem with floating point is the chance of accuracy loss when adding or subtracting two values that differ widely in magnitude.

Experiment: write a program to sum the reciprocals of the first million positive integers. Run the program twice, once in forward scan and once in backward scan. The run that starts with the smallest reciprocal values first will give a much more accurate result than the other.

[Aleks Peshkov]

Integer arithmetic is more natural for humans and more portable across computers.

[Gerd Isenberg]

Hi,

I've started to browse a lot of computer chess code from several different engines. What puzzles me a bit is that "all" engines uses an evaluation function that returns an integer value.

From my ignorant point of view: Would it be more natural to return a floating point value?

Since the answer to the above question is probably "No", can someone explain "why not" ?

-Øystein

Since SSE2 float/doubles are quite fast nowadays, it may worth a try.
But I am not sure about how to define a PVS or MTD(f) null window with float or doubles?

alpha + 4.95e-324 == beta - or some greater epsilon?

Gerd

[bob]

Hi,

I've started to browse a lot of computer chess code from several different engines. What puzzles me a bit is that "all" engines uses an evaluation function that returns an integer value.

From my ignorant point of view: Would it be more natural to return a floating point value?

Since the answer to the above question is probably "No", can someone explain "why not" ?

-Øystein

I'll add mine without worrying about duplication:

(1) speed. floating point is slower than integer.

(2) accuracy. You can't represent numbers like .1 .01, .001 exactly when converting to IEEE floating point. Just like we can't represent fractions like 1/3 exactly in decimal numbers.

(3) comparisons are a pain. == is a no-no in floating point operations because of the inaccuracy mentioned, and the existence of extra precision in the floating point stack that you can't store, so comparisons become problematic and most use a "fuzzy comparison". rather than if (a == b) we would use if (abs(a-b) < .000001) (use whatever precision you want.

4. All bits are significant so you can't just store the lower order N bits in a hash entry, you will have to reserve a full 32 or 64 bits.

5. null-window searches would be problematic in that "what is a null-window"? And before you start trying to play game with scoring increments so that you are sure that nobody changes the score by as little as .0001, go back to the accuracy point and re-read. This would be interesting as well

Integers avoid all of that, and have no down-side, so why would one want to use something that introduces quirks left and right and get nothing in return?

[wlod]

Would it be more natural to return a floating point value?

Since the answer to the above question is probably "No", can someone explain "why not" ?

-Øystein

Programming in integers forces sharper thoughts, it keeps you more alert, ergo--it's good for your (programmer's) brain.

Regards,

• Wlod