Production systems are language based game engines

The history of AI knows production systems, General problem solvers and STRIPS like solvers. What they have in common is, that they are using language based transformation of a system which results into high speed problem solving. To explain the idea in detail i give an example.

A robot is located within the center of a map. He can move in 4 directions (up, down, left, right). The numerical way of problem solving is working with a gametree. All possible sequences of the robot, e.g. “up, up, left, up, left” is stored in a graph and a solver can search in the graph for a goal node. Dedicated path planning algorithm like A* or RRT modify this approach a bit and search the graph faster.

A production system is working different from graph search. The basic idea is, to describe the problem on a semantic level with the help of a robot language. This is equal to introduce macroactions. The robot language contains of the following words:

- lowlevelactions: up, down, left, right

- midlevelactions: 5up, 5down, 5left, 5right

- highlevelaction: movetolocation, moveincircle, resetgame

The words of the robot language can be combined to larger programs, very similar to a behavior tree. A production system is using the grammar for reaching a goal. The advantage over a graph search algorithm is, that the computational effort is much lower. The reason, why STRIPS like solvers are not very common in robotics is because it's hard to invent the robot language from scratch. In most problems only the low level commands (up,down, left, right) are known, but not macro-actions.

In the STRIPS notation, the domain grammar is stored in the STRIPS syntax, while in the SOAR production system the syntax is based on SOAR production rules. In both cases, the domain file is equal to a grammar which describes a problem on a higher level. The grammar allows to search in the action space of the robot more efficient than testing out only lowlevel sequences of actions.

Symbolic AI

Symbolic AI is equal to create a higher abstraction layer on top of movement primitives. On the lower side, the robot can only move in four directions with one step each. He is not able to reach with one command a position far away. This kind of super-actions has to be invented by the programmer. It's possible to transform a super action like “moveto(10,20)” into a sequence of lowlevel actions. In the literature the concept is described as hierarchical planning and it's improves the efficiency in problem solving.

The major question is not how STRIPS or SOAR works internally, which is equal to plan in a hierarchical fashion, the bottleneck is the grammar which describes the macro-actions. Using an existing STRIPS domain description for determine the lowlevel actions of the robot is an easy to solve problem. Because the solver will search in the domain file, test out some alternatives and then he will have found the correct action sequence. The more demanding challenge is to convert a game into the STRIPS domain file.

A language grammar allows to execute high level actions in a game. After running a macro-action the game will be in a new state. The transition is formalized in a symbolic game engine. Let me give an example. According to the grammar, the macro-action “5up” is available. The meaning of the command has to be formalized in sourcecode:

newposition = oldpos + (0,-5)

defines the action precisely. The action modifies the underlying game. It changes the position of the robot. Now we can ask which lowlevel actions are needed to become the same result. The transformation from high level actions into lowlevel actions can be realized with a solver.

Language understanding machines

A software which accepts natural language commands is easier to realize then it might look at the first side. All what is needed is an if-then-statement:

if input==”5up” then ...

if input==”5down” then ...

We can feed the program with a string for example “5up” and the program is doing something. From a perspective of a game programmer, such a software module is called a game engine. It specifies which actions can be send to the game. The statement after the “then” section are grounding the input word. They are formulating precisely, how the game state get changed. After a game engine was programmed it's possible to formulate a high level program written in the domain specific language:

5up

5up

5down

... is an example program. Each command is send to the game engine and is executed in a virtual machine.

A simple grammar for solving Sokoban like puzzles

In he example picture the well known game of sokoban is shown. To make things easier no obstacles are there but the robot has to push the boxes to the goal position at the lower right of the map. The lowlevel actions available for the robot are: left, right, up, down.

The first idea to solve the problem with a RRT graph failed. It's not possible to generate the entire action sequence, because the number of required actions are to high. The robot has to reach first box0, then he has to push the box to the goal, then he has to go to the next box and so on.

The next better approach after using RRT graph search is implementing a robot control language and use a symbolic solver for figuring out the low level actions. This approach works much better. The implemented grammar has the following elements:

"reset","movetobox","pushboxtowaypoint","movesmall", "pushsmall"

