Copy Link
Add to Bookmark
Report
AIList Digest Volume 4 Issue 137
AIList Digest Tuesday, 3 Jun 1986 Volume 4 : Issue 137
Today's Topics:
Review - Expert Systems Strategies,
Psychology - Simulating Insect Behavior,
Bindings & AI Tools - Thinking Machine Inc. & Connection Machines
----------------------------------------------------------------------
Date: Wed 28 May 86 11:43:43-CDT
From: CMP.BARC@R20.UTEXAS.EDU
Subject: Expert Systems Strategies
At a recent AI conference, copies of the April 86 issue of the monthly
newsletter "Expert Systems Strategies" were being distributed.
Almost 14 of the 16 pages dealt with defining "mid-sized tools" and
comparing three of them -- M.1, NExpert and Personal Consultant. The
overall comparison was informative and I think would provide valuable
information to potential buyers of these or any expert system tools.
However, there were a number of shortcomings that made me wonder
whether the newletter came close to justifying its $20+ price per
issue ($247 per year).
First, the comparison was at best on a par with those found in PC
World, Byte, MacUser, etc. But those magazines give you 75-200 pages
of information for $3-4. Of course, they have 75-200 pages of
advertising to help keep their prices down. But the ads are useful
too, and the absence of advertising in "ES Strategies" has not bought
it any apparent degree of independence. The authors of the comparison
(Brian Sawyer and Paul Harmon) seem to be very careful not to step
very hard on anyone's toes. They point out shortcomings, but in an
overly nice fashion. They end up recommending all three products to
various markets. (I would be hard-pressed to recommend one, perhaps
two, of them to anyone.)
Another complaint with "ES Strategies" is the number of errors. The
worst of these concerns a small knowledge base, called Beta, that was
used to test the features of the various systems. Beta is fully
defined, and for each system, a partial representation is shown. Each
representation has at least two, and as many as four, errors. Most
errors simply give variables the wrong values, while some misname
variables or actually misrepresent the knowledge. They also do some
confusing representation. E.g., there are two variables, alpha and
beta-1, which can take on the values HIGH and LOW. In one tool, they
introduce a variable alpha ranging over HIGH and LOW, and a Boolean
beta-1-high. Finally, there is some evidence that the authors did not
even test the products hands-on, especially NExpert and Personal
Consultant. The figures in the review that show the representations
are not actual screens or direct printouts from the systems.
Moreover, the two figures that clearly are copies of actual screens
come from the vendor literature and reviews in other magazines, rather
than from their own extended examples with Beta. In addition, there
is no hard performance or benchmark data.
Of course, there were two pages of "ES Strategies" besides the
mid-sized tool discussion. These were devoted to news items and a
calendar of ES events. It was rather standard fare, readily available
in InfoWorld, Datamation, etc. in the same timeframe. The news was
grouped together in one place, but was by no means exhaustive in its
coverage.
In summary, based on this issue, I might spend $10-20 for a year's
subsription, but certainly not for a single issue. Like many of the
AI tools themselves, it seems overpriced by at least an order of
magnitude. However, in case you're interested in finding out for
yourself, "Expert Systems Stragtegies" is published by
Cutter Information Corp.
1100 Massachusetts Avenue
Arlington, MA 02174-9990
Phone: (617) 648-8700
Telex: 650 100 9891 MCI UW
Dallas Webster
CMP.BARC@R20.UTexas.Edu
{ihnp4 | seismo | ctvax}!ut-sally!batman!dallas
------------------------------
Date: 27 May 86 18:06:54 GMT
From: ihnp4!ihlpg!portegys@ucbvax.berkeley.edu (Tom Portegys)
Subject: Insect rituals
Observing the amazing behavior of a wasp constructing its
nest, I was brought to wonder at the procedures which bring
about this performance. It occurred to me that
if complete algorithms were to be constructed for the
complexity of the wasp's environment, such as lighting,
nest location, and material, that the algorithms
would also have to be incredibly complex.
If, however, rituals were used - small pieces of invariant
stimulus-response behavior which serve to signify the state of the
world, then I would guess that a simple set of algorithms may be
made to operate in a complex environment.
I remember not too long ago hearing that someone had indeed found
something like this to be true for a certain insect - that if
it was disrupted in its nest building at some point, then it would
go back to the beginning and start over.
This also reminds me of Simon's Ant, which looks like it is
employing a very complicated procedure to cross a pebble covered
beach, but most of the complexity is in the environmet, not the
ant.
A ritual would be a highly structured stream of stimulus-response
pairs. It must have an initiating stimulus(i). If in the course
of performing the ritual, an incomplete condition is observed,
for example, a circular nest area is not complete, then it would
trigger another behavior to rectify the situation, for example,
go get more nesting material.
In addition to nest building behavior, homing
abilities could be explained by specific pattern matching
schemes. For example, in order to find its nest, a bee
may rely on a specific pattern of ground figures (which
may be transformed internally to account for the position
of the sun). Upon not finding the specific pattern, it
would commenced a seek behavior (perhaps a spiral search)
until the pattern matches.
The often elaborate courting and signaling rituals of insects also
tends to support the requirement that a specific sequence
of stimulus-response's is at work.
I also think that in simpler life forms, the senses of
smell and hearing are overlooked in importance by the vision
dominated creatures that we are. With smell and hearing ,
a simple set of mechanisms can be utilized to provide effective seeking
performance for food, home, mates, etc, since the organism
simply moves in the direction of the stronger odor or
sound.
Tom Portegys, ..ihnp4!ihlpg!portegys
AT&T Bell Labs
------------------------------
Date: 29 May 86 01:51:00 GMT
From: cad!nike!ll-xn!mit-amt!bc@ucbvax.berkeley.edu (William H Coderre)
Subject: References from my thesis
A while back I sent a note asking for references in regard
to animal behavior simulation using rule systems.
Well, my thesis is done, and here's the references I got.
(I know that some of them are not very complete. If I had
more info, I woulda put it in...)
If anyone desperately needs any of the below, or wants a copy of
my thesis, feel free to drop me a note. I'll try to help out....bc
________
Agre, Phil, Routines, MIT AI Laboratory Memo 828, May 1985.
Alkon, Daniel L., Learning in a Marine Snail, Scientific American,
June 1983, pp 70 P 84.
Amari, Tom, and Druin, Allison, The Role of Graphics in Expert Systems,
MIT Visible Language Workshop Memo {available through author of
paper}, May 1986.
Batali, John, Computation Introspection, MIT AI Lab Memo number 701,
February 1983.
Braitenberg, Valentino, Vehicles: Experiments in Synthetic
Psychology, MIT Press, 1984.
Camhi, Jeffrey M., The Escape System of the Cockroach, Scientfic
American, December 1982, pp 158 - 172.
Davis, James R., Pesce, computer program modelling fish behavior,
September, 1983.
Davis, Randall, Meta-Rules: Reasoning about Control, MIT AI Lab Memo
number 576, March 1980.
Greilich, Horst, Vehicles, software package for Apple Macintosh, MIT
Press, 1986.
Hofstadter, Douglas R., The Copycat Project: An Experiment in
Nondeterminism and Creative Analogies, MIT AI Lab Memo number
755, January 1984.
Jacobs, Walter, How a Bug's Mind Works {paper in unidentified book;
author has listed affiliation with American University, Washington
DC}.
Kay, Alan C., Trial Vivarium Curriculum, Trial User Interface, Trial
Vivarium Graphics and Animation, Trial Vivarium Moist Models,
1985 {four papers on aspects of the Vivarium project, available by
contacting author}.
Kay, Alan C., Computer Software, chapter of Computer Software,
Scientific American, 1984.
Kehler, Thomas P., and Clemenson, Gregory D., KEE, The Knowledge
Engineering Environment for Industry, Intelligenetics, Inc., 1983
{paper available from Intelligenetics, 124 University Ave, Palo Alto,
CA}.
Lenat, Douglas B., Beings: Knowledge as interacting experts, Procedings
of the Fourth IJCAI, pp 126 - 133, 1975.
Lenat, Douglas B., and Harris, Gregory, Designing a Rule System that
Searches for Scientific Discoveries, CMU Department of Computer
Science.
Lenat, Douglas B., and Brown, John Seeley, Why AM and EURISKO
Appear to Work, Artificial Intelligence, 1984, pp 269 P 294.
Lorenz, Konrad, King Solomon's Ring, Thomas Y. Crowell Company,
1952.
MacLaren, Lee S., A production system architecture based on biological
examples, PhD thesis, U. Washtington Seattle, 1978 {available as
University Microfilms order number 79-17604}.
Minsky, Marvin, The Society of Mind, Simon and Schuster, 1986 or
1987 {this author greatly thanks Professor Minsky for a
pre-publication copy of his forthcoming book}.
Robot Odyssey I, The Learning Company {computer game widely
available}.
Stefik, Mark, et al., Knowledge Programming in Loops: Report on an
Experimental Course, AI Magazine, Fall 1983.
Various Authors, The Brain, Scientific American, 1979.
------------------------------
Date: 29 May 86 07:04:18 GMT
From: cad!nike!think!bruce@ucbvax.berkeley.edu (Bruce J. Nemnich)
Subject: Re: Help on Thinking Mach. Inc.
Hi. Yes, Thinking Machines is indeed on the net, though we don't have
many people here who read news. Let me try to address your questions.
I'm adding net.ai to the distribution since they are probably
interested in the Connection Machine System, too.
> * How is the CM programmed?
> ...
> The Connection Machine Lisp manual is, evidently, unavailable to those
> of us who do not have a million dollars to by a CM.
The CMLisp manual isn't available becuase the language is still in the
design and implementation phases; i.e., it's not stable enough yet to
give out manuals. It certainly has nothing to do with money. It will
be a lot like the language in Danny Hillis's book (which was written
before we had working hardware). I hear there will be a paper on it
by Danny and Guy Steele at an upcoming Lisp conference; sorry I don't
know the details.
Many people have many different ideas about how to program the CM, and
there has already been quite an evolution of lisp-based languages here
in the last couple of years. The language we are distributing with
the first machines is *Lisp ("star-lisp"), which consists of a large
collection of functions and macros for defining and manipulating
parallel datatypes which live in the CM from lisp.
There is also a language being implemented called C* ("C-star"), which
is an extention to C which handles CM datatypes and control flow. The
extensions, which have the syntatic flavor of C++, provide
sophisticated ways of defining layouts of data on the CM, provide
control flow, etc.
There's no one answer to "How does one program the CM?", but most
applications to which the CM (or any fine-grained SIMD architecture)
is particularly well-suited have some kind of inherent data-level
parallelism; i.e., similar computations on a large number of data
points. Typically each datum is assigned a processing element.
Given that, there are two common classes of problems: graph problems
and grid problems. For example, the CM's "connections" give the
ability for one datum to point to other(s), so arbitrary data graphs
can be constructed. Such a graph could be searched for a given datum
in constant time: every processor just compares its value to the
desired value (regular SIMD, no use of pointers). Distance on the
graph between two data can be found in time proportional to the
distance by chasing pointers (fanning out) in parallel from one until
one of the paths reaches the other. Simple logic simulation can be
done by setting up such a graph with the outputs of one element
pointing to an input of another. Each element would compute output
values based on its inputs and pass them along to the next level.
The grid problems are those which also rely on communication between
elements but don't require general pointers; they only require local
communication on a cube or grid. The Connection Machine has
facilities for local communication on the cube or grid which are
faster than the more general pointer-like mechanism.
> Imagine a message is traveling through the CM and it encounters a hot
> spot. The message is rerouted. Just after it is rerouted, the
> congestion clears and the next message to that destination goes
> through the direct binary n-cube path. The two messages may now be
> out of order, since the second message could arrive before the first.
Messages are addressed to a given processor and memory address within
the processor. Usually an operation is something like "everyone who
is currently selected send the N bits in your memory beginning at S to
the processor whose address is stored in your memory at M, and put
them in his memory at D." If there are collisions in destinations
(two or more are both trying to send to the same processor/address),
they are combined in some way (current choices are: IOR, AND, XOR,
ADD, MIN, MAX, OVERWRITE (overwrite means just one is delivered)).
There is no order to messages within a delivery cycle. One could sum
a field over all the processors by having everyone send the field to
processor 0 and specifying to combine collisions by adding them
together (there are more efficient ways of doing this, though).
> * How does the CM handle processor failure?
> How are messages rerouted to avoid the failed PE?
You're right, fault tolerance is very important. We have though about
it, though there's a lot we want to implement which isn't yet in the
hardware. The current hardware/software basically assumes things are
working. Reasonably quick diagnostics can be run to verify with high
confidence that nothing's broken. Almost all failures are on CM
matrix boards, of which there are 128 identical copies in a 64k-proc
CM. They're easy to swap.
But since we think a 64k CM is small, serious fault-tolerance is
necessary. The "router" is the general message-routing mechanism, one
for every 16 processors, currently arranged in a hypercube. There is
currently hardware support for turning off paths (a cube edge) between
routers. If a wire between two routers was broken, that path could be
turned off in software. If a whole router was broken (or perhaps the
processors which belong to it), all paths to it could be turned off.
If a message would normally go over that path, it would instead go
another direction (preferably, but not necessarily, another direction
the message wanted to go).
However, fault tolerance on the local grid and cube communication is
more of a problem, since applications using them typically rely on the
regular topology. A glitch in a 2-d grid, for instance, could be
ignored by effectively bridging out that row and column of the grid.
We don't have any support for that, though.
> Thinking Machines has been, at least with me, very secretive about the
> CM.
> Once a machine is released for sale, information must be released to
> sell it.
Absolutely. On behalf of whomever you talked to, sorry. We don't
mean to be secretive. We have just been through the period of getting
ready trying to announce the machine, scrambling to gather/write the
kind of information you want, and trying to put in place mechanisms to
distribute it. We WANT people to know and think lots about Connection
Machines. Hope I've been of help.
Just in case I'm supposed to say this, "Connection Machine" is a
registered trademark of Thinking Machines Corporation. :-)
--
--Bruce Nemnich, Thinking Machines Corporation, Cambridge, MA
--bruce@think.com, ihnp4!think!bruce; +1 617 876 1111
------------------------------
End of AIList Digest
********************
