| Andrew Cooke | Contents | Latest | RSS | Twitter | Previous | Next

C[omp]ute

Welcome to my blog, which was once a mailing list of the same name and is still generated by mail. Please reply via the "comment" links.

Always interested in offers/projects/new ideas. Eclectic experience in fields like: numerical computing; Python web; Java enterprise; functional languages; GPGPU; SQL databases; etc. Based in Santiago, Chile; telecommute worldwide. CV; email.

Personal Projects

Lepl parser for Python.

Colorless Green.

Photography around Santiago.

SVG experiment.

Professional Portfolio

Calibration of seismometers.

Data access via web services.

Cache rewrite.

Extending OpenSSH.

Last 100 entries

Neural Nets Applied to Go; Programming, Business, Social Contracts; Distributed Systems for Fun and Profit; XML and Scheme; Internet Radio Stations (Curated List); Solid Data About Placebos; Half of Americans Think Climate Change Is a Sign of the Apocalypse; Saturday Surf Sessions With Juvenile Delinquents; Ssh, tty, stdout and stderr; Feathers falling in a vacuum; Santiago 30m Bike Route; Mapa de Ciclovias en Santiago; How Unreliable is UDP?; SE Santiago 20m Bike Route; Cameron's Rap; Configuring libxml with Eclipse; Reducing Combinatorial Complexity With Occam - AI; Sentidos Comunes (Chilean Online Magazine); Hilary Mantel: The Assassination of Margaret Thatcher - August 6th 1983; NSA Interceptng Gmail During Delivery; General IIR Filters; What's happening with Scala?; Interesting (But Largely Illegible) Typeface; Retiring Essentialism; Poorest in UK, Poorest in N Europe; I Want To Be A Redneck!; Reverse Racism; The Lost Art Of Nomography; IBM Data Center (Photo); Interesting Account Of Gamma Hack; The Most Interesting Audiophile In The World; How did the first world war actually end?; Ky - Restaurant Santiago; The Black Dork Lives!; The UN Requires Unaninmous Decisions; LPIR - Steganography in Practice; How I Am 6; Clear Explanation of Verizon / Level 3 / Netflix; Teenage Girls; Formalising NSA Attacks; Switching Brakes (Tektro Hydraulic); Naim NAP 100 (Power Amp); AKG 550 First Impressions; Facebook manipulates emotions (no really); Map Reduce "No Longer Used" At Google; Removing RAID metadata; New Bike (Good Bike Shop, Santiago Chile); Removing APE Tags in Linux; Compiling Python 3.0 With GCC 4.8; Maven is Amazing; Generating Docs from a GitHub Wiki; Modular Shelves; Bash Best Practices; Good Emergency Gasfiter (Santiago, Chile); Readings in Recent Architecture; Roger Casement; Integrated Information Theory (Or Not); Possibly undefined macro AC_ENABLE_SHARED; Update on Charges; Sunburst Visualisation; Spectral Embeddings (Distances -> Coordinates); Introduction to Causality; Filtering To Help Colour-Blindness; ASUS 1015E-DS02 Too; Ready Player One; Writing Clear, Fast Julia Code; List of LatAm Novels; Running (for women); Building a Jenkins Plugin and a Jar (for Command Line use); Headphone Test Recordings; Causal Consistency; The Quest for Randomness; Chat Wars; Real-life Financial Co Without ACID Database...; Flexible Muscle-Based Locomotion for Bipedal Creatures; SQL Performance Explained; The Little Manual of API Design; Multiple Word Sizes; CRC - Next Steps; FizzBuzz; Update on CRCs; Decent Links / Discussion Community; Automated Reasoning About LLVM Optimizations and Undefined Behavior; A Painless Guide To CRC Error Detection Algorithms; Tests in Julia; Dave Eggers: what's so funny about peace, love and Starship?; Cello - High Level C Programming; autoreconf needs tar; Will Self Goes To Heathrow; Top 5 BioInformatics Papers; Vasovagal Response; Good Food in Vina; Chilean Drug Criminals Use Subsitution Cipher; Adrenaline; Stiglitz on the Impact of Technology; Why Not; How I Am 5; Lenovo X240 OpenSuse 13.1; NSA and GCHQ - Psychological Trolls; Finite Fields in Julia (Defining Your Own Number Type); Julian Assange

© 2006-2013 Andrew Cooke (site) / post authors (content).

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