All these words are equal to powerful macroactions. It modifies the position of the player in absolute values. For example the action “movesmall” is able to teleport the robot 2 fields with a single command. Let us observe how a potential high level plan will look like:

1. movetobox 0 # a parameter is given to the command to specifiy the box0

2. pushboxtowaypoint 0

3. movetobox 1

4. pushboxtowaypoint 1

If the high level planner is made more detailed the improved plan will look the following:

1. movetobox 0

1a movesmall

1b movesmall

2. pushboxtowaypoint 0

2a pushsmall

2b pushsmall

2c pushsmall

3. movetobox 1

3a movesmall

3b movesmall

4. pushboxtowaypoint 1

4a pushsmall

4b pushsmall

Even this detailed plan is not expanded fully. A low level planner has to convert all the movesmall and pushsmall actions into lowlevel primitives. The resulting plan will contains only “left,right,up,down” actions. That's the basic idea of a hierarchical planner and the idea is powerful enough to determine the actions of the robot. The proposed system contains of three elements:

1. the Sokoban game itself

2. the grammar which includes lowlevel and highlevel actions

3. the planner which generates the plan and converts it into lowlevel action sequence

Let us dive into potential pitfalls. There are two possible pathways in generating the macro actions. I have choosen the manual way. That means, in the program there is a subroutine for “movesmall” and for “pushsmall”. In the subroutine the angle to the goal and the new position is determined with normal computer code. I'm unsure if it's possible to generate the macro actions without human intervention. In the literature the concept is called “Rule learning”, but I'm in doubt if this works for Sokoban. That means, my program doesn't have learning capabilities but it's static. All the macro actions are defined before the runtime.

Solving a symbolic problem

Let us go a step backward and describe what the planner has to do. Instead of trying out a sequence of lowlevel actions, the newly established environment contains of macro actions:

"reset","movetobox","pushboxtowaypoint","movesmall", "pushsmall"

The goal state has to reached with using a sequence of these actions. Because the macro actions are more powerful than the regular actions the sequence will become much shorter. The proposed plan can be described with a few commands. Before the planner can generate the actions autonomously it's important to ground the macro actions. Grounding means, that the actions are not only given in a Python list, but that the game engine accepts the command as a valid command and so something in return. That means, if the command movetobox is send to the game engine, the game engine will modify the robot's position and the result is displayed on the screen. This is called grounded actions, because the resulting game engine state can be measured by the planner.

Let me give an example. We are using a simple randomized planner which is sending randomly macro-actions to the game engine. After each trial we are testing what the position of the robot and the boxes is. If the boxes are at the goal position the plan has been found. Before we can measure the robot's position the action need to have an influence on the game engine. The counter example would be, that we are sending the high level action “movesmall” to he game engine but nothing happens. Then the action is not grounded and it's only a word in the program without having a meaning.

Short history of the Gutenberg Galaxy

The Gutenberg Galaxy is a virtual space of printed books. The most important event was the invention of the Gutenberg press in the 15th century. This technology allows for the first time to reduce the photocopy costs. A later milestone was the invention of the motor driven high speed press by Koenig&Bauer in the 19th century. They have revolutionized the printing of newspapers. At the same time the first public libraries were established in larger cities all over the world.

A recent event in the progression of the Gutenberg galaxy were the first soft cover books in the 1960's. They have replaced former hard cover printings and their main advantage was the lower price. Around the year 2000 a very important milestone was reached, which is the internet. From now on it's possible to store a digital copy of a book in the cloud and – very important – do a fulltext search in the content. This results into today's information age in which classical books have become obsolete.

All the invention from 1500 until today have lowered the costs of distribution knowledge. It's easier than ever to write, print and reproduce information. This is equal to flood the Gutenberg universe with more content. A look back into the past shows, that not the invention of the computer, nor the electric light was the most important invention, but the supporting technologies of the Gutenberg age can be understand as the tipping point. Without the distribution of books, it would not be possible to discuss biology, literature, mathematics or engineering.

