Unlike conventional computer languages and spreadsheets, Analytica only evaluates each variable when it needs to -- e.g. when you press a "Calc" button to view its result, or the value of a variable that depends on it. It doesn't (usually) evaluate variables you don't yet 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 are:

you don't have to wait while it computes results you don't need (e.g. when loading the model), and
you don't have to wait while it recomputes results that it computed previously.

Proactive evaluation is the opposite of lazy evaluation: Analytica evaluates a proactively evaluated variable while loading the model. It may also re-evaluate it immediately after you change its definition or any variable it depends on. In some cases, a variable with standard lazy evaluation may be evaluated on loading anyway because it is used by another variable that needs immediate evaluation. One example is 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.

In some models, all index variables are proactively evaluated. This is controlled by the Proactively evaluate indexes preference setting. It is almost always best to turn this setting off, so you don't have to wait for computed indexes (which often include time-consuming database queries) to evaluate when you are loading your model. Prior to Analytica 4.4, this setting was on by default, so if you are working with a legacy model, you may need to turn it off.

Proactive evaluation by release

What gets proactively evaluated has changed between various releases. In general, there has been a trending away from default and mandatory proactive evaluation to more lazy evaluation.

In Analytica 4.2 and earlier, indexes objects were always proactively evaluated, with no option to set them to be otherwise. At that time, it was not uncommon to see a variable node used for an index, just to avoid proactive evaluation.

Analytica 4.3 introduced the ProactivelyEvaluate attribute, which made it possible to turn off proactive evaluation of all index nodes, or to configure other class types or individual objects to to proactively evaluate. The default was still for indexes to proactively evaluate, but it could now be configured.

Analytica 4.4 exposed the Proactively evaluate indexes preference on the Preference Dialog, and set the default to off for new models. For legacy models, it remained on to avoid breaking backward compatibility, but it was recommended that users turn it off.

Whenever a variable appears as a table index (even if it isn't an index object), the index had to be proactively evaluated at model load time in order to parse the table definition up through Analytica 4.3. An interal restructuring of table parsing rendered this proactive parsing unnecessary, so that is Analytica 4.4, even index used by tables are evaluated in a lazy fashion. This became complete with the 4.4.4 patch.

Custom configuration of proactive evaluation

We believe the ideal is to keep proactive evaluation off by default, but turn it on for individual objects where you want it.

Why would you want something to be proactively evaluated? Although rare, there are cases where you might want something to happen as soon as the model is loaded. A simple example would be if you wanted to display a message box with some welcome information. You could put the code for that in a proactively evaluated variable. A lazy variable will eventually have to be evaluated, so you might prefer paying that price at load time rather than later, especially if the value isn't going to be changed. You might want your output variables on a user interface to immediately show the computed value, rather than a Calc button. It the future (but not yet as of Analytica 4.5), the attribute will cause variables to reevaluate immediately if anything they depend on is changed, which is useful when an output node appears on a user interface so that the value is updated without having to press a Calc button each time.

The behavior is controlled by the ProactivelyEvaluate attribute. If an object has this set to 1, then it gets proactively evaluated, and if set to 0 then it is lazily evaluated. If the attribute is not set at all, then the ProactivelyEvaluate attribute for the objects class determines its behavior.

To change the ProactivelyEvaluate attribute for an object, you'll need to use the Typescript Window, which you can get to by pressing F12.

You can control the default behavior for object classes like Decision, Variable, Index, Objective, Constraint, and Constant. For example, you could make all constants proactive by typing

ProactivelyEvaluate Constant:5

Turning off the Proactively evaluate indexes preference is equivalent to typing

ProactivelyEvaluate Index:0

And turning it on is equivalent to setting it to 1.

You can look at the current defaults from the Typescript Window, e.g.

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

You can override this default for individual variable objects by setting the attribute explicitly for the indicated variable. For example:

Untitled> ProactivelyEvaluate Va1 : 4
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). In a future release, we plan to add (c) when any value it depends on changes.

(As of Analytica 4.5) 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).