Before doing most net operations (e.g. compiling, absorbing nodes, reversing links, or optimizing decisions), each involved node must have a relation contingency table (e.g. its CPT) to express its relationship with its parents. If you have entered the relationship as an equation, then a table must be built from the equation.
To build tables for particular nodes, select the nodes, and then choose Table → Equation to Table or click the toolbar button. If some of the selected nodes don’t have equations, they will just be skipped. If no nodes are selected, then Netica will build tables for all the nodes which have equations.
If a node with an equation, or any of its parents, are for continuous variables, then they must be discretized before converting the equation to a table (except a utility node). When Netica does the conversion, it must decide where within each discretized “cell” to evaluate the equation. It chooses a number of points (at truly random positions) within the cell, and uses the average of the results obtained. Just before the conversion process, Netica will put up a dialog box asking you how many random samples to make per cell. The larger this number, the more accurate the results will be, but the longer it will take.
Sampling Uncertainty: Since this sampling process can’t check every point within the cell, it may miss a narrow spike or ridge. Netica can represent within the created table the additional uncertainty due to the sampling, or it can assume that the sampling was truly representative. Netica will put up a dialog box asking you which it should do. It is best to ignore the sampling uncertainty when you know the equation doesn’t have any narrow spikes or ridges.
When the sampling uncertainty is included, then none of the table entries will be zero, since Netica can never be sure that it hasn’t missed some nonzero points within the cell. The sampling uncertainty will be smaller if you increase the number of samples per cell. Sampling uncertainty can be removed after the table is created by choosing Table → Harden, and providing a degree of 1.
Large: The
size of the table generated is the product of the number of states of
the node with the numbers of states of each of its parent nodes. So
if a node has many states, or many parents, then the tables may be very
large, and Netica may report that it doesn’t have enough memory for the
operation. Or it may just take a long time. You can alleviate
the problem by eliminating unnecessary parents and using coarser discretizations
(perhaps have more than one node for the same variable, with different
discretizations depending on which node it is a parent for).