Application Programmers Manual: Invalidation of Node Values

From DSL

As explained in the node structure section, a node value is invalidated (its contents are no longer up to date) whenever any of the following operations takes place in the node or in any other node that is relevant to it:

• Evidence is observed/cleared

New marginal distributions should be computed whenever a piece of knowledge about the model is incorporated/discarded.

• Arcs are added/removed

Adding and removing parents naturally invalidates the value of the new child node.

• Definition of a node changed substantially

By substantially we mean a change that invalidates the current value (for example, a change in the conditional probability distribution of a chance node should invalidate the belief state of the node. Adding/removing an outcome should invalidate the node also). Changes that are not substantial will not lead to invalidation (for example, changing the name of one of the choices of a decision node). Note that some of these "important" changes will not be automatically detected by the library and you will have to explicitly notify the node about them.

After any of these operations has taken place, relevance reasoning will automatically invalidate the values of all the nodes that are affected by the operation. This step is taken by default but means are provided to skip this automatic invalidation of nodes individually for each of the operations. SetRelevanceLevelFlag() and ClearRelevanceLevelFlag() network methods give this ability. For instance, if we do not want relevance reasoning to be applied whenever an arc is added, we should issue the following call:

aNetwork.ClearRelevanceLevelFlag(DSL_RELEVANCE_ARC_ADDED);

On the other hand, if we want to activate relevance reasoning again for the arc adding operation, we should call:

 aNetwork.SetRelevanceLevelFlag(DSL_RELEVANCE_ARC_ADDED);

As indicated above, there is a special type of change that will not trigger relevance reasoning automatically. For example, you can directly change the individual distribution inside a conditional probability table. It would be costly to perform relevance reasoning each time one of these numbers change so a protocol must be followed for relevance reasoning to work properly. This protocol consists of two calls of DSL_nodeDefinition methods. One call before the change takes place - BeforeDirectChange() - and the second call after the changes have been done - AfterDirectChange(). You can make as many changes as you want in between those two calls. This ensures that relevance reasoning "notices" that something has changed and acts accordingly. Normally, you may not have to call these functions at all. See the description of DSL_nodeDefinition for a more detailed explanation and an example.

See also the description of DSL_nodeValue to find out what a valid/invalid value means for each kind of node.