The "Secret" TT-move Singular Extension

[bob]

One guiding principle I have adhered to over the years is "if I am going to do something, I am going to do it for a reason." I've tried a ton of SE approaches particularly last year. I have done everything in Crafty, except to do the full Hsu SE implementation. That was a lot of code to add to Cray Blitz... and I unfortunately lost all the source so it would have to be a "complete from scratch" implementation. It is really not so clear that it will ever be a significant gain, which means there are other ideas to examine first. Particularly the inverse SE idea, that of reducing some moves more than others... Got a lot of ideas to try there when I find time...

I often do experiments just to see what happens - not expecting a particular result. Sometimes I do this to challenge my own intuition.

In this case I did that. It produced no significant elo gain for me, after a lot of tuning. I then disabled it in stockfish for validation and it produced no significant gain/loss there either...

[bob]

Well, you can indeed store a best move at all nodes. Just save the best move the search finds, even if it is below alpha.

No, you can't. All you can store is some random move that seems to be best. But at ALL nodes, there is by definition, no "best move". And if you just happen to pick the one that has the best score that is <= alpha you are picking a pretty random move. If you search the real best move at an ALL node, and get the best reply, you get a low score. If you search a much worse move but in response you also look at a much worse move, then you get a better score backed up. it is wrong.

This topic comes up every year or two, I point this out every year or two, someone doesn't believe me every year or two, and they run the experiment. And they discover, every year or two, that it does not work. Having a _good_ move as the best move is important for ordering. If you store poor guesses, you get larger trees. Feel free to try it. Ed did (In Rebel) and discovered that what seemed to be a reasonable idea was actually costing him 10% in increased tree size.

This is just a bad idea. You can use the trick I use to get a little speed bonus, that of storing the _first_ move you search at an ALL node as "best". If it was a hash move, good, we try it first and if it doesn't cause a cutoff, oh well. If it was not a hash move, whatever I search first without a hash move is still a good thing to store and try first. But not some random move based on the old nonsense of "best = - inf" and then best = Max(best, value) where value comes from the recursive search return value...

It really doesn't work well.

I was just saying you CAN save a move. Not that it will necessarily be the best, any more than saying a move causing a beta cutoff is going to be the best. This is a fact. You CAN store it. Now does it help? Well at one point my testing said it did and another point it said it did not. It seems largely seems to depend on how well the fail hard/fail soft stuff is done. After criticizing me and being factually wrong, you then go and propose doing the same thing. Why all the drama Bob? How about just doing a run with a recent crafty and report the results. Say "Yes you can do it, but it does not hep, and here is the data".

OK, in that regard, when you buy a new lawn mower, and the sticker on top of the mowing deck says "do not put hands or feet under here while mower is running", you _can_ put your hands or feet under there. The result might not be very good, but you can do that... Same deal with an ad-hoc move ordered as "best"...

[mjlef]

you still have not presented the data.

[Ralph Stoesser]

Here's an optimization idea. Whenever you extend an alleged forced move from TT, store back in the TT at the end of search() whether this move turned out to be the best move or not. If the extended move was not the best move, the SE exclusion search obviously gave a wrong estimate. The next time you visit this node you won't extend this node again. Assumption: There is no forced move at this node. If the extended move was the best move, then extend this move again next time, but trust in your previous exclusion search and skip the exclusion search part. Assumption: The move is forced.

[Evert]

Here's an optimization idea. Whenever you extend an alleged forced move from TT, store back in the TT at the end of search() whether this move turned out to be the best move or not.

Not sure how that would work: if it isn't the best move, you're hardly going to store it in the TT again...

[Ralph Stoesser]

Here's an optimization idea. Whenever you extend an alleged forced move from TT, store back in the TT at the end of search() whether this move turned out to be the best move or not.

Not sure how that would work: if it isn't the best move, you're hardly going to store it in the TT again...

Consider it an information about the node rather than about the move. If the the old TT move was assumed to be forced, but it turned out it wasn't, the assumption is that the node is a non-singular node.

[bob]

you still have not presented the data.

I presented it here when I ran the tests...

[bob]

Here's an optimization idea. Whenever you extend an alleged forced move from TT, store back in the TT at the end of search() whether this move turned out to be the best move or not.

Not sure how that would work: if it isn't the best move, you're hardly going to store it in the TT again...

Consider it an information about the node rather than about the move. If the the old TT move was assumed to be forced, but it turned out it wasn't, the assumption is that the node is a non-singular node.

What if the _new_ move is, however, singular.

Hsu's approach solved this nicely...