## Evaluation functions. Why integer?

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
oysteijo

### Evaluation functions. Why integer?

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
Posts: 295
Joined: Wed Mar 08, 2006 7:29 pm
Contact:

### Re: Evaluation functions. Why integer?

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
Posts: 3830
Joined: Thu May 15, 2008 7:57 pm
Location: Berlin, Germany
Full name: Sven Schüle
Contact:

### Re: Evaluation functions. Why integer?

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

### Re: Evaluation functions. Why integer?

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
Posts: 4675
Joined: Mon Mar 13, 2006 6:43 pm

### Re: Evaluation functions. Why integer?

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
Posts: 4675
Joined: Mon Mar 13, 2006 6:43 pm

### One problem with floating point

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
Posts: 882
Joined: Sun Nov 19, 2006 8:16 pm
Location: Russia

### Re: Evaluation functions. Why integer?

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

Gerd Isenberg
Posts: 2142
Joined: Wed Mar 08, 2006 7:47 pm
Location: Hattingen, Germany

### Re: Evaluation functions. Why integer?

oysteijo wrote: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
Posts: 20813
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

### Re: Evaluation functions. Why integer?

oysteijo wrote: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

(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

### Re: Evaluation functions. Why integer?

oysteijo wrote: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