Dann Corbit wrote:My opinion is that if the position has a hash hit, don't clear it. If the position analyzed is not in the hash then clear it.
So if you analyze a game at ply N and follow by analyzing ply N-1 you would clear the hash? That doesn't sound optimal.
If I search a game position at depth N and then search it at depth N-1, then the position will be a hash hit.
If I search a game from start to end one position at a time and then start over from the beginning of the game, it will possibly be in the hash table, depending upon your overwrite policy and other factors. If it is not in the hash, I am not sure how you would improve upon it.
I also see no reason to analyse a game or position at depth N-1 after just completing analysis at depth N.
So I guess that really I do not understand your objection.
Dann Corbit wrote:My opinion is that if the position has a hash hit, don't clear it. If the position analyzed is not in the hash then clear it.
So if you analyze a game at ply N and follow by analyzing ply N-1 you would clear the hash? That doesn't sound optimal.
If I search a game position at depth N and then search it at depth N-1, then the position will be a hash hit.
If I search a game from start to end one position at a time and then start over from the beginning of the game, it will possibly be in the hash table, depending upon your overwrite policy and other factors. If it is not in the hash, I am not sure how you would improve upon it.
I also see no reason to analyse a game or position at depth N-1 after just completing analysis at depth N.
So I guess that really I do not understand your objection.
Dann Corbit wrote:My opinion is that if the position has a hash hit, don't clear it. If the position analyzed is not in the hash then clear it.
So if you analyze a game at ply N and follow by analyzing ply N-1 you would clear the hash? That doesn't sound optimal.
If I search a game position at depth N and then search it at depth N-1, then the position will be a hash hit.
If I search a game from start to end one position at a time and then start over from the beginning of the game, it will possibly be in the hash table, depending upon your overwrite policy and other factors. If it is not in the hash, I am not sure how you would improve upon it.
I also see no reason to analyse a game or position at depth N-1 after just completing analysis at depth N.
So I guess that really I do not understand your objection.
He said ply, not depth.
OK, what I was talking about was not to clear the hash table every time we see something that is not in the hash.
Rather, if someone does a setpos or edit or newgame or whatever, we clear the hash if and only if the next position that we see is not already in the hash table.
Who is 'we'? It seems to me there is some cofusion here as to this is somethg an engine should do or a GUI should do.
I think in an optimal design the engine should only clear its hash when it feels a necessity (e.g. switchig to another variant which causes severe collisions, e.g. suicide in stead of normal), or when the GUI tells it so.
The GUI should only order clearing of the hash table in situations where efficiency is secondary to other issues (such as timing measurements, or reproducibility). Only the GUI or user can know that, and I think it would be bad to put heuristics in the engine to guess it.
hgm wrote:Who is 'we'? It seems to me there is some cofusion here as to this is somethg an engine should do or a GUI should do.
I think in an optimal design the engine should only clear its hash when it feels a necessity (e.g. switchig to another variant which causes severe collisions, e.g. suicide in stead of normal), or when the GUI tells it so.
The GUI should only order clearing of the hash table in situations where efficiency is secondary to other issues (such as timing measurements, or reproducibility). Only the GUI or user can know that, and I think it would be bad to put heuristics in the engine to guess it.
If this is the case, then the GUI must also offer an option to turn that behavior off.
Historically, there has been dirty pool by at least one GUI that rhymes with mess-face, where it would tell engines to clear the hash at every move during a game.
I thik it was not as bad as that: it only sent a 'new' command on every move to WB engines. But WB protocol leaves it intetionally unspecified whether an engine should clear its hash tables on reception of such a command. Some engines do, however, and those are severely disadvantaged in that interface.
Dann Corbit wrote:My opinion is that if the position has a hash hit, don't clear it. If the position analyzed is not in the hash then clear it.
So if you analyze a game at ply N and follow by analyzing ply N-1 you would clear the hash? That doesn't sound optimal.
If I search a game position at depth N and then search it at depth N-1, then the position will be a hash hit.
If I search a game from start to end one position at a time and then start over from the beginning of the game, it will possibly be in the hash table, depending upon your overwrite policy and other factors. If it is not in the hash, I am not sure how you would improve upon it.
I also see no reason to analyse a game or position at depth N-1 after just completing analysis at depth N.
So I guess that really I do not understand your objection.
He said ply, not depth.
OK, what I was talking about was not to clear the hash table every time we see something that is not in the hash.
Rather, if someone does a setpos or edit or newgame or whatever, we clear the hash if and only if the next position that we see is not already in the hash table.
But even if you do it that way, the problem Greg presented will still be there.
Imagine you analyze a game position which happened after a capture, then you edit the position to revert the capture and analyze that position. There is no way the position before the capture will be in the hash, so you would clear the hash table and lose a lot of valuable information.
I don't see a good generic solution which works well both for test suites and general analysis. The goals in each case are directly opposite (in one case, complete independence, in the other increased search speed by depending on the previous search).
For test suites the best general way to ensure independence is to restart the program for each case (unless the program saves/loads data in disk).
Dann Corbit wrote:My opinion is that if the position has a hash hit, don't clear it. If the position analyzed is not in the hash then clear it.
So if you analyze a game at ply N and follow by analyzing ply N-1 you would clear the hash? That doesn't sound optimal.
If I search a game position at depth N and then search it at depth N-1, then the position will be a hash hit.
If I search a game from start to end one position at a time and then start over from the beginning of the game, it will possibly be in the hash table, depending upon your overwrite policy and other factors. If it is not in the hash, I am not sure how you would improve upon it.
I also see no reason to analyse a game or position at depth N-1 after just completing analysis at depth N.
So I guess that really I do not understand your objection.
He said ply, not depth.
OK, what I was talking about was not to clear the hash table every time we see something that is not in the hash.
Rather, if someone does a setpos or edit or newgame or whatever, we clear the hash if and only if the next position that we see is not already in the hash table.
But even if you do it that way, the problem Greg presented will still be there.
Imagine you analyze a game position which happened after a capture, then you edit the position to revert the capture and analyze that position. There is no way the position before the capture will be in the hash, so you would clear the hash table and lose a lot of valuable information.
I don't see a good generic solution which works well both for test suites and general analysis. The goals in each case are directly opposite (in one case, complete independence, in the other increased search speed by depending on the previous search).
For test suites the best general way to ensure independence is to restart the program for each case (unless the program saves/loads data in disk).
I don't see that as a benefit. If we clear the hash every time, then we never save any work.
If we do not clear the hash when the node is already in the table, we will surely save some effort.
I can see that there are times when you would want a "clear the hash after each position analyzed" radio button. But I would also want to be able to turn it off.
Dann Corbit wrote:My opinion is that if the position has a hash hit, don't clear it. If the position analyzed is not in the hash then clear it.
So if you analyze a game at ply N and follow by analyzing ply N-1 you would clear the hash? That doesn't sound optimal.
If I search a game position at depth N and then search it at depth N-1, then the position will be a hash hit.
If I search a game from start to end one position at a time and then start over from the beginning of the game, it will possibly be in the hash table, depending upon your overwrite policy and other factors. If it is not in the hash, I am not sure how you would improve upon it.
I also see no reason to analyse a game or position at depth N-1 after just completing analysis at depth N.
So I guess that really I do not understand your objection.
He said ply, not depth.
OK, what I was talking about was not to clear the hash table every time we see something that is not in the hash.
Rather, if someone does a setpos or edit or newgame or whatever, we clear the hash if and only if the next position that we see is not already in the hash table.
But even if you do it that way, the problem Greg presented will still be there.
Imagine you analyze a game position which happened after a capture, then you edit the position to revert the capture and analyze that position. There is no way the position before the capture will be in the hash, so you would clear the hash table and lose a lot of valuable information.
I don't see a good generic solution which works well both for test suites and general analysis. The goals in each case are directly opposite (in one case, complete independence, in the other increased search speed by depending on the previous search).
For test suites the best general way to ensure independence is to restart the program for each case (unless the program saves/loads data in disk).
I don't see that as a benefit. If we clear the hash every time, then we never save any work.
If we do not clear the hash when the node is already in the table, we will surely save some effort.
I can see that there are times when you would want a "clear the hash after each position analyzed" radio button. But I would also want to be able to turn it off.
I said ensuring independence (clearing hash / restarting the program) in testsuites only. Not when doing any random analysis.
Dann Corbit wrote:My opinion is that if the position has a hash hit, don't clear it. If the position analyzed is not in the hash then clear it.
So if you analyze a game at ply N and follow by analyzing ply N-1 you would clear the hash? That doesn't sound optimal.
If I search a game position at depth N and then search it at depth N-1, then the position will be a hash hit.
If I search a game from start to end one position at a time and then start over from the beginning of the game, it will possibly be in the hash table, depending upon your overwrite policy and other factors. If it is not in the hash, I am not sure how you would improve upon it.
I also see no reason to analyse a game or position at depth N-1 after just completing analysis at depth N.
So I guess that really I do not understand your objection.
He said ply, not depth.
OK, what I was talking about was not to clear the hash table every time we see something that is not in the hash.
Rather, if someone does a setpos or edit or newgame or whatever, we clear the hash if and only if the next position that we see is not already in the hash table.
But even if you do it that way, the problem Greg presented will still be there.
Imagine you analyze a game position which happened after a capture, then you edit the position to revert the capture and analyze that position. There is no way the position before the capture will be in the hash, so you would clear the hash table and lose a lot of valuable information.
I don't see a good generic solution which works well both for test suites and general analysis. The goals in each case are directly opposite (in one case, complete independence, in the other increased search speed by depending on the previous search).
For test suites the best general way to ensure independence is to restart the program for each case (unless the program saves/loads data in disk).
I don't see that as a benefit. If we clear the hash every time, then we never save any work.
If we do not clear the hash when the node is already in the table, we will surely save some effort.
I can see that there are times when you would want a "clear the hash after each position analyzed" radio button. But I would also want to be able to turn it off.
I said ensuring independence (clearing hash / restarting the program) in testsuites only. Not when doing any random analysis.
How does the GUI know that my testsuite is just a random collection of positions as compared to the sequential moves of a game generated with pgn2fen or some related tool? I do this sort of analysis very frequently.
