Towards a Simulation-Based Programming Paradigm for AI applications

05/20/2015
by   Jörg Pührer, et al.
0

We present initial ideas for a programming paradigm based on simulation that is targeted towards applications of artificial intelligence (AI). The approach aims at integrating techniques from different areas of AI and is based on the idea that simulated entities may freely exchange data and behavioural patterns. We define basic notions of a simulation-based programming paradigm and show how it can be used for implementing AI applications.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

06/25/2019

Towards Enterprise-Ready AI Deployments Minimizing the Risk of Consuming AI Models in Business Applications

The stochastic nature of artificial intelligence (AI) models introduces ...
03/04/2020

AI-Mediated Exchange Theory

As Artificial Intelligence (AI) plays an ever-expanding role in sociotec...
04/07/2022

Predicting Performance of Heterogeneous AI Systems with Discrete-Event Simulations

In recent years, artificial intelligence (AI) technologies have found in...
04/22/2019

Galaxy Learning – A Position Paper

The recent rapid development of artificial intelligence (AI, mainly driv...
10/03/2021

Exploration of AI-Oriented Power System Transient Stability Simulations

Artificial Intelligence (AI) has made significant progress in the past 5...
04/27/2019

Regulating AI: do we need new tools?

The Artificial Intelligence paradigm (hereinafter referred to as "AI") b...
02/12/2018

Towards self-adaptable robots: from programming to training machines

We argue that hardware modularity plays a key role in the convergence of...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Artificial intelligence (AI) is a wide field of research in which many different outstanding techniques have been developed and refined over the last decades [15]. Naturally, the question arises how to couple or integrate different subsets of these accomplishments. Besides many approaches to couple specific individual methods, a need for a wider integration of different AI techniques has been identified in the area of artificial general intelligence [16, 10]. Here, the goal is to build strong AI systems, i.e., reach human level intelligence. Arguably, integration of existing techniques is also desirable for less ambitious AI applications (that we aim for), consider for instance the realisation of intelligent opponents in computer games as a motivating example. As a side remark, note that current solutions for game AI rarely make use of techniques from reseach in AI but are often ad-hoc, based on hardcoded strategies, and incapable of learning.

Simulation has been used in different fields of AI (such as agent-based systems [12, 18]

or evolutionary computation 

[4]) for achieving intelligent behaviour. The rationale is that many aspects of intelligent behaviour are complex and not well understood but can be observed to emerge when the environment in which they occur is simulated adequately. In this work, we propose to use a simulation environment for realising AI applications that offers an easy way to integrate existing methods from different areas of AI such as computational intelligence, symbolic AI, or statistical methods. In particular, we present the basic cornerstones of a simulation-based programming paradigm (SBP) and demonstrate how it can be used to model different use cases for intelligent systems. The basic idea of SBP is to simulate an environment of interacting entities driven by concurrent processes. Entities are not grouped in types or classes and contain data as well as transition descriptions that define possible behaviour. Both, the behaviour and data associated to entities are subject to change which allows for learning techniques.

In the proposed approach, different points of views, hypothetical reasoning, or different granularities of simulation can be addressed by using multiple worlds refering to (not necessarily) the same entities. For example, the beliefs of an agent which is modelled by an entity can be represented by a world that might differ from the data available in another world that represents an objective reality. This gives rise for epistemic reasoning capabilities, where e.g., an agent A thinks about what agent B thinks and acts upon these beliefs.

The remainder of the paper is organised as follows. Next, we introduce the basic notions of a simulation-based programming paradigm. Section 3 discusses how to model different scenarios of AI applications in the approach. We show how behaviour can be exchanged between entities and discuss how evolutionary processes can emerge. Moreover, we demonstrate the use of different worlds for hypothetical reasoning, expressing and exchanging different beliefs about facts and processes, and for using different granularities of simulation. In Section 4 we discuss interface considerations for transition descriptions. After that, Section 5 addresses the issue of maintaining consistency when data is updated by concurrent processes. Section 6 discusses the relation to existing techniques including differences to agent-based approaches and object-oriented programming. The paper is concluded in Section 7 with a short summary and an outlook on future work.

2 Simulation-Based Programming

In this section we explain the architecture of the proposed simulation-based programming paradigm on an abstract level.

An SBP system deals with different worlds, each of which can be seen as a different point of view. The meaning of these worlds is not pre-defined by SBP, e.g., the programmer can decide to take an objectivistic setting and consider one world the designated real one or treat all worlds alike. Different worlds allow for example to model the beliefs of an agent as in an agent-based approach. Other applications are hypothetical reasoning or realising different granularities of abstraction for efficiency, e.g., parts of the simulation that are currently in focus can be manipulated by a world that offers a more precise simulation whereas parts out of focus are handled by another world that implements an approximation (see Section 3).

A world contains a set of named entities which are the primary artifacts of SBP. Entities may have two sorts of named attributes: data entries which correspond to arbitrary data (including references to other entities) and transition descriptions which define the behaviour of the entities over time. The name of an entity has to be unique with respect to a world and serves as a means to reference the entity, however the same entity may appear in different worlds with potentially different attributes and attribute values. Transition descriptions can be seen as the main source code elements in the approach and they are, similar to the data entries, subject to change during runtime. This allows for a dynamic setting in which the behaviour of entities can change over time, e.g., new behaviour can be learned, acquired from other entities, or shaped by evolutionary processes. We do not propose a particular language or programming paradigm for specifying transition descriptions. It might, on the contrary, be beneficial to allow for different languages for different transition descriptions even within the same simulation. For instance, a transition description implementing sorting can be realised by some efficient standard algorithm in an imperative language, while another transition description that deals with a combinatorial problem with many side constraints uses a declarative knowledge representation approach like answer-set programming (ASP) [8, 13] in which the problem can be easily modelled. Declarative languages are also quite useful in settings where the transition description should be modified at runtime (as mentioned above) as they often allow for easy changes. That is, because problem descriptions in these languages are typically concise and many declarative languages offer high elaboration tolerance [9], i.e., little changes of the problem statement require only few adaptations of the source code that solves the problem.

We require transition descriptions—in whatever language they are written—to comply to a specific interface that allows us to execute them in asynchronous processes. In particular, the output of a transition contains a set of updates to be performed on worlds, entities, data entries, and transition descriptions. When a transition has finished, per entity, these changes are applied in an atomic transaction that should leave the entity in a consistent state (provided that the transition description is well designed).

As mentioned, transition descriptions are executed in processes. Each process is associated with some entity and runs a transition description of this entity in a loop. A process can however decide to terminate itself or other processes at any time, initiate other processes, and wait for their results before finishing their own iteration.

We assume an infinite set of names and say that a concept is named if it has an associated name . We frequently use the data structure of a map, which is a set of pairs such that is a named object, , and implies . With slight abuse of notation we write for . In the following we describe how the concepts discussed above are related more formally. To this end, we assume the availability of a set of semantics for transition functions that will be explained later on.

Definition 1
  • A transition description is a pair , where is a piece of source code, and is a semantics.

  • A process is a tuple , where is a transition description and is a timestamp marking the begin of the current transition.

  • An entity is a tuple , where is a map of named data, is a map of named transition descriptions, and is a map of named processes. Entries of ,, and are called properties of .

  • A world is a map of named entities.

  • An SBP configuration is a map of named worlds.

We assume a pre-specified set of updates which are descriptions of what changes should be made to an SBP configuration together with a fixed update function that maps an SBP configuration, an entity name, the name of a world, and a set of updates, to a new SBP configuration.

Definition 2

A result structure for a process is a tuple , where is a set of updates and is one of the boolean values or that decides whether process should continue with another transition.

A semantics is a function that maps a piece of source code, an SBP configuration, the name of a world, the name of an entity, and a timestamp to a result structure.

Dynamic Behaviour

For presentational reasons we forgo giving a precise definition of the runtime semantics of an SBP system that would require heavy notation but describe the behaviour of the system on a semi-formal level using the concepts introduced above.

For running an SBP system we need an initial collection of worlds. Thus, let be an SBP configuration.111In practice, could by convention consist of a single world with a process running a transition description for initialisation, similar to a main function. We assume a discrete notion of time where a run of the system starts at time , and that denotes the SBP configuration of each point in time during a run.

At every time during the run of an SBP system the following conditions hold or changes are performed:

  • for each process such that for some entity in some world of there are three options:

    • continues, i.e., for entity with in world with ;

    • can be cancelled, i.e., for as in Item (i);

    • has finished its computation, i.e., the result of , namely

      is computed for . The updates that were computed by are added to a set of updates for entity in world , i.e., .

      The original process is deleted similar as in Case (ii). However, if then, at time point after , a new iteration of the process starts, i.e., if there is an entity with in world with and there is a transition description such that , then contains a new process with .

    Why and when a process continues, is cancelled, or finishes is not further specified at this point because, intuitively, in an SBP system this depends on decisions within the process itself, other processes, and the available computational resources.

  • starting with , iteratively, for every item in some world of where the set of collected updates is non-empty, a new SBP configuration is computed by the update function:

    The SBP configuration computed in the last iteration becomes the new configuration of the system for the next point in time.

    We do not make assumptions about the order in which updates are applied for now and discuss the related topic of consistency handling in Section 5.

Using names (for worlds, entities, and properties) allows us to speak about concepts that change over time. For example, if is an entity in some world at time and some data is added to for time then, technically, this results in another entity . As our intention is to consider an updated version of we use the same names for both, i.e., . In the subsequent work we will sometimes refer to concepts by their names. Along these lines, we introduce the following path-like notation using the -operator for referring to SBP concepts in a run. Assuming a sequence of SBP configurations in a run as above, we refer to

  • the world by ,

  • the entity by ,

  • the property in , , or by (we assume that no entity has multiple data entries, transition descriptions, or processes of the same name).

If clear from the context, we drop the name of the world or entity and apply the timestamp directly to entities or properties, or also drop the timestamp if not needed or clear.

3 Modelling AI Applications in SBP

The concepts introduced in the previous section provide an abstract computation framework for SBP. Next, we demonstrate how to use it for modelling AI scenarios. Note that in this section we will use high-level pseudo code for expressing the source code of transition descriptions and emphasise that in an implementation we suggest to use different high-level programming languages tailored to the specific needs of the task handled by the transition description. We discuss interface considerations for these embeddings of other formalisms in Section 4.

Following the basic idea, i.e., simulating an intended scenario on the level of the programming language, entities in SBP are meant to reflect real world entities. In contrast to objects as in object-oriented programming (cf. Section 6), entities are not grouped in a hierarchy of classes. Classes are a valuable tool in settings that require clear structures and rigorously defined behaviour. However, in the scenarios we target, the nature of entities may change over time and the focus is on emerging rather than predictable behaviour. For example, in a real-world simulation, a town may become a city and a caterpillar a butterfly, etc., or, in fictional settings (think of a computer game) a stone could turn into a creature or vice versa. We want to directly support metamorphoses of this kind, letting entities transform completely over time regarding their data as well as their behaviour (represented by transition descriptions). Instead of using predefined classes, type membership is expressed by means of properties in SBP, e.g., each entity may have a data entry that contains a list of types that currently belongs to.

Example 1

We deal with a scenario of a two-dimensional area, represented by a single SBP world , where each entity may have a property with values of form determining the location of to be at coordinates . The area is full of chickens running around, each of which is represented by an entity. In the beginning, every chicken has a transition description that allows the chicken to move around with the pseudo code:

 wait(randomValue(1..5000))
 dir = randomValue(1..4)
 switch{dir}
  case 1: return {’mv_up’}
  case 2: return {’mv_right’}
  case 3: return {’mv_down’}
  case 4: return {’mv_left’}

The transition first waits for a random amount of time and chooses a random direction for the move, represented by the updates . The semantics of always returns , where contains the update (the direction to move) and indicates that after the end of the transition there should be a new one. When the update function is called with one of the updates it changes the value of , e.g., if has value and the update is then has value .

Besides randomly walking chickens, the area is sparsely strewn with corn. Corn does not move but it is eaten by chicken. Hence, each chicken has another transition description with the code:

 if there is some entity en in myworld with
  en.loc = my.loc and
  en.types contains ’corn’
 then
  return {’eatCorn(en)’}

Here, we assume that using the keyword my we can refer to properties of the entity to which the transition description belongs ( in this case). Furthermore, myworld refers to the world in which this entity appears. Also here, every iteration of automatically starts another one. For an update , the update function

  • deletes the location entry of the corn and

  • notifies the corn entity that it was eaten by setting the data entry to (we will need the information which chicken ate the corn later) and adding a process to the corn entity with the transition description that is specified by the following pseudo code:

      return {’delete_me’}
    

    that causes the corn to delete itself from the area. Unlike for the other transition descriptions, a process with lasts for only a single iteration.

Assume we have an initial SBP configuration , where every chicken entity in has an active process named with transition description and a process with transition description . Then, a run simulates chickens that run around randomly and eat corn on their way.

While Example 1 illustrates how data is changed over time and new processes can be started by means of updates, the next example enriches the scenario with functionality for learning new behaviour.

Example 2

We extend the scenario of Example 1 to a fairy tale the setting by assuming that among all the corn entities, there is one dedicated corn named that has the power to make chickens smarter if they eat it.

This has a transition description :

 wait(randomValue(1..1000))
 en is an entity in myworld where
  en.types contains ’corn’ and
  there is no other entity en’
                 in myworld where
    en’.types contains ’corn’  and
    distance(en’.loc,my.loc) <
            distance(en.loc,my.loc)
 let my.loc=(myX,myY)
 let en.loc=(otherX,otherY)
 distX = otherX - myX
 distY = otherY - myY
 if |distX| > |distY| then
   if distX > 0 then
    return {’mv_right’}
   else
    return {’mv_left’}
  else
   if distY > 0 then
    return {’mv_down’}
   else
    return {’mv_up’}

Intuitively, this transition causes an entity to move towards the closest corn rather than walking randomly as in . Another difference is that processes have shorter iterations on average as the range of the random amount of time to wait is smaller. The does not have active processes for this transition definition itself but can pass it on to everyone who eats it. This is defined in the transition that differs from the transition description of other corn:

  ch = my.eatenBy
  return {’delete_me’,
        ’copyTransition(mvSmart,ch)’,
        ’changeTransition(ch.move,mvSmart)’}

Besides issueing the update as it is the case for normal corn, the update copies the transition description from the to the chicken by which it was eaten. The update changes the process of the chicken to use its new transition description instead of . Thus, if a chicken happens to eat the it will subsequently have a better than random strategy to catch some corn.

Having means to replace individual behavioural patterns, as in the example allows for modelling evolutionary processes in an easy way. For example, if the chicken scenario is modified in a way that chicken which do not eat corn regularly will die, a chicken that ate the has good chances to survive for a long period of time. Further processes could allow chickens to reproduce when they meet such that baby chicken may inherit which transition description to use for moving from one of the parents. Then, most likely, chicken using will be predominant soon.

The next example illustrates the use of worlds for hypothetical reasoning.

Example 3

Entity represents a waiter of an international restaurant in a tourist area trying to talk people on the street into having dinner in his restaurant. To this end, guesses what food they could like and makes offers accordingly. We assume an SBP configuration in which for every entity that represents a human, there is a world that represents the view of the world of this human. The following transition description allows to set the eating habits of passer-by in his world using country stereotypes.

 wait(randomValue(50))
 let en be an entity in myworld where
   en.loc near my.loc
   en.types contains ’human’
   en.eatingHabits = unknown
  country = guess most likely
            home country of en
  prototype = myworld.country.inhPrototype
  return {’setEatingHabits(en,propotype)’,
          ’setPotentialCustomer(en)’}

For every country, contains a reference to an entity representing a typical person from this country. The update copies transition descriptions and data properties that are related with food from person to person . Moreover, the update lets consider entity to be a potential customer. In order to choose what to offer a potential customer, the waiter thinks about what kind of food the person would choose (based on his stereotypes). This is modelled via the following transition :

 let cus be a potential customer in myworld
 w’ = copy of myworld
 w’.cus.availableFood =
                    restaurant.availableFood
 w’.cus.hungry = true
 intermediate return {addWorld(w’),
           startProcess(w’.cus.startDinner)}
 when process w’.cus.foodSelected is finished
  food = w’.cus.selectedFood
  return {praiseFood(food), deleteWorld(w’)}

To allow for hypothetical reasoning by the waiter, a temporary copy of the world is created. The sole purpose of this world is to simulate the customer dining. We use a temporary world since the simulation uses the same transition descriptions that drive the overall simulation. For example, if we would use instead, this would mean that thinks that the customer is actually having dinner. If we would use the world of the customer that would mean that the customer thinks she is having dinner and so on.

After creating , the transition description defines that the food available to the version of the customer in is exactly the food that is on the menu of the restaurant and the customer is set to be hungry in the imagination of the waiter. Then, is added to the SBP configuration and a process for is started using the transition description that lets enitity start dining in . Note that the keyword intermediate return in the pseudo code is a convenience notation that allows for manipulating the SBP configuration during a transition which is strictly speaking not allowed in the formal framework of Section 2. Nevertheless, the same behaviour could be accomplished in a conformant way by splitting into two separate transition descriptions that are used in an alternating scheme. As soon as the customer chooses some food in the simulation, transition is notified. It continues with reading which food has been chosen in the hypothetical setting. Finally, the update causes the waiter to make an offer for the chosen food in the subsequent computation, whereas deletes the temporary world.

Note that copying worlds as done in Example 3 does not necessarily imply copying all of the resources in this world within an implementation of an SBP runtime engine (cf. the final discussion in Section 7). Moreover, it will sometimes be useful to adjust transition definitions in the copied world. For instance, when a transition definition deliberately slows down the pace of the simulation as it is done in Examples 1 and 2 using the wait statement, it would make sense to reduce the waiting time in a world for hypothetical reasoning. Another need for adapting a copied world is mentioned in Section 4 in the context of externally controlled processes.

Example 4

We continue Example 3 by assuming an SBP configuration where a tourist, , passes by the waiter. His process for transition .classifies Ada by her looks to be an Englishwoman. After that, the process for starts hypothetical reasoning about Ada having dinner. Following the stereotypes of about English eating habits, the process reveals that would go for blood pudding which he offers her subsequently. However, Ada is not interested in this dish as she is vegetarian. She explains her eating habits to the waiter, modelled by the following transition description :

 let pers be current discussion partner
                                in myworld
 if pers offers food containing meat then
  let w_pers be the world of pers
  return {’setEatingHabits(w_pers.me,
                           myworld.me)’}

Here, the update that we used also in the previous example, the transition will overwrite the food related properties of the entity representing Ada in the world of with her actual eating habits. If runs the dining simulation again for making another offer the result will match the real choices of Ada.

The last two examples showed how worlds can be used to express different modalities like individual points of views or hypothetical scenarios. Next, we sketch a setting where different worlds represent the same situation at different granularities.

Example 5

Consider a computer game in which the player controls a character in an environment over which different villages are distributed. Whenever the character is close to or in a village the inhabitants of the village should be simulated following their daily routines and interacting with the player. However, as the game environment is huge, simulating all inhabitants of each village at all times is too costly. The problem can be addressed by an SBP configuration that has two worlds, and for each village . Intuitively, simulates the village and its people in all details but has only active processes while the player is closeby. The world approximates the behaviour of the whole village, e.g., increasing or shrinking of the population, economic output and input, or relations to neighbour villages, based on statistics and it has only active processes whenever the player is not around. Whenever the player enters a village, a process is started that synchronises the world with the current state of the village in , e.g., by deleting or adding new inhabitants or shops. Moreover, it starts processes in and cancels processes in . Another type of process is started when the player leaves again, that performs an opposite switch from to being active.

While learning by simply copying transition descriptions from different other entities as shown earlier already allows for many different behaviour patterns to emerge, an SBP system can also be designed such that new transition descriptions are created at runtime. For example, by implementing mutation or crossing-over operators for decision descriptions, it is easy to realise genetic programming 

[6] principles in SBP. Another source for new transition descriptions is related to an important challenge in AI: learning behaviour by watching the environment. In an SBP framework it is easy to incorporate existing learning techniques [14, 1] by means of transition descriptions. Behaviour acquired by processes executing such transitions can then also be represented by means of transition descriptions and distributed to entities.

4 Interface Considerations for Transition Descriptions

As we want to allow for different formalisms to be used for transition descriptions it is important that they are able to interact smoothly. This is essentially already reached if their semantics respects the interface of Definition 2. As different transitions communicate by reading and writing from and to the SBP configuration their formalisms do not need to be aligned in a different way. It is certainly necessary, however, that they use the same format for property values.

The examples in the previous section already show some of the features that we think are useful in a language realising a transition description. For one, it is valuable to have generic keywords standing for the name of the entity to which the transition belongs to and its world, like me and myworld in the examples. This way, if the transition description is copied to another entity or the same entity in another world it dynamically works with the other entity or world.

We do not define an explicit user interface for SBP systems but suggest that interaction of the user or another external source with an SBP system by means of externally controlled processes: A transition description can use a dedicated ’external semantics’ where the result structure returned for every transition is provided by the user or an external system. Following this approach, an SBP system acts as a reactive approach that is influenced by events from its environment. By having the decision which parts are controlled externally and which ones within the system on the level of transition descriptions allows for having parts of the behaviour of an entity partially controlled by the user and partially by the system. Moreover, as decisions descriptions can be replaced at runtime it is also possible to take control over aspects previously handled by the system and, conversely, formerly externally controlled transitions can be automatised. This way one can replace, e.g., a human player in a computer game by an AI player or vice versa. Naturally, this requires a proper modelling. For instance, in a simulation where worlds are copied for hypothetical reasoning like in the restaurant examples, a modeller would probably want to replace human controlled processes by automated ones in the copied world. Otherwise, the user would have to provide additional input for the hypothetical scenario.

In the context of the model-view-controller pattern, an SBP configuration represents the model and an SBP runtime engine corresponds to the controller. We suggest to handle the view outside of SBP, although it would be interesting to explore whether it is beneficial to also model graphical user interfaces inside SBP.

5 Consistency of Data

A key element of SBP is concurrent programming. Thus, a natural question is how problems regarding concurrent access on data and consistency of data are handled in the approach. Conceptionally, conflicting updates that occur at the same time instant do not cause a technical problem as the update function resolves an arbitrary set of updates to a valid follow-up SBP configuration. In practice, however, the functionality of this function has to be implemented and conflicts (e.g., deleting and changing a property of the same name at the same time) have to be addressed. Here, techniques for concurrency control in databases [2] could be useful. Moreover, it might be worthwhile to give the modeller means for specifying how to resolve individual conclicts by a dedicated language. Besides technically conflicting updates on data, another issue are semantical inconsistencies, i.e., data whose meaning with respect to the modelled problem domain is conflicting. As an example, consider an SBP configuration modelling a banana and two monkeys and assume that each monkey has a transition description that lets him grab the banana whenever it is laying on the ground. Now suppose that both monkeys detect the banana at slightly different times and their grabbing processes start. Then, after the first monkey has taken the banana, the process of the other monkey is still going on and, depending on the concrete modelling, it could happen that the system is in a state where each monkey is believed to have the banana. We argue that consistency problems of this kind should be tackled on the level of modelling rather than by the underlying computational framework as there are many types of issues that have to be addressed in different ways and also in the real world two monkeys could believe that they succeeded in getting a banana for a short period of time. One solution in the example could be that the successful grabbing process of the first monkey cancels that of the other or that the grabbing update is implemented in a conditional way such that grabbing takes only place if the banana is still in place at the time instant when the process has finished. Although one cannot expect that problems of this kind are handled automatically, a concurrent formalism should allow for addressing them in an easy way. A major point for future work on SBP is to explore best practices for avoiding inconsistencies in the first place by adequate modelling. Moreover, situations should be singled out in which inconsistency avoidance requires much modelling effort but the respective problem could be handled by adding features to the framework.

6 Influences and Relation to Existing Approaches

A goal of our approach is to integrate the use of different AI techniques in a dynamic framework. Here, a main mechanism of integration is using existing AI formalisms (e.g., ASP, planning techniques, etc.) for solving subproblems by means of transitions descriptions. This is similar in spirit to the use of different context formalisms in recent reactive forms of heterogenous multi-context systems [3, 5].

The idea of using multiple worlds for different points of view and modalities is loosely related to the possible world semantics of modal logics [7].

Evolutionary processes are intrinsic to many types of simulation. In, genetic algorithms 

[11] the fitness of individuals is typically rated by a dedicated fitness function, whereas the most obvious approach in SBP is simulating natural selection by competition in the simulated environment, as discussed in the context of the chicken scenario after Example 2. The evolution of behaviour is related to genetic programming [6]

where computer programs are shaped by evolutionary processes. Besides processes for the evolution of data and behaviour also other techniques that are frequently used in meta-heuristics, like swarm intelligence methods can be modelled and mixed in SBP in a natural way.

Agent-based systems (ABS) [12, 18] share several aspects with SBP like the significance of emerging behaviour when entities are viewed as agents. This view, however, is not adequate for all types of entities in the SBP setting as an entity could also represent objects like stones, collections of entities, or intangible concepts like ’the right to vote’ which should not be seen as agents. Moreover, agents interact via explicit acts of communication that can but need not be modelled in an SBP configuration. Thus, we see SBP conceptionally one level below ABS, i.e., SBP languages can be used for implementing ABSs rather than being ABSs themselves.

Focuses of integration efforts in artificial general intelligence are communication APIs [19] and design methodology [17].

The shift of paradigm from procedural to object-oriented programming (OOP) can be seen as a step towards structuring programming to be more like the real world: in OOP, a world of objects of defined types. In particular, objects are instances of classes that are organised in a hierachy of classes in which data structures and behaviour can be inherited from top to bottom. While classes are well-suited for applications that require a clear structuring of data, they also impose a rigid corset on their instances: the data and behaviour of objects is in essence limited to what is pre-defined in their class. Moreover, the type of object is defined on instantiation and does not change during runtime. In contrast, the behaviour and data of entities in SBP can be changed over time. Inheritance in SBP works on the individual level: entities can pass their transition descriptions and data entries to fellow entities. Thus, compared to OOP, inheritance is not organised in a hierarchical way. The underlying motivation is to follow the main idea of simulating real world objects, taking the stance that entities in nature are individuals that are not structured into distinct classes per se. Instead of the instantiation of classes for generating new objects, an important strategy for obtaining new entities in SBP is the prototype pattern: copying an entity that is closest to how the new entity should be like. As discussed in Section 3, other techniques for creating new objects are sexual reproduction or random mutation.

Another difference between typical object-oriented languages and the SBP approach is related to the control flow. Like procedural programming, OOP programs are executed in an imperative way. Typically, a run of a program in OOP starts with an entry method executed in a main thread from which child threads can be spawned in order to obtain concurrency. When a method calls another, it is per default executed in the same thread, i.e., the execution of the calling method is paused until the called method has finished. In SBP, there is no main thread and each transition runs in an independent process. Thereby, the approach exploits the trend to concurrent computing due to which simulation became feasible for many applications.

7 Conclusion

In this work we proposed an approach for using simulation as a programming paradigm. The cornerstones of the approach are

  • typeless entities

  • different worlds for different views on reality

  • behaviour defined by heterogenous concurrent services

  • exchange of behavioural patterns and individual inheritance

The main contribution of the paper is not a ready-to-use language but an initial idea for an architecture to combine these principles in a simulation-based programming paradigm. Clearly, there are many important aspects that need to be addressed when putting SBP in practice. Examples are the choice of data structures for entities, their interface when using different formalisms in transition definitions, and consistency of data as discussed in Section 5.

As a next step we want to explore the capabilities of different formalisms as a transition description language starting with ASP and identify different modelling patterns for important problems. A major goal is the development of a prototype SBP runtime engine which opens a wide field for further research: An important point is how to manage resources in SBP systems in which multiple worlds and entities share identical or slightly different data and processes. Efficiency requirements could necessitate mechanisms for sharing resources, e.g., by only keeping track of differences when a world or entity is cloned.

References

  • [1] Brenna Argall, Sonia Chernova, Manuela M. Veloso, and Brett Browning, ‘A survey of robot learning from demonstration’, Robotics and Autonomous Systems, 57(5), 469–483, (2009).
  • [2] Philip A. Bernstein, Vassos Hadzilacos, and Nathan Goodman, Concurrency Control and Recovery in Database Systems, Addison-Wesley, 1987.
  • [3] Gerhard Brewka, Stefan Ellmauthaler, and Jörg Pührer, ‘Multi-context systems for reactive reasoning in dynamic environments’, in Proc. ECAI’14, (2014). To appear.
  • [4] L.J. Fogel, A.J. Owens, and M.J. Walsh, Artificial intelligence through simulated evolution, Wiley, Chichester, WS, UK, 1966.
  • [5] R. Gonçalves, M. Knorr, and J. Leite, ‘Evolving multi-context systems’, in Proc. ECAI’14, (2014). To appear.
  • [6] John R. Koza, Genetic Programming: On the Programming of Computers by Means of Natural Selection, MIT Press, Cambridge, MA, USA, 1992.
  • [7] Saul Kripke, ‘A completeness theorem in modal logic’, J. Symb. Log., 24(1), 1–14, (1959).
  • [8]

    Victor W. Marek and Mirosław Truszczyński, ‘Stable models and an alternative logic programming paradigm’, in

    In The Logic Programming Paradigm: a 25-Year Perspective, eds., Krzysztof R. Apt, Victor W. Marek, Mirosław Truszczyński, and David S. Warren, 375–398, Springer, (1999).
  • [9] John McCarthy, ‘Elaboration tolerance’, in Proceedings of the 4th Symposium on Logical Formalizations of Commonsense Reasoning (Common Sense 98), pp. 198–217, (1998).
  • [10] Marvin Minsky, Push Singh, and Aaron Sloman, ‘The st. thomas common sense symposium: Designing architectures for human-level intelligence’, AI Magazine, 25(2), 113–124, (2004).
  • [11] Melanie Mitchell, An introduction to genetic algorithms, MIT Press, 1998.
  • [12] Muaz Niazi and Amir Hussain, ‘Agent-based computing from multi-agent systems to agent-based models: a visual survey’, Scientometrics, 89(2), 479–499, (2011).
  • [13] Ilkka Niemelä, ‘Logic programs with stable model semantics as a constraint programming paradigm’, Annals of Mathematics and Artificial Intelligence, 25(3-4), 241–273, (1999).
  • [14]

    Santiago Ontañón, José L. Montaña, and Avelino J. Gonzalez, ‘A dynamic-bayesian network framework for modeling and evaluating learning from observation’,

    Expert Syst. Appl., 41(11), 5212–5226, (2014).
  • [15] Stuart J. Russell and Peter Norvig, Artificial Intelligence - A Modern Approach (3. internat. ed.), Pearson Education, 2010.
  • [16] Kristinn R. Thórisson, ‘Integrated a.i. systems’, Minds and Machines, 17(1), 11–25, (2007).
  • [17] Kristinn R. Thórisson, Hrvoje Benko, Denis Abramov, Andrew Arnold, Sameer Maskey, and Aruchunan Vaseekaran, ‘Constructionist design methodology for interactive intelligences’, AI Magazine, 25(4), 77–90, (2004).
  • [18] Michael J. Wooldridge, An Introduction to MultiAgent Systems (2. ed.), Wiley, 2009.
  • [19] Kai yuh Hsiao, Peter Gorniak, and Deb Roy, ‘NetP: A network API for building heterogeneous modular intelligent systems’, in Proceedings of the AAAI 2005 Workshop on Modular Construction of Human-Like Intelligence, (2005).