sje wrote:Symbolic uses separate tables for white and black. Simple and fast.
I've never liked the separate table approach. In the typical tree, one side has way more entries than the other, thanks to the odd/even approach and one table can be overloaded, while the other is sparsely populated...
This can be caused by odd/even search depths as iterations progress, but also because of how the alpha/beta tree is searched, where the root is an ALL node, and for the cases where you don't change your mind, you end up with a huge number of ODD numbered ALL nodes, and very few even-numbered ALL nodes which really loads the table with the odd-numbered depth TIP branches...
Symbolic, like many programs, has much code dedicated to extensions and reductions. The effect of variable depth search is that both tables are roughly equally utilized. Also, the tables are persistent from move to move and this further reduces any color bias.
I used to think that was true, but statistically the extensions and reductions are applied randomly in the tree. You should just tally the white/black scores that are stored to see what I mean. The only bias that is important is that which happens on the _last_ iteration where one table gets excessive replacements...
I'll try to find that data, I'm pretty sure I saved it, or else it is trivial to add two counters and then print 'em out over several search positions...
bob wrote:The only bias that is important is that which happens on the _last_ iteration where one table gets excessive replacements...
But the last iteration, often unfinished, will have the same extensions and reductions active. The ply depth will range over a significant interval and will overall end with even ply as often as with odd ply.
Now, if one would construct a no-extension program that always searched a fixed number of ply, then it might make sense to consider storing all the hashes in one table regardless of side to move. The only other case I can think of is a perft movepath enumerator that goes to a fixed depth with transposition table assistance.
bob wrote:The only bias that is important is that which happens on the _last_ iteration where one table gets excessive replacements...
But the last iteration, often unfinished, will have the same extensions and reductions active. The ply depth will range over a significant interval and will overall end with even ply as often as with odd ply.
Now, if one would construct a no-extension program that always searched a fixed number of ply, then it might make sense to consider storing all the hashes in one table regardless of side to move. The only other case I can think of is a perft movepath enumerator that goes to a fixed depth with transposition table assistance.
It has never made sense to me to "build a wall" somewhere (such as between black and white positions) because one of the two rooms is guaranteed to be too small, and one too large. I can't think of a good reason to have two tables other than for the btm/wtm issue which is easy to fix with somewhat less overhead of doing a wtm test and a complement which is a direct x86 instruction.
