Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!AIList-REQUEST@SRI-AI From: AIList-REQUEST@SRI-AI (AIList Moderator Kenneth Laws) Newsgroups: net.ai Subject: AIList Digest V3 #113 Message-ID: <8508260423.AA17886@UCB-VAX.ARPA> Date: Sun, 25-Aug-85 23:33:00 EDT Article-I.D.: UCB-VAX.8508260423.AA17886 Posted: Sun Aug 25 23:33:00 1985 Date-Received: Tue, 27-Aug-85 01:18:37 EDT Sender: daemon@ucbvax.ARPA Reply-To: AIList@SRI-AI Organization: University of California at Berkeley Lines: 378 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 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 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 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 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 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 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 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 ********************