Difference between revisions of "Proactive Evaluation"

m (Editing for clarity, and moving history of previous releases to the end)
Line 1: Line 1:
 
[[Category:Concepts]]
 
[[Category:Concepts]]
 +
= Lazy vs. Proactive evaluation =
  
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:  
+
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:  
* 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 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 previously.  
+
* you don't have to wait while it recomputes results that it computed and cached previously, unlike programs in most standard computer languages.
  
''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. 
+
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.  
  
In some models, all index variables are proactively evaluated. This is controlled by the '''Proactively evaluate indexes''' [[Preferences|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 [[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.
+
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.  rior 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]]
  
= Proactive evaluation by release =
+
= Custom configuration with '''ProactivelyEvaluate''' attribute =
 
 
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.
+
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.)
  
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 [[MsgBox|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.
+
Another case would be if you wanted to display a [[MsgBox|message box]] with welcome information when a model is loaded. You could call the MsgBox() function in a proactively evaluated variable.  
  
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 evaluatedIf the attribute is not set at all, then the '''ProactivelyEvaluate''' attribute for the objects class determines its behavior.  
+
You cause proactive evaluation for a variable by setting its '''ProactivelyEvaluate''' attribute to 1. You can set it back to 0 for lazy evaluationYou can also change the default behavior for an entire class of Objects by setting '''ProactivelyEvaluate''' attribute for a Class -- e.g. for Index.  
  
To change the '''ProactivelyEvaluate''' attribute for an object, you'll need to use the [[Typescript Window]], which you can get to by pressing F12.  
+
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
 
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
Line 66: Line 55:
  
 
(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).
 
(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).
 +
 +
= 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 internal 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.

Revision as of 22:19, 26 December 2014

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:

  • 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 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 database queries) to evaluate when you are loading your model. rior 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

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).

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 internal 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.

Comments


You are not allowed to post comments.