Proactive Evaluation
Lazy vs. Proactive evaluation
Unlike most conventional computer languages and spreadsheets, Analytica normally does lazy evaluation: it evaluates each variable only when it needs to -- e.g. when you press a Calc button to view its result, or you ask for the result of another variable that depends on it. After evaluating a variable, it retains (caches) its value until something that it depends on is changed, when it is reset to "uncomputed". The advantages of lazy evaluation are:
- you don't have to wait while it recomputes results that it computed and cached previously, unlike programs in most standard computer languages.
- you don't have to wait while it computes results you don't need, as in a spreadsheet that normally tries to compute all values when you first load it, and
In cases where a diagram contains a Choice pulldown menu input control or an edit table, Analytica will pro-actively evaluate any index used in the menu or edit table so that it can display them properly. In Analytica 4.3 and earlier releases, it tried to evaluate every Index on loading the model. You can still set this behavior by checking the Proactively evaluate indexes preference setting. But, it's almost always best to turn this setting off, so you don't have to wait for computed indexes (which may 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.
Custom configuration with ProactivelyEvaluate attribute
Occasionally, it is useful to turn on proactive evaluation for selected variables. One case is when you want to show a result in a user Output node immediately when you display the Diagram user interface that contains it, without having to click its Calc button. (We plan in a future release (not yet as of Analytica 4.5) that Proactive evaluation to 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.)
Another case would be if you wanted to display a message box with welcome information when a model is loaded. You could call the MsgBox() function in a proactively evaluated variable.
You cause proactive evaluation for a variable by setting its ProactivelyEvaluate attribute to 1. You can set it back to 0 for lazy evaluation. You can also change the default behavior for an entire class of Objects by setting ProactivelyEvaluate attribute for a Class -- e.g. for Index.
Since ProactivelyEvaluate attribute is rather obscure, you must set it in the Typescript Window, which you can get to by pressing F12 (or Ctrl-').
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 IndexObject IndexNodeColor: 39321,39325,65535ProactivelyEvaluate: 0
You can override this default for individual variable objects by setting the attribute explicitly for the indicated variable. For example:
Untitled> ProactivelyEvaluate Va1: 4Untitled> 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 Value2= Domain value4= Mid value8= Prob value16= Accept definition32= OnClick
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.
(new to Analytica 5.0) When the 16 flag is set for an edit table, the table's definition is entered immediately when a cell is changed. This is equivalent to the user pressing the green check button immediately after entering each cell. In a MultiTable, this can be useful for triggering the recomputation of computed cells immediately. In any table, it can also be used to force the OnChange event to trigger after every cell change. Of course, for extremely large table, it may be undesirable to set this flag since large time delays might result, and it means you can't drop all changes by pressing the red X button, since the changes have already been committed.
(new to Analytica 5.0) The 32 flag applies to buttons or images having an OnClick event handler, and indicate that the button's OnClick should be evaluated immediately when the model is loaded.
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).
History
Analytica adopted lazy evaluation as part of its original design philosophy. The main exception was for Indexes, which it evaluated proactively so that they would be available for display of result tables and graphs using those indexes. In more recent releases, it has moved to lazy evaluation even for indexes where possible, and given the modeler the option of proactive evaluation for selected variables.
Analytica 4.3 introduced the ProactivelyEvaluate attribute to let you turn off proactive evaluation of all index nodes, and turn on proactive evaluation for other class types or individual objects. Its default was still to proactively evaluate indexes.
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 users were recommended to turn it off.
A variable used as a table index (even if it isn't formally an index) was evaluated proactively at model load time to enable the table definition to be parsed, up through Analytica 4.3. An internal restructuring of table parsing rendered Analytica 4.4 made this unnecessary, so that even indexes used by tables are evaluated in a lazy fashion.
Analytica 5.0 Introduced proactive acceptance of definitions (flag 16) and proactive evaluation of OnClick (flag 32).
Enable comment auto-refresher