Quick question about TT

[cms271828]

Hi,

In a node (not QS) in the search tree, we generate all the legal moves (lets assume we have some, to avoid checkmate/stalemate situation), and play through them, but supposing none of them are > alpha, then we don't have a best move to play.

So do we just omit storing a move in the TT when we recordHash, just before returning alpha for that node?

Or more simply, if local_best is the best move in that node, it will be initialised as 0 when it is declared, so storing local_best will then store 0, which when probing the TT, we can see that 0 means there is no move.

Thanks

[hgm]

This seems to be what most people do.

In mcro-Max I store the best move anyway, as I keep track of the bestScore independent from alpha, and it s this bestScore that will be returned (fail soft).

The idea is that moves that a move that has a score only very little below alpha at least has a chance to become a PV move in the next iteration. For a move that has an upper bound to its score of -800, I know for sure it blunders away a Queen, and the likelihood of gaining it back in one more ply seems completely unrealistic. So I'd rather not search such a move first. A move that has an upper-bound score slightly below alpha can of course also be arbitrarily bad, but at least there is a chance that it has a reasonable score.

[bob]

This seems to be what most people do.

In mcro-Max I store the best move anyway, as I keep track of the bestScore independent from alpha, and it s this bestScore that will be returned (fail soft).

The idea is that moves that a move that has a score only very little below alpha at least has a chance to become a PV move in the next iteration. For a move that has an upper bound to its score of -800, I know for sure it blunders away a Queen, and the likelihood of gaining it back in one more ply seems completely unrealistic. So I'd rather not search such a move first. A move that has an upper-bound score slightly below alpha can of course also be arbitrarily bad, but at least there is a chance that it has a reasonable score.

This does not work. This discussion has been hashed and re-hashed many times. There is absolutely no concept of a best move at a position where you fail low, fail-soft or not. You simply store a random move if you do this. And that's a mistake, since this is the first move searched. If you don't know the best move, then don't guess. Start with the usual captures, etc. And leave the idea of a best move at a fail-low node where it belongs, in the can.

[hgm]

Well, starting with a random move not proven to be a blunder seems a better proposition then starting with a move that has already proven to be blunder. Even if the latter one would be sorted first statically.

[bob]

Well, starting with a random move not proven to be a blunder seems a better proposition then starting with a move that has already proven to be blunder. Even if the latter one would be sorted first statically.

What if you start with a good capture move instead, which is actually the best move most of the time anyway. And you have not proven that the move you store is not a blunder. You might _assume_ that at the next ply you search the best move first, so that the bound returned by fail-soft is accurate, but that is a poor (and incorrect) assumption. The current move gets refuted by a move that is good enough to produce a score > beta. There may well be another move that produces a much larger score.

This kind of test simply does not work. Unless you move away from alpha/beta.

[cms271828]

Thanks for info,

I basically noticed my TT had move=0 in some entries when I tried to extract PV from it, and it was crashing since there was no move to play.

I think I'll stick with local_best_move=0, and then store that, then I just check for move==0 when I extract the PV after the search is done.

I also noticed my TT spat out an infinite PV, which is what I thought it might do occasionally, I'll have to do a check and stop outputting the PV once I get a repeated position (or equivalently a repeated TT entry)

[jwes]

Well, starting with a random move not proven to be a blunder seems a better proposition then starting with a move that has already proven to be blunder. Even if the latter one would be sorted first statically.

What if you start with a good capture move instead, which is actually the best move most of the time anyway. And you have not proven that the move you store is not a blunder. You might _assume_ that at the next ply you search the best move first, so that the bound returned by fail-soft is accurate, but that is a poor (and incorrect) assumption. The current move gets refuted by a move that is good enough to produce a score > beta. There may well be another move that produces a much larger score.

This kind of test simply does not work. Unless you move away from alpha/beta.

So you are saying that a search at a node that fails low provides zero useful information for move ordering.

[hgm]

What if you start with a good capture move instead, which is actually the best move most of the time anyway. And you have not proven that the move you store is not a blunder. ...

Well, if the good capture move is proven do be a blunder at lower depth, I would think that on the average it is a waste of time to search it first. The move is first searched in QS, and my experience is that if a capture is bad in QS, it usually gets a really low upper bound. Captures typically need a very specific refutation E.g. if a NxB is bad because the N was pinned on Q, so that NxB is refuted by RxQ, then RxQ is usually the only move that refutes it, and almost always the move that is first tried to refute it. So you get an upper bound of -600, even when alpha was at +200.

It seems a bit foolhardy to search a move that scores < -600 at d=0 first at higher depths, in the hope it will give you a cutoff > +200. Even when I knew nothing at all about the other moves, I would still bet my money on one of those blindly rather than stick with the -600.

I can see that it might not always be good to search the move with the highest upper bound first. But I would expect that there is some merit in postponing moves that have upper bounds that fall more than a piece short of alpha And making the frst move with a reasonable upper bound hash move would achieve that. If that move doesn't do the trick becaus ethe upper bound was too optimistic, not much would be lost.

[Gian-Carlo Pascutto]

Well, starting with a random move not proven to be a blunder seems a better proposition then starting with a move that has already proven to be blunder. Even if the latter one would be sorted first statically.

What if you start with a good capture move instead, which is actually the best move most of the time anyway. And you have not proven that the move you store is not a blunder. You might _assume_ that at the next ply you search the best move first, so that the bound returned by fail-soft is accurate, but that is a poor (and incorrect) assumption. The current move gets refuted by a move that is good enough to produce a score > beta. There may well be another move that produces a much larger score.

This kind of test simply does not work. Unless you move away from alpha/beta.

So you are saying that a search at a node that fails low provides zero useful information for move ordering.

He's saying that you don't know for sure what is the best move, and if you don't know for sure, you should be careful about trying a random move instead of the move your normal move ordering would recommend.

I agree with Bob here. (And that doesn't happen a lot)

[bob]

Well, starting with a random move not proven to be a blunder seems a better proposition then starting with a move that has already proven to be blunder. Even if the latter one would be sorted first statically.

What if you start with a good capture move instead, which is actually the best move most of the time anyway. And you have not proven that the move you store is not a blunder. You might _assume_ that at the next ply you search the best move first, so that the bound returned by fail-soft is accurate, but that is a poor (and incorrect) assumption. The current move gets refuted by a move that is good enough to produce a score > beta. There may well be another move that produces a much larger score.

This kind of test simply does not work. Unless you move away from alpha/beta.

So you are saying that a search at a node that fails low provides zero useful information for move ordering.

Correct...