www.s-cube-network.eu

S-Cube Learning Package

Executing the HOCL: Concept of a Chemical Interpreter

INRIA, CNR, SZTAKI

Zsolt Németh, SZTAKI

Learning Package Categorization

S-Cube

Service Infrastructure

Multi-level and self-adaptation

Supporting adaptation of

service-based applications

Learning Package Overview

The notion of chemical modeling

Interpreter for a chemical language

– Design considerations

– Main constructs

– Implementation

Experiences

Background: Complex problems in large scale distributed computing

• Grid, service based systems, clouds are characterized as

– Large number of interacting entities

– Heterogeneity

– Unknown/unpredictable behaviour

– Dynamicity

• Coordination, scheduling, optimisation and other complex tasks like

– Service composition

– Workflow enactment

– Process / Service coordination

– Resource scheduling

– Optimisation

– Recovery

Usually hard to solve/formalize, NP-hard, exact solutions are slow, etc.

Background: Notion of autonomic computing

Kephart: The vision of autonomic computing (2003)

Parts of the system should be able

– Self-configuration

– Self-optimization

– Self-healing

– Self-protection

Since then many self-* proposals

Background: Notion of nature inspired algorithms

The vision of autonomic computing ~ nerves

Nature phenomena like ants, molecules, particles, cells,

membranes, neurons, immune system, foraging, etc.

– possess self-controlled, self-coordinating, self-evolving, etc. properties

Primitive actions emerge as “intelligent” behaviour

Computing processes

– can mimic nature phenomena

– inspired by nature metaphors

See The Chemical Computing model and HOCL Programming

See Dynamic Adaptation with the Chemical Model

The chemical metaphor

Computational chemistry

– Simulate chemical processes

Chemical computing model

– Inspired by chemistry; chemistry as a metaphor

– Data = molecules

– Functions = molecules

– Computation = reactions

– State = chemical solution

Idea: algorithms are artificially sequential

– computing steps should be carried out independently, concurrently locally

– no notion of serialisation, instructions, computing steps, explicit control

– computation is self-evolving

A chemical language

• Higher Order Chemical Language (HOCL)

• based on the -calculus, see The Chemical Computing model and HOCL Programming

• Higher order: active molecules (procedures)

– capture other active molecules

– produce other active molecules

• Multiset rewriting

• multiset = chemical solution

• active molecules capture other molecules and transform

• replace P by M if C in <>

– P: pattern, captured molecules

– M: action, produced molecules

– C: condition

The Dutch flag example

let r = replace <i,red>,<j,white> by <i,white>,<j,red> if i>j in

let w = replace <i,white>,<j, blue> by <i, blue>,<j,white> if i>j in

let b = replace <i,red>,<j,blue> by <i,blue>,<j,red> if i>j in

<<1,blue>,<2,white>,<3,white>,<4,red>,<5,blue>,<6,white>,r,w,b>

blue

white

red 3

6

2

5

4

1

white

blue

white

b w

r

Chemistry and distributed computing

Existing models, proposals, concepts

– Self-coordinating distributed systems

– Service composition

– Workflow enactment

– Dynamic workflow

– Desktop grid coordination

General purpose chemical tools, interpreters do not exist

– Significantly different from current languages, tools, environments

– Long development cycle

A short development cycle for chemical tools: combine multiple models

– Declarative techniques, pattern matching

Learning Package Overview

The notion of chemical modeling

Interpreter for a chemical language

– Design considerations

– Main constructs

– Implementation

Experiences

Backgorund: the idea of abstract interpreter

The chemical model is semantically different from most

computing models

– it is not an imperative language

– it is not deterministic

– it is not related to the von Neumann model

In such cases an intermediate level of abstraction is

introduced: an abstract engine

– Prolog, Lisp, and many others are executed in this way

Efficient pattern matching is necessary

– best known algorithm: RETE

– found in many production systems

© S-Cube – 12/<Max>

Execution of declarative languages

• Highly abstract computational models

• Executed on von Neumann physical

architectures

• Notion of abstract machine

– hypothetic machine inbetween

– gives the illusion of executing a highly abstract

language natively

– high level language compiled to an

intermediate language

– the intermediate language is interpeted

high level

language

abstract

engine

physical

machine

compile

interprete

Production systems

A tool for artificial intelligence applications

– knowledge as facts and rules

Facts

– assumed true

– elementary, learned experience

– produced facts

Rules

– transform the knowledge base

– pattern

– condition

– action

match

action check

rule selected

Conceptual abstract engine

Notion of the abstract interpreter

RETE pattern matching from production system

Intermediate language: that of production system +

extensions

To be solved: hierarchical knowledge base

– Law of locality

– Law of membrane

Parallel/concurrent execution

Learning Package Overview

The notion of chemical modeling

Interpreter for a chemical language

– Design considerations

– Main constructs

– Implementation

Experiences

Passive molecules

Facts: statements

– Sorted (1), (1 2 5 apple), (a b 15 22)

- no names but order does matter

– Unsorted ((slot1 a)(slot2 apple)), ((x 2)(y 5)(z 6))

- slots have names

Molecule template

– (molecule (administrative slots) (instance slots))

- Administrative: id, solution, name

