asymmetric evaluation and TT

[xr_a_y]

I'm trying to use an asymmetric evaluation in Minic in order to implement some kind of playing style (as promised earlier).

I was going for a simple trick, namely use a color indexed set for some parameters and putting special stuff for the root side to play in the appropriate color when search starts.

For example in searchRoot(Position & p)

Code: Select all

param[p.c] = 1 + styleStuff;
param[~p.c] = 1;

so that in evaluation(Position & p), deeper in the search tree

Code: Select all

score += param[White] - param[Black];

shall be fine.

But I think this is not working unless position hashing is taking root position color (side to play) into account ... because evaluations stored in hash table won't know what was the "asymmetric side".

I don't think I'll take the risk of splitting in two my hash table for this, I wonder how others are working with this issue ?

[jorose]

I am working on the issue of asymmetric eval, because I would like to have asymmetric contempt as a feature.

In your case I am not quite following the issue, as the side to move should be part of the position hash anyways? The position is not the same if it is white or black to move respectively?

In any case, an easy solution for you would be to make the style be symmetric, i.e. Minic can assume the opponent is trying to minimize how interesting the position is stylistically. This was the solution Winter had up until the newest released version v0.8.

[xr_a_y]

I am working on the issue of asymmetric eval, because I would like to have asymmetric contempt as a feature.

In your case I am not quite following the issue, as the side to move should be part of the position hash anyways? The position is not the same if it is white or black to move respectively?

In any case, an easy solution for you would be to make the style be symmetric, i.e. Minic can assume the opponent is trying to minimize how interesting the position is stylistically. This was the solution Winter had up until the newest released version v0.8.

I meant the "root side to move" must be part of subsequent computed hash, because now root stm is part of evaluation, no ?

[xr_a_y]

In any case, an easy solution for you would be to make the style be symmetric, i.e. Minic can assume the opponent is trying to minimize how interesting the position is stylistically. This was the solution Winter had up until the newest released version v0.8.

That's what I did first, but then the engine is equally focused on not allowing the opponent to play the given style.

[hgm]

This should not be an issue. For asymmetric eval it doesn't matter who has the move, neither in the root, nor at the leaf. Only the collor matters. The hash table will automatically consistent.

Of course in a game usually the side to move in the root will always be the same color. But during analysis it will not be, and then it is color that counts.

[jorose]

The actual issues with assymetric eval arises when you consider the AB-framework. E.g. when you consider null window searches, the search can fail high and return beta. However, if the same position would be evaluated in the parent node it could also fail high.

[hgm]

Then you must define 'asymmetric evaluation' different from how I understand it. It sounds to me like you are talking about evaluation in a non-zero-zum game, where each player has a different goal, and the same position with the same side to move would be evaluated differently by white and by black (i.e. not the exact opposit). What I would call 'asymmetric' does not have that, but would merely give a different evaluation for color-reversed positions, and who made the evaluation would only determine the sign.

[syzygy]

But I think this is not working unless position hashing is taking root position color (side to play) into account ... because evaluations stored in hash table won't know what was the "asymmetric side".

I don't think I'll take the risk of splitting in two my hash table for this, I wonder how others are working with this issue ?

I guess this should a problem only if the root position color is not always the same, i.e. when the engine is being used for analysis and not when the engine is playing a game.

If the engine is being used for analysis (switching back and forth between root position with white to move and black to move), does it really make sense to use an asymmetric evaluation that switches sides depending on whose turn it happens to be in the root position?
If your answer is no (which imho it should be), then you could consider
(1) disabling the asymmetry in analysis mode and avoid messing up the hashtable, or
(2) making sure that the asymmetry doesn't switch sides, so allow the user to tie it to either white or black.

Last time I looked, this problem was simply ignored in Stockfish (where contempt introduces asymmetry). In Cfish I make sure that contempt is either disabled or fixed at white or black contempt in analysis mode.

My experience with Stockfish shows that the problem is too subtle to bother 99.99% of users.

[syzygy]

Then you must define 'asymmetric evaluation' different from how I understand it. It sounds to me like you are talking about evaluation in a non-zero-zum game, where each player has a different goal, and the same position with the same side to move would be evaluated differently by white and by black (i.e. not the exact opposit). What I would call 'asymmetric' does not have that, but would merely give a different evaluation for color-reversed positions, and who made the evaluation would only determine the sign.

I haven't tried to understand yet what kind of asymmetric evaluation the TS is talking about. Asymmetric evaluation means the same to me as it means to you, and I would add that alpha-beta cannot deal with anything else than zero-sum games.