Copy Link
Add to Bookmark
Report

AIList Digest Volume 2 Issue 060

eZine's profile picture
Published in 
AIList Digest
 · 15 Nov 2023

AIList Digest            Monday, 21 May 1984       Volume 2 : Issue 60 

Today's Topics:
AI Literature - Artificial Intelligence Abstracts,
Survey - Summary on AI for Business,
AI Tools - LISP on PCs & Boyer-Moore Prover on VAXen and SUNs,
Games - Core War Software,
AI Tools - Display-Oriented LISP Editors
----------------------------------------------------------------------

Date: Sun 20 May 84 14:10:16-EDT
From: MDC.WAYNE%MIT-OZ@MIT-MC.ARPA
Subject: Artificial Intelligence Abstracts

Does anyone else on this list wish, as I do, that there
existed a publication entitled ARTIFICIAL INTELLIGENCE
ABSTRACTS? The field of artificial intelligence is probably the
supreme interdisciplinary sphere of activity in the world, and
its vital concerns extend across the spectrum of computer
science, philosophy, psychology, biology, mathematics, literary
theory, linguistics, statistics, electrical engineering,
mechanical engineering, etc.

I wonder if one of the major member publishers of the NFAIS
(National Federation of Abstracting & Indexing Services) could
be convinced to undertake the publication of a monthly
reference serial which would reprint from the following
abstracting services those abstracts which bear most
pertinently on the concerns of AI research:

Biological Abstracts / Computer & Control Abstracts /
Computer & Information Systems Abstracts Journal / Current
Index to Journals in Education / Dissertation Abstracts
International / Electrical & Electronics Abstracts /
Electronics & Communications Abstracts Journal / Engineering
Index / Government Reports Announcements and Index /
Informatics Abstracts / Information Science Abstracts /
International Abstracts in Operations Research / Language and
Language Behavior Abstracts / Library & Information Science
Abstracts / Mathematical Reviews / Philosopher's Index / PROMT
/ Psychological Abstracts / Resources in Education / (This is
by no means a comprehensive list of relevant reference
publications.)

Would other people on the list find an abstracting service
dedicated to AI useful? Perhaps an initial step in developing
such a project would be to arrive at a consensus regarding what
structure of research fronts/subject headings appropriately
defines the field of AI.

--Wayne McGuire

------------------------------

Date: Fri, 18 May 84 15:29:35 pdt
From: syming%B.CC@Berkeley
Subject: Summary on AI for Business

This is the summary of the responses to my request about "AI for Business" one
month ago on AIList Digest.

Three organizations are working on this area. They are Syntelligence, SRI, and
Arthur D. Little, Inc..

Syntelligence's objective is to bring intelligent computer systems for
business. Currently the major work is in finance area. The person to contact is:
Peter Hart, President, 800 Oak Grove Ave, Suite 201, Menlo Park, CA 94025.
(415) 325-9339, <HART@SRI-AI.ARPA>

SRI has a sub-organization called Financial Expert System Program headed by
Sandra Cook, (415) 859-5478. A prototype system for a financial application
has been constructed. <SANDRA@SRI-KL.ARPA>

Arthur D. Little are developing AI-based MRP, financial planning, strategic
planning and marketing system. However, I do not have much information yet.
The person to contact with is Tom Martin. <TJMartin@MIT-MULTICS.ARPA>
The Director of AI at Arthur D. Little, Karl M. Wiig, gave an interesting
talk on "Will Artificial Intelligence Provide The Rebirth of Operations
Research?" at TIMS/ORSA Joint National Meeting in San Francisco on May 16.
In his talk, a few projects in ADL are mentioned. If interested, write to
35/48 Acorn Park, Cambridge, MA 01240.

Gerhard Friedrich of DEC also gave a talk about expert systems on TIMS/ORSA
meeting on Tuesday. He mentioned XSEL for sales, XCON for engineering, ISA,
IMACS and IBUS for manufacturing and XSITE for customer services. XCON is
successor of R1, which is well known. XSEL was published in Machine Intelligence
Vol.10. However, I do not know the references for the rest. If you know, please
inform me.

The interests on AI in Business community is just started. TIMS is probably the
first business professional society who will form a interest group on AI. If
interested, please write to W. W. Abendroth, P.O. Box 641, Berwyn, PA 19312.


