What is an AI toolkit? There are various levels at which we can - PDF document

Oxford Computing Lab, 30 Jan 2001 Birmingham 13 Oct 2003 – York 11 Feb 2004 SimAgent: TOOLS FOR DESIGNING MINDS (A toolkit for philosophers and engineers) Aaron Sloman http://www.cs.bham.ac.uk/˜axs/ School of Computer Science The University of Birmingham INCLUDING IDEAS FROM: Jeremy Baxter (DERA), Richard Hepplewhite (DERA) Riccardo Poli, Brian Logan, Darryl Davis, Catriona Kennedy Matthias Scheutz, Nick Hawes and others THE TOOLKIT IS AVAILABLE WITH SOURCES AT THE BIRMINGHAM FREE POPLOG SITE http://www.cs.bham.ac.uk/research/poplog/ Further information on the toolkit is here http://www.cs.bham.ac.uk/ axs/cogaff/simagent.html This and other related slide presentations are available here http://www.cs.bham.ac.uk/research/cogaff/talks/ SimAgent toolkit Slide 1 Updated March 15, 2007 What is an AI toolkit? There are various levels at which we can build machines, some much harder to start from than others: • Physical components • Digital electronic components • Machine code for an existing computer • Assembly language for an existing computers • Source language for a compiler for various computers • Higher level languages (lots and lots of them, making different things easy ...) • Operating systems • Re-usable procedure libraries • Architecture toolkits: Several for AI – SOAR – ACT, ACT-R, ACT-RP – PRS, JACK – COGENT – MOZART – SIMAGENT SimAgent toolkit Slide 2 Updated March 15, 2007

Requirements for our toolkit Minimal requirements: • The toolkit must support scenarios with rich ontologies. (Many kinds of objects, properties, relationships, internal and external actions, processes....) • The toolkit should support different sorts of agents, with different architectures. • Agents can have complex internal architectures. E.g. different components of a complex architecture may include: – different kinds of information, – different forms of representation, – different kinds of mechanisms • Concurrency is required at all levels: – Different entities in the “world” run concurrently. – Different components of individual agents run concurrently, performing various tasks in parallel, e.g. reacting, deliberating, carrying out plans, generating motives, learning, evaluating, self-monitoring, etc. • The toolkit should support research on machines that understand what they are doing and monitor and control some of their own internal processes. Other toolkits may have other requirements! SimAgent toolkit Slide 3 Updated March 15, 2007 The toolkit must support SCENARIOS WITH RICH ONTOLOGIES Diverse concurrently active entities, e.g.: • A GENTS : which can communicate with one another, • M ECHANISMS : which sense and react to other things, • I NSTRUMENTS : which can act if controlled by an agent, • “R EACTORS ” which do nothing unless acted on (e.g. a mouse-trap) • L OCATIONS : of arbitrary extents with various properties, including continuously varying heights, terrain features, etc., etc. The toolkit should also support different kinds of relationships between agents: • X perceives Y • X acts on Y • X communicates with Y • One event or process causes or modifies another SimAgent toolkit Slide 4 Updated March 15, 2007

INSIDE ONE AGENT Agents can have complex internal architectures • Rectangles represent short- or long-term databases or communication buffers • Ovals represent processing units. • Arrows represent flow of information, including control information Some components are linked to sensors and motors (physical or simulated) Some are connected only to other internal components Some sub-mechanisms change states continuously others only discretely. (The former can only be approximated on computers.) NB: we are mostly talking about virtual machine components whose relationships to brain-mechanisms may be very complex (a type of implementation relationship. For some architectures the diagram is too ‘flat’: there should be different structures at different levels of abstraction. See also http://www.cs.bham.ac.uk/research/cogaff/talks/#super SimAgent toolkit Slide 5 Updated March 15, 2007 The toolkit should support different sorts of agents, with different architectures E.g. agents: • performing different sorts of tasks • with various kinds of sensors and motors (either simulated or physical) • connected to different kinds of concurrently active internal processing modules changing at different speeds • with different kinds of internal short term and long term databases, • with some components monitoring or controlling others • using different forms of representation and reasoning • with different levels of abstraction, and different levels of control See the other slides on architectures and requirements for agents here: http://www.cs.bham.ac.uk/research/cogaff/talks/ It should be possible to include different sorts of agents and different sorts of objects in the same simulation, and it should be easy to add and new sorts. E.g. the sheepdog example includes sheep, trees, the pen and the dog. It is easy to add more of each kind, and to add new kinds, e.g. wolves. SimAgent toolkit Slide 6 Updated March 15, 2007

Concurrency is required at all levels Different entities in the “world” run concurrently. Different components of individual agents run concurrently, performing various tasks in parallel, e.g. • Perception, of different kinds • Using different senses: vision, hearing, smell, touch, proprioception, • Doing different levels of perceptual analysis, • Acting under control of continuous feedback loops, • Linguistic processing (understanding, communicating) • Learning of various kinds, • Triggering “alarms” (various kinds of emotion) • Reasoning • Generating new motives, evaluating motives, comparing motives, • Planning, executing plans, • Generating and changing internal control states (emotions, moods, etc.) • Monitoring internal processes (reflection, meta-management). • Monitoring and reasoning about other agents. The running speeds of different components in the simulation may vary. Compare M.Minsky The Society of Mind. Perhaps we need to think of an “ecosystem of mind”. See Cogaff papers http://www.cs.bham.ac.uk/research/cogaff/ SimAgent toolkit Slide 7 Updated March 15, 2007 Atomic State Functionalism Functionalism is one kind of attempt to understand the notion of virtual machine, in terms of states defined by a state-transition table: there’s a total state which affects input/output contingencies, and each possible state can be defined by how inputs determine next state and outputs. E.g. if the system is in state d then depending on the next input it may remain in state d or switch to state f, and the output it produces, if any, will depend on the state it is in and the input. E.g. see Ned Block’s accounts of functionalism. http://www.nyu.edu/gsas/dept/philo/faculty/block/papers/functionalism.html Many so called “cognitive architectures” conform to this model, though some of the state transitions may involve very complex processes and some transitions may occur without any input or without any output. Our toolkit needs to support a richer, deeper, notion of functionalism, which assumes a complex machine with many interacting components SimAgent toolkit Slide 8 Updated March 15, 2007

Virtual machine Functionalism We assume a kind of functionalism that allows many virtual machine components to co-exist and interact, including some that observe others, all within one agent. So there is not just a single (atomic) state which switches when some input is received. • The different states may change on different time scales: some change very rapidly, others very slowly, if at all. • Some sub-states may change in complexity over time, e.g. growing a parse tree, or a plan. • Sub-states can vary in their granularity: some sub-systems may be able to be only in one of a few states, whereas others can switch between vast numbers of possible states (like a computer’s virtual memory). • Some may change continuously, others only in discrete steps. As theorists and designers we wish to be able to explore such systems and understand their implications, their strengths their weaknesses. (In the footsteps of evolution). SimAgent toolkit Slide 9 Updated March 15, 2007 More on Virtual Machine Functionalism The situation is more complex than the previous diagram suggests. • There need not be a fixed set of sub-processes. • Within each sub-process there need not be a fixed set of possible states. • The individual states may vary in complexity. • Some sub-systems may vary continuously instead of discretely. • Sub-systems may change their speeds of operation asynchronously, instead of everything always changing in step. The figure illustrates this. Our toolkit should, in principle, cope with all of this, though some aspects may be only approximated. SimAgent toolkit Slide 10 Updated March 15, 2007