Strange draw scores when searching Fine#70

[xr_a_y]

If you are right, I guess some better engine would benefit from not storing alpha_bound also ?

[mar]

sorry for reviving this thread, but I have (had) the same problem, so I thought this may be interesting for other people as well

singular extension is a recent addition to my engine (got nice 20 elo in selfplay) and I started getting weird score oscillations when searching fine #70
I've spent a lot of time trying to figure out what's wrong, tried various "remedies" ranging from kludges to completely insane

turns out the problem was simply my always-replace-if-same-signature (hash)

SE extends a lot of moves throughout the tree and puts a lot of pressure on the TT
precious entries get overwritten and this leads to oscillations when the engine "loses the tread"

at the moment I'm trying to figure out a new replacement scheme that doesn't lose much elo

so the solution is to keep higher draft depths in the TT, but not always, because it's still valuable to overwrite when the difference between depth to store/draft isn't too big, because this helps to resolve smaller subtrees faster. tried draft > depth*n => don't overwrite, will try a bias as well. a lot of test games ahead it seems...

[hgm]

do you store one bound in the TT or both bounds? When I did this test (on the K vs R end-game in Suicide) that showed minimax was an order of manitude faster than alpha-beta, I tried to figure out why alpha-beta was giving me such a slowdown. And I could finally trace that to the same entry oscillating between upper and lower bound, all the time. This require the same sub-tree to be searched many times over. With minimax you would only ever search each position once, for a given depth, and the score would be exact, so that it would satisfy all probes of that or lower depth to produce a cutoff.

[mar]

Interesting observation. I only store one bound. I could probably squeeze extra 16 bits from move which is now 32 bits, but that would complicate things a bit for me, because I have lots of move flags (not to mention other changes that storing 2 bounds would imply)

I thought the vast majority would be zero-width searches anyway, but I'd have to count how many upper/lower bounds are actually coming from zw searches to know for sure.

I may also try to reserve 1 bucket slot as always-overwrite fallback in the case where I'd overwrite a higher draft entry with the same signature (I believe you once told me you use something like this in your engines) - either way, there's a lot of things to try. tweaking my replacement scheme seems a lot easier at this point, I don't know.

[mar]

note that I forgot that for two bounds you'd also need two drafts, I'm linking this thread that contains more details on this topic: http://www.talkchess.com/forum3/viewtopic.php?t=50430

[hgm]

My experiment was done with a vanilla alpha-beta search; this could indeed make a difference. But even in PVS, when the root score changes in the next iteration, half of the TT entries becomes useless for the new null-window.