Copy Link
Add to Bookmark
Report
AIList Digest Volume 3 Issue 112
AIList Digest Monday, 19 Aug 1985 Volume 3 : Issue 112
Today's Topics:
Query - GF11 Hardware,
Information Science - Online Bibliographies,
Expert Systems - Definition vs Database Systems,
Logic Programming - Hewitt vs Prolog,
Seminars - Design Expert Systems (CMU) &
- Intelligent Design Completion (CMU),
Call for Papers - Knowledge Represention (Proc. IEEE)
----------------------------------------------------------------------
Date: Sat, 17 Aug 1985 07:44 EDT
From: "David D. Story" <FTD%MIT-OZ @ MIT-MC.ARPA>
Subject: GF11 Hardware
Has anyone out there looked at SIGARCH proceeding of
last month. I was wondering what comments might be
found on IBM's GF11. I heard of this machine years
ago. I thought at that time it was for a group of
problems General Foods had taken to the Yorktown
Group.
I see that they have added some new micro-code features
resembling Hewitt's Actors and Semantic Massage for a
society of experts. Though I dunno as of yet what is
happening with AI at Yorktown it seems they've tried
to get this under the hood. If the machine was meant
for the task of computing chromodynamics seems to me
that the word size would have been re-engineered since
there is no mention of double or quad wording in the
article. Whatta think ?
Dave
------------------------------
Date: Sun, 18 Aug 85 12:46:07 pdt
From: aurora!eugene@RIACS.ARPA (Eugene miya)
Subject: Re: Master bibliography
Excellent suggestion. The net's biggest problem is a lack of
memory. ;-)
I am trying something like this right now for parallel and distributed
computing. Mine is ftp-able, and has over 5000 entries. It also has
some copyright restrictions because I used several preexisting
bibliographies [i.e., stand on the shoulders of giants...]. There is only
one bibliography in the field larger than mine, but it's hardcopy,
hard to use, but it has many more European papers. Mine's dynamic,
useable with text formatters, and updateable. Keys and annotations, too.
I suspect an AI bibliography will have two major problems:
1) AI is a much bigger field.
2) AI has more hype literature associated with it.
If it were possible to moderate the technical content of the papers,
you will succeed nicely. I have a separate bibliography for the
"top ten" required readings in software engineering. I plan to update it
yearly with a call for suggestions. Books will be booted in and out (I hope).
Other minor problems: some work was received in Scribe bibliographic
format: I decided on refer: ran on smaller machines, Unix more widely
available, and so on. I had to write crude Scribe->refer translators.
Getting people to help add, correct, and delete work is surpising difficult:
everybody wants loaves of bread, but few want to do the work.
The initial start is the hardest of course. Try to build off of others
work if they will let you.
--eugene miya
NASA Ames Research Center
emiya@ames-vmsb.ARPA
ames!aurora!eugene on UUCP
------------------------------
Date: Sun, 18 Aug 85 00:35:00 edt
From: BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa>
Subject: Re: Expert System definition vs Database Systems
From: Henry Nussbacher <vshank%weizmann.BITNET@WISCVM.ARPA>
...Somehow, I have always felt Expert
Systems to be glorified database systems....
1) Does the patient have a fever? Y
2) Has the patient vomitted in the past 24 hours? Y
3) Are the pupils dilated? N
4) etc...
But I know of many database packages where a question in the form of:
FIND FEVER > 100 & VOMIT = YES & DILATED = NO
DISPLAY ALL
In the first place, differential diagnosis is both a good and a bad
example. Bad because it is meant to provide a lot of structure that can
be likened to a data-base query with boolean logic and good because it
has been worked on a lot in AI and as you get into more details it
starts to become more clear why the database approach isn't always
powerful enough.
Consider: In the first place, there are many, many diseases. A doctor
doesn't attempt to know all of them. In fact, the questioning (in a
doctor's mind) I believe starts with something more like:
is this person in front of me about to drop dead?
a lot of info has to be processed real fast and inaccurately (from a
data base/strict machine point of view) to answer that and act on it.
Ok, let's try it again:
IF s/he has a fever AND s/he has been vomiting
THEN (will s/he drop dead in a moment?)
or FIND DISEASE WHERE FEVER & VOMIT & DEATH
hmmm, doesn't work. Maybe that's all the patient is saying though. I
guess we better find out if s/he's severely dehydrated, measure the
fever, or maybe they just have a little food poisoning.
Ok, try again:
IF he has a fever AND he has been vomiting
THEN he has malaria...
wait a minute! there's no malaria around here...try again (darn, if s/he
hadn't just fallen over I might have asked if s/he have been traveling in
the tropics lately or eaten any jalisco cheese, now what do I do...)
I think my point is, yes, it's kind of like a database query BUT WHO IS
GENERATING THE QUESTIONS. I think your example weakens a lot once the
first query is made, who decides what the second query is to be? The
expert system of course. You are assuming some magic actor generating
all these nice queries and inferences, get rid of that actor and try it
again.
-Barry Shein, Boston University
------------------------------
Date: Sat 17 Aug 85 10:38:41-PDT
From: PEREIRA@SRI-AI.ARPA
Subject: Hewitt's tirade against Prolog
Carl Hewitt's message is based on several misconceptions:
1. (the least interesting one) All the so-called commercially viable
Prolog systems in Lisp are not really Prolog systems written IN Lisp,
but rather Prolog systems written FOR Lisp machines. Or is it that a
microcode sublanguage or Lisp machine pointer-smashing operations are
part of List as we know it? Without those machine-level operations,
those Prolog systems would run too slow and use too much memory to be
useful for serious Prolog programming. From the Prolog implementation
point of view, what is important about the Lisp machines is not that
they run Lisp, but that they can be microcoded and have good support
for tagged data types and stack operations.
2. If the decisions (actions) of a system are not determined by its
inputs, the system is nondeterministic. Nondeterminism in a system can
be either an artifact of our incomplete knowledge (or lack of
interest) of the detailed operation of the system; or it can be
``real physical'' nondeterminism. It would take us to far to discuss
whether the second kind of nondeterminism is ``real'' or also an
artifact. In any case, most uses of nondeterminism, say in models of
concurrency, are of the first kind, and can be expressed appropriately
in various temporal/dynamic logics. Admittedly, these are not Prolog,
but then Common Lisp is not Lisp 1.5! (Prolog is 13 years old, Lisp
25).
3. The first logic course dictum ``from a contradiction one can
conclude anything'' is getting in the way. Notice that the dictum says
``can'', not ``must''. There is an enormous difference between things
that are in principle true and things that an agent knows to be true
in a way that can affect its action. An agent might know ``p'' and
``not p'', but it might well never come to infer the dreaded totally
unrelated ``q'' which IN PRINCIPLE follows from the contradiction.
This inference might not happen either because of inference control
mechanisms of the agent (eg. it uses the set-of-support strategy) or
because the agent's logic is just TOO WEAK to conclude anything from a
contradiction (vide Hector Levesque's work in the proceedings of the
last AAAI). In any case, Horn clauses (the basis of Prolog) are too
weak to represent contradictions... :-)
4. The question of whether ``taking action'' fits in a logic paradigm
tends to be answered negatively after an hour's worth of
consideration. If you persist for several years, though, this
question becomes a source of insight on the relations between
knowledge, state and action that is not available to those who started
by dismissing the question after that initial hour. There is just too
much work on logics of knowledge and action in AI and computer science
for me to try to discuss it here. Some of this work has been applied
to logic programming, either in the form of new logic programming
languages based on temporal or dynamic logics or in representations of
temporal reasoning and decision in, say, Prolog.
5. It is curious to see someone by implication defend Lisp as a
language for expressing the taking of action! We know by now that the
most difficult issue in ``reactive systems'' is not EXPRESSING action,
but rather keeping it under control to prevent unwanted interactions.
In this area, less is REALLY more, and highly complex languages like
Lisp are just not suitable for the formal reasoning about programs
that is needed to help us believe our programs do what we intend. To
those who say ``...but we can keep to a carefully constrained subset
of Lisp, use only message passing for interactions,...'' I will answer
that the history of all large Lisp programs I know (and I think that
is a representative sample) is littered with the brutalized corpses of
constrained programming styles. Anyone who has looked at the current
flavor mechanism in Zetalisp and its use in the window system will
know what I mean...
6. Underlying Carl Hewitt's misconceptions is the old chestnut ``logic
is static, systems are dynamic''. Any language, be it first-order
logic or Lisp, is static; it is its USE which is dynamic (changes the
state of communicating agents). A good analogy here is the use of
differential equations to model dynamic systems in classical
mechanics. The differential equations themselves do not say directly
what happens when (they are ``static'' in Hewitt's jargon). It is
their SOLUTIONS that tell us the sequence of events. Even the
solutions are given as static objects (functions from an open interval
of the reals to some space). Does anyone worry that such equations do
not ``really'' describe the dynamic behavior of a system? Is it not
possible to combine such ``static'' entities with an incremental
solution procedure to build systems that actually control their
(classical mechanical) environment?
-- Fernando Pereira
------------------------------
Date: 15 Aug 85 15:05:59 EDT
From: Mary.Lou.Maher@CMU-RI-CIVE
Subject: Seminar - Design Expert Systems (CMU)
A GENERATIVE EXPERT SYSTEM
FOR THE DESIGN OF BUILDING LAYOUTS
Ulrich Flemming
Design Research Center &
Department of Architecture
Thursday, August 22 at 1:30 pm
Adamson Wing, Baker Hall
The talk will outline a generative expert system for the design
of building layouts aimed at systematically enumerating layout
alternatives while taking into account a broad range of criteria, a task
to which the human cognitive apparatus is not particularly well suited.
The system is roughly modelled after the DENDRAL system.
In its most simple incarnation, it will consist of a generator able to
generate all possible alternatives, a tester that evaluates these
alternatives, and a control strategy that mediates between the two
to help prune the search tree.
What makes the generator so special is that it
treats spatial relations between the objects to be allocated as the
basic design variables in which the generation takes place.
The completeness and non-redundancy of the generation have been
established.
The tester will be programmed to facilitate the addition and
modification of the design knowledge incorporated in it.
A tentative control strategy will be discussed.
It is expected that for more complicated layout problems, the control
strategy will have to be expanded into a genuine planner with at least two
levels: 'hierarchical' and 'strategic', both of which will be outlined.
------------------------------
Date: 13 Aug 85 13:23:26 EDT
From: Jeanne.Bennardo@CMU-RI-ISL1
Subject: Seminar - Intelligent Design Completion (CMU)
Topic: Presentation of Wright Project
Speaker: Can Baykan
Place: DH3313
Date: Wednesday, August 14
Time: 10:00am - 11:00am
An intelligent design completion system is a knowledge-based CAD system
which provides a design environment and assists the designer in analyzing
and synthesizing designs. For example, the designer may generate a partial
design and have the system carry out a diagnostic evaluation, or complete
the design. Such a system would be composed of two major components: a
knowledge-base and a drafting system.
The WRIGHT system is an interactive CAD system which the designer can use in
representing, analyzing and generating kitchen designs. The goals in
building such a system are to understand:
1. The architecture and components of a design-completion system.
2. The types of knowledge required for analyzing and synthesizing designs,
Knowledge required for recognizing elements in a drawing generated by the
designer,
Knowledge required for recognizing design contexts,
3. The generation of form -a complex, structured object-, based on function
-a diverse set of constraints from many sources.
The application domain chosen for the WRIGHT system is kitchen design.
------------------------------
Date: 13 AUG 85 15:57-N
From: ROSNER%CGEUGE51.BITNET@WISCVM.ARPA
Subject: Call for Papers - Knowledge Represention, Proc. IEEE
CALL FOR PAPERS
Proceedings of the IEEE
Special Issue on Knowledge Representation
Guest Editors: M King, M Rosner, University of Geneva
The special issue is scheduled for publication during the second half of
1986. You are invited to submit a 6-10 page extended abstract on any topic
relevant to the current state of the art in Knowledge Representation.
Deadlines:
submission of abstracts: 30th September 1985
notification of acceptance: 30th December 1985
final copy: 15th February 1986
contact: ROSNER%cgeuge51@WISCVM.ARPA (bitnet)
mcvax!cernvax!cui!rosner (usenet, eunet, uucp)
M Rosner
ISSCO,
54 route des Acacias,
1227 Geneva, Switzerland
------------------------------
End of AIList Digest
********************
