IIDLE
Immunological Inspired Distributed Learning Environment

Home

Introduction

The field of Artificial Immune Systems (AIS) is interested in using immunology as an inspiration for computation paradigms. Predominantly the work in this field has been focused on devising and analysing algorithms inspired by specific immunological theories. The Immunological Inspired Distributed Learning Environment (IIDLE) is an artificial immune system that exploits the inherent parallelism, decentralised control, and spatially distributed nature of the learning behaviours of the mammalian acquired immune system. It is a platform or framework for distributed learning tasks that (among many other features) can have immunological and other algorithms embedded within it.

This page provides a brief description of the conceptual model that underpins IIDLE, as well as a number of case study application scenarios with demonstration software and downloadable source code. The hope is that both the ideas and practical implementation of IIDLE be made accessible and generate interest, comment, and perhaps facilitate the extension of this area of research. Peer-reviewed publications and technical reports on the IIDLE platform are available. If you are interested in discussing the IIDLE platform or potential collaboration or experiment ideas please contact me.

Conceptual Model of IIDLE

IIDLE is based in a holistic abstraction of the acquired immune system as a spatially distributed, circulating and heterogeneous population of specialised discrete units that provide a homogeneous defence against external pathogenic material. It is these discrete, atomic, immutable and disposable units or information packets that represent the knowledge captured by the system, and are the substrate for the maintenance and learning processes.


Conceptualisation of the clonal expansion theory as a triggered population based learning system

Using this population based abstraction of the acquired immune system, the intent in developing the IIDLE platform was to devise an AIS that was distributed and decentralised from the ground up. The following were the principle design goals for developing the platform in the context of the immunological model:

  1. Context Specific Learning - from an initial generic starting point, the system is capable of tuning its performance to the specific environment or domain to which it is applied.
  2. Self-Regulated Resource Maintenance - internal processes exist within the system to govern the allocation and de-allocation of resources in response to the context specific requirements of the system (such as in response to external input and bounding space complexity).
  3. Decentralised Control - the internal maintenance processes of the system are localised and self-governing, not requiring a master controlling process.
  4. Triggered Adaptation - the system modification required when learning occurs in response to an externally introduced trigger defined by the context or environment in which the system is situated.
  5. Robustness and Fault Tolerance - there is an inbuilt lack of dependence and reliance on specific discrete components of the system. This is permitted by architectural and functional redundancy, which facilitates the continued system operation in response dynamic component failure or removal.


A Conceptualisation of the distributed immunological architecture showing locality connectivity, external stimulation, and internal activation

Architecture

  1. Localities - The continuous nature of the vascular and lymphatic systems that provide the migration pathways for lymphocyte cells is discretised  into distinct localities (not unlike island populations) that are connected together in some network topology facilitating the inherent mobility of units. A locality abstract provides both an interface and scope at which to apply local (decentralised) processes, as well as a transient storage location for discrete units.
  2. Tail - A locality supports a population structure called a tail that stores a number of discrete units for a given time. The structure is called a tail given the manner in which it is depicted diagrammatically. The locality and tail are differentiated for conceptual modularity where the physical storage data structure for units can be changed and reconfigured independently of the locality and its associated governing and maintenance processes.
  3. Units - A tail contains a number (zero or more) units at any given time during the simulation. Each unit is a discrete information packet meaningful in the context of the specific problem domain to which IIDLE is being applied (such as a permutation, real number variables, etc... and an associated quality scoring).


Overview of the IIDLE architecture showing localities, tails, and units

Processes

