by Anna O’Connell, P.E.
MacTech Quarterly
Spring 1989 – Page 10
“Artificial intelligence,” depending on how you look at it, is a set of useful tools for building smarter, more powerful applications, or a philosophical concept that threatens humanity, or simply an oxymoron. In this article, Anna O’Connell examines the plethora of AI languages and development platforms that have been introduced for the Macintosh in the past two years, and discusses how AI techniques can be employed to build more intuitive, easier-to-use software.
— Editor
A lot of hype has been generated in the past few years about artificial intelligence (often shortened to AI). More heat than light has been generated, and there is still little common agreement about exactly what artificial intelligence is. One joke making the rounds in the industry is that AI is in the eye of the beholder, to academics, it is “Anything Impossible”, to the military, it is “Anything Invincible”, and to the sales departments of software firms it is “Anything Improved”.
For the purposes of this article, we’re going to define AI as any of a large collection of technologies that attempts to extend to computers skills or attributes usually thought of as intelligent when seen in humans . As programmers well know, computers are infuriatingly methodical devices that do exactly what you tell them; no more, no less. And they must usually be told what to do in excruciatingly small steps. Of course, once they have been correctly programmed, computers can perform calculation or sorting tasks very rapidly and with nearly-flawless accuracy. Humans, on the other hand, can sort among potentials (make decisions) in novel situations with insufficient data and no specific instructions. But they are notoriously slow and inaccurate at other types of tasks. Artificial intelligence attempts to make use of a computer’s speed or accuracy to more effectively perform tasks that require some human judgement or intuition.
Several technologies that had their roots in AI research have grown sufficiently large to be considered disciplines in their own right. Speech recognition and synthesis, robotics and machine vision are now considered to be “mainstream” technologies — no longer part of the AI backwater. Their emergence from the laboratory into the factory was once attended with the same sort of hoopla we currently hear about AI.
“Knowledge engineer” is another term that is helpful to understand in discussing AI. A knowledge engineer is trained to develop AI systems, especially expert systems. The training usually includes one or more AI programming techniques or languages, familiarity with one or more expert system development shells, training in how to elicit knowledge from both published sources and “domain experts” — the people whose expertise is included in an expert system, and thorough background in one or more of the available techniques for structuring complex sets of information. The term was coined at M.I.T., and has come into widespread use throughout the field. An older term, systems analyst, is just as valid, if you remember that a systems analyst has always needed to be familiar with the specific programming techniques which will be used to implement the system being designed. Therefore, my definition of knowledge engineer is a systems analyst who has learned enough AI techniques to wisely choose and use an AI development tool.
AI Hardware
Specialized AI hardware has been a sink for the money and time of many venture capitalists and government agencies, and a source for many of the things that made the Macintosh one of the easiest to use and the most widely imitated microcomputer to date. To quote one of my favorite AI gadflys, Harvey P. Newquist III, “In the late 70’s and early 80’s, everyone with a Ph.D. in LISP programming from M.I.T., Carnegie-Mellon or Stanford formed a company, and there was enough venture capital floating around at that time to fund everyone with a business plan longer than an index card.”
Pointing devices in the form of track balls, joy sticks, light pens, tablets, and mice were first developed by AI researchers. These items are now so common to micro and mini computers that it is widely considered to be impossible to market a computer for graphics oriented applications like games, CAD, or desktop publishing without them.
Another type of specialized AI hardware that is commercially available is processors optimized for executing LISP. Computers optimized for LISP were very expensive until recently — starting at $35,000 for a bottom-of-the-line, non-networkable station and rising rapidly to about $100,000 for a system fully equipped for research. Demand for these workstations was correspondingly quite low, and the market was pretty thoroughly saturated with a total of about 25,000 machines in the entire U.S.
AI development tools were once available only on LISP machines, necessitating a painful porting process to distribute software to a more cost-effective hardware platform. In the way of all humans possessing painfully acquired experience (like putting the screwdriver through your thumb because you were using it as a prybar), many AI researchers came to feel that the tools they developed with so much effort were the only tools capable of doing the job “properly”. And so, there are many people out there who will tell you that writing code in LISP, on a LISP machine, is the best way to “do AI”. This may be an excellent way to do research, if you can get the necessary hardware and research grant support. It is a lousy way to develop a commercial product, unless your target market is AI researchers who already have LISP machines.
There are even some companies out there who are so desperate to sell LISP machines that they market them as a highly productive environment for developing procedure-based software. (I won’t mention any names, but I used to work for a division of one of them.) Under the proposed scenario, the “rich working environment
“ of the LISP machine is used to “rapid prototype” the desired software. The newly developed software is then cross-compiled to the target machine and language — if a cross compiler is available. If no cross-compiler exists, the software is “rewritten in C or other procedural language”. If C was a good choice for the final application, why not write it in C in the first place? And if the rich working environment of the LISP machine was an advantage, why not duplicate aspects of it on machines sharing at least a hardware architecture with your target application? The people selling this brand of snake oil did not have an answer when I asked the questions. Beginners and experienced programmers alike should “beware of AI geeks touting LISP”.
Several makers of these computers have gone bankrupt in the past two years, and makers of software for them have seen lean times as well. It is for this reason that you will now see in the ads that such high-end AI development software as ART (the Automated Reasoning Tool) and KEE (the Knowledge Engineering Environment) are now available for Unix workstations or high-end microcomputers. Only the government and the largest of corporations could afford to pay $60,000 a copy for software that ran only on $90,000 computers, but almost any corporation (and some dedicated individuals) can ante up the $30,000 needed to get a fast ‘386 machine and a copy of PC-KEE.
Macintosh II Co-Processors During 1988, both Texas Instruments and Symbolics announced the availability of their LISP microprocessor chips as add-in boards for the Macintosh II. The Texas Instruments product is co-labelled with Apple, and is called the micro-Explorer. It has been shipping since June of 1988 in moderate quantities, and currently sells for $28,000 complete with Mac II and the necessary RAM (2 Megs or more in the Mac, 4 on the Explorer board). The micro-Explorer board and software alone will set you back a mere $19,000 — somewhat less if you have a university purchase order. Contact Texas Instruments Data Systems Group (head office in Austin, TX — sales and service locations throughout North America) for more information.
The original microExplorer system software had what many Macintosh programmers would consider a fatal flaw — almost no access to the Macintosh toolbox and very limited hooks to other applications. With the latest software release from Texas Instruments, this has been corrected by the addition of a Macintosh toolbox interface developed for them by ExperTelligence. ExperTelligence gave the Macintosh world both ExperCommon LISP and ExperIntefaceBuilder — which taken together made two thirds of a what would have been a wonderful expert system development shell. I’m not sure why they didn’t go on to develop a few inference engines to complete the shell, but I’m glad to see they have not been idle in the last year and a half.
The Symbolics MacIvory board and software were announced somewhat later, during the third quarter of 1988. This is probably due to the financially straightened circumstances Symbolics found themselves in when the bottom fell out of LISP machine sales back in 1987; because I’d heard of prototypes of the MacIvory being shown before TI officially started development of the microExplorer. As of early in the fourth quarter of 1989, they were not shipping production units, but did have a number of prototypes being demonstrated in the field. The price for the complete MacIvory system was announced as $21,900, and it is expected to ship in December, 1988. Available in March of 1989 will be a board and software set which does not include the Mac II (with 4 Mb of RAM) that is also required for a complete system. Price for this package is $10,900.
Neither Symbolics or Texas Instruments has ruled out making co-processor boards for other hardware platforms in the future, but both chose the Mac II because of the ability of the NuBus architecture to accommodate multiple processors operating independently. (And, rumor has it, development seed money from Apple that ran to seven figures.) Texas Instruments uses NuBus in their entire Explorer series of machines, and in their new line of Unix computers as well. The NuBus standard was developed in a cooperative effort between TI and M.I.T., and is licensed to Apple for use in the Macintosh II and subsequent computers.
AI Software Techniques
There are several types of software associated primarily with AI. These include the specialized languages, LISP and Prolog; object oriented programming environments; such specialized software development tools as production rule systems, inference engines and expert system development “shells”; natural language parsers and NL generating systems; and knowledge representation systems such as semantic networks and hypertext. Each of these was originally developed in the process of researching some area of artificial intelligence. A variety of each type of software is currently marketed for the Macintosh.
LISP, which was named from its intended function of LIST Processing, is one of the oldest computer languages still in common use. It is also one of the richest, with nearly 10,000 functions being defined as part of the standard for Common LISP. The language uses a single data type, the list. A list is recursively defined as a series of elements, each of which is either a list or an atom. An atom is a single element that cannot be further subdivided. The definition of list is said to be recursive because it mentions the thing being defined within the definition. Recursion is a concept strongly supported in LISP, and found to be useful in solving many programming problems.
In Europe and Japan, the majority of AI programming was done in Prolog. According to recent report from Edward Feigenbaum, this is no longer as true. Prolog as a language is rather severely limited as to the knowledge representations available within it. Because of this limitation, no higher level tools (expert system development shells) have been successfully based on Prolog.
A Prolog program consists primarily of assertions which are stored in a knowledge base. These assertions may or may not be organized into frames, depending on the knowledge base and the language implementation being used. These assertions (and retractions of assertions) are searched in a backward chaining fashion in response to questions posed by the user of the program. The language has its’ own inference engine built into it. For more on inference engines, see below.
Inference Engines
Inference engines are usually provided as part of expert system development “shells” or “environments”. They are of two basic types — forward chaining and backward chaining, for the route that is followed to form an inference in each type. Both types of inference engines operate on knowledge represented as IF <predicate>: THEN <consequent> rules. This structure is called a “production rule” in AI work, because some of the earliest work was to design programs that “produce” or “infer” rules of this type from properly formatted examples or cases.
In forward chaining the inference engine works forward from known or asserted predicates to derive as many consequents as possible. This frequently results in what is referred to as combinatorial explosion. So many consequents are inferred by the system that the significance of any one of them is lost in a blizzard of information. Forward chaining systems are frequently slow to reach a desired conclusion because of the large number of individual inferences made. There are some methods for limiting the combinatorial explosion of forward chaining inference engines, and thus improving their performance.
In backward chaining, the inference engine works backward from a (user or program supplied) hypothesized concluding consequent to locate predicates that support it. When a supporting chain of rules contains predicates whose truth is not known by the system, the user is queried for the status of that predicate. This is frequently called “goal driven” or “goal seeking” inference. The majority of diagnostic or classification expert systems are based on backward chaining inference.
Model Based Reasoning
In addition to inference engines that process rules, model-based reasoning is also used in developing AI systems. In this technique, a model of a problem space is built up within an AI program. The modeling techniques used can include mathematical descriptions, rules, frames, scripts, object oriented techniques, event simulation, semantic networks and hybrids of these. A reasoning mechanism appropriate to the modeling technique is chosen and a reasoning sub-program is developed. Some method of initializing the model to correspond to a known status of the real world is required. The techniques for initializing a model range from typing answers to queries through “symbolic spreadsheets” to on-line data acquisition.
Model-based reasoning normally requires substantial development work on both a model and an inference engine, and therefore is not widely used as a foundation for packaged AI development shells. One exception to this general rule is Paladin Software, which used model frameworks designed for both corporate finance and manufacturing operations applications in its major products. These programs (Finance Advisor and Operations Advisor, respectively) require only moderate customization for the users’ operations, and originally required LISP machines as a platform. They have been ported to Sun workstations, and may soon be available for other Unix systems as well. I am not aware of any model-based reasoning systems commercially available for the Mac, but I’d be happy to hear if someone out there is developing one.
Expert System Development Shells
Some expert system development shells support only a single mode of reasoning, and some have separate inference engines for each mode, allowing the knowledge engineer to choose the most appropriate reasoning technique for a given application. Other features common to expert system development shells include rule editors, hooks to external software packages such a data base management systems, and the ability to include help or graphics in pop up windows. Some recently developed expert system shells include hypertext features, or hooks to HyperCard.
Knowledge Representation
In addition to the inferencing technique used, the other distinguishing characteristic of expert system development shells is their method(s) of representing knowledge. Nearly all shells support knowledge represented as IF <predicate>: THEN <consequent> rules. This is an efficient representation for many kinds of knowledge, especially diagnostic, classification and policy application applications. Some shells allow certainty factors to be attached to the consequent, allowing for expression of concepts such as “usually”, “most of the time”, or “hardly ever”. Other forms of knowledge representation are available which are more suited to other applications. Commonly available forms of knowledge representation include meta-rules (rules about using rules), pattern description and matching, object oriented systems, and semantic networks.
One approach used for simplistic applications, is an “examples” spreadsheet, from which the expert system development shell will derive rules. These rules are then processed by an inference engine to reach conclusions or diagnoses. This is a specialized form of pattern representation and matching. This “rule inferring” approach purports to make the knowledge engineer unnecessary, and it succeeds for simple applications. When the application is more complex, the domain expert still needs the knowledge engineers’ skills of complexity management and completeness checking to succeed in developing a useful expert system.
Semantic networks, object oriented programming systems, and hypertext are loosely related as concepts for knowledge representation. In many ways these forms of knowledge representation are more suited to supporting model-based reasoning than either inference or rule induction. The model-based reasoning need not be built into the program that uses these knowledge representations. It may be the knowledge engineer who reasons about the model in order to structure knowledge needed to solve the problem in a form that can be processed efficiently by the computer. Or it may be that these forms of knowledge representation are used to build a model that the user will query for explanations, but that is not used by an inference engine to reach a conclusion or diagnosis. Much current research focuses on developing a model of the learning process in order to improve the explanation facilities within rule-based expert systems or to develop “expert tutors” which can train users in applying both specific facts and defined reasoning techniques.
The three techniques discussed above represent knowledge in the form of linkages among objects. Objects in each of these forms of knowledge representation differ in their possible characteristics and the way in which they are defined and stored by the computer. The types of linkages also vary from representation to representation and from implementation to implementation within a specific knowledge representation system. Hypertext in the form of HyperCard is probably the most familiar of these knowledge representation techniques for Macintosh users. Those of you who program the Macintosh are also familiar with object oriented programming systems in the form of either MacApp or some flavor of C++.
Why Use AI?
There are two reasons a programmer would want to learn about AI techniques. The first is sheer intellectual curiosity. The second is that these techniques are sometimes the easiest way to achieve a desired result within a program. Oh, yes, there is a third reason; someone has offered to pay you lots of money for an AI-based program, either because they really need AI or because they want the latest trend in technology.
Intellectual curiosity is the primary driver of sales of the less expensive language packages and expert system development shells. You can pick up very useable, public domain versions of LISP and Prolog off the networks or from user groups. There are a few expert system shells for less than $100 — and a few more for less than $150. This is not what I’d call cheap, but it is a much more reasonable price for indulging your curiosity than spending $5,000 for Nexpert Object or $28,000 for a microExplorer. A frequent side effect of this type of experimentation is enhanced understanding of your own (or other people’s) thought processes. It is very difficult to write a program that will simulate a process that is completely undefined. Therefore you will need to learn about thinking, diagnosis, or decision making in order to write programs that do (or simulate) these things convincingly.
The “it does what I need it to do” is a particularly good reason for including AI-based features in a program under development. A recent example was released in an Adventure-type game called Crossbow. The AI feature in this game was that the monsters “learned” a players’ favored tactics through collective experience. The monsters would quickly change their own behavior to avoid those situations and actions that had resulted in the destruction of a previous monster. The player has to come up with new and different ways to defeat each monster. This makes the game progressively more challenging to the player, and helps to increase the “life” of the product in the market place.
Similarly, if your user needs to be able to input commands in (approximately) English, AI techniques for natural language understanding are available, and appropriate for inclusion. There are even speech comprehension products available (although I know of more for the DOS world than for the Mac so far).
And if your client needs to uniformly apply a set of policies across a variety of locations, an expert system can generate recommendations for each location which will result in a consistent and fair application of the rules to each situation which arises. This is especially valuable to such organizations as insurance companies (for both underwriting and claims adjusting) and banks (for assessing applications for credit). Any company whose inconsistent application of policies would leave them open to legal problems can benefit from AI applications of this type. I wish we could anticipate replacing most companies’ personnel departments (human resource managers, beware!) with a set of expert systems to determine whom to hire for or promote into a particular opening based on rules about levels of competence and the assessments of those who currently perform the work in question. This is, unfortunately, far too obviously a good idea for most companies to take advantage of it unless forced to it by E.E.O. lawsuits. Determining (and stating) clearly just what the selection criteria for most personnel decisions are would be far too cynical for most organizations’ morale.
Why a Mac for AI?
With the introduction of the Macintosh II, Apple finally began to acknowledge the fact that the Macintosh interface is an ideal environment for artificial intelligence work, and to market the machine accordingly. Based on Xerox STAR technology, and owing an additional debt to Xerox LISP workstations, the Macintosh is a machine designed around object oriented programming paradigms. (There, I did it. Every article on artificial intelligence must contain at least one gratuitous use of the words “paradigm” or “heuristic”. It’s a guild rule.) Macintoshes feature the rich user environment of windows, icons, and menus that were originally developed by AI researchers using LISP. Many of the first Macintosh programs available were for doing AI-ish things, like speech generation from text. And then, of course there’s HyperCard as a built in front or back end for knowledge representation.
Another reason for using a Mac to do AI are the coprocessor boards previously mentioned. LISP machines are very definitely computers “for the few of us”, since they cost more per workstation than most of us make in a year. You can do useful, fast-response AI development and deployment on these hybrid computers for less than half of what a LISP machine would cost.
And for those of you who want to put high-powered AI into a hostile environment, there is a solution tailor-made. Automatix, of Billerica, MA makes something they call an AI90 factory floor controller. It consists of a Macintosh II repackaged with an upgraded power supply, NEMA 12 enclosure, positive pressure cooling air, and rack mounting. Adding a LISP co-processor to one of these will give you an industrially hardened LISP machine, with all the data collection facilities, numeric processing power and connectivity features of a Mac. Manufacturing engineers and factory systems integrators, please take note.
An additional reason for choosing the Mac is the availability of some truly excellent expert system development shells and other tools for AI work. Nexpert Object is an extremely powerful development shell, combining rule-based and object oriented programming power. AI systems developed using it are highly portable among the machines for which Nexpert Object is available. Those machines currently include the Macintosh II under either standard System or A/UX, 80286 and 80386 DOS machines running Windows, UNIX workstations from Sun, Hewlett Packard and Apollo, VAXes from the microVAX up, and will soon include IBM mainframes running VM and MVS. It is priced at $5,000 a copy for the microcomputers and workstations. For the VAX and IBM mainframe
versions, the price is $7,000. For more information, contact Neuron Data in Palo Alto, CA or the Bechtel AI Institute in San Francisco, CA. Neuron Data wrote and sells the shell; the Bechtel people train purchasers in its use and do development work as well as sell product.
Another shell that has enjoyed great popularity in the DOS world is GoldWorks II. At the August 1988 MacWorld exposition it was announced that Gold Hill and Coral Software (of Coral/Allegro Common LISP fame) had cooperated to port this shell to the Macintosh. The president of Gold Hill was widely quoted as claiming that this was not just a straight port of the DOS tool — that it had been redesigned to give it a complete Macintosh interface. From what I saw during several hours of playing with a (very robust) beta copy at the show, he was correct. The software is now shipping, it is powerful, very flexible, and has excellent hooks to interface building and data management tools that will be familiar to most Mac programmers. The Mac version of this program owes as much to the skill of the people at Coral Software who developed the underlying Coral Common LISP for the Macintosh, as it does to the people at Gold Hill who wrote the software designed for a souped up 80286 machine, in Gold Hill Common LISP. The asking price for this shell is $7,000 in both Mac and DOS versions.
| Product Applications | Company | Price | Knowledge | Inferencing Mechanism | Interface | Integration with |
| Instant Expert | Human Intellect Systems | $50.00 | Rules | Not Stated | Not included | import screens via clipboard |
| Cognate | Peridome, Inc | $150.00 | Rules/facts | forward chaining, backward chaining | Mac toolbox | import screens via clipboard. |
| MacSmarts | Cognition Technology | $195.00 | examples, some rules | rule induction | import from other applications only. | Excel, HyperCard are mentioned. |
| SuperExpert | SoftSync | $199.00 | examples | forward chaining on induced rules. | import from other applications only. | Working on HyperCard in July 88. |
| Cognate (developers’ version) | Peridome | $250.00 | examples/richer rule structure than Cognate. | forward chaining on induced or explicit rules | import from other applications. | via embedded object code modules. |
| MacSmarts Professional | Cognition Technology | $395.00 | examples,richer structure than MacSmarts | forward chaining | import other applications | Spreadsheets and HyperCard. |
| Instant Expert Plus | Human Intellect Systems | $498.00 | rules | forward chaining and backward chaining | some pre-formatted. Import from other applications. | “hot buttons” to launch other apps. |
| Nexpert Object | Neuron Data | $5000.00 | rules, frames, objects | forward chaining, backward chaining pattern matching, & custom. | Macintosh toolbox. Also import from other applications. | via embedded object code modules. |
| Gold Works II Macintosh Version | Gold Hill Computers | $7000.00 | rules, frames, objects. | forward, backward, pattern matching and custom. | Macintosh toolbox. Also import from other applications | embedded object code modules or launch. |
How to get Started in AI
If you are already a Macintosh programmer skillful at using procedural languages, you need not listen to what I am about to say. You have already proven that you are one of those driven individuals who have to know all about the details of everything. But for those of you who don’t have all the A traps memorized, or who never did master programming in an assembly language, much less the ability to create one, listen up! Mastering a complex new skill takes time, effort, and a certain amount of innate talent. You cannot tell whether or not you have the necessary talent until you put in the time and effort. You will not be able to learn all about AI overnight. Do not attempt to produce programs written in LISP ( at least not for money) if you are only recently aware that it is something other than a speech impediment.
On the other hand, you can learn to do some useful and interesting things fairly quickly by using tools developed by those more skillful than you are now. I strongly advocate that beginners seek out expert system shells that represent knowledge in the way that seems most natural to the problem being solved (more on this later!). Or purchase a natural language parser if you are trying to add ad hoc querying capability to a database application. Or keep your eyes and ears open for the availability of an XCMD inference engine for HyperCard (at least three organizations I am aware of are developing one of these).
The next thing beginners (and this includes beginning Mac programmers, as well) should try is an object oriented program development system. The basis of object oriented programming (OOP) is the idea that data items are objects that belong to classes. Each individual item or object, can both inherit some characteristics of its’ parent class, and possess unique characteristics that distinguish it from other objects. One of the characteristics an object can possess is called a “method”, which is a description of the objects’ behavior under specified conditions. Objects interact with each other by passing messages, which can either trigger methods or can cause the recipient object to acquire a new method form the donor object. Either MacApp or Smalltalk V is an excellent choice if you want to learn about object oriented programming systems. Smalltalk V can be had from Digitalk Inc. of Los Angeles, CA for $199.95.
Choosing A Problem To Solve With AI
As with any other programming effort, you should assess the “market” for an solve significant in terms of the time or money currently spent on surmounting it? Is a faster, more reliable solution worth the time that will be spent to develop that solution? Will someone use the program once you have developed it? Unless at least one of these questions can be answered yes, you have a “toy” problem. These types of problems are OK for early experimentation, or to solve using a variety of tools in order to get a feel for the capabilities of the tools. But you should not put very many hours into work on this kind of problem. You won’t learn enough. Even if you will be the only “customer”, make your learning exercises as practical as possible. But you need not always be your own customer. Perhaps one or more local hotels would buy copies of a Restaurant Advisor expert system for their out of town guests (as long as it recommends their own restaurant, too). Or other members of your HMO who own computers might appreciate having a program to diagnose childhood diseases, telling them when they need only wait for nature to take its course, when to head for the emergency room, and when their child should see a doctor soon but can wait for regular office hours.
Is there an existing solution method? AI techniques can be useful to clearly define the limits of what is currently known about a solution method. And they may be able to apply an otherwise impractically slow method to a greater variety of situations distributed in time and space. But AI cannot make something out of nothing. Tackling unsolved problems is NOT the best way to learn to use a problem solving tool. This warning is equally applicable to experienced developers who ought to know better. You can’t always believe everything your advertising copywriters get past the marketing department.
Is the solution method ill-suited to expression as an algorithm? For many of the smaller problems, and for the early stages of development on many larger ones, those portions of a solution that can be expressed as algorithms can be found in textbooks or manuals. If a problem can be solved using procedural programming methods, and you know how to use those methods, do so. If a purely algorithmic solution is inadequate, AI may be a way to improve the situation. If there are several possible algorithms, and the real problem that users will face is choosing the most appropriate for a given situation, they may need a hybrid AI and procedural system.
Do you, the potential developer, have access to someone who is expert in applying the existing solution method? Is that expert communicative and co-operative? The analogy for non-AI software development is your application specialist. (See The Business of Software articles on Application Selection and Team Building.) You wouldn’t try to develop a CAD system for architects without having a few architects hanging around to tell you what architects do and how they think. In AI development, the knowledge engineer’s access to the domain expert is a critical issue for designing, developing and testing the system.
And last but not least, is the problem “well bounded”. Are there a finite number of possible solutions given each set of initial conditions? If there is more than one possible solution or answer, are they all equally good so that you can stop when the first one is found? Or is there a way to evaluate possible solutions to determine which one is “best”, and is that way practical in terms of time or resources required to evaluate? Is there a finite number of ways to describe the possible initial conditions?
Choosing an AI Development Tool
It is an article of faith with me that one should always use “the proper tool for the job”. I own a variety of screwdrivers, both manual and powered, several prybars, and not a few chisels. Depending on what it is I want to accomplish, I choose the tool most suited for the task in terms of size, weight, material, design intent, and accessibility. While it is possible to use a screwdriver as a wood chisel, I would only choose to do that if no suitably sized wood chisels were available when and where I needed to do the job. In the same way, I choose software development tools based on what the software under development is supposed to do once it has been developed. In general, you should use the highest level tool available if it does what you need it to do.
Choose your AI development tools based on the characteristics of the problem being solved. A programmer friend
of mine whose formal training was in biology claims that all programming problems ultimately boil down to correctly defining the “taxonomy” of the problem. He meant that knowing or developing a consistent, clear terminology that assists the developer to understand the relationships between factors affecting the problem and its solution, is critical to designing a program. My friend further says that the source of most difficulties in program implementation lies in insufficient attention to making the design reflect the taxonomy. These two statements are even more important for AI programming. The limitations on knowledge representation methods available within a tool may rule it out for certain classes of problems. There are many types of knowledge that cannot be expressed in production rules. And semantic networks in which the terminology used is imprecise cannot be parsed to give unambiguously correct relationships among objects. Give careful thought to the characteristics of the knowledge you are including in a system before you decide on the technique you use to capture and encode that knowledge.
The next item to consider is whether the tool supports the reasoning methods required for an adequate solution. Trying to solve a real-time alarm monitoring problem with a backward chaining inference engine is begging to be frustrated. Developing a large rule-based system using a tool that does not have some mechanism for prioritizing the order in which rules are tried will annoy you during development, and your users once the system is deployed. And using Prolog to develop a system relying on model based reasoning will almost certainly doom you to failure. Use forward chaining inference for data driven or situation analysis type systems. Use backward chaining for diagnostic or classification systems. Plan for the time to develop customized inference engines for problems which require model-based reasoning. And plan to need all of the above if you tackle anything still being defined, like “real time scheduling”.
The last item to consider in tool selection is the hardware and software environment that the final system will require. Are the tools you need to build a good user interface built into the environment or easily accessible from within it? Can software developed with this tool be invoked from other programs or invoke such things as DBMS in a manner transparent to the user? Can you develop effectively using the same hardware family on which the system will be delivered? If the answer to all of these is yes, you have a good candidate tool for your project. If it also meets all the criteria in the paragraphs above, you can count on being able to work effectively on the problem you selected.
About the Author
Ann Marie O’Connell formerly worked at Texas Instruments developing microcomputer based expert systems for use in manufacturing operations, and acted as the AI (artificial intelligence) and factory automation marketing manager for TI’s automotive accounts. She now works for one of the Big Three car makers in the areas of automated assembly and the use of information technologies to improve productivity.
Where To Look For More Information…
Books
The Handbook of Artificial Intelligence, edited by Avron Barr, Edward Feigenbaum and Paul Cohen. This three volume set defines terms, summarizes seminal research findings, and acts as a pointer (or sometimes a handle) to more academic sources. Extremely complete up through its’ publication date in 1982.
Expert Systems; Artificial Intelligence in Business by Paul Harmon and David King. A survey of the commercial uses of expert systems. Currently a little dated; this is a good book to hand a manager who wants to know a little bit about the technology before buying into it.
Crafting Knowledge Based Systems: Expert Systems Made Realistic by John Walters and Norman Nielsen. The single best book for the potential developer of expert systems I have encountered to date. The chapters on knowledge representation, reasoning methods and user interface design are especially germane. This is a must read for apprentice knowledge engineers.
Structure and Interpretation of Computer Programs by Harold Abelson, Gerald Sussman and Julie Sussman. If you really crave to learn LISP programming, this is the book for you. Used in the mandatory freshman computer course at M.I.T.
Common LISP, the Language by Guy Steele Jr. Widely accepted as the definitive reference on Common LISP. Heavy sledding for those not accustomed to language definition manuals or intimately familiar with LISP. Use as a reference only.
Magazines
AI Expert published by Miller Freeman Publications, 500 Howard St., San Francisco CA 94105. Subtitled “the magazine of artificial intelligence in practice”, this is where gadfly columnist Harvey Newquist gores someones’ AI ox every month. Full of code samples (also available via CompuServe and USENET) and realistic, useable reviews. Until late (November) ’88 there was little or no Mac content. Advertisers wised them up, and they’re trying.
IEEE Expert published by the Computer Society of the Institute of Electrical and Electronic Engineers. Back issues of this irregular quarterly can be found in most university engineering libraries, or can be purchased from IEEE. Contact Reader Services, P.O. Box 16508, N. Hollywood, CA 91615. Mostly very academic, but highly readable reports on recent research.
MacTech Quarterly, which you are currently reading. This publication focuses on software development using procedural languages (Pascal, C, FORTRAN), object oriented programming systems, and customizable applications (HyperCard, 4D,
GoldWorks II). Forthcoming articles will include detailed reviews of AI languages and development tools for the Mac if the makers of same wish to supply either reviewers from among their customers or single copies of their products for review.
Artificial Intelligence Magazine, published by the American Association for Artificial Intelligence. Highly academic, extremely prestigious journal. This is the place the researchers publish their latest discoveries. Not bad, if you remember that it will take at least a year for anything first mentioned in an article here to be used commercially. This organization also sponsors an annual conference that is the AI world’s place to see and be seen.