The interesting point is, that all innovations in the Gutenberg related domain were rejected at the beginning. In the 1960s in which the first soft cover books were published, the criticism were great. Most people doesn't like the new bookformat well and they prefered to spend more money in exchange of a hard-cover book which has a higher quality. The same techno-scepticism is there against the Academia.edu platform which is a breakthrough in distributing academic knowledge. Most researchers doesn't like the idea to upload their pdf paper to a server without paying the former Article processing charge. They don't trust the idea of reducing the costs of knowledge. They fear this will change the world. And all the concerns are correct.

Let us research some behaviors related to the gutenberg galaxy. How does it feels, if somebody buys a soft cover book for a cheaper price but not the hard cover version? How does it feel if somebody buys a newspaper instead of visiting the church at sunday? What is the emotion if somebody uploads a pdf paper to Academia.edu instead of sending the manuscript to a publisher? It feels always bad, it is nothing what looks right. It is something not wanted by society. In all of these cases, the individual user who is doing so stands up of the crowd. He is doing the opposite of what all other are doing. The reason is, that the idea of reducing the costs is something which is equal to make progress. And this is what Luddites are in fear of.

Industrial revolution

Some authors are surprised why the world has made since the 17th century such a dramatic progress and many new inventions were taken during the industrial revolution. The simple explanation is, that the printing press was the basis technology which triggered all the other inventions. If it's possible to copy a book, it is possible to establish a university in which the books are archived in libraries. And if a university is available, students will attend the classes, gets educated and can found new companies which brings economy forward.

Let us imagine an industrial revolution without the printing press. It won't work. Even if a certain genius had invent something, it wouldn't be possible to spread the news to other people. The printing press is some kind information highway which connects all the other development in society. The role of the printing press was overtaken by the Internet. It provides the same service but at lower costs and much faster. To understand the power of Internet technology we have to focus on a technical simple workflow. An author has written a manuscripts and uploads the pdf file to a server. Then the information is indexed by google and all the other users can download the document. They didn't have to pay anything, and they can get the content within seconds. That's the fastest printing press ever invented.

For today's point of view, this simple use case of the internet seems normal, but in the history of mankind it's rare. The first internet flatrates and the first search engines were invented in the year 2000. That means, the described workflow of uploading and download electronic manuscripts was invented only 19 years ago. What would happen if this innovation is active for a longer period of time, for example for 100 years? Yes, it will revolutionize everything. The amount of information will grow, and the number of people which have access to the content as well. What they are doing exactly with this electronic press is unclear, but it will speed up the information exchange.

Will Rust replace C++?

The Rust programming language looks like a promising candidate which simplifies programming. In contrast to C++ the language was designed from scratch and has many powerful features. Even the performance can be compared with C++. Unfortunately these features are not enough to compete with C++. The problem with C++ is, that the language is nearly perfect, which means there is no need for new kind of language. The reason why C++ has pointers is because a computer is working with pointers, and the reason why so much libraries are available in C++ is because so much programmers have written it. It's simply not possible to invent programming from scratch and make everything much better.

The future of C++ isn't Rust, but the future is a layered software development workflow in which the prototype is written in Python and the production code in C/C++. That's the best practice method in producing high quality software which runs on major operating systems. It's true that there is need for additional language apart from C/C++ but not with the aim to replace it but to extend it.

The funny thing with programming is, that writing code isn't very hard. I've never heard of a programming project in which the programmers where not able to create an array and fill it with values. The reason why software projects fails has to do with coordinating programmers, decide which kind of program has to be written and because the users doesn't like the application. Converting a specification into executable binary code is the easy part in a software project. If somebody is in the comfortable position, that he can type in C++ sourcecode into an IDE the project is on the right track.

Software engineering can't be revolutionized with new programming languages but with new collaborations tools like atlassian jira, wikis, github and so forth.

Is there a need for an alternative to SOAR?

The cognitive architecture SOAR is a well known and intensively documented framework for creating Artificial Intelligence agents which contains lots of interesting features like subgoaling, chunking and graph based working memory. But something is wrong with SOAR, which prevents that the software can be recommended for serious application. It has mainly to do with the documentation which are formulated always in the “you can do something”, and “you have to click this button” and so on. This kind of language works similar to the promotional language used in advertisement campaign, in which the new car is simply great, and and all what the user has to do is to get excited.

