S-CUBE LP: Executing the HOCL: Concept of a Chemical Interpreter

433 views

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
433
On SlideShare
0
From Embeds
0
Number of Embeds
24
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

S-CUBE LP: Executing the HOCL: Concept of a Chemical Interpreter

  1. 1. S-Cube Learning PackageExecuting the HOCL: Concept of a Chemical Interpreter INRIA, CNR, SZTAKI Zsolt Németh, SZTAKI www.s-cube-network.eu
  2. 2. Learning Package Categorization S-Cube Service Infrastructure Multi-level and self-adaptation Supporting adaptation of service-based applications
  3. 3. Learning Package Overview The notion of chemical modeling Interpreter for a chemical language – Design considerations – Main constructs – Implementation Experiences
  4. 4. Background: Complex problems in largescale 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. 5. Background: Notion of autonomiccomputing  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. 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. 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. 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. 9. The Dutch flag examplelet r = replace <i,red>,<j,white> by <i,white>,<j,red> if i>j inlet w = replace <i,white>,<j, blue> by <i, blue>,<j,white> if i>j inlet 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. 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. 11. Learning Package Overview The notion of chemical modeling Interpreter for a chemical language – Design considerations – Main constructs – Implementation Experiences
  12. 12. Backgorund: the idea of abstractinterpreter 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>
  13. 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. 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. 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. 16. Learning Package Overview The notion of chemical modeling Interpreter for a chemical language – Design considerations – Main constructs – Implementation Experiences
  17. 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. 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. 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. 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. 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. 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. 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. 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. 25. Learning Package Overview The notion of chemical modeling Interpreter for a chemical language – Design considerations – Main constructs – Implementation Experiences Conclusions
  26. 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. 27. Program controlCurrent reaction Breakpoints, adding molecules at runtimeMolecules Potential reactions per solution Debug information
  28. 28. Learning Package Overview The notion of chemical modeling Interpreter for a chemical language – Design considerations – Main constructs – Implementation Experiences Conclusions
  29. 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. 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. 31. Learning Package Overview The notion of chemical modeling Interpreter for a chemical language – Design considerations – Main constructs – Implementation Experiences Conclusions
  32. 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
  33. 33. Connections to other teaching units Foundations – The Chemical Computing model and HOCL Programming Application – Dynamic Adaptation with the Chemical Model © S-Cube – 33/<Max>
  34. 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. 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).

×