A question about PV

[Adam Hair]

I am trying to understand how an engine's principle variation when analyzing a position may be different when the position is fed directly to the engine as opposed to when the position is reached by moving through a game move by move.

I have a hazy idea that it involves interactions with the hash, but I can't really say I understand why. What is the explanation for this?

[bob]

I am trying to understand how an engine's principle variation when analyzing a position may be different when the position is fed directly to the engine as opposed to when the position is reached by moving through a game move by move.

I have a hazy idea that it involves interactions with the hash, but I can't really say I understand why. What is the explanation for this?

two things.

(1) the TT carries information along from one search to the next, as you suspected, which can change the scores, the actual PV, and even at times the best move. If you start from setting a position, you get none of that.

(2) repetition list is a big influence as well. If you start from a position, no history is present, no repetitions with earlier moves is possible, and draws will be harder to see. If you stuff the moves into the program (something I got Tim to add to xboard eons ago, then you can avoid (or favor) repetitions depending on the position.

Either will affect the results in a major way in the right positions.

[Adam Hair]

I am trying to understand how an engine's principle variation when analyzing a position may be different when the position is fed directly to the engine as opposed to when the position is reached by moving through a game move by move.

I have a hazy idea that it involves interactions with the hash, but I can't really say I understand why. What is the explanation for this?

two things.

(1) the TT carries information along from one search to the next, as you suspected, which can change the scores, the actual PV, and even at times the best move. If you start from setting a position, you get none of that.

(2) repetition list is a big influence as well. If you start from a position, no history is present, no repetitions with earlier moves is possible, and draws will be harder to see. If you stuff the moves into the program (something I got Tim to add to xboard eons ago, then you can avoid (or favor) repetitions depending on the position.

Either will affect the results in a major way in the right positions.

Thanks, Bob. The repetition list was something I did not know about, but I see the logic of maintaining that type of list.

[Adam Hair]

I have another question. I am not certain how to succinctly state it, so I will try to describe it:

I am comparing the evaluations of different positions by several engines at low depths. Let's say that we consider the general consensus for the score for a certain position at a certain depth to be approximately correct (relative to that depth), especially if that eval score holds through additional plies. I have noticed that the score one particular engine gives to a candidate move at low depths can change depending on how many PVs are being run at one time. For one to two PVs, the score at low depths typically falls in line with the general consensus. For three or more PVs (multi pv), the score at those depths is sometimes radically different. As far as I have checked, it does not appear to be a common occurrence (I saw 2 instances out of 100+ positions).

Why would this occur?

[hgm]

Again it must have to do with the hash table. By asking for more PVs, you force the engine to search part of the tree that it otherwise would not consider. I the next iteration the search of the primary move would encounter those stored positions in the hash table.

You must realize that strong engines search highly selectively. They prune many moves because these moves have not a high probability to be good, and they miss many good moves because of that. (But they discover even more good moves by following up the high-probability moves, so it pays off.) If you have forced the engine to think about some low-probability moves in the root, doing these moves deeper in the tree of the primary move will bring it in 'known territory', which could tell it that the move in fact is good, despite the probability of it being good is only low. From that moment on they will take the move seriously, and that could make the root score of the other moves change.

[Don]

I have another question. I am not certain how to succinctly state it, so I will try to describe it:

I am comparing the evaluations of different positions by several engines at low depths. Let's say that we consider the general consensus for the score for a certain position at a certain depth to be approximately correct (relative to that depth), especially if that eval score holds through additional plies. I have noticed that the score one particular engine gives to a candidate move at low depths can change depending on how many PVs are being run at one time. For one to two PVs, the score at low depths typically falls in line with the general consensus. For three or more PVs (multi pv), the score at those depths is sometimes radically different. As far as I have checked, it does not appear to be a common occurrence (I saw 2 instances out of 100+ positions).

Why would this occur?

Keep in mind that for the reasons Bob has stated, chess programs are notoriously non-deterministic. That would be the case even if there were no hash tables because the killer moves themselves would change the move order slightly and that would impact LMR. Also, note that most programs use some form of history heuristic which changes the move order too - and the changes are semi-random being based on the most recent moves that happened to be good. If you don't clear the killer and history between moves you just won't get the same search and with most forms of selectivity you won't even get the same scores and PV - and sometimes not even the same best move.

Some versions of Komodo have a "deterministic" mode which enables you to search any position and be guaranteed of getting the same score, node count, PV and all the important statistics. But that significantly degrades the quality of play because it works by clear any table before each search that could have any impact on the determinism. I use is primary for debugging - some changes should have no impact on the search and if they do it's a sure sign of a bug when deterministic mode is on.

Deterministic mode probably won't return EXACTLY the same result if you start from a fen position where the history of the game is a factor for repetition detection and 50 move rule. Even a single additional draw score buried deep in the tree can be like a butterfly flapping it's wings and impacting the weather patterns several months from now.

[bob]

I have another question. I am not certain how to succinctly state it, so I will try to describe it:

I am comparing the evaluations of different positions by several engines at low depths. Let's say that we consider the general consensus for the score for a certain position at a certain depth to be approximately correct (relative to that depth), especially if that eval score holds through additional plies. I have noticed that the score one particular engine gives to a candidate move at low depths can change depending on how many PVs are being run at one time. For one to two PVs, the score at low depths typically falls in line with the general consensus. For three or more PVs (multi pv), the score at those depths is sometimes radically different. As far as I have checked, it does not appear to be a common occurrence (I saw 2 instances out of 100+ positions).


Why would this occur?

When you ask for multiple PVs, you force the program to search a much larger tree. This gives more opportunity for the scores to "cross-pollinate" from one branch to another. It changes the pruning within a single move as well...

Anything you do to change the shape of the tree can also change the best move or score.

[Adam Hair]

Thanks HG, Don, and Bob. Your answers make sense to me. My uncertainty was due to limited knowledge of how engines search the tree.