Cache over-writing and PV's

[hgm]

In contrast to what you seem to think, the ability to meaningfully exchange information on this forum is essentially dependent on people attaching the same meaning to the same words.

So it was important to set the record straight about the meaning of PV node. A node isn't a PV-node because some programs happen to search it with a routine called Search_pv any more than that it is a "D-node" because micro-Max happens to search it with a routine called D().

This is not a point that is open to discussion, just a statement of fact. But it seems hard for you to leave it at that.

[mvk]

There is no consensus on this. See for example http://www.talkchess.com/forum/viewtopi ... 11&t=38408. A person skilled in the art will recognize when the qualifier "expected" is being omitted.

[hgm]

There is, however, a big difference between not adding it when the context makes it clear what is meant, and insisting that it is always implied and that 'PV node' can never mean anything else than 'expected PV node' in any context.

The whole concept of 'expected PV node' is in fact problematic, as not everyone has the same expectations. So some people might mean something completely different by it than others, which is a source for confusion and discussion. This quite unlike the concept of 'PV node', which has a unique game-theoretical meaning.

[mvk]

Onno's definition is precise and useful in the context of PVS enhanced alpha-beta.

If someone wants to say "Type-1 node by Knuth's definition in the context of plain alpha-beta", they can say that

[hgm]

Onno's definition is precise and useful in the context of PVS enhanced alpha-beta

That doesn't really help if there are many alternative but not equivalent definitions, precise or not...

What makes it IMO less than precise is that it seems to depend on the move ordering.

[Angrim]

It sounds like one thing that would be very useful for your use is a learning cache. This is a cache that only stores exact values that are from the root a search. And this is saved to disk, so that it won't forget what it has learned. This is mostly useful when your engine is playing online and people try to repeat a line against it, but also useful for analysis, in the sort of situation that you were describing where you search a possible resulting position deeply and then want to use the result of that search when searching the parent position.

[syzygy]

In contrast to what you seem to think, the ability to meaningfully exchange information on this forum is essentially dependent on people attaching the same meaning to the same words.

Reasonable people are able to read terms in their proper context. The meaning of "PV node" in Rein's comment was abundantly clear. For reasonable people.

Now let the predicted meaningless and utterly unconstructive semantic discussion continue!

[hgm]

It can only unproductive under the assumption that you are not capable of learning.

You seem to have missed the point that it was I who set the context, by pointing out that many engines do not take hash cutoffs in the PV, exactly for the reason of not clipping it. And guess what: most of these engines are not so stupid, as to replace the result of a high-depth search they get for free by that of a low-depth search they have to work for, in the hope that the latter will give a sufficiently wrong result that would bring them back in window.

So, as you say, reasonable people would have been able to read that in the proper context of a real PV node rather than an expected one.

I happened to introduce the term PV-node into the discussion, which I would have avoided if I had known how much confusion is apparently associated with this, as it was just a sidenote in my posting, which really was about the disadvantages of this search strategy cut/no-cut as a main topic. There was apparently some misunderstanding by Rein about what I meant, (I guess you would not consider him amongst the 'reasonable people'?), so I cleared that up.

Then you barged in, without having anything to say really, apparently for no other purpose than to have an 'unproductive discussion', and complain about it. Well, if you want to play sillybuggers, you get what you ask for.

[syzygy]

I happened to introduce the term PV-node into the discussion,

Stan Arts did, but anyway. Even in your post the term "PV node" can only refer (for the non-mind reader) to a node that at that point in the search appears to be a PV node. If a later searched child of the parent appears to be better, the node stops being a PV node, so in your terminology never was a PV node...

If one is talking about decisions taken in the search() function based on node type, the natural understanding is the expected node type. For example Arasan never takes hash cuts in "PV nodes":

Code: Select all

            // if using TBs at this ply, do not pull a non-TB entry out of
            // the hashtable. Also do not allow hash based cutoff of a PV
            // node.
            if (using_tb || node->PV()) {
               result = HashEntry::Invalid;
            }
...

Clearly node->PV() is not looking into the future. So Arasan is not allowing hash cuts in PV nodes even if the hash entry indicates that the real score is outside the window.

The reason Arasan does this is most likely that hash scores from non-PV node searches are considered not as reliable as hash scores from PV node searches.

[syzygy]

Onno's definition is precise and useful in the context of PVS enhanced alpha-beta.

If someone wants to say "Type-1 node by Knuth's definition in the context of plain alpha-beta", they can say that

Onno's definition is indeed very precise and useful.

Knuth's definition of type 1/2/3 nodes obviously served Knuth's purpose, which was to prove something about the alpha-beta algorithm, just fine. But, unless one applies Onno's common sense approach, Knuth's definition is completely useless for describing an actual search algorithm. For starters, Knuth is only classifying the nodes of a minimal tree and chess programs can't assume they are only searching the minimal tree.

Marsland and Popowich, who introduced the terms PV, CUT and ALL nodes, are discussing an actual search algorithm, so are in fact applying common sense and talking about "expected" type 1/2/3 nodes. When they talk about "PV splitting" they don't mean to limit splitting to type 1 nodes of the minimal tree which is only known after the search is done.