The people who have responsed to my request and shown interests are:
---------------------------------------------------
SAL@COLUMBIA-20.ARPA
DB@MIT-XX.ARPA
Henning.ES@Xerox.ARPA
brand%MIT-OZ@MIT-MC.ARPA
NEWLIN%upenn.csnet@csnet-relay.arpa
shliu%ucbernie@Berkeley.ARPA
klein%ucbmerlin@Berkeley.ARPA
david%ucbmedea@Berkeley.ARPA
nigel%ucbernie@Berkeley.ARPA
norman%ucbernie@Berkeley.ARPA
meafar%B.CC@Berkeley.ARPA
maslev%B.CC@Berkeley.ARPA
edfri%B.CC@Berkeley.ARPA
------------------------------------------------------

Please inform me if I made any mistake on above statements. Keep in touch.

syming hwang, syming%B.CC@Berkeley.ARPA, (415) 642-2070,
350 Barrows Hall, School of Business Administration,
U.C. Berkeley, Berkeley, CA 94720

------------------------------

Date: Tue, 15 May 84 10:25 EST
From: Kurt Godden <godden%gmr.csnet@csnet-relay.arpa>
Subject: LISP machines question

To my knowledge, the least expensive PC that runs LISP is the Atari.
Sometime during the past year I read a review in Creative Computing of
an Interlisp subset that runs on the Atari family. The reviewer was
Kenneth Litkowski and his overall impression of the product was favorable.
-Kurt Godden
General Motors Research Labs

------------------------------

Date: 14-May-84 23:07:56-PDT
From: jbn@FORD-WDL1.ARPA
Subject: Boyer-Moore prover on VAXen and SUNs

[Forwarded from the Stanford bboard by Laws@SRI-AI.]

For all theorem proving fans, the Boyer-Moore Theorem Prover has now
been ported to VAXen and SUNs running 4.2BSD Unix. Boyer and Moore ported
it from TOPS-20 to the Symbolics 3600; I ported it from the 3600 to the
VAX 11/780, and it worked on the SUN the first time. Vaughn Pratt has
a copy. Performance on a SUN 2 is 57% of a VAX 11/780; this is quite
impressive for a micro.
Now when a Mac comes out with some real memory...

Nagle (@SCORE)

------------------------------

Date: Sunday, 20 May 1984 23:23:30 EDT
From: Michael.Mauldin@cmu-cs-cad.arpa
Subject: Core War

[The Scientific American article referred to below is an entertaining
description of software entities that crawl or hop through an address
space trying to destroy other such entities and to protect themselves
against similar depredations. Very simple entities are easy to protect
against or to destroy, but are difficult to find. Complex entities
(liveware?) have to be able to repair themselves more quickly than
primitive entities can eat away at them. This leads to such oddities
as a redundant organism that switches its consciousness between bodies
after verifying that the next body has not yet been corrupted. -- KIL]


If anybody is interested in the May Scientific American's Computer
Recreations article, you may also be interested in getting a copy
of the CMU version of the Redcode assembler and Mars interpreter.

I have written a battle program which has some interesting implications
for the game. The program 'mortar' uses the Fibonacci sequence to
generate a pseudo-random series of attacks. The program spends 40% of
its time shooting at other programs, and finally kills itself after
12,183 cycles. Before that time it writes to 53% of memory and is
guaranteed to hit any stationary program larger than 10 instructions.

Since the attacks are random, a program which relocates itself has no
reason to hope that the new location is any safer than the old one.
Some very simplistic mathematical analysis indicates that while
Dwarf should kill Mortar 60% of the time (this has been verified
empirically), no non-repairing program of size 10 or larger can beat
Mortar. Furthermore, no self-repairing program of size 141 can beat
Mortar. I believe that this last result can be tightened significantly,
but I haven't looked at it too long yet. I haven't written this up,
but I might be cajoled into doing so if many people are interested.
I would very much like to see some others veryify/correct these results.

========================================================================
Access information:
========================================================================

The following Unix programs are available:
mars - A redcode simulator, written by Michael Mauldin
redcode - A redcode assembler, written by Paul Milazzo

Battle programs available:
dwarf, gemini, imp, mortar, statue.

