**Next:** The Script Editor

**Up:** Components of the Virtual Laboratory

**Previous:** Tcl

Computation networks [6]
are a popular programming paradigm for experimental mathematics. The nodes of these
networks each represent some computational activity. For simplicity we call this the
node's *action*. Each node may have a set of *inputs* and *outputs*; the
inputs may be thought of as arguments to the computation and the outputs as the results.
Whenever the inputs to a node change, then the node's action is invoked to bring the
outputs up to date.

The nodes are assembled into a directed graph by adding edges, each of which connects
an output of some node to an input. This establishes a *dependence* of the second
node on the first. Whenever the outputs of the first node change, the second node's action
must be invoked. Implementations typically provide an automatic algorithm which propagates
such changes along the edges of the graph and *updates* the nodes.

Cycles in the graph must be handled carefully by the update mechanism, since they can
easily lead to infinite loops. Most implementations have a strategy to allow cycles; the
computational action of some node is expected to apply a conditional that terminates the
loop in the update process. We return to this below when discussing how **Oorange**
handles this problem.

An important feature of any implementation of such computational network is what
exactly is passed from node to node. In *data flow* networks the system manages the
movement of data during the update process, typically by copying the data along the edges
from output to input. This model has proved to be very successful when applied to a wide
range of natural scientific domains. The commercial packages AVS [13] and Explorer [3] are
both based on this model.

However the situation with respect to mathematical research is not satisfactory. The disadvantages of existing data flow implementations for mathematical experiments are essentially twofold. First, there is a restricted set of data types which can be moved along an edge. Most actual mathematical structures do not fit into these simple types. Second the action of a given node is typically difficult to modify. Update actions are typically written in a compiled language such as C or Fortran; when it possible at all to modify them, such modifications require advanced programming skills, compilers, and source code. In practice this restricts many researchers to using actions which are not exactly what they want, or starting again from scratch and creating a new one.

**Oorange** has maintained the essential update mechanism from the data flow model
but has replaced the fixed data types and fixed actions with more flexible tissue. To
begin with, **Oorange** concentrates on *objects*, rather than *data*. The
contents of the simplest **Oorange** nodes are **Objective C** objects. Object
pointers are passed from one node to the next along the edges of the graph, freeing the
user to pass arbitrary types of data between nodes.

Secondly, rather than having a compiled, relatively fixed update action , an **Oorange**
node is provided with an editable **Tcl** script, the *node script*. This
typically consists of a sequence of **Objective C** statements (as explained above in 3.1.2) directed at the contents or ingredients of the node.
This script can be modified, or new **Objective C** commands may be selectively
executed before adding them to the script. Node scripts combined with network nodes
provide an elegant solution to simulating computational loops, such as iterated
convergence algorithms.

The **Oorange** network model, then, provides the flexibility and power that the
experimental mathematician needs to carry out his experiments.

How are **Oorange** networks constructed? They can be interactively assembled in the
**Oorange** Network Manager. This provides a visual ``assembler'' for creating new
nodes, loading existing subnetwork nodes, adding ports and links, cutting and pasting, and
a variety of other useful editing tasks.

Copyright © 1997 Sonderforschungsbereich 288, Differential Geometry and Quantum Physics, TU-Berlin