Quick question about TT

[hgm]

So, you have a clue that the best SEE capture produced a pretty high fail-high bound at the next ply, how do you decide what to store in the hash move? Not by comparing fail-soft bounds, so what is left? It is one thing to know that one move looks bad, but that doesn't help figure out which one will look good.

Well, you could for instance store the first move in the static ordering with a bound that is not very much below what you need.

Of course bringing a single not-already-known-to-be-bad move in front as hash move is of course only of limited usefulness. If that move did not work (which is very likely), the known-to-be-bad moves will still be searched as second, third, etc., before you get to moves tht t least stand a chance.

So perhaps it would be better to do a single iteration at d=1 of all the moves, and sort those that have upper-bounds < alpha-150 to the back, but keep static move ordering for the others. A sort of IID not to get the best move, but to weed out the really poor ones. Normally the d=1 iteration would be completely satisfied from hash, of course, at a draft of N-1.

[bob]

So, you have a clue that the best SEE capture produced a pretty high fail-high bound at the next ply, how do you decide what to store in the hash move? Not by comparing fail-soft bounds, so what is left? It is one thing to know that one move looks bad, but that doesn't help figure out which one will look good.

Well, you could for instance store the first move in the static ordering with a bound that is not very much below what you need.

You _could_. You also _could_ put your foot under a running lawnmower, because there is no law that says you can't. But there is very little information in that "bound" you are quoting. A legitimate try would be to store the first move you searched, since that is the move you search with no ordering information. That might be an existing hash move or it might come from the static move ordering. But I would not use the fail-soft bounds for making that decision because they are very inaccurate.

Of course bringing a single not-already-known-to-be-bad move in front as hash move is of course only of limited usefulness. If that move did not work (which is very likely), the known-to-be-bad moves will still be searched as second, third, etc., before you get to moves tht t least stand a chance.

So perhaps it would be better to do a single iteration at d=1 of all the moves, and sort those that have upper-bounds < alpha-150 to the back, but keep static move ordering for the others. A sort of IID not to get the best move, but to weed out the really poor ones. Normally the d=1 iteration would be completely satisfied from hash, of course, at a draft of N-1.

I think that of everything I read above, the only thing I would try (and I am going to test/measure this idea) would be that if I fail low at a given ply, the best move is going to be stored as the first move actually searched at this ply... Hopefully this will be a hash move stored elsewhere that caused a hit here, but if not, it will at least give me a first move to search. Only issue will be the cost of excluding this from a second search, or letting it get searched a second time if it doesn't fail high the first time.

[hgm]

You _could_. You also _could_ put your foot under a running lawnmower, because there is no law that says you can't. But there is very little information in that "bound" you are quoting.

The point is that there was _a lot_ of information in the bounds of the moves you skipped.

Bounds are just that: bounds. So if an upper-bound is -600, while alpha is +200, they exclude the score from being anywhere in the range (-600,+200). I would call that a lot of information.

[bob]

You _could_. You also _could_ put your foot under a running lawnmower, because there is no law that says you can't. But there is very little information in that "bound" you are quoting.

The point is that there was _a lot_ of information in the bounds of the moves you skipped.

Bounds are just that: bounds. So if an upper-bound is -600, while alpha is +200, they exclude the score from being anywhere in the range (-600,+200). I would call that a lot of information.

It is no more meaningful than a bound of +199. Bounds are not exact. They float all over as the recursive search fails high or low on sub-optimal moves. At the next ply your opponent might try the very best move possible, to return you that -600, where on the next move you try, he tries a lousy move that only returns +199. Still good enough for a fail high at the next ply, but not the best move. Trying to use bounds for comparison is not going to produce information that is anywhere near useful.

[hgm]

That is wrong. An upper-bound of -600 is a lot more meaningful than an upper bound of +199. The first means that the exact score cannot be between -600 and +199. In the latter case it could. An upper bound of -600 implies an upper bound of +199, but not vice versa.

So the upper bound of -600 excludes a lot of cases the other doesn't, some of them very relevant cases. (Like the possibiliy that the move is remotely reasonable...)

In fact the tightest bound found for all depths so far could give you a much more accurate indication of the likelihood the move is no good at all than the bound on the largest depth so far. Search is lazy, and scores ted to approach the window at lager draft. Keeping the tightest bound in the hash table and use it for move sorting could be profitable.

[Zach Wegner]

That is wrong. An upper-bound of -600 is a lot more meaningful than an upper bound of +199. The first means that the exact score cannot be between -600 and +199. In the latter case it could. An upper bound of -600 implies an upper bound of +199, but not vice versa.

So the upper bound of -600 excludes a lot of cases the other doesn't, some of them very relevant cases. (Like the possibiliy that the move is remotely reasonable...)

In fact the tightest bound found for all depths so far could give you a much more accurate indication of the likelihood the move is no good at all than the bound on the largest depth so far. Search is lazy, and scores ted to approach the window at lager draft. Keeping the tightest bound in the hash table and use it for move sorting could be profitable.

True. While generally these lower bounds don't provide much useful information, one possible thing to try is to use Bob's node-based move ordering, but if a move was some threshold below the best move (say a pawn), then override the node ordering and put the move near the end. Or maybe divide the node count by some constant.

[bob]

That is wrong. An upper-bound of -600 is a lot more meaningful than an upper bound of +199. The first means that the exact score cannot be between -600 and +199. In the latter case it could. An upper bound of -600 implies an upper bound of +199, but not vice versa.

Sorry, but _wrong_. When the bound itself is inaccurate, you can't compare 'em. If I have an upper bound of -600 that was computed because I looked at the _wrong_ move at the next ply, I am not sure what the upper bound actually is, because that bound was created by just being less than some other lower bound, which could be based on another move being greater than some other upper bound.

Knuth/Moore discuss the bounds quite a bit.

So the upper bound of -600 excludes a lot of cases the other doesn't, some of them very relevant cases. (Like the possibiliy that the move is remotely reasonable...)

In fact the tightest bound found for all depths so far could give you a much more accurate indication of the likelihood the move is no good at all than the bound on the largest depth so far. Search is lazy, and scores ted to approach the window at lager draft. Keeping the tightest bound in the hash table and use it for move sorting could be profitable.

That would be true _if_ you had real bounds. But we cut off and return bounds that are either above or below the current actual bounds in use, and those values can be wildly inaccurate. Hence we just care that they are above or below, _not_ by how much (again, Knuth/Moore to the rescue)

[bob]

That is wrong. An upper-bound of -600 is a lot more meaningful than an upper bound of +199. The first means that the exact score cannot be between -600 and +199. In the latter case it could. An upper bound of -600 implies an upper bound of +199, but not vice versa.

So the upper bound of -600 excludes a lot of cases the other doesn't, some of them very relevant cases. (Like the possibiliy that the move is remotely reasonable...)

In fact the tightest bound found for all depths so far could give you a much more accurate indication of the likelihood the move is no good at all than the bound on the largest depth so far. Search is lazy, and scores ted to approach the window at lager draft. Keeping the tightest bound in the hash table and use it for move sorting could be profitable.

True. While generally these lower bounds don't provide much useful information, one possible thing to try is to use Bob's node-based move ordering, but if a move was some threshold below the best move (say a pawn), then override the node ordering and put the move near the end. Or maybe divide the node count by some constant.

Avoid that move but how to choose another? And don't tell me to use the error-prone bounds returned for the other moves at this ply, either...