The document describes an interpreter for a chemical language called Higher Order Chemical Language (HOCL) based on the chemical computing model. The interpreter uses a production system approach with RETE pattern matching to enable efficient execution of the chemical language. Key constructs of the language include passive molecules to represent facts, active molecules to represent rules, and solutions to represent independent computational threads. The interpreter was implemented using Jess rule engine and experiences showed the importance of random conflict resolution and intelligent compilation for chemical modeling applications.
S-CUBE LP: Executing the HOCL: Concept of a Chemical Interpreter
1. S-Cube Learning Package
Executing the HOCL: Concept of a Chemical
Interpreter
INRIA, CNR, SZTAKI
Zsolt Németh, SZTAKI
www.s-cube-network.eu
2. Learning Package Categorization
S-Cube
Service Infrastructure
Multi-level and self-adaptation
Supporting adaptation of
service-based applications
3. Learning Package Overview
The notion of chemical modeling
Interpreter for a chemical language
– Design considerations
– Main constructs
– Implementation
Experiences
4. 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.
5. 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
6. 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
7. 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
8. 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
9. 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>
2
5 blue
white 6
1
r white
blue
white
3 4 b
w red
10. 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
11. Learning Package Overview
The notion of chemical modeling
Interpreter for a chemical language
– Design considerations
– Main constructs
– Implementation
Experiences
13. Execution of declarative languages
• Highly abstract computational models
• Executed on von Neumann physical
high level
architectures language
• Notion of abstract machine compile
– hypothetic machine inbetween
abstract
– gives the illusion of executing a highly abstract engine
language natively
interprete
– high level language compiled to an
intermediate language physical
– the intermediate language is interpeted machine
14. Production systems
A tool for artificial intelligence applications
– knowledge as facts and rules
Facts
– assumed true
– elementary, learned experience
match
– produced facts
Rules
– transform the knowledge base
– pattern check action
– condition
– action rule selected
15. 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
16. Learning Package Overview
The notion of chemical modeling
Interpreter for a chemical language
– Design considerations
– Main constructs
– Implementation
Experiences
17. 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))
18. 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.
19. 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>
)
20. 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
(solution (id x)(in nil)(molecules y z))
(molecule (id y)(in x)(value 5)…)
5 blue
(molecule (id z)(in x)(type blue)…)
21. Solutions
Single step, flat pattern matching
The Dutch flag example (cont’d)
(defrule r (solution (id k)(in nil)(molecules j l))
(rule red)
(solution ?x) (molecule (id j)(in k)(value 4)…)
(molecule (value ?i)(in ?x)) (molecule (id l)(in k)(type red)…)
(molecule (color red)(in ?x))
(solution ?y) (solution (id x)(in nil)(molecules y z))
(molecule (value ?j)(in ?y))
(molecule (id y)(in x)(value 2)…)
(molecule (color white)(in ?y))
(test ?i > ?j) (molecule (id z)(in x)(type white)…)
→
;swap <i, red> and <j, white>
22. 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
23. 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
24. 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))
25. Learning Package Overview
The notion of chemical modeling
Interpreter for a chemical language
– Design considerations
– Main constructs
– Implementation
Experiences
Conclusions
26. 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
27. Program control
Current reaction
Breakpoints,
adding molecules
at runtime
Molecules Potential reactions
per solution
Debug
information
28. Learning Package Overview
The notion of chemical modeling
Interpreter for a chemical language
– Design considerations
– Main constructs
– Implementation
Experiences
Conclusions
29. 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
30. 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
31. Learning Package Overview
The notion of chemical modeling
Interpreter for a chemical language
– Design considerations
– Main constructs
– Implementation
Experiences
Conclusions
32. 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
34. 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
35. 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).