Copy Link
Add to Bookmark
Report
AIList Digest Volume 2 Issue 045
AIList Digest Thursday, 12 Apr 1984 Volume 2 : Issue 45
Today's Topics:
AI Tools - Real-Time AI & MASSCOMP & MV68000 Systems Wanted,
Review - Micro LISPs & Common LISP Alert & CACM Humor,
AI Jobs - Noncompetition Clauses,
Expert Systems - Articulation,
Natural Language - Metaphors,
Seminars - Automated Algorithm Design & Engineering Problem Solving
----------------------------------------------------------------------
Date: 3 Apr 84 11:46:21-PST (Tue)
From: hplabs!hao!ames-lm!al @ Ucb-Vax
Subject: Real time man-in-the-loop LISP machines
Article-I.D.: ames-lm.196
Does anyone know of any AI systems or LISP machines that are oriented
towards real time, man-in-the-loop simulation? We are beginning work
on a space station simulator aimed at human factors research. LISP
is an appealing language in many respects but all of the systems
I've heard of are interactive, non-real time oriented. We need something
that can pretend that it's a space station and do it fast enough
and consistantly enough to keep up with human temporal perception.
------------------------------
Date: 5 Apr 84 10:04:50-PST (Thu)
From: decvax!mcnc!philabs!rdin!perl @ Ucb-Vax
Subject: OPS5 and Franz LISP wanted
Article-I.D.: rdin.371
We are looking for implemetations of Franz LISP and OPS5 that
will run on a MASSCOMP MC500 under MASSCOMP UNIX version 2.1 (2.0).
Thank you.
Robert Perlberg
Resource Dynamics Inc.
New York
philabs!rdin!rdin2!perl
------------------------------
Date: Mon, 9 Apr 84 16:37:27 cst
From: George R. Cross <cross%lsu.csnet@csnet-relay.arpa>
Subject: LISP on a Data General?
Does anyone know of a LISP implementation on Data General's
MV8000 type computers under AOS/VS? One good enough for
teaching is all that is required.
George Cross
Computer Science, LSU
<cross%lsu@csnet-relay>
------------------------------
Date: 11 Apr 1984 0206 PST
From: Larry Carroll <LARRY@JPL-VLSI.ARPA>
Reply-to: LARRY@JPL-VLSI.ARPA
Subject: micro LISP review
There's a good article in the April issue of PC Tech Journal
about three micro versions of LISP: IQ LISP, muLISP-82, and
TLC LISP. It gives a fair amount of implementation detail,
contrasts them, and compares them to their mini and mainframe
cousins. The author is Bill Wong, who's working on his PhD in
computer science at Rutgers.
At least the article looks pretty good to me, but it's been a
long time since I did any LISP programming. Anyone feel like
reviewing Wong's review?
Larry Carroll
Jet Propulsion Lab.
larry@jpl-vlsi
------------------------------
Date: Mon, 9 Apr 84 13:03 EST
From: Tom Martin <TJMartin@MIT-MULTICS.ARPA>
Subject: Could it be COMMON LISP?
A announcement just arrived in the mail from Digital Press:
COMMON LISP manual,Guy L. Steele, Jr.
$22.00/May 1,1984/Paperbound/
--Tom Martin
Arthur D. Little, Inc.
------------------------------
Date: Wed 11 Apr 84 09:53:20-PST
From: Ken Laws <Laws@SRI-AI.ARPA>
Subject: What's Happening to Stuffy Old CACM?
I just can't resist passing along these items from Jon Bentley's
column in the April CACM:
The CRAY-3 is so fast that it can execute an infinite loop
in less than two minutes.
Have you heard how [it] implements a branch instruction?
It holds the program counter constant and moves the memory.
If you like those, you'll also like the articles beginning on
page 343. Of particular interest to AIers is "The Chaostron:
An Important Advance in Learning Machines."
-- Ken Laws
------------------------------
Date: Sun, 8 Apr 1984 15:21 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
Subject: Non-competition clauses
Recently a student of mine applied for a position with one of the new AI
companies (I'd rather not say which one) and received what he considers
to be a very attractive offer. Unfortunately, there is one problem that
will probably prevent him from accepting the job: the company requires
him to sign an agreement that if he leaves that company for any reason,
he will not compete with them or work for any competitive business for a
period of three years. In order to keep this agreement in effect, the
company would have to continue to pay him his salary, minus any money he
makes from other employment or consulting. Since this company defines
its business as AI and AI tools in a very broad sense, this means that
they could force the former employee to stay completely out of the field
of AI for three whole years if he leaves them -- an eternity in this
field.
I've heard of companies that require you to promise not to use any
proprietary knowledge on behalf of your next employer (or anyone else),
but I've never heard of an agreement like this one. Since the penalty
for leaving is potentially so high (you get a salary for doing nothing,
but are effectively prohibited from practicing your chosen profession
for a period of time that is long enough for you to go completely
stale), it looks to me like they are trying to make you sign up with
them for life -- at their option, of course.
This company seems to think that this agreement is a perfectly routine
matter and that many companies in AI have similar requirements. Is this
true? Is this sort of thing spreading? Have people out there actually
signed agreements of this sort? Are they legally enforceable? Unless I
hear otherwise, I'm going to consider this as an isolated case of
institutional paranoia on the part of this one company, and will steer
my students away from that company in the future. If everyone is doing
it, that is much more alarming.
-- Scott Fahlman, CMU <fahlman at cmu-cs-c.arpa>
------------------------------
Date: Sun 8 Apr 84 18:14:52-PST
From: Ken Laws <Laws@SRI-AI.ARPA>
Subject: Noncompetition Clauses
This is the first I've heard of the post-employment restrictions
Scott Fahlman mentioned, although I've heard of noncompetition agreements
in other industries. (I believe Nolan Bushnell, for instance, started
Pizza Time Theaters because he couldn't compete with his own creations
at Atari. I've also heard of cases in the giant-screen TV and
restaurant businesses, always part of a buy-out agreement.) The
intention is obviously to stop someone from spinning off his own
company to market an idea developed for the first employer.
Although the clause in question is a strong constraint, I don't see
that it would necessarily bind you to the company for life. Think of
it as a three-year paid sabatical or other grant. It has a built-in
disincentive for taking a job in any other field, but is a real
bonanza for someone who wants to spend time taking courses and
catching up on the literature in the AI field.
As a practical matter, I doubt that the employer would exercise his
option unless you intended to compete directly in the same product
you were working on. It wouldn't make sense to buy you off if you
intended shifting to even a moderately different AI application.
-- Ken Laws
------------------------------
Date: 3 Apr 84 18:04:46-PST (Tue)
From: decvax!cwruecmp!borgia @ Ucb-Vax
Subject: Re: expert system algorithms
Article-I.D.: cwruecmp.1127
Don't we always come back to the same old epistemological question?
What good is any system to a human being unless it is understood
(maybe in parts) by one or more human beings?
An expert system should be an intelligent and articulate student
who learns from several experts. Understanding control structures
is not the critical issue. Well-known and fairly simple inference
mechanisms are available. The key issue is articulating what
knowledge was used and how in solving a problem.
"What good is knowledge when it brings no profit to its bearer"
- Teireisias in Oedipus the King, Sophocles
-- joe borgia
usenet: decvax!cwruecmp!borgia
csnet: borgia@case
arpanet: borgia.case@csnet-relay
------------------------------
Date: Thu, 5 Apr 84 15:57:13 est
From: Michael Listman <mike%brandeis.csnet@csnet-relay.arpa>
Subject: metaphors
I am interested in finding information on the extent of
natural language research and expectations.
In particular, I would like to find out if any research
has been done on comprehension of metaphors. I realize that
this would present problems such as what to do upon
encountering a metaphor that one (or a system) has never
before encountered.
Take as an example,
"Man is a wolf"
- although it seems obvious to a human, how does one know
which aspects of wolf to apply to man?
As another example, how do we know that
"Man is a Bic pen"
is a bad metaphor? Do we exhaust all the features of each ( man
and Bic pen) and decide that not enough of them are similar enough
for a reasonable comparison? This seems plausible, but I could
imagine a situation in a discourse where this or a similar metaphor
would make perfect sense (please don't ask me to).
I believe that in pursuing research in this direction, we
will eventually attain the knowledge to build a psychologically real
natural language understander, which I believe is the only way we
will ever attain a system that can approximate human comprehension.
If anyone can point me toward research in this area, or
references, or simply guess as to where research like this will lead
in the near future (or ever) please respond as soon as possible.
--- Michael Listman
------------------------------
Date: 9 Apr 84 09:28:48 EST
From: DSMITH@RUTGERS.ARPA
Subject: Semiautomated Algorithm Design
[Forwarded from the Rutgers bboard by Laws@SRI-AI.]
Rutgers' Computer Science Colloquium
Semiautomated Algorithm Design
Douglas R. Smith
Algorithm design is viewed as the transformation of a formal specification
of a problem into an algorithm. We present a formal top-down method for
creating hierarchically structured algorithms. The method works as follows: to
design an algorithm A0 for a problem specification P0, the programmer
conjectures the overall structure S of A0, then uses knowledge of the
structure S to deduce subproblem specifications P1,...,Pn for the
underdetermined parts of S. Algorithms A1,...,An are then designed for the
subproblems P1,...,Pn and assembled (via the structure S) into an
algorithm for the initial problem P0. This process results in the
decomposition of the initial problem specification into a hierarchy of
subproblem specifications and the composition of a corresponding
hierarchically structured algorithm. The knowledge used to deduce
specifications for subproblems is obtained by analysis of the particular
structure S and is encoded in a procedure called a design strategy for S.
The top-down design process depends on design strategies for many
different kinds of algorithm structures.
We illustrate this approach by presenting the knowledge needed to
synthesize a class of divide and conquer algorithms and by deriving a
quicksort algorithm. Our examples are drawn from experiments with an
implemented algorithm design system called CYPRESS. Current efforts to
systematically acquire design strategies for fundamental classes of
algorithms will be discussed.
DATE: Thursday, April 12, 1984
TIME: 10:30 a.m.
PLACE: Hill Center - Room 705
* Coffee will be served at 10:00 a.m.
------------------------------
Date: 9 Apr 1984 14:15 EST (Mon)
From: "Daniel S. Weld" <WELD%MIT-OZ@MIT-MC.ARPA>
Subject: Engineering Problem Solving
[Forwarded from the MIT bboard by SASW@MIT-MC.]
AI Revolving Seminar
Wednesday, April 11, 4:00pm 8th floor playroom
Jerry Roylance -- "Programs that Design Circuits"
People can design circuits; this task -- at least partially --
can be done by computers. I'll talk about how designers think about
circuits and how to make computers think that way, too. While the talk
will be directed toward circuit design, that is not the sole intent.
How will building problem solvers in one engineering domain help us
build them in other domains? What "domain-independent" facts can be
carried across?
Engineering domains (such as circuit design) are good ones to
teach computers. They have well defined models that let the machine
verify and debug its designs (thus allowing some chance at creativity).
Engineering domains also have many "standard problems" with cookbook
solutions. If the computer can be clever about recognizing instances of
these problems and combining them together, it can produce nontrivial
designs. The quality of a design in an engineering domain is also easy
to assess.
The circuit design domain is not simple, however. Hierarchical
expansion of abstract components fails to account for many designs. The
parts of a design are not independent and that makes it difficult for
the knowledge sources to be modular. Arithmetic constraints solve some
of these problems; some others can be solved by manipulating mechanism
constraints.
An important perspective: when teaching a system a new trick,
find out why the some one thought of that trick in the first place.
------------------------------
End of AIList Digest
********************
