Hierarchical Networks

Hierarchical Networks

Note:
This is a somewhat technical programming section which carries on from ideas and techniques developed at length in "Lingo Sorcery"
As mentioned in the introduction [of Lingo Sorcery], much of the story of biological evolution is about OOPS strategies. It is about the blind progress of interacting and cooperating units which become progressively more adept at coping with an ever changing environment.

However, it isn't necessary to go deep into evolutionary biology to uncover some of the basic structures of OOPS because the evolution of the human race has evolved many different kinds of object-oriented systems which can be used as models for understanding various types of OOPS paradigms.

We have already covered [in Lingo Sorcery] one such evolved human object-oriented system: the business firm. Another, even older evolved structure, might give you another insight into a different aspect of the enigmatic OOPS concepts: the military army.

Imagine the planning of a battle. In very primitive times a large group of people would just gather together and attack another group of people. With no planning, the largest group would win. As conflicts became a common feature of human existence, survival depended upon winning these battles. Winning proved to be more probable if groups had leaders and even more probable if the leaders devised plans and tactics. With every side evolving leaders, tactics and strategies, winning depended upon which side had the best tactics and strategies.

Now if you forget about all the theorizing that must have gone on over the thousands of years of human conflicts and just realize that these battles have been about survival you will understand that the best strategies are those that would have become common to all armies: simply because the supporters of inferior strategies get killed off.

Looking at the system used by military forces we see that they have all evolved hierarchical structures with orders flowing from higher levels of the hierarchy down to the lower levels.

At the lowest level of a military force, is a single soldier. The single soldier is an object which is reproduced about ten times to produce a squad (virtual object). A squad object is repeated about three times to produce a regiment (virtual object); a regiment object is repeated about three times to produce a brigade (virtual object); a brigade object is repeated about three times to get a division (virtual object); a division object is repeated about three times to get a corps (virtual object). An army (virtual object) might have several corps and a country (virtual object) might have several armies.

General orders are issued from the top. These orders are dissipated as they go down the hierarchy, becoming more detailed and more specific as they get closer to the bottom level. In this way a general need not have to bother about what every man or piece of equipment in his army has to be doing to play their part in battle.

The general can concentrate on the main heuristic components of his strategy and leave the detail to others further down the line.

Each element in turn receives each order from higher up and interprets that order in light of the information at hand and passes it on (dividing it into components where necessary) to the elements lower down. In this way, an order, to capture a large town will be broken down into innumerable elements, which ends up as specific instructions to single soldiers to take specific actions.

You might compare this object-oriented arrangement with that of the 'general' who is playing table top war games. The table top war game is the equivalent of the top down or structured approach where all the actions and activity are the result of a single controlling mind who has complete control and responsibility for every object's activity.

The real life general on the other hand just sets a goal and triggers the system off, leaving it to organize itself. Each object in the system triggers another, producing cascades of interdependent activity brought about by messages, with the result that the interactions are completely out of the hands of the general once he has issued the orders.

A hierarchical system of regulation and control is common with most organizations involving people because people are each capable of being autonomous decision makers.

Strict hierarchical bands have to be drawn to delineate ranges of responsibility and authority to maintain overall control and stability. A typical company management hierarchy would be of the form shown in fig 19/1.

Figure 19/1 A conventional management hierarchy

You might wonder how this management hierarchical structure differs from the hierarchical constructs we encountered earlier [in the Lingo Sorcery book] with the ancestor property. Can you see the difference between this management hierarchy and the ancestor based hierarchy we used with the example of the calculating men example [in the Lingo Sorcery book]? Take a look at the diagrams in figs 19/2a and 19/2b.

(Note: the ancestor hierarchy is based upon message flows through the ancestor portal - see Object-oriented programming)

Figure 19/2a Messages flowing down a hierarchy

Figure 19/2b Messages flowing up a hierarchy

In the hierarchical structure (fig 19/2a), the messages move from the top of the hierarchy to the bottom. In the ancestor structure (fig 19/2b) the messages move from the bottom to the top.

The difference between the two is that in the hierarchical structure the nodes have to make a decision (as to which node to pass the message on to) before they pass the message on and in the ancestor structure there is no need to make such a decision because there is only the single choice available.

In the ancestor structure diagram, shown in fig 19/2b, node C passes the message upwards where the message can only go to the single Node B in this direction. When Node B receives the message, it can only pass it on upwards to Node A.