Userid "ftpguest" with password "cmunix" on the "CMU-CS-G" VAX has access
to the Mars source. The following files are available:

mlm/rgm/marsfile ; Single file (shell script)
mlm/rgm/srcmars/* ; Source directory

Users who cannot use FTP to snarf copies should send mail requesting
that the source be mailed to them.
========================================================================

Michael Mauldin (Fuzzy)
Department of Computer Science
Carnegie-Mellon University
Pittsburgh, PA 15213
(413) 578-3065, mauldin@cmu-cs-a.

------------------------------

Date: 11 May 84 7:00:35-PDT (Fri)
From: hplabs!hao!seismo!cmcl2!lanl-a!cib @ Ucb-Vax
Subject: Re: wanted: display-oriented interlisp structure editor
Article-I.D.: lanl-a.7072

Our system is ISI-Interlisp on a UNIX VAX, and I normally use
emacs to edit Interlisp code. emacs can be called with the
LISPUSERS/TEXTEDIT program. It needs a minor patch to be able
to handle files with extensions. I can give further details by
mail if you are interested.

------------------------------

Date: 8 May 84 13:32:00-PDT (Tue)
From: pur-ee!uiucdcs!uicsl!ashwin @ Ucb-Vax
Subject: Re: wanted: display-oriented interlisp s - (nf)
Article-I.D.: uicsl.15500035

We use the LED editor which runs in InterLisp-VAX under UNIX. It's no DEDIT
but is better than the TTY editor. We have the source which should make it
pretty easy to set up on your system. I have no idea about copyright laws
etc., but I suppose I could mail it to you if you want it. Here's a write-up
on LED (from <LISPUSERS>LED.TTY):

------------------------------------------------------------


LED -- A display oriented extension to Interlisp's editor
-- for ordinary terminals.

LED is an add on to the standard Interlisp editor, which
maintains a context display continuously while editing. Other than
the automatically maintained display, the editor is unchanged except
for the addition of a few useful macros.


HOW TO USE
----------

load the file (see below)
possibly set screen control parameters to non-default values
edit normally

also: see documentation for SCREENOP to get LED to recognise your
terminal type.

THE DISPLAY
-----------

Each line of the context display represents a level of the list
structure you are editing, printed with PRINTLEVEL set to 0, 1, 2 or 3.
Highlighting is used to indicate the area on each line that is represented
on the line below, so you can thread your eye upward through successive
layers of code.

Normally, the top line of the screen displays the top level of the
edit chain, the second line displays the second level and so on. For
expressions deeper than LEDLINES levels, the top lines is the message:
(nnn more cars above)
and the next LEDLINES of the screen correspond to the BOTTOM levels
of the edit chain. When the edit chain does become longer than
LEDLINES, the display is truncated in steps of LEDLINES/2 lines, so
for example if LEDLINES=20 (the default) and your edit chain is 35
levels deep, the lisplay will be (20 more cars above) followed by
15 lines of context display representing the 20'th through 35'th
levels of the edit chain.

Each line, representing some level of the edit chain, is printed
such that it fits entirely on one screen line. Three methods are
used to accomplish the shortening of the printed representation:
Replacing comments with (*)
Setting PRINTLEVEL to a smaller value,
which changes expressions into ampersands
Truncting the leading and/or trailing expressions
around the attention point.

If the whole expression can't be printed, replacing comments is
tried first. If still to large, truncation is tried if the current
printlevel is >= LEDTLEV. Otherwise the whole process is restarted
with a smaller PRINTLEVEL.
The choice of LEDTLEV effectively chooses between seeing more detail
or seeing more forms.

The last line of the display, representing the "current" expression,
is printed onto ONE OR MORE lines of the display, controlled by the
variable LEDPPLINES and the amount of space (less than LEDLINES) available.
The line(s) representing the current expression are prettprinted with
elision, similar to the other context lines, using a prettyprint algorithm
similar to the standard prettyprinter. Default is LEDPPLINES=6, meaning
that up to six lines will be used to print the current expression. The
setting of LEDPPLINES can be manipulated from within the editor using
the (PPLINES n) command.

The rest of your screen, the part below the context display, is
available just as always to print into or do operations that do
not affect the edit chain (and therefore the appearance of the context
display). Each time the context display is updated, the rest of the
screen is cleared and the cursor positioned under the context display.
On terminals that have a "memory lock" feature to restrict the scrolling
region, it is used to protect the context display from scrolling
off the screen.


TERMINAL TYPES
--------------

Terminal types are currently supported:

HP2640 old HP terminals
HP26xx all other known HP terminals
Hazeltine 1520 hazeltine 1520 terminals
Heathkit sometimes known as Zenith
Ann Arbor Ambassador

The mapping between system terminal terminal type information and
internal types is via the alist SYSTEMTERMTYPES, which is used by
DISPLAYTERMP to set the variables CURRENTSCREEN and DISPLAYTERMTYPE.


Screen control macros: (in order of importance)
----------------------

DON turn on continuous display updating
DOF disable continuous display updating

CLR clear the display
CC clear the display and redo the context display
CT do a context display, incrementally updating the screen.
use CC and CT to get isolated displays even when automatic
updating is not enabled.

(LINES n) display at most n lines of context
default is 20
(PPLINES n) set the limit for prettyprinting the "current" expression.
(TRUNC n) allow truncation of the forms displayed if PLEV<=n
useful range is 0-3, default is 1

PB a one time "bracified" context display.
PL a one time context display with as much detail as possible.

pb and pl are varian display formats similar the the basic
context display.

Global variables:
-----------------

DISPON if T, continuous updating is on
DISPLAYTERMTYPE terminal type you are using. HP HP2640 of HZ
this is set automatically by (DISPLAYTERMTYPE)
HPENHANCECHAR enhancement character for HP terminals. A-H are possibilities.
LEDLINES maximum umber of lines of context to use. Default is 20.
LEDTLEV PLEV at which truncation becomes legal
LEDPPLINES maximum number of lines used to prettyprint the
current expression

FILES:
------
on TOPS-20 load <DDYER>LED.COM
on VAX/UNIX load LISPUSERS/LED.V

these others are pulled in automatically.
LED the list editor proper
SCREEN screen manipulation utilities.
PRINTOPT elision and printing utilities

SAMPLE DISPLAY
______________
(LAMBDA (OBJ DOIT LMARGIN CPOS WIDTH TOPLEV SQUEEZE OBJPOS) & & & & & @)
-12- NOTFIRST & CRPOS NEWWIDTH in OBJ do & & & & & @ finally & &)
(COND [& & &] (T & & &))
((LISTP I) (SETQ NEWLINESPRINTED &) [COND & &])
>> (COND ((IGREATERP NEWLINESPRINTED 0)
-2 2- (add LINESPRINTED NEWLINESPRINTED)
-2 3- (SETQ NEWLINE T))
-3- (T (add POS (IMINUS NEWLINESPRINTED))
-3 3- (COND (SQUEEZE &))))


Except that you can't really see the highlighted forms, this is a
representative LED context display. In an actual display, the @s
would be highlighted &s, and the [bracketed] forms would be highlighted.

The top line represents the whole function being edited. Because the
CADR is a list of bindings, LED prefers to expand it if possible so you
can see the names.

The second line is a representation of the last form in the function, which
is highlighted on the first line. The -12- indicates that there are 12
other objects (not seen) to the left. The @ before "finally" marks where
the edit chain descends to the line below.

The third and fourth lines descend through the COND clause, to an imbedded
COND cluase which is the "current expression"

The current expression is marked by ">>" at the left margin, and an
abbreviated representation of it is printed on the 5'th through 9'th
lines. The expressions like "-2 3-" at the left of the prettyprinted
representation are the edit commands to position at that form.

------------------------------------------------------------

...uiucdcs!uicsl!ashwin

------------------------------

End of AIList Digest
********************

← previous
next →
loading
sending ...
New to Neperos ? Sign Up for free
download Neperos App from Google Play
install Neperos as PWA

Let's discover also

Recent Articles

Recent Comments

Neperos cookies
This website uses cookies to store your preferences and improve the service. Cookies authorization will allow me and / or my partners to process personal data such as browsing behaviour.

By pressing OK you agree to the Terms of Service and acknowledge the Privacy Policy

By pressing REJECT you will be able to continue to use Neperos (like read articles or write comments) but some important cookies will not be set. This may affect certain features and functions of the platform.
OK
REJECT