## Rounding

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.
hgm
Posts: 23785
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

### Re: Rounding

In Joker I used 1/256 Pawn. In HaQiKi D and Shokidoki (which have common ancestry) I use 1/25, to get single-byte PST.

kbhearn
Posts: 411
Joined: Thu Dec 30, 2010 3:48 am

### Re: Rounding

if the goal was to squeeze the most worthwhile resolution into the least bits, you'd transform it through a logarithmic scale or sigmoidal as mentioned earlier - you don't really need to tell the difference between 10.00 and 10.01, decipawns might be sufficient by then.

hgm
Posts: 23785
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

### Re: Rounding

True, but that applies only to the total evaluation, and not to the individual piece values.

It would actually be better to use such a sigmoid correction from a theoretical point of view as well, in combination with a delayed-loss bonus: if sacrificing a minor immediately makes the difference between being a Queen down or Queen+Rook down after 20 ply, it would probably be a bad decision to sac the minor. Repairing that can only be achieved if the bonus for delaying the sacrifice can outweigh the additional Rook in the leaves, which is only realistic if you are in a very flat part of the sigmoid there.

FlavusSnow
Posts: 89
Joined: Thu Apr 01, 2010 3:28 am
Location: Omaha, NE

### Re: Rounding

Could these different precision values be set somehow and optimized with the same methods used to optimize other terms (namely CLOP)?

Zach Wegner
Posts: 1922
Joined: Wed Mar 08, 2006 11:51 pm
Location: Earth
Contact:

### Re: Rounding

Don wrote:
Zach Wegner wrote:
Don wrote:I think it's difficult to change the scale one you have committed to one.
I imagine this is true for most people, but IMO this is because most people use inferior programming languages/development strategies.

I prefer to have all tuned values in floating point, and have the actual fixed-point integer arithmetic generated for some arbitrary precision as a compilation step. In my code this can be adjusted per evaluation module, so e.g. you can switch to higher precision for evaluating king safety, and it rounds at the end.
I did once try using floating point for the primary calculation and it was not that long ago, it was on a dual core modern chip. I had heard that on modern chips this might even benefit the speed since we have a separate floating point execution unit that can do this in parallel. However it was not the case, I saw a noticeable slowdown.

I think I made the right decision - to use 1000 as that allows me to use any lower resolution. If I experiment with the "final" resolution that the search uses I will lay it out in such a way that I can easily experiment with other resolutions with no further pain. It's probably only a 2 hour job even if I do it the hard way and we will probably see if 200 for a pawn is an improvement at some point but it's certainly not very high on our list of priorities.
I'm not talking about using the floating point hardware of the CPU. I mean using floating point in the source and converting to fixed point integer math at compile time, with the fixed-point precision easily changed. You can do this in C with the preprocessor:

Code: Select all

``````#define RES 100.0 // centipawns
#define VALUE&#40;x&#41; (&#40;int&#41;(&#40;x&#41; * RES&#41;)
int some_bonus = VALUE&#40;0.34249&#41;; // 34 cp``````