Difference between revisions of "Proactive Evaluation"

m
m
 
Line 3: Line 3:
 
== Lazy vs. Proactive evaluation ==
 
== Lazy vs. Proactive evaluation ==
  
Unlike spreadsheets and most standard procedural computer languages, Analytica normally does what we call ''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:  
+
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  
 
* 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  
* you don't have to wait while it recomputes results that it computed and cached previously, unlike programs in most standard computer languages.
 
 
Lazy evaluation is Analytica's default behavior, but there are some cases in performs ''Proactive evaluation'' -- i.e. it evaluates a variable when it loads the model, and re-evaluates it immediately after you changing its definition or any variable that it depends on.
 
  
The most common case of proactive evaluation is where a [[Choice]] pulldown input control appears on a diagram.  When you view the diagram, it must compute the index values for the Choice (and any variables it may depend on), so that it can display the Choice pulldown menu. In older releases of Analytica (before 4.5), it evaluated all Index variables proactively, in case they were used in Edit tables. Now, it computes them only when you want to edit or display the table (or a variable that depends on it). You can still specify this behavior by the '''Proactively evaluate indexes''' [[Preferences|preference setting]], so that it behaves as it did in earlier releases. But, it's almost always best to turn this setting off, so you don't have to wait for computed indexes (which often include time-consuming [[DbQuery|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.
+
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''' [[Preferences|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 [[DbQuery|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.
  
 
:[[image:proactive preference.png]]
 
:[[image:proactive preference.png]]

Latest revision as of 17:31, 24 September 2019


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.

Proactive preference.png

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 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
16 = Accept definition
32 = 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).

See Also

Comments


You are not allowed to post comments.