Copy Link
Add to Bookmark
Report

AIList Digest Volume 1 Issue 016

eZine's profile picture
Published in 
AIList Digest
 · 1 year ago

AIList Digest            Friday, 17 Jun 1983       Volume 1 : Issue 16 

Today's Topics:
Encouragement for Lab Reports
LISP for VAX/VMS
Re: Natural Language Challenge (2)
Re: Adventure games as AI (3)
Lunar Rover (2)
----------------------------------------------------------------------

Date: 14 Jun 83 0:18:31-PDT (Tue)
From: hplabs!hp-pcd!jrf @ Ucb-Vax
Subject: Re: Description of AI research at TRW - (nf)
Article-I.D.: hp-pcd.1149

Thanks for the info! More, please.

jrf

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

Date: 14 Jun 1983 11:42-PDT
From: Andy Cromarty <andy@aids-unix>
Subject: LISP for VAX/VMS

[...]

If you are not concerned about maintaining compatibility with an
existing LISP software base (e.g. MacLisp or InterLisp), then the
"CLisp" dialect from UMass-Amherst (for VMS only) represents an
excellent combination of highly developed LISP environment and
efficient execution. CLisp was developed using public funds; I
believe that it is available for the cost of a tape and mailing (i.e.
as far as I know they do not tack on a several hundred dollar
"distribution fee"). The current distributor and maintainer is Dan
Corkill at UMass-Amherst; send inquiries to

CLISP.UMass-CS@UDel-Relay.

CLisp (not to be confused with the InterLisp "CLisp" syntactic-sugar
subdialect) is a mature LISP influenced by both the MacLisp and
InterLisp traditions but departing from both in several respects. The
system includes substantial on-line documentation, a reasonably good
optimizing compiler, an incarnation of the InterLisp editor, and good
hooks into VMS subprocess and system service functions. If I were
working under VMS now, that's the LISP I would personally use over all
the others I know about (e.g. NIL, InterLisp, Utah's "Standard" LISP,
Franz under Eunice, etc.). (Unfortunately, since I'm working under
Unix, we must struggle along with Franz.)

cheers, asc

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

Date: 16 June 1983 01:36 EDT
From: Steven A. Swernofsky <SASW @ MIT-MC>
Subject: Natural Language Application

Do I count as an AI program? I can parse your "legalese" for you.
The quoted paragraph essentially signs over to your insurance company
any rights you may have had to sue someone (anyone) over the accident.
This is in exchange for the company's payout on your claim. They can
then (themselves) sue the people you would have been able to sue and
collect without bothering you or getting your approval.

This is not a legal opinion of any sort. Please send me my can of
Coors Lite via the newly-created CLTP (Coors Lite Transmission
Protocol).

-- Steve

P.S. The Los Angeles /Daily Journal/ is a legal newspaper which
publishes a "sentence of the day" each day, culled from actual legal
writing. It is usually as bad or worse than your quoted example.
They also publish a "sentence of the year" (!).

Since most human beings cannot parse a sentence of that opaqueness, no
AI program should pass the Turing test unless it also fails at it. $$

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

Date: 16 Jun 1983 at 1350-PDT
From: zaumen@Sri-Tsc
Subject: Re: Natural Language Application

Sorry, it has to be parsed by a program (I assume you are a person,
not a machine), so you don't get a real physical can of Coors Lite.

You mentioned that a program that could parse legalese (as convoluted
as in my example) would not pass the Turing test, as most people could
not parse it. Lawyers claim to be able to parse it, thereby leading
me to suspect that lawyers cannot pass the Turing test. This leads to
an interesting question--are lawyers intelligent? If lawyers are
intelligent, what does this imply about the Turing test?

Bill


[The lawyer could pass the test by pretending not to understand the
test sentence. It has always been assumed that an intelligent machine
would similarly hide its superior arithmetic skill. This requirement
for duplicity is a major failing of the Turing test. -- KIL]

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

Date: 15 Jun 1983 1009-PDT
From: Jay <JAY@USC-ECLC>
Subject: Roguematic

There is a program that plays ROGUE (Unix version, not 20 version)
written in C for the UNIX operateing system. Playing games of any
kind is interesting from an AI stand point.

Most arcade games involve little strategy and much reaction
time/image recognition. The strategy component could make a nice toy
AI program, the reaction time component would just be a hardware
problem (or would it?), and the immage recognition would be another
domain for Image Understanding.

j'

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

