I see now how badly written that hash routine was. The amazing thing is that it wasn't affecting the solutions much until it got to 10-ply and above. I didn't notice anything was wrong till ply-18, when it all fell apart. I no longer throw anything away and have a push down stack for a LIFO queue. The most recent hits really made a difference. I will eventually need to limit the queue size, but, right now it's small enough that it's not affecting the time. I took your suggestion: key = (L/(6*400))*6 to prevent overlap. I'm reading your message again to see why I need to capture depth when I think I already have it.hgm wrote: ↑Sun Jul 03, 2022 10:42 pm One more thought:
I think it really hurts when you dont store the search depth in the hash table. For the won positions this depth doesn't matter, because when you have a forced win it should stay a forced win no matter how much deeper you search. So forced wins can be used at any requested depth.
But this is not true for positions where you have not found the forced checkmate yet. I assume you do not store these in the table, because even if you did, you would not be able to use them for anything. You would always have to search then anyway, because you have no idea whether they were obtained by a search that is equally deep or even deeper than the one you try to do now, or whether is is from a shallower search. If you would know that, you could refrain from searching when the current search would not go deeper than the one that produced the table entry, and immediately accept that you would not find a mate.
Since virtually all nodes in the tree will be such 'undecided' nodes before you first find the checkmate, this basically means that your have to find the checkmate without the benefit of a hash table.
I owe you a beer the next time you're in the States. thx for the help