The system is simulated in discrete time intervals and processes represent the algorithmic component that operates upon the discrete unit substrate in the context of a specific problem application. Processes are confined to a locality and can be implemented as either independent threads of execution or executed in aggregate sequentially by a single thread at a desired scoping of localities.

  1. Movement Process - Movement is the process of removing units from the tail of one locality and adding them to the tail of a neighbouring locality. This unit migration facilitates the mobility of the knowledge learned by the system thus facilitating the redundancy of units and general robustness of the architecture.
  2. Decay Process - The decay process is designed to manage the size of the unit population, specifically in response to the creation of new units by the proliferation strategy of the expansion process. Each unit has a finite energy which is initialised upon unit creation, and it is the task of the decay process to decrement unit energy and discard those units that deplete all assigned energy. There are two approaches to this decay process that have been implemented - conformer homeostasis (blind uniform decay) and regulator homeostasis (seek scoped global energy equilibrium).
  3. Expansion Process - Core to the design principles of the expansion process is the conceptualisation of external stimulation (input) that triggers the internal adaptation (learning) processes of the system. The stimulation of a locality may be implemented as the provision of computation time (such as execution of an objective function), provision of memory resources (such as extension and exploration of a state space), or access to a limited resource (such as database records in a mainframe). The expansion process is loosely based upon the clonal expansion principle, although it is modularised into three discrete steps which must be selected in the context of a specific application domain; a stimulation strategy, a selection strategy (for selecting useful units), and a proliferation strategy.


An illustration of the weak coupling between data structures and processes as well as the variable scoping of processes on data structures

Philosophy (Vision) for IIDLE

The vision or philosophy for IIDLE is that of an ever-present or always-on system distributed across the internet on a decentralised P2P substrate. The knowledge of the system is captured by the discrete units (as discussed in the system architecture), although in this vision the units only exist in machines that are apart of the system. Hosts check-in and check-out of the system in an ad-hoc manner increasing and decreasing the knowledge capacity as well as the processing power of the system. Units flow through the network in an autonomous manner, and the hosts of the system selectively filter the units they are interested in, and selective contribute units to the flow.


Depiction of the vision of IIDLE as a network platform showing ad-hoc connection of clients, and the differing contributions of clients (producing units, consuming units, and both)

In practical terms the ever-present nature of the system provides an alternative to the configure-run-analyse cycle of conventional search and optimisation tasks. The scale of the implementation provides the capability to address conventional optimisation as well as collaborative optimisation at a level rarely discussed, let alone attempted (thousands or tens of thousands of clients). It is this ability to capture and harness human intervention to machine-learning tasks on a large scale I think that provides the most interesting application of this technology.

The following points summarise this vision of the IIDLE as an internet machine-learning platform:

Basic Optimization

IIDLE is capable of addressing canonical optimisation problems such as the Travelling Salesman Problem (TSP), Function Optimisation (funcopt) and Protein Folding (HP Model). For this scenario IIDLE is run on a single machine with a number of localities. Stimulation of units equates to evaluation against an objective function, and proliferation is one of three simple optimisation approaches; Genetic Algorithm, Ant Colony Optimisation (ACO), and Random Search.


A graphical display in the IIDLE architecture showing units in various different states

This first IIDLE scenario (basic optimisation) demonstrates an important IIDLE principle, that of an always-on and human interactive search process. The problem domains are relatively easy to solve as they were selected to demonstrate these important and foundational principles of the IIDLE platform. A stop condition has not been set for the simulations permitting the user complete and real-time control over the progression of the simulation. Real-time feedback is provided in the form of line graphs and problem-specific graphics to permit the user to gauge impact of various configurations on the simulation.

Function Optimisation - Schwefel's Function in 2D
The interface provides an indication of mean, best, and worst solution quality over time, as well as an indication of the current systems samples in the context of a two-dimensional plot of the objective function. Jitter (noise) can be added to the objective function in real time, and the function can be adjusted to change dynamically over time.
Try the applet
Travelling Salesman Problem (TSP) - Berlin 52 (52 cities)
Provides an indication of the best tour (minimal length) found to date as well as system performance over time. Also provides a sensitivity plot of all permutations currently in the system, which provides an indication of system convergence toward a common solution.
Try the applet
Protein Folding (HP Model) - Permutation Length 64
Provides an indication of the optimal folding permutation found to date as well as the performance of the system over time.
Try the applet

Multiple Objective Optimization

For the application of IIDLE to optimisation problem domains, the objective function is implemented as stimulation to the system at the scope of localities. Using multiple different objective functions is implemented as multiple different stimulation strategies which can be configured to trigger adaptation in the system in a uniform (all stimulation strategies operate across all localities) or in a partitioned (scoped) manner (localities are divided between the stimulation strategies). The latter partitioned approach results in interesting implicit niching effects, and thus is used as a default configuration in the following TSP and function optimisation examples.

