Mapping Simulation to the Real World

Mapping Simulation to the Real World

When designing a system, one would hope that it would be intended for use in the real world sooner or later. Yet it is impractical to assume that a first generation system can be adequately tested and analyzed in a dynamic environment. What these basic conclusions reveal is that almost every architecture which stands the test of time is going to have to make a transition from a simulated world to the real world.

This transition is no easy task to say the least. A simulation requires that some assumptions be made about the environment, and these assumptions could be crucial to the generality of any system that uses that environment. A classic example of this is a system which assumes that the necessary elements of the environment are instantly recognizable, and the activators of the system perform flawlessly. For instance, when designing a robot, we could assume it could recognize a green box, and we exploit this in the environment by representing it as a logic predicate GreenBox(P1). Similarly, we could have it execute its movement plan by outputting commands such as "Turn Left" and "Go Forward 2". If we actually expected to implement whatever architecture we designed in this system, the dynamic nature of the world and the difficulties of sensing would set us up for a rude awakening.

Even if the simulation environment does not have a such fundamentally slanted view of the world, the manipulation of the system environment could be enough to weaken the value of the testbed. Consider a system that uses an Explanation-based Learning algorithm and which always runs for a set(short) amount of time. Even though it would be likely that an agent could get really good at using EBL for goal reconstruction, opportunistic behavior, etc., this ignores the fact that if we let it run long enough, the system may slow down significantly because of the utility problem. By not addressing the basic problems of EBL, any progress made will be hampered. In this case it's not the environment per se which is affecting the development of the system, but the experimental setting itself.

In the former case, an author of a cognitive architecture should realize the drawbacks of the system under development, and yet also realize subverting them will can only harm the development and refinement of the architecture. The former case is much more tricky; how detailed can a model be and still be a model? There are no easy answers to this question. It helps to have a specific domain in mind for a system when testing, and emulating that domain as best as possible. But for a system which truly displays general intelligence, there is no one testbed which is wholly sufficient.


List of Theories
Table of Contents.

Current Location: Common Descriptions - Theory - Mapping Simulation to the Real World