asymmetric evaluation and TT

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Post Reply
User avatar
xr_a_y
Posts: 1167
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

asymmetric evaluation and TT

Post by xr_a_y » Tue Jun 02, 2020 7:11 pm

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
Posts: 289
Joined: Thu Jan 22, 2015 2:21 pm
Location: Zurich, Switzerland
Full name: Jonathan Rosenthal

Re: asymmetric evaluation and TT

Post by jorose » Tue Jun 02, 2020 7:27 pm

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.
-Jonathan

User avatar
xr_a_y
Posts: 1167
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: asymmetric evaluation and TT

Post by xr_a_y » Tue Jun 02, 2020 7:40 pm

jorose wrote:
Tue Jun 02, 2020 7:27 pm
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 ?

User avatar
xr_a_y
Posts: 1167
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: asymmetric evaluation and TT

Post by xr_a_y » Tue Jun 02, 2020 7:53 pm

jorose wrote:
Tue Jun 02, 2020 7:27 pm
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.

User avatar
hgm
Posts: 24607
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: asymmetric evaluation and TT

Post by hgm » Wed Jun 03, 2020 5:42 am

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
Posts: 289
Joined: Thu Jan 22, 2015 2:21 pm
Location: Zurich, Switzerland
Full name: Jonathan Rosenthal

Re: asymmetric evaluation and TT

Post by jorose » Wed Jun 03, 2020 6:53 am

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.
-Jonathan

User avatar
hgm
Posts: 24607
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: asymmetric evaluation and TT

Post by hgm » Wed Jun 03, 2020 11:57 am

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
Posts: 4584
Joined: Tue Feb 28, 2012 10:56 pm

Re: asymmetric evaluation and TT

Post by syzygy » Sun Jun 21, 2020 12:55 pm

xr_a_y wrote:
Tue Jun 02, 2020 7:11 pm
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
Posts: 4584
Joined: Tue Feb 28, 2012 10:56 pm

Re: asymmetric evaluation and TT

Post by syzygy » Sun Jun 21, 2020 1:02 pm

hgm wrote:
Wed Jun 03, 2020 11:57 am
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.

Post Reply