- (deftemplate number extends molecule (slot value)

(number (value 1))

(color (type white))

Active molecules

Active molecules → rules?

– a simple solution but in this way active molecules cannot be modified

Higher order property?

– active molecules can be captured and transformed

– difficult to realize with rules

Active molecules

– Rule: pattern, condition, action

– Fact: represents the instance

- Derived from molecule template

- Can be asserted, retracted, transferred, etc.

Active molecules

The Dutch flag example

– representation of the “red” molecule

(defrule r

(rule red)

;match <i, red> and <j, white> if i>j

→

;swap <i, red> and <j, white>

)

Solutions

Two-faced entities

– Data when inactive

– Process when active

- Each solution is an independent thread

Solutions are hierarchical but facts cannot be nested

– It is neither a fact nor a rule

Bidirectional references between solutions and molecules

– Prolog-like terms

5 blue

(solution (id x)(in nil)(molecules y z))

(molecule (id y)(in x)(value 5)…)

(molecule (id z)(in x)(type blue)…)

Solutions

Single step, flat pattern matching

The Dutch flag example (cont’d) (defrule r

(rule red)

(solution ?x)

(molecule (value ?i)(in ?x))

(molecule (color red)(in ?x))

(solution ?y)

(molecule (value ?j)(in ?y))

(molecule (color white)(in ?y))

(test ?i > ?j)

→

;swap <i, red> and <j, white>

(solution (id k)(in nil)(molecules j l))

(molecule (id j)(in k)(value 4)…)

(molecule (id l)(in k)(type red)…)

(solution (id x)(in nil)(molecules y z))

(molecule (id y)(in x)(value 2)…)

(molecule (id z)(in x)(type white)…)

Relocate

Most actions are transferring molecules between solutions

– very frequent operation, must be efficient

– must not make the intermediate language too complicated

Hard to maintain the references in an efficient way when

moving molecules between solutions

– serious performance degradation

– error prone

External procedure to the language: relocate

– Written in Java

– Operates on the internal data structures

– Adds imperative flavour where necessary

Relocate

There are various types of moving molecules

– Move x from a to b

- replace a:<x, ωa>,b:<ωb> by a:<ωa>,b:<x,ωb>

– Move everything except x from a to b

- replace a:<x, ωa>,b:<ωb> by a:<x>,b:< ωa,ωb>

– Move everything from a to b

- replace a:<ωa>,b:<ωb> by a:<>,b:< ωa,ωb>

Different for top-level and other solutions

Deleting solutions

All 15 cases represented by a single instruction

– Keep the intermediate language simple

– Realize efficiently

Relocate

Relocate (what to move) (what not to move) (from) (to)

The Dutch flag example (cont’d)

(defrule r

(rule red)

(solution ?x)

(molecule (value ?i)(in ?x))

(molecule (color red)(in ?x))

(solution ?y)

(molecule (value ?j)(in ?y))

(molecule (color white)(in ?y))

(test ?i > ?j)

)

(relocate (molecule (value ?i)(in ?x)) nil (solution ?x) (solution ?y))

Learning Package Overview

The notion of chemical modeling

Interpreter for a chemical language

– Design considerations

– Main constructs

– Implementation

Experiences

Conclusions

Implementation

Initial experiments: CLIPS

– C Language Integrated Production System

Full implementation: jess

– a rule engine for the Java platform

Main components

– Interpreter

– Graphical user interface

– Simple debugging and tracing tools

– Custom interfaces

Molecules

Current reaction

Potential reactions

per solution

Program control

Debug

information

Breakpoints,

adding molecules

at runtime

Learning Package Overview

The notion of chemical modeling

Interpreter for a chemical language

– Design considerations

– Main constructs

– Implementation

Experiences

Conclusions

Experiences I

Importance of random conflict resolution

Corresponds to random molecule selection

Foxes and rabbits (Lotka-Volterra) problem

– Predators and preys in a closed environment

– Their number should oscillate

… Did not oscillate…

Custom made random conflict resolution was necessary

– unexpected importance of real randomness in molecule selection

Experiences II

Importance of intelligent compilation

Tic-tac-toe game (custom interface)

– HOCL active molecule ~ rule

- Performance and scalability problems

- On larger boards response times are very long

– HOCL code broken into many simple rules

- Instead of few but complex rules

- Better fits the RETE algorithm (RETE better supports these)

- No performance issues, good scalability

Intelligent compilation needs further research

Learning Package Overview

The notion of chemical modeling

Interpreter for a chemical language

– Design considerations

– Main constructs

– Implementation

Experiences

Conclusions

Conclusion

The chemical model is a good candidate for autonomic, self-* computing

Various possibilities in distributed scenarios

General purpose tools are needed

Our approach

– Quick realisation of an interpreter

– Notion of abstract engine

– Combine different models

– Interfaces to the environment

Connections to other teaching units

Foundations

– The Chemical Computing model and HOCL Programming

Application

– Dynamic Adaptation with the Chemical Model

© S-Cube – 33/<Max>

References

Vilmos Rajcsányi, Zsolt Németh: The chemical machine: an interpreter for the Higher Order Chemical

Language. CGWS@EuroPar 2011, to appear.

Jean-Pierre Banatre, Pascal Fradet, and Yann Radenac. Programming self-organizing systems with the

higher-order chemical language. International Journal of Unconventional Computing, 3(3):161–177, 2007

Acknowledgements

The research leading to these results has

received funding from the European

Community’s Seventh Framework

Programme [FP7/2007-2013] under grant

agreement 215483 (S-Cube).