Feature score use in search

[xr_a_y]

In Minic, I have a structure to hold eval score by feature (passed pawn, material, danger, ...) separately.
In search some decision are taken using score margin, but it feels like some should be more affected by specific features. For example, 7th rank pawn push is often taken as a non pruning condition.

My idea is to use for example danger score in SEE margin instead of something that just depends on depth.
If there is an attack to build, big danger, it is probably worth making some sacrifices, but negative SEE might prevent them.

It is sound ?

[AndrewGrant]

In Minic, I have a structure to hold eval score by feature (passed pawn, material, danger, ...) separately.
In search some decision are taken using score margin, but it feels like some should be more affected by specific features. For example, 7th rank pawn push is often taken as a non pruning condition.

My idea is to use for example danger score in SEE margin instead of something that just depends on depth.
If there is an attack to build, big danger, it is probably worth making some sacrifices, but negative SEE might prevent them.

It is sound ?

Sound, sure. Optimal? Maybe.

I used to do something quite similar -- in fact it was also for adjusting SEE. There is a tradeoff, however. By depending on some evaluation structure in the search, you essentially are forced to run the evaluation at every node. This means you cannot reuse an evaluation from the TT, it means you cant compute a fast evaluation using the knowledge that the previous move was a NULL one.

In theory, you could find enough elo by using eval features in the search to cover that gap. Or even, you could allow yourself to use cached evals, and simply disable whatever dynamic adjustments would have happened. I would argue that its not worth doing, however. Mixing the search with the eval creates a sort of dependence that I was very unhappy with. It took me a long time to untangle the two without losing the small amount of elo I had gained.

[xr_a_y]

Thanks for the input Andrew. I get your point about trying so split search and eval but aren't they are already very interdependent anyway?

Have you ever think / try to encode additional info in hash score to emphasize some feature. For example a short int more in the TT entry can be used to encode a kind of danger level as well as a mobility score.

[jstanback]

In Wasp I have an evaluation term called danger[side] which is used in the Search() routine to restrict pruning. The danger[] term gets increased by some amount for features such as a piece attacked by enemy pawn or a pawn/piece which is attacked and undefended, enemy having a free pawn on 5th rank or beyond, or a mate threat against the king. It's been quite a while since I've tested this and I can't find my notes on how much Elo it gained. I don't think it was much though...

John

[jstanback]

I forgot to mention that my eval hash table is separate from my main hash table and it includes the danger[] term in addition to the overall evaluation.

John

[xr_a_y]

I forgot to mention that my eval hash table is separate from my main hash table and it includes the danger[] term in addition to the overall evaluation.

John

This makes me wanna try also