Cache over-writing and PV's

[syzygy]

The thread has digressed as most here do.

I replied directly to what the OP wrote. I quoted the relevant parts. If you reflexively reply without reading what you are replying to, that is not my problem.

[Rein Halbersma]

Many programs do not take hash cuts in PV nodes, and this is of course a guarantee against clipped PVs, which in the tri-angular method can only occur by hash cutoffs.

There is a price, however, which is that you will also never be able to see things (like checkmates) beyond the horizon, through hash grafting. By not accepting a sufficient-draft cutoff you will start to re-search that node at lower depth. Which often will follow the original PV line for that node, (which would be pretty cheap, as all side branches will experience hash cutoffs), but also can stumble on a leaf that has a hashed mate-in-2 score, and do QS there to think it sacrificed a Queen for nothing, to disastrously fail low on that branch, and having to look for alternatives.

So the Crafty method is in principle much better.

I do actually take hash cuts in PV nodes, but not indiscriminately but only if the stored exact value exceeds the current search bounds. My code reads:

Code: Select all

TT_entry = TT.find(p);
if (TT_entry && (TT_entry->depth() >= depth) && TT_entry->is_cutoff(alpha, beta))
       return TT_entry->value();

where is_cutoff() returns true if the stored TT value is outside the current search bounds. In Crafty, AFAICS, the equivalent code is:

Code: Select all

TT_entry = TT.find(p);
if (TT_entry &&  (TT_entry->depth() >= depth) && (TT_entry->is_cutoff(alpha, beta)) || TT_entry->type_is_exact())
       return TT_entry->value();

I.e. Crafty will return if an exact TT value is inside the current search window (and it will do the side table bookkeeping). I just keep searching without side table bookkeeping.

Could you or Bob explain to me why one would return for exact values that lie inside the current search window?

[syzygy]

I do actually take hash cuts in PV nodes, but not indiscriminately but only if the stored exact value exceeds the current search bounds. My code reads:

Code: Select all

TT_entry = TT.find(p);
if (TT_entry && (TT_entry->depth() >= depth) && TT_entry->is_cutoff(alpha, beta))
       return TT_entry->value();

where is_cutoff() returns true if the stored TT value is outside the current search bounds.

Based on this code, it seems to me that you also take a hash cut if the stored value is not exact, but sufficient to show that the "real" score lies outside the window. (This would seem to be in contradiction with your "only if".)

Could you or Bob explain to me why one would return for exact values that lie inside the current search window?

The obvious reason is that you have already searched that position to the required depth or more and determined its exact score (so why repeat that effort if you already know the answer).

[hgm]

I do actually take hash cuts in PV nodes, but not indiscriminately but only if the stored exact value exceeds the current search bounds.

But then it isn't a PV node, right? It will be a fail low or a fail high.

[syzygy]

I do actually take hash cuts in PV nodes, but not indiscriminately but only if the stored exact value exceeds the current search bounds.

But then it isn't a PV node, right? It will be a fail low or a fail high.

It is a PV node because it starts out as a PV node (e.g. searched by search_pv() or searched with beta != alpha +1 which triggers certain behaviour, e.g. different treatment of tt probes).

It may also remain a PV node if you don't take the hash cut (so ignore the stored value).

Once you take the hash cut, it will indeed not be a PV node anymore.

(I sense an endless semantic discussion not having any useful value coming...)

[bob]

Many programs do not take hash cuts in PV nodes, and this is of course a guarantee against clipped PVs, which in the tri-angular method can only occur by hash cutoffs.

There is a price, however, which is that you will also never be able to see things (like checkmates) beyond the horizon, through hash grafting. By not accepting a sufficient-draft cutoff you will start to re-search that node at lower depth. Which often will follow the original PV line for that node, (which would be pretty cheap, as all side branches will experience hash cutoffs), but also can stumble on a leaf that has a hashed mate-in-2 score, and do QS there to think it sacrificed a Queen for nothing, to disastrously fail low on that branch, and having to look for alternatives.

So the Crafty method is in principle much better.

I do actually take hash cuts in PV nodes, but not indiscriminately but only if the stored exact value exceeds the current search bounds. My code reads:

Code: Select all

TT_entry = TT.find(p);
if (TT_entry && (TT_entry->depth() >= depth) && TT_entry->is_cutoff(alpha, beta))
       return TT_entry->value();

where is_cutoff() returns true if the stored TT value is outside the current search bounds. In Crafty, AFAICS, the equivalent code is:

Code: Select all

TT_entry = TT.find(p);
if (TT_entry &&  (TT_entry->depth() >= depth) && (TT_entry->is_cutoff(alpha, beta)) || TT_entry->type_is_exact())
       return TT_entry->value();

I.e. Crafty will return if an exact TT value is inside the current search window (and it will do the side table bookkeeping). I just keep searching without side table bookkeeping.

Could you or Bob explain to me why one would return for exact values that lie inside the current search window?

Speed. Why would you REPEAT a search you already have the value for???

[bob]

The thread has digressed as most here do.

I replied directly to what the OP wrote. I quoted the relevant parts. If you reflexively reply without reading what you are replying to, that is not my problem.

Sorry, but I replied in a DIFFERENT part of the thread discussing EXACT hash hits at PV nodes and short PVs.

[hgm]

It is a PV node because it starts out as a PV node (e.g. searched by search_pv() or searched with beta != alpha +1 which triggers certain behaviour, e.g. different treatment of tt probes).

Well, that is what you get when the definition of terms starts to be blurred by faulty albeit popular implementations.

PV node used to be 'node that is on the PV'. And 'PV' is a game-theoretical concept that is independent of any particular implementation as a computer program. It might be advantageous for programs to guess in advance what might become a PV node and what not, but that doesn't give the node any more status than that of expected PV node.

A guess is just a guess, however, and it can be wrong. It seems pretty stupid to stick to the guess in the face of hard evidence that it is actually wrong. In this particular case it would mean you would be doing a search at inferior depth in the hope it would confirm the guess that was shown wrong at higher depth.

So quite justly this is not what good implementations do; these realize the hash probe revokes the PV status, and threat the node as the all-node or cut-node the hash says it is.

It may also remain a PV node if you don't take the hash cut (so ignore the stored value).

Once you take the hash cut, it will indeed not be a PV node anymore.

(I sense an endless semantic discussion not having any useful value coming...)

Yes, I sense that too. But not from me, as I consider my ruling on this final.

[syzygy]

The thread has digressed as most here do.

I replied directly to what the OP wrote. I quoted the relevant parts. If you reflexively reply without reading what you are replying to, that is not my problem.

Sorry, but I replied in a DIFFERENT part of the thread discussing EXACT hash hits at PV nodes and short PVs.

Stop the trolling nonsense. When you reply to my comments, then that's not a different part of the thread. If you don't know what you are replying to then just don't reply! You do not HAVE to reply to each and every comment that is posted.

[syzygy]

It is a PV node because it starts out as a PV node (e.g. searched by search_pv() or searched with beta != alpha +1 which triggers certain behaviour, e.g. different treatment of tt probes).

Well, that is what you get when the definition of terms starts to be blurred by faulty albeit popular implementations.

(I sense an endless semantic discussion not having any useful value coming...)