With the hierarchical structure shown in fig 19/2b, Node A has to make a decision as to whether to send a message to Node B or to Node F. If the message goes down to Node B, Node B has to make a decision as to whether to send it to Node C, Node D or Node E.

At first sight, the ancestor structure seems to provide only a limited facility (and is often complained about by people more familiar with the traditional OOP languages such as SmallTalk, C++ or Object Pascal, where they have a facility which allows a super class to send messages to descendants without knowing before hand what kind of descendants they could be). In fact, the very simplicity of the ancestor mechanism of Lingo objects conceals a very powerful switching mechanism which is ideal for object decision making and for sending messages up and down hierarchical structures.

The secret of unlocking the power of message switching with objects is to remember that the ancestor can be changed at any time (sometimes referred to as dynamic binding).

The trick of sending messages in two directions through an object hierarchy is to have each object store a list of its descendants in one of its other properties: each of which can be placed into the ancestor property as required.

In this way, objects have the facility to send messages up or down their hierarchies. As you will readily appreciate, such an arrangement will provide a versatile switching mechanism for messages: which will facilitate message switching around a network of objects.

To see how this works in practice let's create a hierarchy of objects in memory, each of which incorporates this feature. This will take the form of an abstract communication framework in computer memory consisting of a hierarchy of nodes similar to those of figs 19/2a and 19/2b.

First we create a parent script for a basic node object. This is shown in fig 19/3 (note that we are using the Director 5 syntax new instead of the former word birth used in Director 4).

Node - parent script

property ancestor,descendants,originalAncestor,myName
 
on new me,ancestorGiven,descendantsList,aName
  set ancestor to ancestorGiven
  set originalAncestor to ancestorGiven
  set descendants to descendantsList
  set myName to aName
  return me
end

Figure 19/3 Parent script for creating a node object

You can see , at the birth of any object from this parent script, that we can specify the ancestor. Also provide the object with a list of its descendants and give it a name.

We can create a hierarchy of objects similar to figs 19/2a and 19/2b by using a mouseUp handler of a button. Such a script is shown in fig 19/4.

Create hierarchy - button script

on mouseUp
  global boss,nodeA,nodeB,nodeC,nodeD,nodeE,nodeF,nodeG,nodeH,nodeI
  repeat with i = 1 to 2 --repeating to set nodes in first pass
    set boss to new(script "boss")
    set nodeA to new(script "node",boss,[nodeB,nodeF],"NodeA")
    set nodeB to new(script "node",nodeA,[nodeC,nodeD,nodeE],"NodeB")
    set nodeF to new(script "node",nodeA,[nodeG,nodeH,nodeI],"NodeF")
    set nodeC to new(script "node",nodeB,[],"NodeC")
    set nodeD to new(script "node",nodeB,[],"NodeD")
    set nodeE to new(script "node",nodeB,[],"NodeE")
    set nodeG to new(script "node",nodeF,[],"NodeG")
    set nodeH to new(script "node",nodeF,[],"NodeH")
    set nodeI to new(script "node",nodeF,[],"NodeI")
  end repeat
end

Figure 19/4 Creating a hierarchy of nodes

Notice that each of the nodes is initially birthed with an ancestor which corresponds to the object immediately above it in the hierarchy. The apex of the hierarchy (node A) has been given an ancestor portal to an object named "Boss".

Each object has also been given a list of objects which correspond to the descendants immediately below it in the hierarchy.

Study these scripts until you can see how they represent the hierarchies in figs 19/2a and 19/2b. The ability to be able to make this kind of paradigm switch is essential if you are to make full use of OOPS.

Let us now give the boss object a reality. The parent script for creating a boss object is shown in fig 19/5.

Boss - parent script

on new me
  return me
end
 
on messageToBoss me
  put "Boss has got the message"
end

Figure 19/5 Creating a boss object for the top of the hierarchy

All this boss object does is respond to the message messageToBoss. This is sufficient for us to be able to test the effectiveness of the hierarchy we have created in the memory space of the computer.

By sending this messageToBoss message, to any of the objects in the hierarchy, the message should get passed upwards through the ancestor portals until it reaches the boss object. The results of sending this messageToBoss message to various objects from the message box is shown in fig 19/6.

From the message box:

