Syntax
where are the names of elements, are the names of equations (which must be enclosed in round
brackets), is the name of a
base, and A is the name of an assignment
In the first form of the syntax, the BUILD: command is used to
construct a new element from a linear combination of former
elements, assignments, and components. In the second form
of the syntax, the command is used to build a given assignment.
The second form of the syntax is equivalent to issuing the first form of
the syntax with
so that the assignment of the same name is constructed to be an element.
Each construction takes place separately in every unlocked belief
store. Expectations are only constructed in unlocked expectation
stores. The LOCK: and ELOCK: commands may be used to
change locks.
Base names may be included in the definition part to mean the sum of
every element in the base, and where each element will take the
coefficient given by the equation preceding the base name. For example,
we might build the average of the base named B by issuing the command
BD>build : average=(1/count (B))B
Each BUILD: command has a definition part which, after tracking
through any assignments (possible recursively, and possibly taking
taking into account any varying indices) will result in a linear
combination of elements and components. Whenever there is a possible
confusion between element names and assignment names, the element names
have priority. To force the use of an assignment in case of doubt, the
assignment name may be prefixed with the `!' symbol. Thus, for each name
N in the definition part, the names of elements are checked firstly.
If N is not an element, the assignment names are checked. If in
addition N is not recognised as an assignment, it is assumed to be a
component. The distinctions are that elements have beliefs explicitly
associated with them; assignments are themselves lists of similar
elements and components; and components may have functional beliefs
specified over them. Note that an assignment is parsed recursively
deeper until the definition part is a linear combination of either built
elements or components, but never assignments. Actual construction of
beliefs then takes place, searching for functional declarations if need
be. The element being defined might already exist, in which case it will
be overwritten. If the element already exists and appears in the
definition part, the former definition is used fully as required, and
then finally replaced after the conclusion of all calculations.
Equations which have no succeeding element or assignment or component
are treated as scalar parts of the linear combination, and are included
in determining the expectation for the element.
Once any assignments have been traced through, the definition part for
the new element will be of the form , where is some scalar, is a vector of
coefficients for the vector of elements , and is a
vector of coefficients for the vector of components . We may
assume that consists of all the elements defined to date, with
corresponding if the element is excluded from the
definition part. Beliefs over N are constructed as follows.
where all quantities are known except the vector . is assumed to be
zero unless an expectation has specifically been given for the component
by using the FE: command.
where is a known matrix. The matrices
(consisting of specifcations such as ) and
(consisting of specifications such as ) are assumed to
have all their entries equal to zero except as specified by
FVAR: commands relating the elements to components, and
components to components.
where is known, and is addressed above. It is most
important to understand that the BUILD: command is essentially
memoryless: built elements do not remember their original definition
parts. In particular, the component parts of the definition will not be
taken into account in future use of the element. To illustrate the
deficiency, suppose that you use the BUILD: command to construct
firstly
followed by
This will result in the wrong value for being calculated
as the term will be absent. This term
is absent because the linear combination used to construct
has been forgotten; it is ``remembered'' only through the elements X,
and not through the components C.
To avoid this problem, the COBUILD: can be used to build
elements from functional declarations, and to build up a large number of
covariance structures together, but is generally considerably slower.