Date: Wednesday, 15 June 1983 12:43:27 EDT
From: Michael.Mauldin@CMU-CS-CAD
Subject: An entertaining AI project.


You may be surprised to find that Rog-O-Matic, written by Andrew
Appel, Leonard Hamey, Guy Jacobson and Michael Mauldin at
Carnegie-Mellon University has been available for public consumption
since May 1982. Rog-O-Matic XII is available from CMU, and version
VII has been at Berkeley since August of 1982.

Rog-O-Matic is written in C for Unix systems. Rog-O-Matic has also
been ported to VMS using Rice Phoenix. Rog-O-Matic has been a total
winner against Rogue 3.6, and has scored 7730 against Rogue 5.2 (quit
while ascending from level 27 with the amulet).

Since our paper "Rog-O-Matic: A Belligerent Expert System" was not
accepted to AAAI-83, it will be released this summer as a technical
report of CMU. Copies of the draft may be obtained by sending net
mail to "mauldin@CMU-CS-A", or by writing

Michael Mauldin
Dept. of Computer Science
Carnegie-Mellon University
Pittsburgh, PA 15213.

The source code is also publicly available, and can be mailed via the
net. Or, mail a magtape to the address above, and we'll put it there
for you.

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

Date: 15 Jun 83 16:09:14 EDT
From: Ron <FISCHER@RUTGERS.ARPA>
Subject: Re: Adventure games as AI

I'm a systems staff member of the Lab for Computer Science Research
here at Rutgers. We have an informal group of hackers and programmers
undertaking the implementation of a multi-player adventure game.
We're attempting to combine ROGUE-like strategy with ADVENTURE-like
role-playing.

We'd like to have non-player characters with their own motivations.
Non-player characters are those people in a role playing game being
controlled by the game's referee. In our case this control would be
some chunk of software operating on a representation of the
character's goals and knowledge.

Can anyone provide references for papers in this area (would anyone
sponsor such a thing! A game as research, bah!)

Agreed, adventure games are a very rich environment for this sort of
thing.

(ron)

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

Date: Thu, 9 Jun 1983 01:15 EDT
From: Minsky@MIT-OZ
Subject: Lunar Rover

[Reprinted from the SPACE Digest.]

On Lunar Rover.

If I had 500K/year for research on a lunar rover, I wouldn't spend
any of it on AI or automatic obstacle avoidance, etc. at all. I
would spend all of it on developing a good remote, all-purpose Rover
vehicle, to be controlled [from Earth] through a 2-1/2 second delay
system. I would de-bug in in suitable local environments, e.g.,
staring in the Mohave or somewhere nice like that. We'd see how
often the delay causes accidents; the top design speed would be
perhaps 0.2 meters/second so that most contingencies could be
handled in human reaction times.

Once we know the accident rate we take two tacks. First, simple
automatic probes that measure the terrain a meter ahead of the beast
so that it won't fall into crevasses that the operator missed or was
too careless to avoid. This simple "AI" work would then lead to
increasing concervative reliability.

The other tack would be mechanical escape devices. For example, the
standard operation might be to use a retractable anchor that is
hooked to the terrain before advancing each 100 meters. Then its
prongs are retracted and it is pulled back to the Rover and
reimplanted. This would permit using a winch to get out of troubles.
It might not save the day if a landslide partly buries the Rover,
though. A more advance system would have TWO Rovers roped together,
like climbers, each with good manipulator capability. (Climbers
prefer three.) That could be enough to get out of most problems.

All this would lead to a Rover that can traverse about a
kilometer/day. A few of them could explore a lot of moon in a few
years. The project would stimulate some AI for use on Mars and other
places. But I think that over the next 3-5 years, the fewer new AI
projects the better, in some ways, and anyone with such budgets should
aim them at AI education and research fellowships.

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

Date: 9 June 1983 08:24 EDT
From: Robert Elton Maas <REM @ MIT-MC>
Subject: rover

[Reprinted from the SPACE Digest.]

First year, build a bunch of servo units with built-in 2.5 second
delay and attach them to a random survey of existing vehicles, both
commercial (private automobiles, trucks, dune buggeys, etc.) and
experimental (HPM's cart, SRI's shakey frame, Disney stuff, etc.).
Audition the 10% unemployed as remote-controllers, keeping the best.
Get as much info as possible the first year without having to actually
build any new vehicles.

Then from the general info about the 2.5 second delay and the human
controllers, decide feasibility of lunar-rover project, and if
feasible then use specific info about the various vehicles to decide
what new vehicles to build in later years for further experiments.

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

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