Posted: Sat Jan 21, 2012 3:00 pm
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.
Hosted by Your Move Chess & Games - chessusa.com
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:Don wrote: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.Zach Wegner wrote:I imagine this is true for most people, but IMO this is because most people use inferior programming languages/development strategies.Don wrote:I think it's difficult to change the scale one you have committed to one.
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 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.
Code: Select all
#define RES 100.0 // centipawns #define VALUE(x) ((int)((x) * RES)) int some_bonus = VALUE(0.34249); // 34 cp