Copy Link
Add to Bookmark
Report
AIList Digest Volume 1 Issue 026
AIList Digest Tuesday, 26 Jul 1983 Volume 1 : Issue 26
Today's Topics:
AAAI-83 Schedule on USENet
Roommates Wanted for AAAI
Artificial Intelligence Info for kids
Preparing Govmt Report on Canadian AI Research
Definitions (2)
Expectations of Expert System Technology
Portable and More Efficient Lisps (3)
----------------------------------------------------------------------
Date: 24 Jul 83 20:20:09-PDT (Sun)
From: decvax!linus!utzoo!utcsrgv!peterr @ Ucb-Vax
Subject: AAAI-83 sched. avail. on USENet
Article-I.D.: utcsrgv.1828
I have a somewhat compressed, but still large (18052 ch.), on-line
version of the AAAI-83 schedule that I'm willing to mail to USENet
people on request.
peter rowley, U. Toronto CSRG
{cornell,watmath,ihnp4,floyd,allegra,utzoo,uw-beaver}!utcsrgv!peterr
or {cwruecmp,duke,linus,lsuc,research}!utzoo!utcsrgv!peterr
------------------------------
Date: 22 Jul 83 10:34:11-PDT (Fri)
From: decvax!linus!utzoo!hcr!ravi @ Ucb-Vax
Subject: Room-mates wanted for AAAI
Article-I.D.: hcr.451
A friend (Mike Rutenberg) and I are going to AAAI at the end of
August. We'd like to find a couple of people to share a room with --
both to meet interesting people and to save some money. If you're
interested, please let me know by mail.
Also, if you have any other useful hints (like cheap transportation
from Ontario or better places to stay than the Hilton), please drop me
a line.
Thanks for your help.
--ravi
------------------------------
Date: 24 Jul 1983 0727-CDT
From: Clive Dawson <CC.Clive@UTEXAS-20>
Subject: Artificial Intelligence Info for kids
[Reprinted from the UTexas-20 BBoard.]
I received a letter from an 8th grader in Houston who wants to do a
science fair project on Artificial Intelligence.
"...I plan to explain and demonstrate this topic with
my computer and a program I made on it concerning this
topic. Any information you could send for my research
would be appreciated."
If anybody knows of any source of AI information suitable for Jr. High
School level (good magazine articles written for the layman, etc.)
please let me know. I have come across such stuff every so often, but
I'm having trouble remembering where.
Thanks,
Clive
------------------------------
Date: 23 Jul 83 16:30:27-PDT (Sat)
From: decvax!linus!utzoo!utcsrgv!zenon @ Ucb-Vax
Subject: Preparing Govmt report on Canadian AI research
Article-I.D.: utcsrgv.1823
A consortium of 4 groups has been awarded a contract by the Secretary
of State to prepare a report on what Canada ought to be doing to
support R & D in artificial intelligence in the next 5-10 years. The
groups are Quasar Systems of Ottawa, Nordicity Group of Toronto,
Socioscope of Ottawa, and a group of academic AI people (Pylyshyn,
Mackworth, Skuce, Kittredge, Isabel, with consultants Tsotso,
Mylopoulos, Zucker, Cercone). Because the client's primary interest
is in language (esp. translation) the report will concentrate on that
aspect, though we plan to cover all of AI on the grounds that it's all
of a piece. The contract period is July-Dec 1983. I am coordinating
the technical part of the report.
We are seeking input from all interested parties. I will be touring
Canada, probably in September, and would like to talk to anyone who
has an AI lab and some ideas about where Canada ought to focus. I am
especially eager to receive input from, and information about,
what's happening in Canadian industry.
I welcome all suggestions and invitations. This is the first AI study
commissioned by a federal agency on AI and we should take this as an
opportunity to give them a good cross-section of views.
Zenon Pylyshyn, Centre for Cognitive Science, University of Western
Ontario, London, Ontario, N6A 5C2. (519)-679-2461
utcsrgv!zenon or on the ARPANET Pylyshyn@CMU-CS-C
------------------------------
Date: Fri 22 Jul 83 09:32:16-EDT
From: MASON@CMU-CS-C.ARPA
Subject: Re: definition of robot
I think the definition of robot is a little too broad. I've long been
reconciled to definitions which include, for instance,
cam-programmable sewing machines, but this new definition even
includes pistols. (An input signal, trigger pressure, is processed
mechanically to actuate a mechanical device, the bullet.) Of course,
if the NRA decided to lobby for robots ...
------------------------------
Date: Fri 22 Jul 83 09:22:54-PDT
From: Ken Laws <Laws@SRI-AI.ARPA>
Subject: Definitions
Here are a few definitions taken from a Teknowledge/CEI ad:
Artificial Intelligence
That subfield of Computer Science which is concerned with
symbolic reasoning and problem solving by computer.
Knowledge Engineering
The engineering discipline whereby knowledge is integrated
into computer systems in order to solve complex problems
normally required [sic] in a high level of human expertise.
Knowledge/Expert Systems
Computer systems that embody knowledge including inexact,
heuristic and subjective knowledge; the results of knowledge
engineering.
Knowledge Representation
A formalism for representing facts and rules about a subject
or specialty.
Knowledge Base
A base of information encoded in a knowledge representation
for a particular application.
Inference Technique
A methodology for reasoning about information in knowledge
representation [sic] and drawing conclusions from that knowledge.
Task Domains
Application areas for knowledge systems such as analysis of
oil well drilling problems or identification of computer
system failures.
Heuristics
The informal, judgmental knowledge of an application area
that constitutes the ``rules of good judgement'' in the field.
Heuristics also encompass the knowledge of how to solve problems
efficiently and effectively, how to plan steps in solving
a complex problem, how to improve performance, and so forth.
Production Rules
A widely-used knowledge representation in which knowledge
is formalized into ``rules'' containing an ``IF'' part and
a ``THEN'' part (also called a condition and an action).
The knowledge represented by the production rule is applicable
to a line of reasoning if the IF part of the rule is satisfied:
consequently, the THEN part can be concluded or its
problem-solving action taken.
-- Ken Laws
------------------------------
Date: 24 Jul 83 1:41:35-PDT (Sun)
From: decvax!linus!utzoo!utcsrgv!peterr @ Ucb-Vax
Subject: Expectations of expert system technology
Article-I.D.: utcsrgv.1824
>From a recent headhunting flyer sent to some AAAI members:
"We have been retained by a major Financial Institution, located in
New York City. They are interested in building the support staff for
their money market traders and are looking for qualified candidates
for the following positions:
A Senior AI Researcher who has experience in knowledge rep'n
and expert systems. The ideal candidate would have a
graduate degree in CS - AI with a Psychology (particularly
cognitive processes), Cultural Anthropology, or comparable
background. This person will start by being a consultant in
Human Factors and would interact between the Traders and the
Systems they use. Two new Xerox 1100 computers have been
purchased and experience in LISP programming is necessary
(with INTERLISP-D preferred). This person will have their
own personal LISP machine. The goal of this position will
be to analyze how Traders think and to build trading support
(expert) systems geared to the individual Trader's style."
Two other job descriptions are given for the same project, for an
economist and an MBA with CS (database, communications, and systems)
and Operations Research background.
The fact that the co. would buy the 1100's without consulting their
future user and the tone of the description prompts me to wonder if
the co. is treating expert system technology as an engineering
discipline which can produce results in a relatively short order
rather than the experimental field it appears to be. Particularly
troubling is the problem domain for this system--I would expect such
traders to make extensive use of knowledge about politics and economic
policy on a number of levels, not easy knowledge to represent.
I'm not an expert systems builder by any means and may be
underestimating the technology... does anyone think this co. is not
expecting too much? (Replies to the net, please)
[The company should definitely get copies of
J.L. Stansfield, COMEX: A Support System for a Commodities Analyst,
MIT AIM-423, July 1977.
J.L. Stansfield, Conclusions from the Commodity Expert Project,
MIT AIM-601, (AD-A097-854), Nov. 1980.
The latter, I hear, documents the author's experience with large,
incomplete databases of unreliable facts about a complex world.
It must be one of the few examples of an academic research project
that could not claim success. -- KIL]
------------------------------
Date: Mon 25 Jul 83 02:45:51-EDT
From: Chip Maguire <Maguire@COLUMBIA-20.ARPA>
Subject: Re: Portable and More Efficient Lisps
What I wish to generate is a discussion of what are the
features of LISP@-[n] which provide a nice/efficient/(other standard
virtues) environment for computer aided intellectual tasks (such as
AI, CAD, etc.).
For example, quite a lot of the work that I have been involved
with recently required that from with a LISP environment that I
generate line drawings to represent: data structures, binding
environments for a multi-processor simulator, or even as a graphical
syntax for programming. Thus, I would like to have 1) reasonable
support (in terms of packages of routines) for textual labels and line
drawings; and 2) this same package available irrespective of which
machine I happen to be using at the time [within the limits of the
hardware available].
What other examples of common utilities are emerging as
"expected" `primitives'? Chip
------------------------------
Date: Sat, 23 Jul 83 15:58:24 EDT
From: Stephen Slade <Slade@YALE.ARPA>
Subject: Portable and More Efficient Lisps
Chip Maguire took violent exception to the claim that T, a version of
Scheme implemented at Yale, is "more efficient and portable" compared
to other Lisp implementations. He then listed the numerous machines
on which PSL, developed at Utah, now runs.
The problem in this case is one of operator precedence: "more" has
higher precedence than "and". Thus, T is both portable AND more
efficient. These two features are intertwined in the language design
and implementation through the use of lexical scoping and an
optimizing compiler which performs numerous source-to-source
optimizations. Many of the compiler operations that depend on the
specific target machine are table driven. For example, the register
allocation scheme clearly depends on the number and type of registers
available. The actual code generator is certainly machine dependent,
but does not comprise a large portion of the compiler. The compiler
is written largely in T, simplifying the task of porting the compiler
itself.
For PSL, portability was a major implementation goal. For T,
portability became a byproduct of the language and compiler design. A
central goal of T has been to provide a clean, elegant, and efficient
LISP. The T implementers strove to achieve compatibility not only
among different machines, but also between the interpreted and
compiled code -- often a source of problems in other Lisps. So far, T
has been implemented for the M68000 (Apollo/Domain), VAX/UNIX, and
VAX/VMS. There are plans for other machine implementations, as well
as enhancements of the elegance and efficiency of the language itself.
People at Yale have been using T for the past several years now.
Applications have included an extensible text editor with inductive
inference capability (editing by example), a hierarchical digital
circuit graphics editor and simulator, and numerous large AI programs.
T is also being used in a great many undergraduate courses both at
Yale and elsewhere.
I believe that PSL and Standard LISP have been very worthwhile
endeavors and have bestowed the salutary light of LISP on many
machines that had theretofore languished in the lispless darkness of
algebraic languages. T, though virtuous in design and virtual in
implementation, does not address the FORTRAN-heathen, but rather seeks
to uplift the converted and provide comfort to those true-believers
who know, in their heart of hearts, that LISP can embrace both
elegance and efficiency. Should this credo also facilitate
portability, well, praise the Lord.
------------------------------
Date: Mon, 25 Jul 83 11:41:50 EDT
From: Nathaniel Mishkin <Mishkin@YALE.ARPA>
Subject: Re: Lisp Portability
Date: Tue 19 Jul 83 15:24:00-EDT
From: Chip Maguire <Maguire@COLUMBIA-20.ARPA>
Subject: Lisp Portability
[...]
So lets hear more about the good ideas in T and fewer nebulous
comments like: "more efficient and portable".
I can give my experience working on a display text editor, U, written
in T. (U's original author is Bob Nix.) U is 10000+ lines of T code.
Notable U features are a "do what I did" editing by example system, an
"infinite" undo facility, and a Laurel (or Babyl) -like mail system.
U runs well on the Apollo and almost well on VAX/VMS. U runs on
VAX/Unix as well as can be expected for a week's worth of work.
Porting U went well: the bulk of U did not have to be changed.
- - - - -
Notable features of T:
- T, like Scheme (from which T is derived) supports closures (procedures
are first-class data objects). Closures are implemented efficiently
enough so that they are used pervasively in the implementation of the
T system itself.
- Variables are lexically-scoped; variables from enclosing scopes can
be accessed from closed procedures.
- T supports an object-oriented programming style that does not conflict
with the functional nature of Lisp. Operations (like Smalltalk messages)
can be treated as functions; e.g. they can be used with the MAP
functions.
- Compiled and interpreted T behave identically.
- T has fully-integrated support for multiple namespaces so software
written by different people can be combined without worrying about
name conflicts.
- The T implementors (Jonathan Rees and Norman Adams) have not felt
constrained to hold on to some of the less modern aspects of older
Lisps (e.g. hunks and irrational function names).
- T is less of a bag of bits than other Lisps. T has a language definition
and a philosophy. One feels that one understands all of T after reading
the manual. The T implementors have resisted adding arbitrary features
that do not fit with the philosophy.
- Other features: inline procedure expansion, procedures accept arbitrary
numbers of parameters ("lexpr's" or "&rest-args"), interrupt processing.
All these aspects of T have proved to be very useful.
- - - - -
The predecessor system "Standard LISP" along with the REDUCE
symbolic algebra system ran on the following machines (as October
1979): Amdahl: 470V/6; CDC: 640, 6600, 7600, Cyber 76; Burroughs:
B6700, B7700; DEC: PDP-10, DECsystem-10, DECsystem-20; CEMA: ES
1040; Fujitsu: FACOM M-190; Hitachi: MITAC M-160, M-180;
Honneywell: 66/60; Honeywell-Bull: 1642; IBM: 360/44, 360/67,
360/75, 360/91, 370/155, 370/158, 370/165, 370/168, 3033, 370/195;
ITEL: AS-6; Siemens: 4004; Telefunken: TR 440; and UNIVAC: 1108,
1110.
Hmm. Was the 370/168 implementation significantly different from the
370/158 implementation? Also, aren't some of those Japanese machines
"360s". When listing implementations, let's do it in terms of
architectures and operating systems.
While it may be the case that PSL is more portable than T, T does
presently run on the Apollo, VAX/VMS and VAX/Unix. Implementations for
other architectures are being considered.
------------------------------
End of AIList Digest
********************