Travelling Salesman Problem (TSP) - 3 Objectives
The Berlin-52 TSP problem is tackled using three different approaches (objective functions) of evaluating a tour; Euclidean tour length (minimising), total tour intersections (minimising), and total nearest-neighbour connections (maximising). The localities of the system are partitioned into three to accommodate the three differing objective functions.
Try the applet
Function Optimisation - Separable Function (Schwefel's)
The Schwefel's function is linearly separable between each dimension. In this example, a 2D implementation of the function is tackled by IIDLE although with two partitions each operating upon a different dimension. The experiment is made more interesting by a transition on the evaluation function that causes the axis to flip over time.
Try the applet

Hybrid Optimization

As discussed in the application of IIDLE to multiple objective problems, the localities of IIDLE can be partitioned for the scoping of a stimulation strategies. This scoping can also be applied to differing proliferation strategies - referred to as hybrid search. This section provides an example of IIDLE with a number of different search strategies on a function optimisation and TSP domain.

Function Optimisation - Hybrid Search
Here IIDLE is applied once again to the Schwefel's function in two dimensions. The localities of the system are partitioned into three groups one for each of the following proliferation strategies; ACO, GA, Random Search. The strategies can be changed for each partition in real time.
Try the applet
Travelling Salesman Problem (TSP) - Hybrid Search
IIDLE is applied to the Berlin-52 TSP domain. The localities of the system are partitioned into three groups one for each of the following proliferation strategies; ACO, GA, Random Search. The strategies can be changed for each partition in real time.
Try the applet

Interactive and Networked Collaborative Optimization

As indication, external stimulation is not restricted to access to an objective function, here an example is provided of using human feedback as the stimulation strategy for searching for an optimal TSP tour. Also provided in an example of IIDLE implemented using an open-source peer-to-peer (P2P) network substrate. This permits IIDLE clients to be connected to each other in a self-optimising peer-to-peer network across any physical computer network (eg a computer lab or the internet). When configured with autonomous IIDLE clients the implementation represents a distributed search, when configured for use by interactive-humans the implementation represents a networked collaborative search.

Human-Feedback Travelling Salesman Problem (TSP)
An interactive human-feedback panel is provided that displays a number of TSP tours at a time. The user is then capable of rating the quality or messiness of displayed tours by left-clicking (good quality) or right-clicking (bad quality). The user-supplied quality scorings are then used in the selection and proliferation strategy to produce new tours.
Try the applet
Networked Collaborative Search - TSP
The previous basic TSP optimisation example with network support. Specific network controls as well as network-based visualisation is provided to indicate portal localities (localities on which inbound and outbound movement network processes operate) and visiting units (units from the network).
applet soon...
Networked Collaborative Search - Protein Folding
The previous basic protein folding optimisation example with network support. Specific network controls as well as network-based visualisation is provided to indicate portal localities (localities on which inbound and outbound movement network processes operate) and visiting units (units from the network).
applet soon...

Future

There are many domains and experiments I want to try with IIDLE, the following lists some of the more interesting ideas for future work and preliminary work that has already been completed:

Download

The software was written in Java 1.5 (5.0), and was written to be highly-modular and extensible. Thus it is relatively trivial to include additional processes, strategies and problem definitions. The software also uses a number of open-source libraries (provided in the offline download); JFreeChart, OpensourcePhysics, Jung, Jakarta Commons (collections, lang, logging, math, primitives), colt, pastry. The software download contains configuration and batch files ready to run all of the IIDLE scenarios described on this page.

Frequently Asked Questions (FAQ)

Ask me questions, contact me.

Q. Why is it so slow when adjusting the total number of localities in the system?
A. There is a threading concern - the simple fix is to pause the system when changing the total localities, then un-pause after the configuration change.

To-Do

The following are features I would like to add to this software over time, as well as user-requested features that I'd like to include (time permitting):




Home