BWise functional graphs

by Theo Verelst

A function mostly is taken to be a mathematical procedure or formula with zero or more arguments, which after substitution/evaluation gives an outcome. In computer language, mostly it is seen such that a procedure has a number of usually pass by value arguments which returns a single value.

The relevance probably lies in the overseeableness and mathematical applicability and the abstraction possibility: one makes a function for a certain task, and calls it in the scope of a bigger one as a block with a number of inputs and one output, and composes functions by letting the output of the one act as input of another.

In principle, this can lead to tree structures where the last block or root of the tree gives the answer to a computation which can be arbitrarily branched out in into subtasks, which can also be trees.

In a programming language like tcl, it is perfectly possible to compute a result based on nested function or procedure calls in the normal sense of most modern languages. Intermediate results are silently stored on stack, while the syntax/grammer in the parser of the language will start evaluating/executing the innermost called functions/code, which can be visualized at the leafs of the function calling tree, for instance for this formula in expr:

set x 1;
expr (exp(1/pow($x,2)))/pow($x,2)

Which for x=0.5,1.0,2.0 evaluates to: 218.392600133, 2.71828182846 and 0.321006354172 . Now we may want to break that equation down into principal arithmetical operations (by hand in this case), and see it like this:

using bwise blocks (the value in the mon block isn't for the same computation). Doing that in a straightforward way gives the above graph, to which I added the input entry and output monitor, where feeding the chain with the same values gives: 218.392600132 , 2.71828182846 and 0.321006354173 correct except the very last digit, which probably comes from the difference between the explicit evaluation order in bwise compared to the internal evaluation, or simply because I didn't include all the relevant digits in the passing of bwise arguments.

For analysis of the network, bwise has various functions, for instance to get all blocks left of the last block, let us say fr, we can use

net_allleft fr
epo fr rec sq1 sq2

and get all subnetwork block names returned. The procedure net_funct returns only the 'leaf' nodes of the tree from the left (input) side of the fr block:

(Tcl) 143 % net_funct fr
 Entry1

And after we remove or detach the entry block:

(Tcl) 144 % net_funct fr
 rec sq2

Now what's the point of 'functional' in this context? Basically, that a block has no memory, and that there is one outcome, which depends on the arguments to the overall function, and the decomposition doesn't matter, assuming it is done right. Then the computation order can be thought to be governed by the availability of the input data for each block: as soon as all data is available, the block can be 'fired', which is what bwises' 'net_funprop' works like, and it is provable that each block needs to get fired only once.

Of course once the function (de-) composition tree has been established, it is possible to do obvious enough simplifications, mainly by reusing intermediate results, or by first reordering and reformulating and then outcome reuse, such as the two square operations could be reduced to one.

TV (feb 1 2005) I'll be doing a 'lecture' (entry level) about functional programming / basic functional analysis at fosdem 2005, see [L1 ] .Maybe I'll use this example: Bwise traffic lights with challenges. Also maxima is interesting in that picture like in Bwise blocks using exec maxima because then we could combine maxima mathematical manipulations in a functional way.