About king safety

[Kempelen]

Hi,

Rodin has a primitive king safety routine with tropism, number of attacker, a scale factor and a trigger when there are enought material to do mate. I based it at first in a few ideas I see in simple programs like CPW or TSCP. It has been working well, altought it is not perfect. I see now I need a better one. i.e. it does not look at squares above the pawn shield (King_file + 2), or it does not count other features. During last month I have noted this could be a improvement area because at the strenght of Rodin it looses many games because an improper king safety eval.

So far I have developed two or three systems to try, in original and creative ways, where I have included new features like holes, defending pieces, pawn storm and so on. I have made one like the Rebel method of table[] and defects & attacks counter, and also another method of apply bonus and malus for each term evaluated. These systems look good at first, they seems very logical, but I have encounter I big problem to tune so many parameters, not only about the eval, but make search to take adventage of the new routine.

Any test I have done with those algorithms and probes changing values lead to a decrease of near 100 ELO points after 400/500 games played.

My problem so looks in how to make all (value, routines and search) work together. This is not like evaluating a typical eval term where you only change a value and test it, because king safety is a sum of various eval terms which need to work together. I see the part of finding the exact king safety eval terms is very difficult.

This post is asking for help, about how other has dealed with this issue, opinions or tips. I have read other' source code and all they look to me very difficul to tune (i.e. crafty or stockfish). Also there are not two routines the same. All engines seem to have its own and original routine, - which is a good thing . -

I think a good king safety is a need for having a strong engine. Any tip or advice in how to improve my king safety would be much appreciate.

Thanks.
Fermín

[Ferdy]

Hi,

Rodin has a primitive king safety routine with tropism, number of attacker, a scale factor and a trigger when there are enought material to do mate. I based it at first in a few ideas I see in simple programs like CPW or TSCP. It has been working well, altought it is not perfect. I see now I need a better one. i.e. it does not look at squares above the pawn shield (King_file + 2), or it does not count other features. During last month I have noted this could be a improvement area because at the strenght of Rodin it looses many games because an improper king safety eval.

So far I have developed two or three systems to try, in original and creative ways, where I have included new features like holes, defending pieces, pawn storm and so on. I have made one like the Rebel method of table[] and defects & attacks counter, and also another method of apply bonus and malus for each term evaluated. These systems look good at first, they seems very logical, but I have encounter I big problem to tune so many parameters, not only about the eval, but make search to take adventage of the new routine.

Any test I have done with those algorithms and probes changing values lead to a decrease of near 100 ELO points after 400/500 games played.

My problem so looks in how to make all (value, routines and search) work together. This is not like evaluating a typical eval term where you only change a value and test it, because king safety is a sum of various eval terms which need to work together. I see the part of finding the exact king safety eval terms is very difficult.

This post is asking for help, about how other has dealed with this issue, opinions or tips. I have read other' source code and all they look to me very difficul to tune (i.e. crafty or stockfish). Also there are not two routines the same. All engines seem to have its own and original routine, - which is a good thing . -

I think a good king safety is a need for having a strong engine. Any tip or advice in how to improve my king safety would be much appreciate.

Thanks.
Fermín

In adding new eval terms if you sure your code is right and it does not look good in test, then debug it by printing the score of the feature and the board. Examine those and you will be surprised that sometimes you give a big bonus that ought not be, in this case you might need to add conditions or remove the feature at all. Sometimes you will discover that other features are actually contradicting your new feature.

I remember adding big bonus for my rook that attacks opp king, when my 2 rooks are in an open h-file and my opp king is in g8 square. The 2 rooks will deliver a mate in 1 by moving to h8 square, the big bonus was useless because my opp has a knight in g6 square . There are actually a lot of things that you can improve on your eval by printing and examining what your engine is scoring.

[Kempelen]

As more I study my case, more I see is more imprecise to build an attack safety system when you dont have attack tables. Of course is a gain in speed but I see is difficult to determine how is worthy. To test both system is difficult, as to write such attack tables system is a lot of work.

[Ferdy]

As more I study my case, more I see is more imprecise to build an attack safety system when you dont have attack tables. Of course is a gain in speed but I see is difficult to determine how is worthy. To test both system is difficult, as to write such attack tables system is a lot of work.

What do you mean by attack tables? what informations are in there?

[Jan Brouwer]

As more I study my case, more I see is more imprecise to build an attack safety system when you dont have attack tables. Of course is a gain in speed but I see is difficult to determine how is worthy. To test both system is difficult, as to write such attack tables system is a lot of work.

What do you mean by attack tables? what informations are in there?

In general attack tables contain information about attackers and defenders of squares.
In the case of Rotor, the following information is available in every node, for every square and both colors:

Code: Select all

// bit 0..7   : attack directions by BRQ starting with easterly direction (bit 0), going clockwise
// bit 8..15  : attack directions by Q only
// bit 16..17 : number of pawn attacks (0..2)
// bit 18..21 : number of knight attacks (0..10)
// bit 22     : number of king attacks (0..1)
// bit 23..31 : unused

This information is updated incrementally when making and unmaking moves.
Of course, this comes at a price, I estimate this reduces the nodes per second around 30% in my case.

Jan

[Kempelen]

I am learning that king safety is a mix between detailed information and speculation. I am toying with various ideas around this and each time i am improving it a bit, but it is more difficult than what i thing before.

[Ferdy]

As more I study my case, more I see is more imprecise to build an attack safety system when you dont have attack tables. Of course is a gain in speed but I see is difficult to determine how is worthy. To test both system is difficult, as to write such attack tables system is a lot of work.

What do you mean by attack tables? what informations are in there?

In general attack tables contain information about attackers and defenders of squares.
In the case of Rotor, the following information is available in every node, for every square and both colors:

Code: Select all

// bit 0..7   : attack directions by BRQ starting with easterly direction (bit 0), going clockwise
// bit 8..15  : attack directions by Q only
// bit 16..17 : number of pawn attacks (0..2)
// bit 18..21 : number of knight attacks (0..10)
// bit 22     : number of king attacks (0..1)
// bit 23..31 : unused

This information is updated incrementally when making and unmaking moves.
Of course, this comes at a price, I estimate this reduces the nodes per second around 30% in my case.

Jan

I will try this soon, sounds like we can add a condition to existing pruning/reduction depending on the move's safeness. SEE is also almost 100% available. Looking if king is in check can also be simpler.

[PK]

for the record: one of the versions of CPW used mobility functions for collecting the attack data as well. not terribly efficient, but works. The link to that version of eval code is here:

http://chessprogramming.wikispaces.com/CPW_King

for the record: it has been about equal to previous version using king tropism, and both resulted in an improvement.

[Ferdy]

for the record: one of the versions of CPW used mobility functions for collecting the attack data as well. not terribly efficient, but works. The link to that version of eval code is here:

http://chessprogramming.wikispaces.com/CPW_King

for the record: it has been about equal to previous version using king tropism, and both resulted in an improvement.

Very well written, the code is easy to understand.
I have also in eval something like this, but have to try next time via make_move and unmake_move.

[Kempelen]

The more I experiment, the more problems I see. I dont know others, but a fat score with king safety routine can make lazy eval to be wrong many times. The only solution I see is to increase LE margin to not be wrong, but doing so you loose the strong point of doing LE.
How other has solve this?