Andrew Cooke: C[omp]ute

Source for recursive evaluation pattern?

From: "andrew cooke" <andrew@...>

Date: Sun, 26 Mar 2006 10:26:41 -0400 (CLT)

[sent to pattern discussion email list]

I'm trying to find a decription of what I believe is a common pattern in
numerical computation (and possibly occurs in a modified form in language
evaluation), but don't know how to get started.  Given the description
below does anyone know what it might be, or alternatively, can anyone
point me at a way for finding patterns?  I hope this is an appropriate use
of this list.

Thanks,
Andrew

The aim of the pattern is to evaluate a number of expressions which are
defined in terms of each other and some shared state.

For example, the shared state may be the parameters of a model that is
being optimised, and the expressions calculate observed quantities used to
assess the model against measurements.

The structure of the pattern separates the expressions from a central
"environment" that includes the state, a cache of evaluated expressions,
and an "evaluator".

Evaluation is driven by requesting the expression values from the
evaluator in the environment.  The evaluator checks the cache and, if the
expression is not yet known, passes the environment to the expression.
The expression then requests the values it needs from the evaluator,
calculates its own value, and returns.

The action of requesting values from the environment/evaluator may cause
other expressions to be evaluated and cached, recursively.

The advantages of the pattern are:
- separating the state from the expressions gives easy extension
- the automatic resolution of dependencies between expressions
- efficient evaluation via caching

The main risk is a circular loop where two expressions depend each on the
other.  One way to avoid this is to force the initial system to be
constructed incrementally with no forward references.

I'm looking for a description because I'm curious about the bst way to
structure some details - what is the best way to relate teh evaluator and
cache, and should the expressions and state share the same API for access
- as well as a reference to pass to colleagues when they look at the code
and ask what's happening.

Revised Pattern

From: "andrew cooke" <andrew@...>

Date: Sun, 26 Mar 2006 19:16:41 -0400 (CLT)

The email above got (so far) no response, but it helped me understand more
clearly what I am doing.  Looking again at the code I realised that I had
some confused assumptions; the pattern described above did, too.

So I'll attempt that pattern again.  But before doing that, it's worth
noting that I am actually working on word code in my own free time.  For
the first time in ages, work is actually fun.

Anyway, back to the pattern.

The problem is how best to evaluate a complex function that depends on
many interdependent elements.  The inter-dependency may involve elements
of the function itself.

The pattern splits this problem into 4 stages.

Step 1 - construct a model of the dependencies.  This takes the form of a
directed graph whose nodes are objects in the domain model, and whose arcs
reflect the dependencies between the model element.  Typically the mode is
not fixed, but is composed of generic components which can be assembled
via some configuration process to adapt the system to a particular
instance of the problem.

Step 2 - identify which nodes are necessary to evaluate the function. 
These nodes must implement an interface which returns the value of the
node.

Step 3 - extend the model to include a cache of node values and an
interface to that cache.  The cache interface checks whether a node has
already been evaluated and, if so returns the value directly.  Otherwise
it calls the node to request a value, caches and returns the result.

Step 4 - modify the code within each node so that, instead of collecting
data directly from nodes that it depends on, values a requested from the
environment itself.  This gives the characteristic signature of the
pattern which is a pair of interfaces that reflect each other:

  public Cache {
    public Value getValue(Node node);
  }

  public Node {
    public Value getValue(Cache cache);
  }

Step 5 - evaluate the function by evaluating each node in turn.

The cache is necessary for efficiency - it allows an unordered list of
nodes to be evaluated in a "greedy" manner without worrying about
duplications.

This pattern fails when the graph is cyclic.  Cyclic dependencies can be
detected by the cache (if it records which nodes are being evaluated and
flags an error if a node value is requested during its own evaluation), or
the model can be constrained to be acyclic by other means (for example, by
contructing it in an incremental manner without forward references).


In my particular case, the model describes a database schema and
evaluation corresponds to either loading tables or evaluating stored
procedures/functions; interdependency comes from inter-table references
(foreign keys).


In retrospect, this seems to be equivalent to a greedy algorithm for
constructing a spanning tree of a DAG; I'm not sure it's worth of being
called a pattern.

Two More Details

From: "andrew cooke" <andrew@...>

Date: Sun, 26 Mar 2006 20:39:09 -0400 (CLT)

- It is generally possible to separate the model from the state (the set
of numbers that characterise the model in a particular instant/case). 
Then the state can be accessed via the environment and the model re-used
for different states by re-evaluating with a new environment.

- In my case the model also propogates/validates type information.  The
state values are of a fixed type, but the model itself uses other types
internally, and the types are specified by the configuration.  So type
validation occurs after the model is constructed, but before it is
evaluated for the first time.

Comment on this post

C[omp]ute

Personal Projects

Last 100 entries

Source for recursive evaluation pattern?

Revised Pattern

Two More Details