From an academic standpoint, this kind of description doesn't fulfill the minimum standard, which means, that the SOAR documentation can't be called scientific, but it's a waste of time reading it. Sure, SOAR itself is great, it combines most of the advanced features which are available for modern agent architectures but it's possible to make the overall system much better.

Which means, there is a need to invent things from scratch and built a new cognitive architecture from scratch which is less powerful than SOAR, but provides a better self-description what the project is about. The first step in doing so is to explain what the idea behind SOAR is. In contrast to normal solver, which is searching in the gametree for a goal node SOAR is working with heuristics. That means, the requirement for CPU ressources is low and no high computational task is needed to solve a problem. Everthing in the SOAR universe works reactive and with human engineered knowledge. The concept is sometimes called symbolic AI because no number crunching is involved in the game.

A first approach to understand SOAR better is to compare it with a STRIPS planner. A strips planner contains of actions which can be executed by the solver, and the precondition/postcondition for each action is given in the strips file. A cognitive architecture is some kind of advanced strips planner which has the ability to access a working memory and to learn new goals on the fly.

The Strips notation is a good starting point for developing a cognitive architecture from scratch, because the concept is described in mainstream Gaming AI and it's not very complicated to grasp the basic idea. The game starts with an init state, the solver is trying to find a sequence of actions, and this will guide the robot to the game.

In a paper [1] a mixture was described between a classical HTN planner and a memory architecture. The resulting architecture isn't so powerful like SOAR, bit explains more easier to understand what the idea is. It starts with a vanilla HTN planner for figuring out the actions for the robot. Before the planning process gets started, some operations on the internal memory have to be done. The paper admits, that it has reverse engineered the SOAR architecture, and the similarity is there. Exactly this approach makes sense, because this kind of inventing something twice is equal to learn something. If somebody isn't able to clone a software, he hasn't understand it.

HTN planning plus short term memory

The idea of combining HTN planning with a memory was also discussed in another paper.[2] It describes a non player character in a game, which doesn't have full information about the game, but sees only a limited amount of information which are stored in the short term memory. Similar to the previous referenced paper, the systems starts with a normal HTN planner for generating actions which is extended by additional components like a subgoal generator and a short term memory.

It's interesting to know, that the concept of a working memory plus subgoaling is described as well in the SOAR context as in Game AI non player characters as well. It seems, that life-like characters in games have a natural demand for a working memory and for hierarchical planning capabilities.