messageToBoss nodeG
-- "Boss has got the message"

messageToBoss nodeB
-- "Boss has got the message"

messageToBoss nodeE
-- "Boss has got the message"

Figure 19/6 Sending a message to the boss from different places in the hierarchy

As you can see from fig 19/6, the hierarchy responds as expected, with the messages traveling to the top of the hierarchy each time via the ancestor property.

The next thing to test is the ability of this hierarchy to transmit messages from the top of the hierarchy to the bottom. For this to happen the nodes need to be able to alter their ancestor properties. This can be done by providing a suitable handler in the nodes' parent script - a switchAncestor handler is shown in fig 19/7.

Node - parent script

property ancestor,descendants,originalAncestor,myName
 
on new me,ancestorGiven,descendantsList,aName
  set ancestor to ancestorGiven
  set originalAncestor to ancestorGiven
  set descendants to descendantsList
  set myName to aName
  return me
end
 
on switchAncestor me,num
  set ancestor to getAt(descendants,num)
end
 
on replaceOriginalAncestor me
  set ancestor to originalAncestor
end

Figure 19/7 A node can be told to change its ancestor

When the node object is created, it puts the ancestor it was given at birth into a property called originalAncestor. This allows the object to remember its "set up state".

Included in the parent script is a handler replaceOriginalAncestor which will allow the object to get back to its original state - which, as we shall see later, allows the original hierarchy to be restored to the way it was set up at birth.

Now that there is a facility for the hierarchy to be able to re configure itself, let's create another similar hierarchy with people. Lets create the hierarchy of people shown in fig 19/1.

The parent script (field "people") for creating people objects is shown in fig 19/8. It is exactly the same as the node object parent script except there is an additional handler which will allow a people object to identify itself if it receives a message (whoGetsIt).

people - parent script

property ancestor,descendants,originalAncestor,myName
 
on new me,ancestorGiven,descendantsList,aName
  set ancestor to ancestorGiven
  set originalAncestor to ancestorGiven
  set descendants to descendantsList
  set myName to aName
  return me
end
 
on switchAncestor me,num
  set ancestor to getAt(descendants,num)
end
 
on replaceOriginalAncestor me
  set ancestor to originalAncestor
end
 
on whoGetsIt me
  put myName & " has got it"
end

Figure 19/8 The node is given a way to identify itself

We can set up the hierarchy as shown in fig 19/1 in exactly the same way as we set up the hierarchy of nodes. This is shown in the mouseUp handler of button "Create people" in fig 19/9.

Create people - button script

on mouseUp
  global boss,Jennifer,June,John,William,Susan,James,Rachel,Lizzie,Joe
  repeat with i = 1 to 2 --repeating to set nodes in first pass
    set boss to new(script "boss")
    set Jennifer to new(script "people",boss,[June,James],"Jennifer Gray")
    set June to new(script "people",Jennifer,[John,William,Susan],"June White")
    set James to new(script "people",Jennifer,[Rachel,Lizzie,Joe],"James Scarlet")
    set John to new(script "people",June,[],"John Yellow")
    set William to new(script "people",June,[],"William Red")
    set Susan to new(script "people",June,[],"Susan Black")
    set Rachel to new(script "people",James,[],"Rachel Blue")
    set Lizzie to new(script "people",James,[],"Lizzie Brown")
    set Joe to new(script "people",James,[],"Joe Green")
  end repeat
end

Figure 19/9 Creating a hierarchy of people in memory space

It is worth taking a little time out here to try to visualize what it is we have now created in memory.

With the node hierarchy we created an abstract mechanism which has no exact physical equivalent. However, it can be adapted to a number of different metaphors.

It can be thought of as a river system where water from various tributaries flow into the main river. This is looking upwards, from the bottom. It can be seen as a system of water pipes with a series of pipes feeding water into a main pipe (again looking upwards). It can be seen as wires connecting onto a common bus, as with an electrical circuit.

Although the people hierarchy has exactly the same structure as the node hierarchy, it no longer has the same abstract quality . With the people hierarchy you can easily imagine what could happen. Looking up from the bottom, you wouldn't imagine orders flowing upwards, but, you can well imagine information and feedback flowing upwards from lower to higher levels of the hierarchy.

This is again the critical feature of OOPS coming into play: where a paradigm switch, using a metaphor, reveals a new pattern or possible potential use.

