I'm trying to understand what you mean by this. If you are on the first move at some node (one that is a PV node) and the search returns a score >= beta, what do you do? Do you update alpha allowing it to be greater than beta? Do you update the score and best move in the PV? Or do you pretend like it it was never searched? (You can't do that either or you may not get a Principal variation.)
Or are you saying that you just don't allow this as a result of hash scores returned? I cannot see any logic in this, but I suspect I don't fully understand what you are saying.
Don wrote:Or are you saying that you just don't allow this as a result of hash scores returned? I cannot see any logic in this, but I suspect I don't fully understand what you are saying.
Most people who use PVS don't allow hash table cutoffs at PV nodes. The logic is simple: If you do, you'll sometimes end up with incomplete or incorrect PVs, which makes debugging more difficult. Everything is so much easier when the score returned by the search is always equal to the static evaluation of the position at the end of the PV. Because you don't save a significant amount of nodes by allowing hash table cutoffs at PV nodes anywhay (I've never even been able to measure any difference), there is no point in doing it.
Don wrote:Or are you saying that you just don't allow this as a result of hash scores returned? I cannot see any logic in this, but I suspect I don't fully understand what you are saying.
Most people who use PVS don't allow hash table cutoffs at PV nodes. The logic is simple: If you do, you'll sometimes end up with incomplete or incorrect PVs, which makes debugging more difficult. Everything is so much easier when the score returned by the search is always equal to the static evaluation of the position at the end of the PV. Because you don't save a significant amount of nodes by allowing hash table cutoffs at PV nodes anywhay (I've never even been able to measure any difference), there is no point in doing it.
Tord
Ok, I'm trying to wrap my head around this. So at PV nodes I might use the hash table only to get a move from the hash table? Otherwise I am not interested in anything else returned by the hash table entry for this position?
I'm trying to understand what you mean by this. If you are on the first move at some node (one that is a PV node) and the search returns a score >= beta, what do you do? Do you update alpha allowing it to be greater than beta? Do you update the score and best move in the PV? Or do you pretend like it it was never searched? (You can't do that either or you may not get a Principal variation.)
Or are you saying that you just don't allow this as a result of hash scores returned? I cannot see any logic in this, but I suspect I don't fully understand what you are saying.
Alfred
I believe the idea is that you just ignore cutoffs caused by hash hits on a PV node. I also do not understand the reasoning and don't do this myself. But then again, some don't store actual mate scores or bounds, nor draw scores, etc... all in an attempt to fix a problem by, in my opinion, introducing a fix that is worse than what is supposed to be the problem.
Don wrote:Or are you saying that you just don't allow this as a result of hash scores returned? I cannot see any logic in this, but I suspect I don't fully understand what you are saying.
Most people who use PVS don't allow hash table cutoffs at PV nodes. The logic is simple: If you do, you'll sometimes end up with incomplete or incorrect PVs, which makes debugging more difficult. Everything is so much easier when the score returned by the search is always equal to the static evaluation of the position at the end of the PV. Because you don't save a significant amount of nodes by allowing hash table cutoffs at PV nodes anywhay (I've never even been able to measure any difference), there is no point in doing it.
Tord
Ok, I'm trying to wrap my head around this. So at PV nodes I might use the hash table only to get a move from the hash table? Otherwise I am not interested in anything else returned by the hash table entry for this position?
Don
\
The problem with this is that the PV is over 50% of the search effort... "most" might not allow cutoffs in PV nodes, but I always have...
Don wrote:Or are you saying that you just don't allow this as a result of hash scores returned? I cannot see any logic in this, but I suspect I don't fully understand what you are saying.
Most people who use PVS don't allow hash table cutoffs at PV nodes. The logic is simple: If you do, you'll sometimes end up with incomplete or incorrect PVs, which makes debugging more difficult. Everything is so much easier when the score returned by the search is always equal to the static evaluation of the position at the end of the PV. Because you don't save a significant amount of nodes by allowing hash table cutoffs at PV nodes anywhay (I've never even been able to measure any difference), there is no point in doing it.
Tord
Ok, I'm trying to wrap my head around this. So at PV nodes I might use the hash table only to get a move from the hash table? Otherwise I am not interested in anything else returned by the hash table entry for this position?
Don
\
The problem with this is that the PV is over 50% of the search effort... "most" might not allow cutoffs in PV nodes, but I always have...
I can see some logic to this. It's probably very rare that you would get a cutoff at those nodes, this can only concern the very first move, not several because we are talking about PVS search. And I can imagine that the very few times it happens the search below would terminate very quickly. Perhaps at some point I will try it. If it doesn't make my program weaker it is probably a good thing.
Having said that, I have not had any problems with this, so in a sense I would be fixing something that isn't broken, not a very good engineering principle is it? Since someone claims it made their program stronger, I should be noble minded about this and test to see if it's so.
Don wrote:Or are you saying that you just don't allow this as a result of hash scores returned? I cannot see any logic in this, but I suspect I don't fully understand what you are saying.
Most people who use PVS don't allow hash table cutoffs at PV nodes. The logic is simple: If you do, you'll sometimes end up with incomplete or incorrect PVs, which makes debugging more difficult. Everything is so much easier when the score returned by the search is always equal to the static evaluation of the position at the end of the PV. Because you don't save a significant amount of nodes by allowing hash table cutoffs at PV nodes anywhay (I've never even been able to measure any difference), there is no point in doing it.
Tord
Ok, I'm trying to wrap my head around this. So at PV nodes I might use the hash table only to get a move from the hash table? Otherwise I am not interested in anything else returned by the hash table entry for this position?
Don
\
The problem with this is that the PV is over 50% of the search effort... "most" might not allow cutoffs in PV nodes, but I always have...
I believe what they mean is to not allow hash table cutoffs at nodes with non-zero windows, which are only a small fraction of 1% of all nodes.
Don wrote:Or are you saying that you just don't allow this as a result of hash scores returned? I cannot see any logic in this, but I suspect I don't fully understand what you are saying.
Most people who use PVS don't allow hash table cutoffs at PV nodes. The logic is simple: If you do, you'll sometimes end up with incomplete or incorrect PVs, which makes debugging more difficult. Everything is so much easier when the score returned by the search is always equal to the static evaluation of the position at the end of the PV. Because you don't save a significant amount of nodes by allowing hash table cutoffs at PV nodes anywhay (I've never even been able to measure any difference), there is no point in doing it.
Tord
Ok, I'm trying to wrap my head around this. So at PV nodes I might use the hash table only to get a move from the hash table? Otherwise I am not interested in anything else returned by the hash table entry for this position?
Don
\
The problem with this is that the PV is over 50% of the search effort... "most" might not allow cutoffs in PV nodes, but I always have...
I believe what they mean is to not allow hash table cutoffs at nodes with non-zero windows, which are only a small fraction of 1% of all nodes.
That's what I actually meant. I think I understand it now. Thanks.
Don wrote:Or are you saying that you just don't allow this as a result of hash scores returned? I cannot see any logic in this, but I suspect I don't fully understand what you are saying.
Most people who use PVS don't allow hash table cutoffs at PV nodes. The logic is simple: If you do, you'll sometimes end up with incomplete or incorrect PVs, which makes debugging more difficult. Everything is so much easier when the score returned by the search is always equal to the static evaluation of the position at the end of the PV. Because you don't save a significant amount of nodes by allowing hash table cutoffs at PV nodes anywhay (I've never even been able to measure any difference), there is no point in doing it.
Tord
Ok, I'm trying to wrap my head around this. So at PV nodes I might use the hash table only to get a move from the hash table? Otherwise I am not interested in anything else returned by the hash table entry for this position?
Don
\
The problem with this is that the PV is over 50% of the search effort... "most" might not allow cutoffs in PV nodes, but I always have...
I can see some logic to this. It's probably very rare that you would get a cutoff at those nodes, this can only concern the very first move, not several because we are talking about PVS search. And I can imagine that the very few times it happens the search below would terminate very quickly. Perhaps at some point I will try it. If it doesn't make my program weaker it is probably a good thing.
Having said that, I have not had any problems with this, so in a sense I would be fixing something that isn't broken, not a very good engineering principle is it? Since someone claims it made their program stronger, I should be noble minded about this and test to see if it's so.
- Don
Well, it fixes something that is "broken". If you collect your PV with an array method in the search, you won't get this nasty cuts in the length of your PV when you do not allow TT cuts in PV nodes. Some programmers (and I include myself) like to always have a full PV, and if you use the move of the PV of a previous iteration for any kind of move sorting, it can be an advantage to actually have one.
Don wrote:Or are you saying that you just don't allow this as a result of hash scores returned? I cannot see any logic in this, but I suspect I don't fully understand what you are saying.
Most people who use PVS don't allow hash table cutoffs at PV nodes. The logic is simple: If you do, you'll sometimes end up with incomplete or incorrect PVs, which makes debugging more difficult. Everything is so much easier when the score returned by the search is always equal to the static evaluation of the position at the end of the PV. Because you don't save a significant amount of nodes by allowing hash table cutoffs at PV nodes anywhay (I've never even been able to measure any difference), there is no point in doing it.
Tord
Ok, I'm trying to wrap my head around this. So at PV nodes I might use the hash table only to get a move from the hash table? Otherwise I am not interested in anything else returned by the hash table entry for this position?
Don
\
The problem with this is that the PV is over 50% of the search effort... "most" might not allow cutoffs in PV nodes, but I always have...
I can see some logic to this. It's probably very rare that you would get a cutoff at those nodes, this can only concern the very first move, not several because we are talking about PVS search. And I can imagine that the very few times it happens the search below would terminate very quickly. Perhaps at some point I will try it. If it doesn't make my program weaker it is probably a good thing.
Having said that, I have not had any problems with this, so in a sense I would be fixing something that isn't broken, not a very good engineering principle is it? Since someone claims it made their program stronger, I should be noble minded about this and test to see if it's so.
- Don
Well, it fixes something that is "broken". If you collect your PV with an array method in the search, you won't get this nasty cuts in the length of your PV when you do not allow TT cuts in PV nodes. Some programmers (and I include myself) like to always have a full PV, and if you use the move of the PV of a previous iteration for any kind of move sorting, it can be an advantage to actually have one.
I'm doing a test now to see if anything interesting happens. It is definitely playing slower by a factor of about 1.3. I measure this by taking the median time to play a whole game (as measured over all the games in the auto-tester.) It's currently playing 35 ELO stronger but after only 70 games so there is no statistical confidence here.
