Copy Link
Add to Bookmark
Report
AIList Digest Volume 4 Issue 074
AIList Digest Thursday, 10 Apr 1986 Volume 4 : Issue 74
Today's Topics:
Policy - Discussion Style & Professional Ethics & Press Releases,
Programming Languages - LetS Lisp Loop Notation
----------------------------------------------------------------------
Date: Thu, 3 Apr 86 11:52:18 GMT
From: gcj%qmc-ori.uucp@cs.ucl.ac.uk
Subject: Less on IQ tests for Computers, more on Editorial Policy?
Scott Preece asks in Vol 4 # 66 :-
``Do we really want this list to be a battleground for unsubstantiated
personal opinions on the potential for machine intelligence?'' Agreed
that this a moderated digest, it is interesting to note that the net.ai
forum is currently carrying a discussion of the cognitive (and emotional)
abilities of an arbitrarily large number of toasters. Here is an example:-
> In article <2345@jhunix.UUCP> ins_akaa@jhunix.UUCP (Ken Arromdee) writes:
> >You are actually quite correct. There's one problem here. Toasters can
> >store perhaps two or three bytes of information. Consider how many
> >toasters would be required to be as complex as a human brain.
> >
> >And as for the future toasters, toasters' primary function is to affect
> >items of a definite physical size (toast).
> >--
> >Kenneth Arromdee
>
> Gee, I always thought that toasters' primary function was to affect
> items of a definite physical size (bread).
> --
>
> When you meet a master swordsman,
> show him your sword.
> When you meet a man who is not a poet,
> do not show him your poem.
> - Rinzai, ninth century zen master
>
> --Nathan Hess
> uucp: {allegra, ihnp4}!psuvax1!gondor!hess
> csnet: hess@penn-state.CSNET
> Bitnet: HESS@PSUVAXG.BITNET
I would also like to extract this from the List_of_Lists :-
> Contributions may be anything from tutorials to rampant speculation. In
> particular, the following are sought:
> Abstracts Reviews
> Lab Descriptions Research Overviews
> Work Planned or in Progress Half-Baked Ideas
> Conference Announcements Conference Reports
> Bibliographies History of AI
> Puzzles and Unsolved Problems Anecdotes, Jokes, and Poems
> Queries and Requests Address Changes (Bindings)
The poetry of Rinzai is illuminating, cf Vol 4 # 50,53, and very apt.
Gordon Joly
ARPA: gcj%qmc-ori@ucl-cs.arpa
UUCP: ...!ukc!qmc-cs!qmc-ori!gcj
[I am unable to follow the logic of this message, but find it
easier (and faster!) to let it pass than to engage in editorial
debate with Gordon. Contributors should note that it is they,
not I, who control the quality of AIList. My thanks to you
all; keep up the good work. -- KIL]
------------------------------
Date: Fri, 4 Apr 86 12:53:55 GMT
From: gcj%qmc-ori.uucp@cs.ucl.ac.uk
Subject: World Times, April 1, 2284.
A special analysis of the entries in the AI Digests of the
mid 1980's has shown that all the entries written by "The
Joka" were the products of an automated intelligent system.
This result is regarded by some as an interesting twist on
the Turing test.
Other News.
Today the World's first trial by computer was held. The jury
consisted of 12 independent intelligent systems and they sat
at the World Court in the U.N. The jury returned it's first
verdict after a few seconds, and the judge commented on the
impartiality of the jurors, unclouded by any emotion or form
of prejudice. On trial was the off-world outlaw, Roy Baty...
Reporter : PiQuan.
------------------------------
Date: Thu, 3 Apr 86 9:38:45 CST
From: Glenn Veach <veach%ukans.csnet@CSNET-RELAY.ARPA>
Subject: Professional ethics.
Over the past several months I have been receiving the AIList, and
I must take this time to express some concerns of mine. I have seen
several "policy notices" and debates raging where the authors have
lowered themselves to the level of the "ad homina"(sp?) attack.
One should have more substantive comments if one wishes to express
criticism, and not resort to personal attacks.
I am in no way opposed to healthy debate, even if it should become
heated. However, there seems to be some dislike, on the part of many,
of pointed criticism. I wish to admonish those who take part in
this medium of intellectual exchange to express a little more common
courtesy and professional ethic, if indeed either of these still
remain. Let's drop the name-calling.
I personally welcome criticism of AI, even if it (the criticism) may
be in left field. After all, many think we are in left field, while
we may hold that they are in left field. So, exactly where is left
field? Perhaps it is dependent on ones own position? Also, we should
remember that this is a monitored digest. I personally trust the
discretion of Ken, who I think does a good job, to weed out any
inappropriate notices. Thus, I would love to see this list continue
to announce various product and research development, whether it be
presented by a party directly involved in the development or someone
farther removed. As long as it is not out and out advertisement, I,
as well as others (I think), am interested in such postings.
Enough for now...
Glenn O. Veach
Artificial Intelligence Laboratory
Department of Computer Science
University of Kansas
Lawrence, KS 66045-2192
(913) 864-4482
veach%ukans.csnet@csnet-relay.csnet
------------------------------
Date: Wed 9 Apr 86 10:50:34-PST
From: Pat Hayes <PHayes@SRI-KL>
Subject: Re: AIList Digest V4 #70
Part of this AIlist reads perilously like an advertisement, even though it is
protected by Les Earnest's mention. Do we have to have whole 'product
descriptions' ( ie advertising brochures ) put out over the net? Isn't that
( just slightly ) illegal?
Pat Hayes
------------------------------
Date: Sun 16 Mar 86 22:01:03-PST
From: Ken Laws <Laws@SRI-AI.ARPA>
Subject: Policy - Press Releases
A press release typically contains factual information; the cost of
transmitting it is small. Is it not always in the government's
interest for me to pass on the information to those who may need it
rather than to censor it (to avoid annoying those who don't)?
Early net organizers were no doubt [rightly] worried about corporate
PR departments broadcasting unwanted press releases to everyone on
the net. The situation has changed. A press release judged appropriate
for a narrow-topic discussion list by its moderator is unlikely to
offend many (other than self-appointed censors) or to seriously
waste the time of the list members. It will not mislead readers so long
as it is clearly marked as a commercial message. The inherent bias of
such messages is mitigated by the opportunity for immediate rebuttal
and for submission of equally biased messages supporting other views.
Any resulting controversy sparks interest and keeps the list active.
Outright flaming or numbing repetition can be prevented by the moderator.
If the moderator fails to intervene, comments from disgruntled readers
will fill his (or her) mailbox and eventually become a metadiscussion
within the list itself. Readers who get tired of all this can drop out.
My view is that policy on commercial content (hardware hype, job ads,
prices, whatever) within a discussion list should be set by the
moderator and the list members -- not by conventions required for
unmoderated message streams. The Arpanet administrators and host
administrators will always hold the trump, of course; they can refuse
to support any list that violates >>their<< standards.
-- Ken Laws
------------------------------
Date: Fri, 28 Mar 1986 15:56 EST
From: Dick@MC.LCS.MIT.EDU
Subject: LetS -- a new Lisp loop notation
[Forwarded from the MIT bboard by Laws@SRI-AI.]
This message advertises a Common Lisp macro package called LetS (rhymes with
process) which it is hoped will become a standard iteration facility in Common
Lisp. LetS makes it possible to write a wide class of algorithms which are
typically written as loops in a functional style which is similar to
expressions written with the Common Lisp sequence functions. LetS supports a
number of features which make LetS expressions more expressive than sequence
expressions. However, the key feature of LetS is that every LetS expression is
automatically transformed into an efficient iterative loop. As a result,
unlike sequence expressions, LetS expressions are just as efficient as the
traditional loop expressions they replace.
An experimental version of LetS currently exists on the MIT-AI machine in the
file "DICK;LETS BIN". Although LetS is written in Common Lisp, it has not yet
been tested on anything other than a Symbolics Lisp Machine. For various
detailed reasons it is unlikely to run on any other machine. Everyone who
wants to is invited to borrow this file and try LetS out. I am very
interested to hear any and all comments on LetS.
Extensive documentation of LetS is in the file "DICK;LETSD >" also on the
MIT-AI machine. Even people who do not have a Lisp Machine or are not able
to access the code are invited to read this documentation and make comments on
it. I am interested in getting as wide a feedback as possible. If you cannot
access the documentation file directly, send me your US mail address and I will
mail you a copy. The documentation is much too long to reliably send via
computer mail.
After an initial testing and feedback period, a final version of LetS which
runs under all Common Lisps will be created along with formal documentation.
This should happen within a couple of months.
A very brief summary of lets is included at the end of this message.
Dick Waters
The advantages (with respect to conciseness, readability, verifiability and
maintainability) of programs written in a functional style are well known. A
simple example of the clarity of the functional style is provided by the
Common Lisp program below. This function computes the sum of the positive
elements of a vector.
(defun sum-pos-vect (v)
(reduce #'+ (remove-if-not #'plusp v)))
A key feature of sum-pos-vect is that it makes use of an intermediate
aggregate data structure (a sequence) to represent the selected set of vector
elements. The use of sequences as intermediate quantities in computations
makes it possible to use functional composition to express a wide variety of
computations which are usually represented as loops. Unfortunately, as
typically implemented, sequence expressions are extremely inefficient.
The problem is that straightforward evaluation of a sequence expression
requires the actual creation of the intermediate sequence objects. Since
alternate algorithms using loops can often compute the same result without
creating any intermediate sequences, the overhead engendered by using sequence
expressions is quite reasonably regarded as unacceptable in many situations.
A solution to the problem of the inefficiency of sequence expressions is to
transform them into iterative loops which do not actually create any
intermediate sequences before executing them. For example, sum-pos-vect might
be transformed as shown below.
(defun sum-pos-vect-transformed (v)
(prog (index last sum element)
(setq index 0)
(setq last (length v))
(setq sum 0)
L (if (not (< index last)) (return sum))
(setq element (aref v index))
(if (plusp element) (setq sum (+ element sum)))
(setq index (1+ index))
(go L)))
Several researchers have investigated the automatic transformation of
sequence expressions into loops. For example, APL compilers transform many
kinds of sequence expressions into loops.
Unfortunately, there is a fundamental problem with the transformation of
sequence expressions into loops. Although many sequence expressions can be
transformed, many cannot. For example, Common Lisp provides a sequence
function (reverse) which reverses the elements in a sequence. Suppose that a
sequence expression enumerates a sequence, reverses it, and then reduces it to
some value. This sequence expression cannot be computed without using
intermediate storage for the enumerated sequence because the first element of
the reversed sequence is taken from the last element of the enumerated
sequence. There is no way to transform the sequence expression into an
efficient loop without eliminating the reverse operation.
A solution to the problems caused by the presence of non-transformable
sequence operations is to restrict the kinds of sequence operations which
are allowed so that every sequence expression is guaranteed to be
transformable. For example, one could start by outlawing the operation
reverse.
LETS
LetS supports a wide class of sequence expressions that are all guaranteed
to be transformable into efficient loops. In order to avoid confusion with
the standard Common Lisp data type sequence, the data type supported by LetS
is called a series.
Using LetS the program sum-pos-vect would be rendered as shown below. The
function Evector converts the vector v into a series which contains the same
elements in the same order. The function Tplusp is analogous to
(remove-if-not #'plusp ...) except that it operates on a series. The function
Rsum corresponds to (reduce #'+ ... :initial-value 0) except that it takes in
a series as its argument.
(defun sum-pos-vect-lets (v)
(Rsum (Tplusp (Evector v))))
LetS automatically transforms the body of this program as shown below. The
readability of the transformed code is reduced by the fact that it contains a
large number of gensymed variables. However, the code is quite efficient.
The only significant problem is that too many variables are used. (For
example, the variable #:vector5 is unnecessary.) However, this problem need
not lead to inefficiency during execution as long as a compiler which is
capable of simple optimizations is available.
(defun sum-pos-vect-lets-transformed (v)
(let (#:index12 #:last4 #:sum21 #:element11 #:vector5)
(tagbody (setq #:vector5 v)
(setq #:index12 0)
(setq #:last4 (length #:vector5))
(setq #:sum21 0)
#:p0 (if (not (< #:index12 #:last4)) (go #:e9))
(setq #:index12 (1+ #:index12))
(setq #:element11 (aref #:vector5 #:index12))
(if (not (plusp #:element11)) (go #:p0))
(setq #:sum21 (+ #:element11 #:sum21))
(go #:p0)
#:e9)
#:sum21))
RESTRICTIONS ENFORCED BY LETS
The key aspect of LetS is that it enforces a palatable (and not overly
strict) set of easily understandable restrictions which guarantee that every
series expression can be transformed into a highly efficient loop. This
allows programmers to write series expressions which are much easier to work
with than the loops they might otherwise write, without suffering a decrease
in efficiency.
There are two central restrictions which are enforced by LetS. First, every
series must be statically identifiable so that transformation can occur at
compile time rather than at run time. Second every series function is
required to be "in-order". A series function is said to be in-order if it
reads each input series in order, one element at a time, starting from the
first one, and if it creates the output series (if any) in order, one element
at a time, starting from the first one. In addition, the function must do
this without using internal storage for more than one element at a time for
each of the input and output series. For example, the series functions
Evector, Tplusp, and Rsum are all in-order. In contrast, the function reverse
is not in-order. (Reverse either has to read the input in reverse order, or
save up the elements until the last one is read in.)
OTHER FEATURES OF LETS
Although efficiency is the main goal of LetS, LetS supports a number of
features which are not directly related to efficiency per se. Most notable of
these is implicit mapping of functions over series. Whenever an ordinary Lisp
function is syntactically applied to a series, it is automatically mapped over
the elements of the series.
The following example illustrates implicit mapping. In the function below,
the computation "(lambda (x) (expt (abs x) 3))" is implicitly mapped over the
series of numbers generated by Evector. Implicit mapping of this sort is a
commonly used feature of APL and is extremely convenient.
(defun sum-cube-abs-vect (v)
(Rsum (expt (abs (Evector v)) 3)))
(sum-cube-abs-vect #(1 -2 3)) => (+ 1 8 27) => 36
New series functions can be defined by using the form defunS. The following
example shows how the function Rsum could be defined. More complex forms can
be defined by using the ordinary Common Lisp macro definition facilities to
define macros which create appropriate series expressions.
(defunS Rsum (numbers)
(declare (series numbers))
(reduceS #'+ 0 numbers))
LetS provides two forms (LetS and LetS*) which are analogous to let and
let*. As shown in the example below, These forms can be used to bind both
ordinary variables (e.g., num-obs, mean, and deviation) and series variables
(e.g., ob). Whether or not a variable is a series is determined
by looking at the type of value produced by the expression which computes
the value bound to it.
(defun mean-and-deviation (observations)
(letS* ((ob (Elist observations))
(num-obs (Rlength ob))
(mean (/ (Rsum ob) num-obs))
(deviation (- (/ (Rsum (expt ob 2)) num-obs) (expt mean 2))))
(list mean deviation)))
The complete documentation of LetS compares LetS with the Common Lisp
sequence functions and with the Zeta Lisp Loop macro. LetS supports
essentially all of the functionality of the Loop macro in a style which looks
like sequence functions and which is exactly as efficient as the loop macro.
THE ANCESTRY OF LETS
The LetS package described here is descended from an earlier package of the
same name (See MIT/AIM-680a and "Expressional Loops", Proc. Eleventh ACM
SIGACT-SIGPLAN Symposium on the Principles of Programming Languages, January
1984). The current system differs from the earlier system in a number of
ways. In particular, the new system supports a much wider set of features.
------------------------------
End of AIList Digest
********************
