jdart wrote:With PVS most moves do not have reliable scores in the hash table. Typically all moves except the PV to fail low and all you know about their scores is that the upper bound is alpha. Since it is the same upper bound for all moves that does not help with ordering.
--Jon
In PVS when first move is almost always the best move then next moves, which are searched with a null window, almost all fail low say at level N. When these next moves were searched at level N-1 they almost all failed high. But failing high with different values so they are stored in the hash with different lower bounds at level N-1 when using fail soft.
So when using fail soft, bounds in hash have different values but their standard deviation may be low (I'd better check this in a test).
jdart wrote:With PVS most moves do not have reliable scores in the hash table. Typically all moves except the PV to fail low and all you know about their scores is that the upper bound is alpha. Since it is the same upper bound for all moves that does not help with ordering.
--Jon
In PVS when first move is almost always the best move then next moves, which are searched with a null window, almost all fail low say at level N. When these next moves were searched at level N-1 they almost all failed high. But failing high with different values so they are stored in the hash with different lower bounds at level N-1 when using fail soft.
So when using fail soft, bounds in hash have different values but their standard deviation may be low (I'd better check this in a test).
Bottom line: random move ordering. When you fail high, you don't fail high on the best move, so that you get the best fail-soft score. You fail high on the FIRST move that returns a score >= beta. That's not necessarily the best score at all.
jdart wrote:With PVS most moves do not have reliable scores in the hash table. Typically all moves except the PV to fail low and all you know about their scores is that the upper bound is alpha. Since it is the same upper bound for all moves that does not help with ordering.
--Jon
In PVS when first move is almost always the best move then next moves, which are searched with a null window, almost all fail low say at level N. When these next moves were searched at level N-1 they almost all failed high. But failing high with different values so they are stored in the hash with different lower bounds at level N-1 when using fail soft.
So when using fail soft, bounds in hash have different values but their standard deviation may be low (I'd better check this in a test).
Bottom line: random move ordering. When you fail high, you don't fail high on the best move, so that you get the best fail-soft score. You fail high on the FIRST move that returns a score >= beta. That's not necessarily the best score at all.
Yes the lower bounds will be quite poor. Maybe if some moves have lower bounds and other moves have upper bounds then the moves with the lower bounds should be tried first ?
jdart wrote:With PVS most moves do not have reliable scores in the hash table. Typically all moves except the PV to fail low and all you know about their scores is that the upper bound is alpha. Since it is the same upper bound for all moves that does not help with ordering.
--Jon
In PVS when first move is almost always the best move then next moves, which are searched with a null window, almost all fail low say at level N. When these next moves were searched at level N-1 they almost all failed high. But failing high with different values so they are stored in the hash with different lower bounds at level N-1 when using fail soft.
So when using fail soft, bounds in hash have different values but their standard deviation may be low (I'd better check this in a test).
Bottom line: random move ordering. When you fail high, you don't fail high on the best move, so that you get the best fail-soft score. You fail high on the FIRST move that returns a score >= beta. That's not necessarily the best score at all.
Yes the lower bounds will be quite poor. Maybe if some moves have lower bounds and other moves have upper bounds then the moves with the lower bounds should be tried first ?
I don't see how moves from the same position can have upper bounds in some cases, lower bounds in other cases...
My general comment on all of this is that it is imprudent to work on program's move ordering if the program has not yet passed all of the usual perft() test position verifications. Similar comments could be made about search, evaluation, etc.