Let us imagine, how a non player character can be created which is more flexible. The first thing to do is to realize the working memory not as a normal datastructure but as a semantic network. All kind of variables can be stored there and nodes inbetween the items are possible, similar to a linked list. The second thing to do is to add a learning functionality. Which is a decision tree ID3 learning algorithm. This allows the non player character to adapt his behavior in realtime.`

[1] Zhang, Jun, et al. "MBHP: A memory-based method on robot planning under uncertainties." 2011 IEEE International Conference on Robotics and Biomimetics. IEEE, 2011.

[2] Mahmoud, Ibrahim M., et al. "Believable NPCs in serious games: HTN planning approach based on visual perception." 2014 IEEE Conference on Computational Intelligence and Games. IEEE, 2014.

Measuring Artificial Intelligence

The problem with most AI related projects is, that the newbies doesn't know what the goal is. Sure, Artificial Intelligence is the goal, but how exactly is this defined? A possible answer to the problem is to define Artificial Intelligence on a time scale. AI is equal to run a problem solver very fast.

Let us make a small example. The task is to solve the first level of Sokoban game. For doing so, the robot has to push some boxes. He can do so by building a graph of all possible movements and a common algorithm for doing so is RRT (Rapidly-exploring random tree). After starting the software, the CPU will consume 100% and after a while the program has found the solution. In case of Sokoban, the needed gametree is very large. Even if RRT is a nice algorithm he will consume lots of cpu ressources.

Can we increase the performance? Exactly here comes Artificial Inteligence into the game. RRT itself can be called AI, because it's a vanilla graph search algorithm. It's working a bit faster than a brute force solver but not very much. If the Sokoban problem is slightly more complicated the solver will fail. That means, a standard problem has to little cpu ressources to build the tree in realtime. It will takes many hours, until the sequence of robot moves was generated. AI related problem solving is to identify a faster technique. The aim is to solve the sokoban puzzle but with less computational effort.

The definition has the advantage that it explains what the goal is. The goal is more than only to control a robot, because the RRT algorithm can do so very well. The aim is to use as little cpu ressources as possible. That means, to invent an algorithm which is using the underlying hardware more efficient. Somebody may argue, that apart from graph search there is no alternative available which means, that games like Sokoban or Lemmings can't be solved. But this ignores that some AI heuristics are available which can do so much faster. The amount of potential speed up technique is large, and it's up to the programmer to identify the best one.

The interesting aspect of using the RRT algorithm is, that the technique is in theory well suited to solve any kind of Sokoban level. But in reality it can't. The problem is, that after some movements in the game, the game tree will become very large and even the RRT algorithm isn't able to handle this complexity. That means, everything works fine, but the CPU of the underlying hardware will need to much ressources. This brings the computer to it's physical limit and there is a need to invent something which works better. The question is not how to program an AI, the question is how to make the RRT algorithm more faster.

Let us take a look into RRT. The algorithm itself works great. It is using a graph to store existing movements in the game, and it extends the graph in a tricky way. Programming an RRT algorithm in software is a bit more complicated than programming the Sokoban game itself, but it's possible with all programming language available. The difficulty is, that RRT won't solve the core problem which is to find a path through the game tree. It's simply a scaling problem which means, that RRT works well only for problem which has 1000 upto 10000 nodes and then it becomes difficult. On the first look this insights sounds surprising, because RRT is one of the most efficient graph search algorithm available. Sometimes it was described as faster as A*. Unfortunately, this advantage is not enough. Because Sokoban is more complicated to solve than the RRT algoirthm has to offer.

All serious AI techniques are trying to overcome the bottleneck of classical graph search algorithm. They are trying to find a path in a large state space. They are doing so with heuristics and domain knowledge. What we can say for sure, is that normal graph search algorithm like A* or RRT are not able to solve harder problems. Hard means, that the map is huge in which the pathplanning problem is there or that the state space of the robot is huge. This is a surprising insight, because for the newbie RRT looks like a powerful tool for solving all kind of planning problems. The bottleneck is not to improve RRT a bit, for example by using a multicore CPU, the problem is, that solving Sokoban needs a speed up of 1 million percent. This is equal to a complete new algorithm apart from graph search.

What's wrong with RRT?

RRT is one of the most powerful search algorithm available. The reason why is a combination of building a graph and extend the graph efficiently with new nodes. Creating a graph is important because this helps to not figure out the same sequence of actions twice, and adding new nodes with the RRT techniques saves many ressources.

RRT outperforms A* a tittle bit. Not as much, that A* is become obsolete, but using RRT as the standard search algorithm for pathplanning and action planning in games. The only problem is, that RRT itself will fail in most problems. Graph search plus an optimized node-adding method isn't enough to handle a state space which contains of millions of nodes. If we like to use RRT for solving computer chess, sokoban, Lemmings or a robotics task we will notice, that the algorithm fails. That means, if will take to long for finding an answer. This has nothing to do with a certain programming language for example Python vs. C++, but the problem is, that a speedup of around 1000 upto 1 million is needed which can't be provided with RRT.

The answer to the problem is, to modify the problem itself. Instead of searching in the state space of lowlevel actions, the idea is to search in a symbolic state space. If RRT is used, for sampling PDDL actions, it's a very powerful algorithm. The problem is, that searching in symbolic actions has nothing to do with graph search, but it's a heuristic which goes beyond the RRT idea. The advantage of RRT is at the same time it's bottleneck. Searching in a graph works for all kind of problems but it results into a poor performance.

Let us go back to the Sokoban problem. Suppose, the RRT Solver is trying to analyze the state space. After a while, it's obvious that it takes too much time. We can cancel the operation and write a notice that RRT won't solve the problem. That means, RRT is useless for solving sokoban. We can switch back to the normal brute force solver which has nearly the same performance. That means, a highly optimized RRT algorithm will need 1 year to search in the game tree, and a normal brute force algorithm will take 100 years. Both performance results are not practical because the software has to find the next move in under a second.

What i want to explain is, that for serious problem we can ignore RRT and use a normal brute force solver without any graph building strategy. The bottleneck isn't how to search fast in a graph, the problem is how to map a task to a graph. Suppose, there is a graph given which contains of 2000 nodes and the aim is to find the shortest path. Under this constraints, RRT makes totally sense, because it's able to search the path very fast. Importunately, the Sokoban game doesn't provide a graph with 2000 nodes, but it provides no graph at all, and it's up to the programmer to identify a data structure in the game.

A well known technique for speed up the search in the state space is called “reactive planning”. That are non-sampling techniques which needs no or only a little amount of computational effort. Usually they are working in a hierarchical fashion. For example, it make sense to divide a map into smaller maps and use an quadtree planner to find the path. This is only the most common introduction into the subject of reactive planning, there are many more strategies available to reduce the state space drastically.

Artificial Intelligence is grouped around alternatives to classical RRT planning and is using knowledge, reactive planning and heuristics for speeding up the search in the game tree. The goal is to reduce the computational load to a minimum which allows to solve very complex problems on mainstream CPUs.

On the first look, quadtree like planner looks not very powerful. But compared to a vanilla RRT algorithm they are able to speed up the search for 10000x times and more. That means, after starting the algorithm the result is presented within milliseconds. The good news is, that octree planners, reactive planning and cognitive architectures doesn't contain Artificial Intelligence itself, but what they are doing is to search faster in the game tree. They are producing the same action sequence for a robot like the vanilla RRT algorithm but in a shorter amount of time. The initial problem is not “how to make the robot” smart, but the problem is, that the robot is smart already, but the solver needs 100 days, until he has determined the next move. AI is equal to reducing the calculating speed to zero or almost zero.

Lessons learned from implementing RRT for Sokoban

RRT (Rapidly-exploring random tree) is sometimes presented as the preferred path planning algorithm which works well for larger maps and for real time purposes. Implementing the algorithm in software is not that hard. It's mainly a class which contains of methods like “comparewithgoal”, “addnode”, “getparentid”, and “showpath”. If the user starts the algorithm the software will generate a game tree and adds new nodes carefully. This is equal to a fast sampling of the state space.

For smaller problems it works great. A small problem is a map of 20x20 fields, in which the robot is at top left and has to find the path to a goal and additionally some obstacles are in the map. Running the RRT algorithm for such kind of problems results into a performance of around 1 seconds which is fast enough. If the programming language is carefully selected for example C++, the speed is much better and it can be used under realtime constraints.

The problem begins if we are modify the setup slightly. In the robocode domain, the robot has not only move to a goal he has to push a box. The goal function has to check if the box has reached the goal. If the RRT algorithm is used for such kind of purposes the performance will become worse. On my computer it takes many minutes until a solution was found. A simple request to the solver like “put the box to goal position A” will result into a larger processing task which occupies lots of CPU ressources and will take 2 minutes. A more complicated task in which two boxes should be moved to a goal position results into an runtime of many hours which means, that the RRT algorithm doesn't find a solution.

The reason why has to do with the state space. If the robot has to move to the box, he will need around 10 steps, for moving the box to a goal he needs additional 15 steps, then he needs again 10 steps to move to box 2 and so on. The amount of possible actions in this longer sequence is high, and the resulting graph will grow quickly which is too much for the RRT algorithm.

The problem is, that it's not possible to improve the performance a bit, because for solving the box pushing task the algorithm has to run 1000x faster. RRT is not the answer to the problem, it prevents that the solver will find a solution. Sure, RRT is one of the fastest sampling algorithm available, but state space sampling isn't able to solve complex problems. I think the problem is located within planning itself. The idea of providing a start position and the solver has to find the goal position isn't working anymore. Only for simplify toy problems the algorithm will find the steps in between.

The good news is, that this understanding not only critizes the RRT algorithm, but similar techniques like PRM, A* and reinforcement learning will have the same poor performance. The only way to overcome the difficulty is to switch to a different kind of search strategy which doesn't sampling the state space.

Alternatives

Possible alternatives to RRT which are working faster are easy to tell. The first one is a quadtree path planner, which means, that the map is divided into submaps which have different sizes. This allows to plan longer routes with a single step. The second technique is symbolic planning in which the problem is converted into a STRIPS domain file which is equal to hierarchical actions. In both cases, the original problem is ignored, the normal state space is no longer relevant but a different layer is built on top of the original game.

Short description of symbolic AI in the 1960s

The General Problem solver and the Logic Theorist program was both realized in the late 1950s on mainframe computers. It was an early attempt in realizing a production systems. Later examples from the same subject were OPS5 (late 1970s) and SOAR (early 1980). A production system has much in common with STRIPS and PDDL planning tools. The idea is to formalize a problem into abstract actions which are planned by a solver. Sometimes, the planning process is supported by a goal stack and (Strips) and a working memory which is common for cognitive architectures for agent simulation.

The reason why the General Problem Solver and modern PDDL planners doesn't match the requirements into Artificial Intelligence is, because the planner/solver itself is useless, if the domain model is not available. All the capabilities which are provided by the STRIPS planner which includes the recursive goal stack will not solve a problem, if the strips input file is missing.

A production system is similar to an expert shell only the environment which is able to find the actions for a given STRIPS file, but it can't answer the question how to transform a domain into the strips file. Before it's possible to start the SOAR program, execute the PDDL solver or taking advantage of the OPS5 system an input file has to provided which contains of the action names, the variable names and the effects written down in a programming language. Even a modern cognitive architecture has the ability to learn, it's not so powerful that it can learn the domain description itself.

Let us analyze the simplest possible cognitive architecture which is a strips planner. Strips takes a domain description as input, creates a graph, and then it will search for a path through the symbolic graph. Programming a strips solver from scratch isn't very hard, because the algorithm for backtracking a graph is well known and the sourcecode is available at Rosettacode. The more demanding problem is how to convert a problem for example a game of Lemmings into a STRIPS domain description. This transformation is called grounding and STRIPS nor General Problem solver has the answer to the problem.

STRIPS domain file

Every STRIPS like planner needs as input file a domain description. This is equal to a domain specific language (Formalized as a grammar) plus some routines written in that language. In the well known robot gripper domain (blocksworld) the grammar is equal to a robot programming language. It contains of commands like opengripper, closegripper and movedown. The STRIPS planner is able to transform the language specification into a program. It's some kind of automatic programming aka genetic programming. The program can be executed on the robot which brings the system into a goal state.

“Learning from demonstration” allows acquire a robot language from human interaction.[1]

[1] Mohan, Shiwali, et al. "Learning grounded language through situated interactive instruction." 2012 AAAI Fall Symposium Series. 2012.

Why learning English is a waste of time

English is sometimes promoted as an easy to learn world language which gives people access to all the academic knowledge in world. All the books, most websites and even movies are created native for an English speaking audience so it makes sense to invest a bit of time in become fluent either in the UK or the US dialect. The problem with learning English is, that the vocabulary is hard to memorize. For example, if a native speaker of French likes to write a letter in English, he needs to lookup a word in the French to English dictionary. For example, he knows that he like to start the sentence with the normal “bonjour”, but what he doesn't know is how to translate this into English.

If somebody is not able to speak the language very well, he doesn't know how to translate a sentence into English. He can ask a bidirectional translater which explains, that bonjour is translated into “good morning” but can the word used in the same way like the french vocabulary? In most cases the answer is no and the French speaker will make his first serious grammar issue and the reader of the letter will recognize, that he is not familiar with the English very well. What he is producing, isn't a letter in fluent English, but his typed in words would read like a beginner translation from French to English.

The better idea is to avoid the foreign language from the beginning and write the entire letter in the native language which is easier to read and will show that the speaker has learned his own language on an expert level. Even if the other side isn't able to understand French he will notice, that the letter was written well and he can ask somebody who can translate it. In the modern age, the translator can be an automatic software.