Transposition Table - Replacement and PV

Discussion of chess software programming and technical issues.

Moderators: hgm, Dann Corbit, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
Rebel
Posts: 6357
Joined: Thu Aug 18, 2011 10:04 am

Re: Transposition Table - Replacement and PV

Post by Rebel » Sun Dec 09, 2012 12:47 pm

diep wrote:
Rebel wrote:
diep wrote:
Joost Buijs wrote:
Don wrote: Something else I wanted to someday experiment with (which is highly speculative and probably won't work) is to actually give some kind of preference to how recent the entry is. I don't mean the generation or age but perhaps the node counter when the entry was stored. If it's relevant to store the "generation" it seems like this is just a abstraction of the same concept. I would of course still give generation and depth precedence.
Don
It seems like a good idea to add the node count into the formula. I never thought about this. I am certainly going to try this some day.
Losing 5 bytes?

If you try to lose less say 6 bits, you can store iteration depth.
Funny that you mention this. I store the iteration depth as well. If iteration depths do not match then the depths in the tree should match else I don't reward a transposition. These 2 extra checks and 2 extra bytes in the TT (compared to the standard approach) slow down my search with 10% but the performance (in matches) although not big are consistently better.

I am not saying I understand the logic, I don't.
It makes sense for Rebel, not for any other program, to use strict transposition rules like this.

Your selective search, after the brute force depth, it is dependant upon the iteration depth, that's why.

Now if we clear hashtable and just search 1 position you still wouldn't notice it, maybe. Yet if we start overwriting previous searches, suddenly at iteration I depthleft D we will get already a cutoff from a previous search at the same position with depthleft D and iteration depth I' which was a lot larger, which was cutoff right after somehow as we are in the selective search depth there.

This would be a dubious cutoff. In short you would need complicated logics involving both depths stored in transpositiontable.

Probably you found a clever simple shortcut there which loses you less (though 10% timereduction) yet works well enough.
It's true (and logic) that my approach bites aging and so I don't use aging which is the downside. Funny again Vince, I saw in my source code a remark that I made these (debug) changes due to a bug in the TT I discovered during a game in Leiden against.......... DIEP :lol:

After the bug was fixed I found out it's better to keep the debug code.

diep
Posts: 1786
Joined: Thu Mar 09, 2006 10:54 pm
Location: The Netherlands
Contact:

Re: Transposition Table - Replacement and PV

Post by diep » Sun Dec 09, 2012 1:37 pm

Ed, was this the famous escape of Diep to a draw being total lost?

I normally would've resigned that game, yet the mainline of Rebel and its score was so much off reality that i considered playing another few moves :)

User avatar
Rebel
Posts: 6357
Joined: Thu Aug 18, 2011 10:04 am

Re: Transposition Table - Replacement and PV

Post by Rebel » Sun Dec 09, 2012 3:07 pm

diep wrote:Ed, was this the famous escape of Diep to a draw being total lost?
I vaguely remember, yes.
I normally would've resigned that game, yet the mainline of Rebel and its score was so much off reality that i considered playing another few moves :)
Next time we play I will blindfold you first :wink:

Post Reply