Copy Link
Add to Bookmark
Report
AIList Digest Volume 2 Issue 039
AIList Digest Saturday, 31 Mar 1984 Volume 2 : Issue 39
Today's Topics:
Applicative Simulation - Request,
AI Tools - Request,
Distributed Programs - Request,
AI - Definition of AI Problems,
Expert Systems - Explanatory Capability & Legal Systems & NY Times,
Seminar - Theory of the Learnable,
Course - System Description Languages
----------------------------------------------------------------------
Date: 2 Apr 84 12:50:24-EST (Mon)
From: ihnp4!houxm!hogpc!houti!ariel!vax135!ukc!srlm @ Ucb-Vax
Subject: applicative / functional simulation
Article-I.D.: ukc.4146
I am looking for information on functional/applicative
simulators of anything (communications protocols, to
cite a good one) written in a PURELY applicative/functional
style (no setq's please).
If you know of anything about this (papers, programs, etc)
I'd be very grateful if you could mail the pointers to me.
Silvio Lemos Meira
UUCP: ...!vax135!ukc!srlm
computing laboratory
university of kent at canterbury
canterbury ct2 7nf uk
Phone: +44 227 66822 extension 568
------------------------------
Date: Thu, 29 Mar 84 16:19 cst
From: Bruce Shriver <ShriverBD%usl.csnet@csnet-relay.arpa>
Subject: request for references
I would like to be referred to either one or two seminal papers or one or
two highly qualified persons in the following areas (if you send me the
name of an individual, the person's address and phone number would also
be greatly appreciated):
1. Tutorial or survey papers on logic programming, particularly those
dealing with several different language approaches.
2. Reusable Software (please give references other than the Proceedings
of the Workshop on Reuseability in Programming which was held in
Newport, RI last September).
3. Your favorite formal specification technique that can be applied to
large scale, complex systems. Examples demonstrating the completeness
and consistency of a set of specifications for real systems.
4. Integrated programming environments such as Cedar and Spice versus
the Ada-style environments (APSEs, etc.). Discussions on the
relative merits of these two kinds of environments.
5. Knowledge Based System Architectures (i.e., support of knowledge
based systems from both the hardware and software point of view).
Knowledge representation and its hardware/software implications.
The relationship between "knowledge bases" and "data bases" and
the relationship between knowledge base systems and data base
systems.
Thank you very much for your time and consideration in this matter. I
appreciate your help: Bruce D. Shriver
Computer Science Department
University of Southwestern Louisiana
P. O. Box 44330
Lafayette, LA 70504
(318) 231-6606
shriver.usl@rand-relay
------------------------------
Date: 30 Mar 84 1208 EST (Friday)
From: Roli.Wendorf@CMU-CS-A
Subject: Distributed Programs
As part of my thesis, I am collecting information on the behavior of
distributed programs. I define distributed programs as consisting of
multiple processes. Thus, multiprocess programs running on uniprocessor
systems would qualify as well.
If you have written, or know of any distributed programs, I would like to
hear from you. I am specially interested in hearing about distributed
versions of commonly used programs like editors, compilers, mail systems, etc.
Thanks in advance,
Roli G. Wendorf
------------------------------
Date: 30 Mar 84 12:04:36 EST (Fri)
From: Dana S. Nau <dsn%umcp-cs.csnet@csnet-relay.arpa>
Subject: Re: A call for discussion
From: Sal Stolfo <sal@COLUMBIA-20.ARPA>
This note is a solicitation of the AI community for cogent
discussion ... We hope that all facets will be addressed including:
- Differences between the kinds of problems encountered in AI and those
considered more conventional. (A simple answer in terms of
``ill-defined'' and ``well-defined'' problems is viewed as a copout.)
...
One of the biggest differences involves how well we can explain how we
solve a problem. The problems that humans can solve can be divided roughly
into the following two classes:
1. Problems which we can solve which we can also explain HOW to solve.
Examples include sorting a deck of cards, adding a column of numbers, and
payroll accounting. Any time we can explain how to solve a problem, we can
write a conventional computer procedure to solve it.
2. Problems which we can solve but cannot explain how to solve (for a
discussion of some related issues, see Polanyi's "The Tacit Dimension").
Examples include recognizing a face, making good moves in a chess game, and
diagnosing a medical case. We can't solve such problems using conventional
programming techniques, because we don't know what algorithms to use.
Instead, we use various heuristic approaches.
The latter class of problems corresponds roughly to what I would call AI
problems.
------------------------------
Date: 28 Mar 84 19:25:42-PST (Wed)
From: pur-ee!uiucdcs!marcel @ Ucb-Vax
Subject: Re: 'Explaining' expert system algorithms
Article-I.D.: uiucdcs.6403
There is no need for expert system software to be well-understood by anyone but
its designers; there IS a need for systems to be able to explain THEMSELVES.
Witness human thinking: after 30 years of serious AI and much more of cognitive
psychology, we still don't know how we think, but we have relatively little
trouble getting people to explain themselves to us.
I think that we will not be able to produce such self-explanatory software
until we come up with a fairly comprehensive theory of our own mental workings;
which is, admittedly, not the same as understanding an expert program. On the
other hand, if you're a theoretical sort you tend to accept Occam's razor, and
so I believe that such a theory of cognition will be as simplifying as the
Copernican revolution was for astronomy. Thereafter it's all variations on a
theme, and expert systems too will one day be correspondingly easy.
Marcel S.
U of Illinois
------------------------------
Date: 30 Mar 1984 08:55-PST
From: SSMITH@USC-ECL
Subject: Expert Legal System
Regarding your request in the latest AI-LIST:
George Cross, an assistant prof. at Louisiana State University has
been working for aprox. the last 2 years with a law prof. to formalize
that state's legal codes. From what I understand, Louisiana uses a
form of law, not found in other states, based on precise rules, rather
than the method of refering to past cases to obtain legal precedence.
I know he has a few unpublished papers in this area and is preparing
a paper for the Austin AAAI. From what I can tell, the work is similar
in scope to McCarty's work at Rutgers.
George can be contacted over the CS-NET: cross%lsu.csnet@CSNET-RELAY.
---Steve Smith (SSmith@USC-ECL)
------------------------------
Date: Thu 29 Mar 84 06:32:32-PST
From: Edward Feigenbaum <FEIGENBAUM@SUMEX-AIM.ARPA>
Subject: Expert Systems/NY Times
[Forwarded from the Stanford bboard by Laws@SRI-AI.]
See front page story of today's New York Times entitled
"Machines Built to Emulate Human Experts' Reasoning".
Features knowledge engineering, expert systems, and Sheldon Breiner,
chairman of Syntelligence.
------------------------------
Date: 03/30/84 14:40:07
From: STORY@MIT-MC
Subject: Theory of the Learnable
[Forwarded from the MIT bboard by SASW@MIT-MC.]
TITLE: "A THEORY OF THE LEARNABLE"
SPEAKER: Professor L.G. Valiant, Harvard University
DATE: Thursday, April 5, 1984
TIME: 3:45 Refreshments
4:00 Lecture
PLACE: NE43-512a
We consider concepts as represented by programs for recognizing them and define
learning as the process of acquiring such programs in the absence of any
explicit programming. We describe a methodology for understanding the limits
of what is learnable as delimited by computational complexity. The methodology
consists essentially of choosing some natural information gathering mechanism,
such as the observation of positive examples of the concept, and determining
the class of concepts that can be learnt using it in a polynomial number of
steps. A probabilistic definition of learnability is introduced that leads to
encouraging positive results for several classes of propositional programs.
The ultimate aim of our approach is to identify once and for all the maximum
potential of learning machines.
HOST: Professor Silvio Micali
------------------------------
Date: Fri 30 Mar 84 17:28:02-PST
From: Ole Lehrmann Madsen <MADSEN@SU-SCORE.ARPA>
Subject: System Description Languages
[Forwarded from the Stanford bboard by Laws@SRI-AI.]
The following course will be given in the spring quarter:
CS 249 TOPICS IN PROGRAMMING SYSTEMS:
LANGUAGES FOR SYSTEM DESCRIPTION AND PROGRAMMING
Questions to Ole Lehrmann Madsen, M. Jacks Hall room 214, tlf. 497 - 0364,
net address MADSEN@SU-SCORE.
Listing: CS 249
Instructor: Ole Lehrmann Madsen
Time: Monday 1:00pm - 4:00pm
Room: 352 building 460
This course will consider tools and concepts for system description and
programming. A number of languages for this purpose will be presented. These
include SIMULA 67, DELTA, EPSILON and BETA, which have been developed as part
of research projects in Norway and Denmark.
SIMULA I was originally developed as a tool for simulation. SIMULA 67 is a
general programming language with simulation as a special application. The
formalization of a system as a SIMULA program often gave a better understanding
of the system than did the actual simulation results.
This was the motivation for designing a special language (DELTA) for making
system descriptions. DELTA is intended for communication about systems. e.g.
data processing, biology, medicine, physics. DELTA among others contains
constructs for describing discrete state changes (by means of algorithms) and
continuous state changes (by means of predicates). The EPSILON language is
the result of an attemp to formalize DELTA by means of Petri Nets.
BETA is a programming language originally intended for implementing DELTA
descriptions of computer systems. However the project turned into a long-
term project with the purpose of developing concepts, constucts and tools
in relation to programming. The major results of this projetc is the BETA
language. BETA is an object oriented language like SIMULA and SMALLTALK,
but unlike SMALLTALK, BETA belongs to the ALGOL family with respect to
block structure, scope rules and type checking.
Various other languages and topics may also be covered. Examples of this are:
Petri Nets, environments for system description and programming, alternative
languages like Aleph and Smalltalk, implementation issues. Implementaion issues
could be: transformation of a system description to a program, implementation
of a typed language like BETA obtaining dynamic possibilities like in LISP.
Prerequisites
Students are expected to have a basic knowledge of programming languages.
The course may to some extent depend on the background and interests of the
participating students. Students with a background in simulation or description
of various systems within physics, biology, etc. will be useful participants.
Course work
Students will be expected to read and discuss in class various papers
on system description and programming languges. In addition small
exercises may be given. Each student is supposed to write a short
paper about one or more topics covered by the course and comment on
papers by other students.
------------------------------
End of AIList Digest
********************
