Unlike conventional computer languages and spreadsheets, Analytica (by default) only evaluates each variable when needed -- i.e. when you (the user) ask to see its value, or the value of a variable that depends on it. It does not evaluate variables you don't need. After evaluating a variable, it keeps (caches) the value until something that it depends on is changed, when it is reset to "uncomputed". We refer to this scheme as lazy evaluation.

The advantages of lazy evaluation over conventional evaluation schemes are: (1) you don't have to wait while it computes results you don't need, for example, while the model loads, and (2) you don't have to wait while it recomputes results that it already computed.

Proactive evaluation is the opposite of lazy evaluation. A proactively evaluated variable is valuated while the model is being loaded, or immediately after you change its definition (or any variable it depends on).

In some cases, the difference between proactive and lazy evaluation is just a difference of when the computation take place. For example, if you load your model and then view a result that depends on X, then X will have to be computed at some point. A proactive evaluation would evaluate X while the model is being loaded, thus shortening the delay when the result is requested later, while a lazy approach would load the model faster but take longer to bring up the computed result.

Even when a variable is computed in a lazy fashion, its value may be needed for various purposes before you ever request a result. Hence, it may appear that it is being proactively evaluated when in fact it is only being computed on-demand. One example is the case where a Choice pulldown input control appears on a diagram. In order to display the diagram, Analytica must compute the index values for the Choice, and hence, the index object is evaluated. Another example is an edit table index, whose index value is required in order for Analytica to be able to parse an edit table (which will occur at model load time). Parsing an edit table definition requires Analytica to discover the length of the index, and hence, the index must be evaluated.

Due to a historical legacy in Analytica's design, Index objects (those that appear as parallelograms on an influence diagram) are proactively evaluated, while other variable types are lazily evaluated. Since a general variable (the rounded rectangle) can be used as an index equally well, you can control the proactive vs. lazy evaluation by setting the object class to either index or variable.

One situation that often occurs is where your model queries an external database. If you use an index object for your DbQuery(..) call, then the data will be read when your model is first loaded, causing excessive load times when large queries are involved. So by changing these indexes to variable objects, you can defer the time for queries until after the model is loaded.

In other cases, proactive evaluation is sometimes used to ensure that output nodes immediately display their computed values on the diagram when a model is loaded, rather than a Calc button.

Attribute ProactivelyEvaluate

New to Analytica 4.3

Starting with Analytica 4.3, you can explicitly control whether individual variable or index object is proactively or lazily evaluated. This is controlled using the new attribute ProactivelyEvaluate.

The attribute setting can be used to control the default behavior for any particular Analytica class (you would normally change it from the typescript window). For example, in the typescript window you can see how the Index class is configured to proactively evaluate by default:

Untitled> Profile Index
Object Index
NodeColor: 39321,39325,65535
ProactivelyEvaluate: 1

By changing the attribute to 0, or deleting the attribute value entirely, you can alter Analytica 4.3's behavior so that index objects will be evaluated lazily by default:

Untitled> ProactivelyEvaluate Index : 0

Likewise, you could configure Constants to be proactively evaluated:

Untitled> ProactivelyEvaluate Constant : 1

For object classes like Decision, Variable, Index, Objective, Constraint, and Constant, the attribute controls the global default behavior for all objects of the indicated class. You can override this default for individual variable objects by setting the attribute explicitly for the indicated variable. For example:

Untitled> ProactivelyEvaluate Va1 : 1
Untitled> ProactivelyEvaluate In1 : 0

The above lines change the default so that index In1 is lazily evaluated and variable Va1 is proactively evaluated, regardless of the class default.

The value assigned to the ProactivelyEvaluate attribute is actually a bit-field, which can be the sum of any of the following values:

1 = Index Value

2 = Domain value

4 = Mid value

8 = Prob value

Setting to 1, as the previous examples do, cause Analytica to compute the index value. In many cases, computing the index value (or discovering that there is no self-index value) will also require evaluate of the Mid value. Alternatively, setting it to 4 would force the proactive computation of the mid-value.

When Proactive Evaluation occurs

When a variable X is configured to be proactively evaluated, this proactive evaluation occurs: (a) when the model is first loaded, and (b) when the definition of X is changed (e.g., by editing it in the object window).

Suppose the definition of a variable that X depends on changes. This does not cause the immediate proactive evaluation of X. Thus, if you have an output control for X, it will switch to a [Calc] button. If the definition of X is edited, then it will proactively evaluate. (Enhancement being considered: A variable set to proactively evaluate Mid=4 or Prob=8 would automatically evaluate when the output control is rendered on the diagram. The [Calc] button would appear only when the evaluation is unsuccessful because of an error or user abort).