End game flag in zobrist key

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
stevemulligan
Posts: 117
Joined: Wed Jul 20, 2011 12:54 pm
Location: Ottawa, Canada
Contact:

End game flag in zobrist key

Post by stevemulligan » Fri Jun 22, 2012 1:58 pm

If an eval function uses the end game flag to determine the score, do I need to account for this flag in the zobrist key?

The reason I ask is I found in fixed depth testing I get scores from the hash table that are not necessarily from the current end game state.

In self play my version with the hash table gets about -70 Elo and this is the only oddity I've been able to find so far.

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

Re: End game flag in zobrist key

Post by hgm » Fri Jun 22, 2012 1:59 pm

Well, I am pretty sure it can never be the reason for the -70 Elo.

User avatar
stevemulligan
Posts: 117
Joined: Wed Jul 20, 2011 12:54 pm
Location: Ottawa, Canada
Contact:

Re: End game flag in zobrist key

Post by stevemulligan » Fri Jun 22, 2012 3:06 pm

Ahh, I should have been able to answer that myself. I forced the end_game flag to 0 and I still see the big Elo drop in self play.

I'm perplexed. To try and isolate this bug all I do is store the full eval score in the cache. All the other TT features are disabled. So all I'm doing is caching the results of an eval based on Zob key..

And this is still causing a big difference in fixed depth testing and I would expect the Elo difference to be 0. (It is 0 when I play with the same features enabled)

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

Re: End game flag in zobrist key

Post by hgm » Fri Jun 22, 2012 5:30 pm

Well, one test would be to check if the retrieved eval is equal to a freshly calculated eval, in all cases.

But if you don't use the TT for doing something useful (like pruning branches that were already searched, or using the TT move in move sorting), a big table could easily slow you down a factor >2, explaining the 70-Elo drop.

syzygy
Posts: 4455
Joined: Tue Feb 28, 2012 10:56 pm

Re: End game flag in zobrist key

Post by syzygy » Fri Jun 22, 2012 5:48 pm

stevemulligan wrote:I'm perplexed. To try and isolate this bug all I do is store the full eval score in the cache. All the other TT features are disabled. So all I'm doing is caching the results of an eval based on Zob key..
Are searches returning the same evaluation at the same depth in the same number of nodes? (Probably not, unless the slow down mentioned by the previous poster is the explanation.)

Daniel Shawul
Posts: 3758
Joined: Tue Mar 14, 2006 10:34 am
Location: Ethiopia
Contact:

Re: End game flag in zobrist key

Post by Daniel Shawul » Fri Jun 22, 2012 9:27 pm

If you determine the end game flag from material score, then there is no need to incorporate it in zobrist hash key. Game phase is a derived feature not something fundamental like enpassant square that needs to be included in the key itself. What do you use to determine game phase ?

User avatar
lucasart
Posts: 3041
Joined: Mon May 31, 2010 11:29 am
Full name: lucasart
Contact:

Re: End game flag in zobrist key

Post by lucasart » Sat Jun 23, 2012 3:26 am

stevemulligan wrote:If an eval function uses the end game flag to determine the score, do I need to account for this flag in the zobrist key?

The reason I ask is I found in fixed depth testing I get scores from the hash table that are not necessarily from the current end game state.

In self play my version with the hash table gets about -70 Elo and this is the only oddity I've been able to find so far.
The key is a signature of the position. So if you hash the position into it, I don't see any reason to hash an "endgame flag" into it: the endgame flag is already a function of the position!
I don't know what your "endgame flag" is exactly, but I must warn you:
* make sure it's not path dependant !! Adding a condition like the move count since the begining of the game, is a stupid idea...
* what do you do with an endgame flag in the eval anyway ? I'm worried your eval will suffer discontinous behaviour that way. It's better to calculate an opening and and endgame score, and interpolate linearly between the two. That's what everyone does since Fruit showcased this concept.

User avatar
stevemulligan
Posts: 117
Joined: Wed Jul 20, 2011 12:54 pm
Location: Ottawa, Canada
Contact:

Re: End game flag in zobrist key

Post by stevemulligan » Sat Jun 23, 2012 2:37 pm

lucasart wrote: * what do you do with an endgame flag in the eval anyway ? I'm worried your eval will suffer discontinous behaviour that way. It's better to calculate an opening and and endgame score, and interpolate linearly between the two. That's what everyone does since Fruit showcased this concept.
Ahh! I was trying to keep 1 score and I would set the end_game flag at the start of each search by counting # of pieces. That is a much easier way of doing it.

Also, thank you to Ron & HGM, comparing the cached score to the real eval helped track down a couple problems. I'm still stuck on something strange but I have the entire day to track it down :)

Post Reply