Yes, margin gets larger with depth, in fact they just use depth or depth * constant as the margin. But I'm still unclear on the rationale. True, near the root the extension affects larger subtrees, but near the leaves the extension occurs vastly more often, so it is not obvious whether the extension costs more near the root or near the leaves in total. Can you explain why you think the total cost of all such extensions would be greater near the root than near the leaves?[/quote]lkaufman wrote:[quote="bobThe Hsu "sticky" stuff was done to address a search instability issue. When I did SE in the 1993/1994 Cray Blitz versions, I originally left that out not knowing whether it was that important or not. It was. The problem is that if you SE a move on iteration N, but when you get to N+1, things have changed a bit and the SE search says "don't extend". Now you are warping the shape of the tree and can see instability in the eval and/or PV moves. I don't remember the specifics since that was almost 20 years ago now, but as I carefully read his explanation and created the sticky TT table, the instability problem was mitigated. There was a "time-out" built in. SE says singular this iteration, but not the next. But the sticky says "treat it as singular". But if the next iteration also says "not singular" it would be removed. I don't remember the precise specifics about that, without getting to the office to dig up Hsu's ICGA paper on the algorithm...
How are these programs varying depth? For example, if the margin gets larger as remaining depth increases, that is probably a stop-gap measure to prevent the tree from exploding, as those moves are less likely to get extended near the root, where the extension affects a very large sub-tree. ."
If you extend one ply at depth 10, you're extending all the subtree by a whole ply, but if you extend 95% of depth 4 searches, you still have 5% depth 4 nodes not extended (and all d5, d6, d7, ...), so the net cost is smaller.