How far can expert systems go
Mott Given
> How far can expert systems go??
> or,
> What, potentially, can they accomplish??
Their accomplishments can be significant. Canon uses an expert system
to generate new ideas and designs in lenses design, and is able design lenses
10 times faster. AI tools can be used in conventional programming instead
of languages like Cobol to speed up software development; eg. American
Express developed an application in 6 months using IBM's Expert System
Environment (a mainframe expert system shell) instead of the 3 years it
would have required with other languages. NASA is using cooperating expert
systems for automated monitoring and diagnostics. The Fusion Group (New York)
has created a network management application for a distributed network of
UNIX workstations. Ultra-human (i.e. better than human) performance has been
achieved by expert systems in some domains by melding the knowledge of several
experts and using the expert system for guidance where there are so many
factors to be considered in the problem that it is easy even for an expert
to overlook some aspects of the optimal solution. A good way for you to
get an overview of this is write to AI vendors and get their literature.
Some vendors even have free newsletters:
?-consult(user). (from Quintus Corp., 800-542-1283)
Aion Update (from AION Corp. 312-380-8870)
ARTLines (from Inference Corp. 602-585-3066)
AI Interactions (from Texas Instruments)
LUCID Moments (from Lucid Inc. 415-329-8400)
NeuralWorks Connection (from NeuralWare, 412-787-8222)
Software AE Bulletin (from Software A & E, 703-276-7910)
> Will they ever replace human experts??
> Will they ever be trusted??
Some references on these topics:
AI EXPERT, Nov. 1989, Why expert systems fail
BYTE, Jan. 1991, AI's identity crisis
IEEE Expert, Feb 1990, AI and expert systems myths, legends, and facts
IEEE Expert, June 1990, Validating expert systems
IEEE Expert, June 1990, Expert system security
"Implementing Japanese AI Techniques: Turning the Tables for a Winning
Strategy" by Richard Greene
McGraw-Hill Publishing Co. (phone 800-2-MCGRAW), New York, 1990, 266 pages.
--
Mott Given @ Defense Logistics Agency Systems Automation Center,
DSAC-TMP, Bldg. 27-1, P.O. Box 1605, Columbus, OH 43216-5002
INTERNET: mgi...@dsac.dla.mil UUCP: ...{osu-cis}!dsac!mgiven
Phone: 614-238-9431 AUTOVON: 850-9431 FAX: 614-238-9928 I speak for myself
Robert Marti
>[...] AI tools can be used in conventional programming instead
>of languages like Cobol to speed up software development; eg. American
>Express developed an application in 6 months using IBM's Expert System
>Environment (a mainframe expert system shell) instead of the 3 years it
>would have required with other languages.
I have been arguing that using AI tools speeds up software development
myself. Still, how do you (or American Express, if you prefer) know
that developing the above mentioned application in "another language"
would have required the three years you claim? What kind of application
was this? And what is "another language", for that matter? Cobol? C?
Pascal? An object-oriented language such as C++ or Smalltalk? Lisp?
Prolog? A so-called 4GL? HyperCard?
Does anyone know of serious scientific experiments which have compared
the different languages? (In a SIGMOD Record a couple of years back,
someone compared Lisp and C++ but that's all I'm aware of ...)
Robert Marti | Phone: +41 1 254 72 60
Institut fur Informationssysteme | FAX: +41 1 262 39 73
ETH-Zentrum | E-Mail: ma...@inf.ethz.ch
CH-8092 Zurich, Switzerland |
Robert Marti
Kai Seim
>
>In article <29...@dsac.dla.mil> ntm...@dsac.dla.mil (Mott Given) writes:
>>[...] AI tools can be used in conventional programming instead
>>of languages like Cobol to speed up software development; eg. American
>>Express developed an application in 6 months using IBM's Expert System
>>Environment (a mainframe expert system shell) instead of the 3 years it
>>would have required with other languages.
>
>I have been arguing that using AI tools speeds up software development
>myself. Still, how do you (or American Express, if you prefer) know
>that developing the above mentioned application in "another language"
>would have required the three years you claim? What kind of application
>was this? And what is "another language", for that matter? Cobol? C?
>Pascal? An object-oriented language such as C++ or Smalltalk? Lisp?
>Prolog? A so-called 4GL? HyperCard?
That is a very good question, indeed. I can't tell anything about related
work, but i can tell about my own experiences. I've written my diploma-thesis
during the last half year (with a friend). We built an xps, which supported
a woking-place in an administration. We wanted to generate text, related to the
case, we have had.
We decided to use a xps-tool (babylon) (as alpha-tester):
(common-)lisp-based (Clos) frames (behaviors eqv to clos-methods),
production-rules (backward eqv. prolog, forward with conflict-sets with
breath-first or depth-first-search, sequential) .
After a hard time of understanding the tool, we were able to develop our prototyp
in a short amount of time (4 month). Our prototyp was quite small (about 100
frame-definition, 100 instances of classes and about 40 rules). It's important
to know, that we built an GUI in this time too. Because there was no
interface-builder available, we use the allegro-cl-window-system (mac). This
took about 60% of our implementation.
Now about the comparison between a conventional programming language (pl)
and an XPS-tool.
One thing, which has been very important for us was the environment.
A graphic-tool for the inspection of the frame-hierarchy. This helped a lot
to develop the related methods. The tracing-tool from lisp, the tracing-tool
of the tool helped a lot too. That is one point.
The second is the object-oriented programming-paradigm (frames based on clos).
The main point for us was, to use the frame-system of the tool, i.e. programming
in an object-oriented style.
Because of this, we need not (very often) to transfer quite abstract concepts,
which we found during our system-analysis, to normal data-types (ints, reals,
chars). We needn't very much programming-disciplin, as it's necessary in a con-
ventional pl as pascal or c.
A third point may be the easy to use rule-component of the tool. We needn't
to think about a connection to our frames and instances. But that's not the
main point. It was good, but not important.
A fourth point was, that we didn't use KNOWLEDGE-engineering, but SOFTWARE-
engineering (rapid-prototyping) to manage our system-development. We never
tried to rebuild a person's mind in a mac-box. We only standardized objects
and actions of communication.
>
>Does anyone know of serious scientific experiments which have compared
>the different languages? (In a SIGMOD Record a couple of years back,
>someone compared Lisp and C++ but that's all I'm aware of ...)
>
Well, that's our next question: Does anybody ever tried to solve the same
problem with both paradigms: xps vs conventional -pl
knowledge-eng. vs software-eng
oops vs conv. pl
xps vs oops
I'll argue, that oops and software-engineering were the main points during
our project. XPS-tools are nice, but i think, using smalltalk in good environ-
ment would be as fast as using babylon ot kee.
>Robert Marti | Phone: +41 1 254 72 60
with best regards
Kai Seim
--
--------------------------------------------------------------------
Kai Seim email: se...@opal.cs.tu-berlin.de
Taborstr. 14a phone: + 49 30 6125451
D 1000 Berlin 36
Germany Org.: TU Berlin
--------------------------------------------------------------------