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.......... DIEPdiep wrote:It makes sense for Rebel, not for any other program, to use strict transposition rules like this.Rebel wrote: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.diep wrote:Losing 5 bytes?Joost Buijs wrote: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.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
If you try to lose less say 6 bits, you can store iteration depth.
I am not saying I understand the logic, I don't.
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.
After the bug was fixed I found out it's better to keep the debug code.