Need help with new history idea

[Michael Sherwin]

An example might be:
If(depth > num) {score = a_two_ply_search (no hash lookup) to compare with the score from a full_depth_search; if(the full_depth_search scores > than one_pawn more than the two_ply_search) histTblFail[fig][fs][ts] += 100;}

The idea is to have a history table of moves that look okay but at higher depths fail tactically. This table can then be used I hope for LMR reductions so that moves with a high tactical failure rate are not reduced. Other uses may be possible.

What would alpha/beta be set at in the two ply search and what would the test look like?

It does not seem to be working for me so I think that I might be doing it wrong.

[Michael Sherwin]

An example might be:
If(depth > num) {score = a_two_ply_search (no hash lookup) to compare with the score from a full_depth_search; if(the full_depth_search scores > than one_pawn more than the two_ply_search) histTblFail[fig][fs][ts] += 100;}

The idea is to have a history table of moves that look okay but at higher depths fail tactically. This table can then be used I hope for LMR reductions so that moves with a high tactical failure rate are not reduced. Other uses may be possible.

What would alpha/beta be set at in the two ply search and what would the test look like?

It does not seem to be working for me so I think that I might be doing it wrong.

I said that wrong. The idea is to have a history table that looks better when searched at full depth. Those moves are not reduced.

[zd3nik]

It does not seem to be working for me so I think that I might be doing it wrong.

Could you define "not working"? Is it simply not improving playing strength or perhaps failing some test position(s) you expected it to solve?

I wonder how expensive those 2 ply searches without hash lookup are? Perhaps they're simply offsetting any benefit you're gaining from the change. What value of num are you using in the (depth > num) test?

Regards,
STC

[Michael Sherwin]

It does not seem to be working for me so I think that I might be doing it wrong.

Could you define "not working"? Is it simply not improving playing strength or perhaps failing some test position(s) you expected it to solve?

I wonder how expensive those 2 ply searches without hash lookup are? Perhaps they're simply offsetting any benefit you're gaining from the change. What value of num are you using in the (depth > num) test?

Regards,
STC

I had not gotten that far into the idea so not working meant running slow. The two ply searches cost no noticeable time delay. I was using 5 for num. It was running slow because of the zero window alpha/beta values I was using. That is why I asked what values I should be using. Instead of one pawn, 20 centipawns seem to be closer to what I'm looking for. Instead of num = 5, num = 3 seems okay. My problems with speed went away when I used a much wider a/b window. It is too early to talk of an improvement but some results have been no worse.

[zd3nik]

My problems with speed went away when I used a much wider a/b window.

That's the opposite of what I would expect. A narrow alpha/beta window should always be faster than a wider one. If not, perhaps the narrower windows are triggering a lot of re-searches for some reason. If so you'll probably want to track that down.

Perhaps you're referring to the gap between the full depth search alpha/beta and the 2-ply search rather than the alpha/beta window size? For example, if you're full depth alpha/beta window is A/B and your 2-ply search window is (A-delta)/(B-delta), are you referring to 'delta'?

If so, I've tried similar things before, including very recent SE experimentation, and I would concur that 'delta' would be better as a sub-pawn value like 20 or 50.

Swap off evaluation (SEE: static exchange evaluation), generating good captures first via other techniques, killer move heuristic, transposition table, etc should all take care of placing moves with large gains first in your search order. The technique you're talking about seems better suited for sorting moves "after" those processes, in which case you're dealing with more subtle positional values.

Just my two cents. Hopefully I'm not talking about something completely different than what you're talking about!

[Michael Sherwin]

The idea is interesting but probably another dead end. But, thanks anyway.

[jordanbray]

I find when tuning something like this the best method is to first disable search reductions and look at node count on some test positions. The history tables should cause more cut-offs, which should reduce the number of nodes.

If that is working, then look at nodes per second, and if that is also within good bounds then it is a useful change.

Move ordering is kinda a black-magic sort of thing, and there's no real way (IMHO) to really know if it'll work without testing.