Newbie needs help: the TT breaks my PV scheme

[Tony]

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.

I see for most people it's easier to copy Fruit than to understand it.

Fruit doesn't allow reductions in PV nodes. If it would accept hashtable cutoffs in PV nodes, they might be from reduced searches, which might give serious instabillities.

Tony

[bob]

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

Here is one simple way to cause this... Do a deep ponder search, which fills the TT with deep draft entries. Opponent makes a different move. You start over at iteration 1, but most everything transposes by ply 4. Do you not use all those good "LOWER" or "UPPER" entries to speed up this search, and just have to plod thru all the iterations with no quick jump to a deep depth?

Just doesn't make good sense, IMHO. And allowing this has never caused me any problem other than perhaps failing high but not being able to resolve the score before time runs out. Without this trick, I probably would not have even had time to fail high on the good move and might have actually missed it... That's worse than the original problemof short PVs by a big margin.

[Tony]

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

Here is one simple way to cause this... Do a deep ponder search, which fills the TT with deep draft entries. Opponent makes a different move. You start over at iteration 1, but most everything transposes by ply 4. Do you not use all those good "LOWER" or "UPPER" entries to speed up this search, and just have to plod thru all the iterations with no quick jump to a deep depth?

Just doesn't make good sense, IMHO. And allowing this has never caused me any problem other than perhaps failing high but not being able to resolve the score before time runs out. Without this trick, I probably would not have even had time to fail high on the good move and might have actually missed it... That's worse than the original problemof short PVs by a big margin.

That's actually the reason why I don't allow the cutoffs.

It happened quite a few times that I would reach 12 ply in a sec, and then block because I basicly started an uninformed 13 ply search. IID never solved that.

It might matter less now, because EBF is much lower nowadays.

Tony

[Don]

That's actually the reason why I don't allow the cutoffs.

It happened quite a few times that I would reach 12 ply in a sec, and then block because I basicly started an uninformed 13 ply search. IID never solved that.

It might matter less now, because EBF is much lower nowadays.

Tony

Ok, I my implementation of this was buggy and I was throwing out too many which probably explains why it was too slow.

You say you don't allow cutoffs, so I'm not accepting hash table scores that create beta cutoffs. What if the score <= alpha? Does the same reasoning apply? If I return this, it is returned to the parent as a beta cutoff, and it's coming indirectly from a hash table entry.

I normally test changes with a quicky performance test (100 middlegame positions to see how long and how many nodes it takes to do an N ply search) and at 8 ply there is no statistical difference in time or nodes searches. (it searches 1/40 of a percent more nodes.) I'm assuming the beta cutoff rule, not alpha and beta.

I guess I'm willing to keep this change if it actually solves any problems since it is obviously not hurting anything. If fruit does it, it probably isn't the worst thing in the world.

[bob]

That's actually the reason why I don't allow the cutoffs.

It happened quite a few times that I would reach 12 ply in a sec, and then block because I basicly started an uninformed 13 ply search. IID never solved that.

It might matter less now, because EBF is much lower nowadays.

Tony

Ok, I my implementation of this was buggy and I was throwing out too many which probably explains why it was too slow.

You say you don't allow cutoffs, so I'm not accepting hash table scores that create beta cutoffs. What if the score <= alpha? Does the same reasoning apply? If I return this, it is returned to the parent as a beta cutoff, and it's coming indirectly from a hash table entry.

I normally test changes with a quicky performance test (100 middlegame positions to see how long and how many nodes it takes to do an N ply search) and at 8 ply there is no statistical difference in time or nodes searches. (it searches 1/40 of a percent more nodes.) I'm assuming the beta cutoff rule, not alpha and beta.

I guess I'm willing to keep this change if it actually solves any problems since it is obviously not hurting anything. If fruit does it, it probably isn't the worst thing in the world.

Note that this is far less of an issue in just running test positions. It is more likely to be an issue when playing real games with pondering enabled so that you fill the TT with stuff while pondering, then the opponent plays a different move but the TT stuff is still useful because of transpositions in the order here and there...

So it becomes more of a "game mode" issue rather than "test position mode"...