Different metaphors provide different paradigms when sending messages down a hierarchy from top to bottom. With a river metaphor the flow disperses as the water flow spreads out as it might do at a river estuary. With a hierarchy of pipes you can see how water can be directed along a particular path to come out at a particular pipe by using a system of taps. The electrical metaphor would see the system as a system of switches.

With the people metaphor, the hierarchy can be seen to be an intelligent network; where at each node there is a decision maker who makes a decision as to where an instruction coming from the top is passed on to the appropriate person below to deal with.

Seemingly, all these metaphors give a simple hierarchical network different roles, even though they all apply to an identical construct. The differences are all in the mind - it is the paradigm switch.

One paradigm might see the hierarchy as nodes gathering intelligence to make autonomous decisions. Another paradigm might see the hierarchy as a switching network or message flow device, which is set according to the actions of decision makers external to the hierarchy.

Even more exciting, a hierarchical network might be seen as an internal part of an object's intelligence system, enabling the object to make intelligent rational decisions based upon what conditions it encounters in the environment.

With this bag full of paradigms to switch between, let's now look at how we can re configure hierarchies and direct messages through them in a downwards direction.

Using a mouseUp handler in a button (see fig 19/10) the ancestor of object nodeA is changed to object nodeF, the ancestor of object nodeF is changed to object nodeG and the ancestor of object nodeG is changed to object Rachel.

Button script:

on mouseUp
  global boss,nodeA,nodeB,nodeC,nodeD,nodeE,nodeF,nodeG,nodeH,¬
       nodeI,Jennifer,June,John,William,Susan,James,Rachel,Lizzie,Joe
  switchAncestor nodeA,2
  switchAncestor nodeF,1
  set the ancestor of nodeG to Rachel
end

Figure 19/10 Setting an upwards route through the hierarchy

Confirmation of these ancestor changes can be obtained from the message box (see fig 19/11). The changes now create a new path through the hierarchy which can be seen by sending a whoGetsIt message to object nodeA which ends up being trapped in the Rachel object of the people hierarchy.

From the message box:

put the myName of the ancestor of nodeA
-- "NodeF"

put the myName of the ancestor of nodeF
-- "NodeG"

put the myName of the ancestor of nodeG
-- "Rachel Blue"

whoGetsIt nodeA
-- "Rachel Blue has got it"

Figure 19/11 Looking at the ancestor route and sending a message along it

The path of this message through the network of nodes is illustrated in fig 19/12.

Figure 19/12 The route of the message to Rachel

Clearly, this is only a single simple example. The ancestors could also be changed through a variety of different objects (and object networks) in response to all kinds of environmental or decision factors: producing any kind of route through the nodes.

Notice, in particular, the way in which the message is directed to a node in another hierarchy. Fig 19/13 shows how this principle can be extended further to arrange routes through more than one network of nodes.

In this scenario the president of the company, Jennifer Gray, wants to increase manufacturing. She sends a manufacturing order to vice-president June White, who oversees the manufacturing. June White gives the order to William Red in manufacturing who has to work out what product to make. As the weather forecast is reported to be wet he plumps for making umbrellas. Stock reports indicate that he needs to make a quantity of 1,000.

Figure 19/13 A logical decision making hierarchical network

Although this is an extremely simple example, you should be able to see the scope for organizing all kinds of complex interactions between objects and networks as they combine with each other to provide information for decision making in light of user response or environmental conditions.

This type of structure has many applications in artificial intelligence and is often described as a tree structure due to the branching effect from the nodes. Such a structure is used for problems of logical deduction where, like the parlor game of "twenty questions", the number of possible options is dramatically reduced after each logical question is posed (at each decision node).

Once you have grasped the concept of sending messages down hierarchical structures, you will then realize that there is no need to have a hierarchical arrangement at all. Nodes can be in any arrangement and the techniques which have been used here to direct messages down a hierarchical path can be used to define a message path across any arrangement of nodes.

Having a population of such node objects in the memory space of a computer, will allow the creation of flexible three dimensional networks of intelligent switching nodes of any shape or dimension.

Just by sending messages to object nodes to alter their ancestors, message paths through networks can be altered

Networks can be re configured according to any number or criteria. These networks can then form the basis of innumerable types of intelligent logical decision making mechanisms.

[Index]
[Next - Logical thinking networks]
[Back - Speculations]