Copy Link
Add to Bookmark
Report
AIList Digest Volume 3 Issue 113
AIList Digest Monday, 26 Aug 1985 Volume 3 : Issue 113
Today's Topics:
Queries - Machine Learning Journals & Lisp to C &
Hardware Choices For Running LISP & Modularity and Compositionality &
Expert Systems in Psychiatry,
Literature - Master Bibliography,
Humor - Media Portrayal of Scientists,
Games - Book Openings,
Logic Programming - Hewitt's Reply to Pereira,
Seminar - Partial Evaluation in Meta-Interpreters (SU)
----------------------------------------------------------------------
Date: Sun, 18 Aug 85 23:00:23 cdt
From: Raj Doshi <doshi%umn.csnet@csnet-relay.arpa>
Subject: machine learning journals..
I (as a co-author) would like to publish a modest article
which has something to do with MACHINE LEARNING.
Can someone tell me the JOURNALs that are strictly for
machine learning ????
Are there any such conferences. ????
Thanks in advance.
--- raj doshi, University of Minnesota
doshi%umn.csnet@csnet-relay.arpa
[Gluck@SU-PSYCH announced a new Machine Learning journal in
AIList V. 3, No. 106, Aug. 10. It will come out quarterly
beginning January 1986. Executive Editor: Pat Langley;
Editors: Jaime Carbonell, Ryszard Michalski, Tom Mitchell;
Kluwer Academic Publishers, 190 Old Derby Street, Hingham,
MA 02043, or call 617-749-5262. -- KIL ]
------------------------------
Date: 20 Aug 85 17:18:44 EDT (Tue)
From: duke@mitre.ARPA
Subject: Lisp to C
We are looking for a Lisp to C translator, in the hope
that it might help us move some Franz Lisp programs onto
some parallel processor machines which currently lack Lisp.
Does anyone know of such a translator?
Duke Briscoe
Mitre
------------------------------
Date: Fri, 23 Aug 85 12:09 EST
From: Clarke Thacher <UKC323%UKCC.BITNET@WISCVM.ARPA>
Subject: Hardware Choices For Running LISP.
Our computing center director has asked me to get some information and
make recommendations on alternatives for supporting LISP at the
University. Specifically, he has been getting researchers in several
departments submitting requests for single user LISP workstations. He
is reluctant to approve all of these requests, if a more economic
solution is available. I would appreciate any pointers which people
might be able to offer. We have an IBM 3081 with VM & CMS, and 3
Prime superminis. One of the Primes has the Salford LISP/Prolog
system but I suspect that the researchers want more than that.
Approximate costs would be appreciated.
Clarke Thacher BITNET : UKC323@UKCC
(606) 257-2900
72 McVey Hall
Computing Center
University Of Kentucky
Lexington, Ky. 40506-0045
------------------------------
Date: Wed 21 Aug 85 21:19:25-PDT
From: Lee Altenberg <ALTENBERG@SUMEX-AIM.ARPA>
Subject: Modularity and Compositionality
A few issues back someone used the term "modularity" to refer to parts of a
program. This leads me to ask, is there a precisely defined notion of what
"modularity" is? Also, it seems to me that there is a natural connection
between modularity as I understand it and "compositionality" as used in
linguistics. Does anyone have any information, references, or ideas on these
points?
-Lee Altenberg
------------------------------
Date: Thu, 22 Aug 85 17:20 EST
From: Clarke Thacher <UKC323%UKCC.BITNET@WISCVM.ARPA>
Subject: Expert Systems
A professor in our Psychiatry department has expressed interest in any
work which has been done with Expert Systems in psychiatry (please not
ELIZA). He is interested in it as a diagnostic tool to be used by the
physician (and for teaching third year medical students).
Please send any leads to:
Clarke Thacher BITNET: UKC323@UKCC
Computing Center
University Of Kentucky
Lexington, Ky.
------------------------------
Date: Wed, 21 Aug 85 13:28:56 pdt
From: aurora!eugene@RIACS.ARPA (Eugene miya)
Subject: Additional comment about master bibliography
Oh, I forgot one MAJOR point of maintenance work.
I am just now receiving smaller bibiliographies on things like computer
networks. There are many collisions with papers already in the existing file.
The problem is subtle because of slight variations in annotation
styles which bibliographic sorting programs cannot appropriately
handle. Also, transferring interesting comments and annotations
from one entry to another is also time consuming. Two smaller
bibliographies have come from England, and differences in spelling are
another subtle problem: Defense and Defence.
--eugene miya
NASA Ames Research Center
{hplabs,hao,dual,ihnp4,vortex}!ames!aurora!eugene
emiya@ames-vmsb.ARPA
------------------------------
Date: 20 Aug 1985 02:54:13-EDT, Tue, 20 Aug 85 02:37 EDT
From: straz@AQUINAS.THINK.COM@MIT-CCC, Steve Strassmann
<straz@AQUINAS.THINK.COM>
Subject: Good news and bad news, Mr. Wizard...
[Forwarded by BNevin@BBNCCH.]
>From the September issue of "Science 85":
"This is a good time to play a scientist on TV. Researchers at the
University of Pennsylvania say that scientists on the tube are warm,
attractive, and five times more likely to be virtuous than villainous.
But the study also showed that TV scientists are killed more often than
soldiers, private eyes, and police officers."
------------------------------
Date: 25 Aug 1985 10:25:51 PDT
From: Stuart Cracraft <CRACRAFT@USC-ISIB.ARPA>
Subject: Drew Liao's comments about chess
"I too believe that a computer should learn how to play chess before
it is allowed to play in a tournament rather than rely on moves
encoded into the program."
- Drew Liao, AILIST V3 #102, 1-Aug-85
The above doesn't make much sense to me. Currently, chess programs
such as Belle and Cray Blitz usually play no more than the first
10 moves from a pre-stored "opening book".
If the opponent makes an extremely odd or unusual move early,
retrieval from the book is terminated and normal tree-searching
is begun in order to generate a move.
What would Drew have us do? Turn off book completely? Rely only
on tree-search for the opening? The opening is extremely tricky,
because pawn configurations and piece placements are being set
up for 20 moves later.
Thus, most programs that rely on heuristics and tree-search
for opening play are prone to fall into traps a book usually
avoids. They are also prone to jumble their pieces in bad ways.
Therefore, I argue that allowing opening book is essential to
good play. A more valid criticism would concern the transition
from opening book to tree-searching. Many programs deal with
this transition very poorly. International Masters or Grand-
masters can often take advantage of their poor *TRANSITION*
play and mop up quickly in a positional sense.
I see no great difference between storing 50,000 opening positions
in a computer "book" and a human expert spending 5 weeks studying
the Caro-Kann defense. Both have memorized in order to avoid
re-creating extensive work *OTHERS* have done for them ahead
of time.
Why re-invent the wheel?
Stuart Cracraft
------------------------------
Date: Mon, 19 Aug 1985 13:30 EDT
From: Hewitt@MIT-MC
Subject: Prolog will fail as the foundation for AI
Misconceptions?
From: PEREIRA at SRI-AI.ARPA
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?
Yes. They are DEFINITELY part of Common Lisp as we know it being
implementations of reading and writing operations on record
structures. Such implementation methods are NOT part of Logic as a
Programming language.
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.
It is important to many users that they can make use of ALL the software
available to the community and not just be limited to the tiny amount
in Prolog. Furthermore in the future good software will be ported
from stand alone Prolog systems to Prolog implemented on Lisp. However
to good Lisp software will not be able to be ported to the stand
alone Prolog systems.
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).
Yes indeed there is a large problem here that poses fundamental problems
for using Logic as a Programming language to make decisions in Open
Systems.
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... :-)
I claim that in practice the contradictions lie close to the surface and
occur in any nontrivial application. Thus the contradictions
pose fundamental problems for using Logic as a Programming Language.
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.
I have been thinking about the problem for many years having designed
Micro-Planner, the first "procedural embedding of logic" programming
language in 1967. I claim that the problem of taking action poses
fundamental problems for using Logic as a Programming language.
5. It is curious to see someone by implication defend Lisp as a
language for expressing the taking of action!
I claim that current Lisp systems are better than current Prolog
systems for taking action because the only ways to take action in
current Prolog systems are kludges.
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...
5. Underlying Carl Hewitt's misconceptions is the old chestnut ``logic
is static, systems are dynamic''.
Note that the above quotation is NOT anything that I said.
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).
I do not deny that dynamic systems can be DESCRIBED using logic only
that they can be CONTROLLED.
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?
I do not believe that the control system can be implemented using Logic
as a Programming language
------------------------------
Date: Tue 20 Aug 85 21:44:22-PDT
From: Ashok Subramanian <ashok@SU-SUSHI.ARPA>
Subject: Seminar - Partial Evaluation in Meta Interpreters (SU)
Prof. Ehud Shapiro, of the Weizmann Institute of Science, will present a
talk at 9 am on Monday, the 26th of August, in Margaret Jacks Hall room 352.
The Magic of Partial Evaluation,
or
Meta Interpreters for Real
Ehud Shapiro
The Weizmann Institute of Science
Enhanced meta-interpreters can implement sophisticated functions within
complex software system. Examples are explanation facilities in expert
systems, algorithmic debuggers in programming environments, and layers of
protection and control in operating systems.
However, the execution overhead of the added layer of interpretation
is unacceptable in many applications.
Partial evaluation can eliminate the overhead of meta-interpreters.
A partial-evaluator can specialize an enhanced meta-interpreter
with respect to a given program,
generating a variant of this program which inherits the enhanced
functionality of the meta-interpreter, but not its overhead.
An application of a Concurrent Prolog partial evaluator
to operating system development will be shown.
------------------------------
End of AIList Digest
********************
