Singular extension tests

[bob]

Hi,

you sould at least not "delete" the hash move currently stored if the position that now fails low. Thus:

New_Hash_Move = FailLow? Old_Hash_Move : Best_Move.

I think that most if not all elo difference is coming from keeping the "old" hash-move as it has been the best move in some other search on the same position.

Greetings Volker

That is the effect of this approach. If there _was_ a hash move for this position, it is always searched first. So it would be the one that is stored in an ALL node, which is the only place this trick is used. If there was no hash move to suggest what to search first, I just use the first move searched, since that's a reasonable place to start (if I had no best move that is the same move I would start with since it is the first one produced by the generator).

Hi Bob,

I did understand your optimization (using first searched move as hash move in all_nodes). But for testing the ttSE trick you commented it out and lost a lot of elo. My point is that the elo loss is from loosing a former best-move and not from calling some more move generations. Thus instead of commenting out the hole line try to replace it with keeping the hash-move version. It should bring back all elo´s you lost. If not it is a hint for an improvement for me

Greetings Volker

Actually I did both. I went back and removed just the "first-move" trick for ALL nodes, setting best move to 0, I found this dropped 2-3 Elo. I did test ttSE on that version, but found the same -5 or so elo drop by using it. I simply don't find any gain with it. The idea, to me, is basically flawed, because we are not extending a "class" of moves (moves which are S units better than all the rest, we are extending a sub-class of those moves, with no real rhyme or reason for which ones we extend and which we don't, except that they appear in the TT...

[Mincho Georgiev]

It gave me -5 ELO without the check for move for the new entry saving. Could be wrong result though.

Simple change so I have this queued up for a test run...

When you mentioned this, I originally thought that I was doing this. And at one point, I was, but it was broken. I used to stuff the hash-move into a variable "current_move[ply]" and the null-move search was storing this value. But I later modified the code to store that hash move elsewhere so that I could make sure to not search it a second time (along with killers) when I try "the rest of the moves".

Fixing this was a +2 Elo improvement. Again, not big, but not insignificant.

Thanks for prompting me to check and notice it was broken...

In recent versions, the move I stored was always "0"...

Close to my result. Thanks!