writing an evaluation

[lucasart]

hello

my engine still doesn't have an eval: it just has PSQ table + mobility for the moment.
there are a ton of things I could do, but I just wonder where to start.
what is the most usefull thing to start adding/testing ?

thank you
lucas

[gladius]

Roughly in order. And you can spend a lot of time on these .

Passed pawns.
Pawn structure.
King safety.

[rbarreira]

Material

[smatovic]

what is the most usefull thing to start adding/testing ?

I suggest to choose a test suite first, for example the Bratko Kopec Test:

http://chessprogramming.wikispaces.com/ ... Kopec+Test

Then you can edit your evaluation and see how the changes affect your search.

--
Srdja

[smatovic]

Hi Lucas,

i took a look into your eval.c

return PSQTable[phase][piece][color ? sq : sq ^ 070];

not sure, but i think you should "flipflop" the sq for your psq-table instead of XORing with 070 :

#define FLIPFLOP(square) (((square)^7)^56)
...
return PSQTable[phase][piece][color ? sq : FLIPFLOP(sq)];

..
Srdja

[Sven]

Hi Lucas,

i took a look into your eval.c

return PSQTable[phase][piece][color ? sq : sq ^ 070];

not sure, but i think you should "flipflop" the sq for your psq-table instead of XORing with 070 :

#define FLIPFLOP(square) (((square)^7)^56)
...
return PSQTable[phase][piece][color ? sq : FLIPFLOP(sq)];

Since 070 (octal) is 56 (decimal) the only difference between FLIPFLOP and the code of Lucas is the additional XORing with 7 which would also flip the file of the square.

But I don't think this would be necessary in DoubleCheck, and I also don't think it would be correct in the general case:

a) In DoubleCheck (looking at 1.1), all PSQ tables seem to be symmetrical so that flipping the files would not change any single value.

b) In the general case, by flipping also the file you would map g1 (from white viewpoint) to b8 (from black viewpoint) which could be incorrect in a program that has an asymmetrical king PSQ by intent, for instance. The normal mirroring of a position when flipping the colors does involve flipping the ranks only, at least if one of the castling rights is still present.

Btw that code is in psq.h, of course it is used indirectly in eval.c (eval_material).

Sven

[smatovic]

Code: Select all

    {
     0, 0, 0, 0, 0, 0, 0, 0,
    50,50,50,50,50,50,50,50,
    30,30,30,30,30,30,30,30,
     5, 5, 5,10,10, 5, 5, 5,
     3, 3, 3, 8, 8, 3, 3, 3,
     2, 2, 2, 2, 2, 2, 2, 2,
     0, 0, 0,-5,-5, 0, 0, 0,
     0, 0, 0, 0, 0, 0, 0, 0
    },

hmm, this table is from blacks point of view,
if white is on B8 => index 54, then it should be mapped to index 9,
this is done by 54^7^56.

--
Srdja

[smatovic]

hmm, this table is from blacks point of view,
if white is on B8 => index 54, then it should be mapped to index 9,
this is done by 54^7^56.

forget it, you are right.

--
Srdja

[Don]

hello

my engine still doesn't have an eval: it just has PSQ table + mobility for the moment.
there are a ton of things I could do, but I just wonder where to start.
what is the most usefull thing to start adding/testing ?

thank you
lucas

Just a guess, but in this order I would guess:

1. Mobility - will go a long way by itself
2. Pawn structure - start with weak pawns and passed pawns.
3. King safety - hardest to do well but extremely important.

It's impossible to say which you need the most because if your program is out of balance, different things will affect it differently. But my guess is that if you do good mobility next you will get the single biggest payoff if done right. You may have to modify your piece square tables in conjunction with this if they were tuned without mobility.

Unfortunately, it's a huge black art how to do this. It's not difficult to come up with the most important set of features but how to weight them is a bear.