Copy Link
Add to Bookmark
Report
AIList Digest Volume 5 Issue 259
AIList Digest Thursday, 5 Nov 1987 Volume 5 : Issue 259
Today's Topics:
Queries - Creativity & Adaptive Systems & Coarse Coding &
PROLOG for Various Machines,
AI Tools - FORTRAN,
Bibliographies - Classification Systems,
Applications - Natural Language Interfaces
----------------------------------------------------------------------
Date: 04 Nov 87 13:27:02 PST
From: oxy!hurley@csvax.caltech.edu (Mark Luke Hurley)
Subject: Creativity
I am a cognitive science major at Occidental College. I am presently
writing my senior thesis on the creative computational systems. I want
to examine the ability of automatic formal systems to capture various
forms of creativity including, but not limited to, artistic creativity,
problem solving, and music composition. I would appreciate any
suggestions or advice about specific literature in this area. I welcome
any leads you can give me that might help in my research.
Thank you.
Mark Hurley
Box 437
1600 Campus Rd.
Occidental College
Los Angeles, CA 90041
ARPANET: oxy!hurley@CSVAX.Caltech.EDU
BITNET: oxy!hurley@hamlet
CSNET: oxy!hurley%csvax.caltech.edu@RELAY.CS.NET
UUCP: ....{seismo, rutgers, ames}!cit-vax!oxy!hurley
------------------------------
Date: 2 Nov 87 17:36:11 GMT
From: stride!tahoe!unrvax!oppy@gr.utah.edu (Brian Oppy)
Subject: references for adaptive systems
i think the header summarizes this pretty well. what i am looking for are
references in the scientific literature, preferably journals, and as recent
as possible. the direction i wish to go with this is toward learning systems,
equivalences in the way computers and biological organisms learn.
thanks in advance for any help you can offer,
brian oppy (oppy@unrvax)
------------------------------
Date: 2 Nov 87 12:26:13 GMT
From: berke@locus.ucla.edu
Subject: "2**n events using only n units" references? (from Berke)
Many connectionist researchers have asserted that a
distributed representation provides efficient use of resources,
encoding 2**n patterns in n units. The "2**n states for
n units" argument is sketched below:
Replace unit-encoding (grandmother cells) with patterns of
activation over n (binary) units. Instead of representing only
n distinct "events," one with each unit, we can represent up to
2**n events using only n units. These patterns overlap, and
this overlap can be used to gain "associative" recall.
Does anyone have any references to such arguments? I've
heard this argument made verbally, but I don't recall exact
references in print. Do you? Also, is there a net-convention
for 2 to-the-n? I'm using 2**n above, (a vestige of my early
FORTRAN experience?) which I prefer to 2^n. Anyone have any
others?
Perhaps it would be appropriate to "r" a reply to me
rather than posting a follow-up to net. If they are many or
interesting, I'll be sure to post them in one batch.
I would appreciate exact quotes, with references
including page numbers so that I could find the, as the NLP
people say, context.
Thanks
Pete
------------------------------
Date: Tue, 3 Nov 87 01:05 MST
From: DOLATA@rvax.ccit.arizona.edu
Subject: PROLOG for various machines
I have an IRIS 3130, a microVAX II running ULTRIX, and an NCUBE-4
parallel machine (along with a Mac II coming). I am looking for
a PROLOG system to run on all of my machines. I want the system
to have the same syntax on all machines, and the ability to link in
C and Fortran code for some number crunching. I will probably need
a system which is avaialble in source rather than executable products
since the software house which develops code for the NCUBE doesn't
know of any NCUBE prolog (per se').
Anybody know of such a beast? If not, whats the next best bet?
(If you reply to AIlist, please cc: directly to me too)
Thanks
Dan (dolata@rvax.ccit.arizona.edu)
------------------------------
Date: 1 Nov 87 08:38:52 GMT
From: psuvax1!vu-vlsi!swatsun!hirai@husc6.harvard.edu (Eiji "A.G."
Hirai)
Subject: Re: Suggestions for Course
In article <1746@unc.cs.unc.edu> bts@unc.UUCP (Bruce Smith) writes:
>Turbo Prolog for an AI course? Why not FORTRAN, for that matter?
>Quoting (without permission) from Alan Bundy's Catalog of AI Tools:
>
> FORTRAN is the programming language considered by many to
> be the natural successor of LISP and Prolog for AI research.
This must be some very sick joke or this book you quoted from
is majorly screwed up. Fortran is bad for almost anything, least of
all AI. There are zillion plus one articles which will support me in
attacking Fortran, so I won't list or quote them here.
Fortran is EVIL. You were kidding right? Please say you're kidding.
--
Eiji "A.G." Hirai @ Swarthmore College, Swarthmore PA 19081 | Tel. 215-543-9855
UUCP: {rutgers, ihnp4, cbosgd}!bpa!swatsun!hirai | "All Cretans are liars."
Inter: swatsun!hirai@bpa.bell-atl.com | -Epimenides
Bitnet: vu-vlsi!swatsun!hirai@psuvax1.bitnet | of Cnossus, Crete
------------------------------
Date: 2 Nov 87 17:14:56 GMT
From: nau@mimsy.umd.edu (Dana S. Nau)
Subject: Re: Suggestions for Course
In article <1746@unc.cs.unc.edu> bts@unc.UUCP (Bruce Smith) writes:
>Turbo Prolog for an AI course? Why not FORTRAN, for that matter? ...
In article <1361@byzantium.swatsun.UUCP> hirai@swatsun.UUCP writes:
> [lots of flames about FORTRAN]
To me, it seemed obvious that the original posting was a joke--in fact, a
rather good one. Too bad it got taken seriously.
--
Dana S. Nau ARPA & CSNet: nau@mimsy.umd.edu
Computer Sci. Dept., U. of Maryland UUCP: ...!seismo!mimsy!nau
College Park, MD 20742 Telephone: (301) 454-7932
------------------------------
Date: Mon 2 Nov 87 14:29:09-PST
From: Ken Laws <LAWS@IU.AI.SRI.COM>
Subject: In Defense of FORTRAN
Eiji Hirai asks whether FORTRAN is seriously considered an AI language.
I'm certain that Alan Bundy was joking about it. That leaves an opening
for a serious defender, and I am willing to take the job. Other languages
have already been much touted and debated in AIList, so FORTRAN deserves
equal time.
Many expert system companies have found that they must provide their
end-user programs in C (or occasionally PASCAL or some other traditional
language). A few such companies actually prefer to do their development
work in C. There are reasons why this is not insane. The same reasons
can be made to apply to FORTRAN, providing that one is willing to consider
a few language extensions. They apply with even more force to ADA, which
may succeed in giving us the sharable subroutine libraries that have been
promised ever since the birth of FORTRAN. I will concentrate on C because
I know it best.
The problem with traditional languages is neither their capability nor
their efficiency, but the way that they limit thought. C, after all,
can be used to implement LISP. A C programmer may be more comfortable
growing the tail end of a dynamic array than CONSing to the head of
a list, but that is simply an implementation option that should be
hidden within a package of list-manipulation routines. (Indeed, the
head/tail distinction for a 1-D array is arbitrary.) Languages that
permit pointer manipulation and recursive calls can do just about
anything that LISP or PROLOG can. (Dynamic code modification is
possible in C, although exceedingly difficult. It could be made more
palatable if appropriate parsing and compilation subroutines were made
available.)
My own definition of an "AI" program is any program that would never
have been thought of by a FORTRAN/COBOL programmer. (The past tense
is significant, as I will discuss below.) FORTRAN-like languages
are thus unlikely candidates for AI development. Why should this
be so? It is because they designed for low-level manipulations (by
modern standards) and are clumsy for expressing high-level concepts.
C, for instance, is so well suited to manipulating character strings
that it is unusual to find a UNIX system with an augmented library of
string-parsing routines. It is just so much easier to hack an
efficient ad hoc loop than to document and maintain a less-efficient
general-purpose string library that the library never gets written.
String-manipulation programs do exist (editors, AWK, GREP, etc.), but
the intermediate representations are not available to other than
system hackers.
FORTRAN, with its numeric orientation, is even more limiting. One can
write string-parsing code, but it is difficult. I suspect that string
libraries are therefore more available in FORTRAN, a step in the right
direction. People interested in string manipulation, though, are more
likely to use SNOBOL or some other language -- almost any other language.
FORTRAN makes numerical analysis easy and everything else difficult.
Suppose, though, that FORTRAN and C offered extensive "object oriented"
libraries for all the data types you were likely to need: lists, trees,
queues, heaps, strings, files, buffers, windows, points, line segments,
robot arms, etc. Suppose that they also included high-level objects
such as hypotheses, goals, and constraints. (These might not be just
what you needed, but you could use the standard data types as templates
for making your own.) These libraries would then be the language in
which you conduct your research, with the base language used only to
glue the subroutines together. A good macro capability could make the
base+subroutine language more palatable for specific applications,
although there are drawbacks to concealing code with syntactic sugar.
Given the appropriate subroutine libraries, there is no longer a mental
block to AI thought. A FORTRAN programmer could whip together a
backtrack search almost as fast as a PROLOG programmer. Indeed,
PROLOG would be a part of the FORTRAN environment. Current debugging
tools for FORTRAN and C are not as good as those for LISP machines,
but they are adequate if used by an experienced programmer. (Actually,
there are about a hundred types of FORTRAN/COBOL development tools
that are not commonly available to LISP programmers. Their cost and
learning time limit their use.) The need for garbage collection can
generally be avoided by explicit deallocation of obsolete objects
(although there are times when this is tricky). Programming in a
traditional language is not the same as programming in LISP or PROLOG,
but it is not necessarily inferior.
The problem with AI languages is neither their capability nor
their efficiency, but the way that they limit thought. Each makes
certain types of manipulations easy while obscuring others.
LISP is a great language for manipulating lists, and lists are an
exceptionally powerful representation, but even higher level constructs
are needed for image understanding, discourse analysis, and other
areas of modern AI research. No language is perfectly suited for
navigating databases of such representations, so you have to choose
which strengths and weaknesses are suited to your application.
If your concern is with automating intelligent >>behavior<<,
a traditional algorithmic language may be just right for you.
-- Ken Laws
------------------------------
Date: 4 Nov 87 15:55:46 GMT
From: ssc-vax!dickey@beaver.cs.washington.edu (Frederick J Dickey)
Subject: Re: AIList V5 #253 - LISP, NIL, Msc.
In article <MINSKY.12346702081.BABYL@MIT-OZ>, MINSKY@OZ.AI.MIT.EDU writes:
> In reply to noekel@uklirb.UUCP who is
> >
> >currently building a AI bibliography and still searching for a
> >suitable classification/key word scheme.
In "The AI Magazine" a couple of years ago, there was an article that presented
an AI classification scheme. If my memory serves me right, the author of the
article says he developed it for some sort of library/information retrieval
application. It sounds like it is fairly close to what noekel@uklirb wants.
I can't give a more specific citation because my collection of AI Magazines
is at home.
------------------------------
Date: 5 Nov 87 04:58:00 GMT
From: crawford@endor.harvard.edu (Alexander Crawford)
Subject: Re: The future of AI.... (nothing about flawed minds)
The first impact from AI on software in general will be natural
language interfaces. Various problems need to be solved, such as how
to map English commands completely onto a particular application's set
of commands COMPLETELY. (As Barbara Grosz says, if it can be said, it
can be said in all ways, e.g. "Give me the production report",
"Report", "How's production doing?".) Once this is completed for a
large portion of applications, it will become a severe disadvantage in
the marketplace NOT to offer a natural-language interface.
Coupled with a NLI, machine-learning will allow applications to
improve in different ways as they are used:
-Interfaces can be customized easily, automatically, for
different users.
-Complex tasks can be learned automatically by having the
application examine what the human operator does normally.
-Search of problem spaces for solutions can be eliminated and
replaced by knowledge. (This is called "chunking". See
MACHINE LEARNING II, Michalski et al. Chapter 10:
"The Chunking of Goal Hierarchies: A Generalized Model of
Practice" by Rosenbloom and Newell.)
-Alec (crawford@endor.UUCP)
------------------------------
End of AIList Digest
********************
