Copy Link
Add to Bookmark
Report

AIList Digest Volume 5 Issue 094

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

AIList Digest            Thursday, 2 Apr 1987      Volume 5 : Issue 94 

Today's Topics:
Queries - Intelligent Database Retrieval & Reliable AI Systems,
Humor - 7th Generation Computing Proposal: Basketball and AI,
Jargon - Daemons,
Comments - Military Sponsorship & Teaching Expert Systems &
Policy on Broadcasting Code,
Inference - What is the Color of Clyde?

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

Date: Tue 31 Mar 87 09:51:26-PST
From: Kevin W. Whiting <Whiting@SRI-STRIPE.ARPA>
Subject: Wanted:Info. on Tools which intelligently facilitate db retrieval

All information about tools (PC based tools particularly), shells, products,
and/or projects aimed at adding intelligence to database retrieval would be
appreciated. Information on experiences with products such as Guru, Clout,
Savvy, Q & A, or software resulting from project work such as ZOG, GUIDON,
etc., is desired as well. I had thought there was a summary more or less on
this topic posted to the net last fall but can't find it now. If you can point
me to it or other summaries - it would be mucho appreciated.

Kevin Whiting
whiting@stripe.sri.com

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

Date: 29 Mar 87 17:18:32 EST (Sun)
From: dciem!mmt@seismo.CSS.GOV
Reply-to: mmt@dciem.UUCP (Martin Taylor)
Subject: Re: Oxymoron: Real-time Knowledge-Based Nurse/Nuclear Plant
Operator


>
>I strongly agree. Any safety-critical system should have certain
>characteristics: it should be rigorously specified (AT LEAST the safety
>aspects); it should be possible to reason rigorously about the
>implementation, to convince others that it matches the specification;
>it should be developed using QC/QA techniques that guarantee an audit trail
>so that any faults discovered after development can be traced to their
>cause.
>
>These considerations dictate the use of mathematically rigorous methods, and
>a certified Quality Assurance regime. Does anyone know of an AI system
>which measures up? Please reply by mail - I'll summarise.
>

Does anyone know of a human-controlled safety-critical system that measures
up to these criteria? Presumably not, but people don't expect them to do
so. To examine the reasons why not might be to get at the heart of what
"Artificial Intelligence" is and is not, in relation to human intelligence.

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

Date: Tue, 31 Mar 87 13:16:03 cst
From: lugowski%resbld%ti-csl.csnet@RELAY.CS.NET
Subject: 7th generation computing proposal: basketball and AI

In the wake of Indiana's capture of NCAA 1987 men's basketball championship
and in the wake of AIList discussions on militarism in AI and real-time
safety-critical AI, I propose that the emulation of basketball games would
be a good domain for developing all sorts of useful technology, starting with
multi-agent planning and ending in real-time control. For starters, one
could consider a bird's eye view of the basketball court with moving
circles representing the players and the ball. The robotics people could
work on the missed dunk. The vision people could work on recognizing
timeout signals. The naive physics crowd could model missed free throws.
And the speech-to-text and image-to-speech ("this game's so good it speaks
for itself"
) could zero-in on play-by-play. Analogies and metaphor folks
could distinguish zone defenses from man-to-man, as well as the eigen-cliches
of various color commentators. Reasoning under uncertainty could model the
referees' calls. And the AI-in-law effort could model Coach Knight's use of
the technical faul -- and the connectionist models of sentences -- of his
faul language.

This endeavor would be plenty difficult. It would offer abundant military
applications as well as civilian ones. Moreover, it would provide the AI
research community with a common performance yardstick while allowing
everyone to do their own thing, from neural networks to expert systems. It
would advance science and technology, not to mention the physical fitness
of AI experimentalists. It might even do something for Indiana's AI effort
and boost CMU's basketball standing. And we could anticipate hearing
Marvin Minsky or David Rumelhart from the TV booths of the NCAAs tournaments
to come -- "The Society of Swoosh", "Backpropagation of Missed Free Throws".
There's just one more thing...

Um, funding anyone?
-- Marek Lugowski (Indiana M.S. '84)
Neural Networks Project
Texas Instruments
Lugowski%CRL1@ti-csl.csnet P.O. Box 655936, M/S 154
(214) 995-4207 Dallas, Texas 75265

"basketball people and AI folks, unite!"



[Too late -- it's being done. The following seminar at SRI described
a system that tracks soccer players in down-looking imagery and reasons
about their actions and intentions. It then generates a play-by-play
commentary, being careful not to state anything that the listener could
infer from previous statements. -- KIL]

Prof. Wolfgang Wahlster of the Univeristy of Saarbruecken will
give a talk and demonstration of his systems on Friday February 20th
at 10 AM.

GENERATING NAUTRAL LANGUAGE DESCRIPTIONS FOR IMAGE SEQUENCES

Wolfgang Wahlster
Computer Science Department
Univerity of Saarbruecken
West Germany

The aim of the project VITRA (VIsual TRAnslator) is the
development of a computational theory of the relation between natural
language and vision. In this talk, we will focus on the semantics of
path prepositions (like "along" or "past") and their use for the
description of trajectories of moving objects, the intrinsic and deictic
use of spatial prepositions and the use of linguistic hedges to express
various degrees of applicability of spatial relations.

First, we describe the implementation of the system CITYTOUR,
a German question-answering system that simulates aspects of a
fictitious sightseeing tour through a city. Then we show how the
system was interfaced to an image sequence analysis system. From
the top of a 35m high building, a stationary TV camera recorded an
image sequence of a street crossing on video tape. In 130 selected
frames the moving objects were automatically recognized by analyzing
displacement vector fields. Our system then answers natural language
queries about the recognized events.

Finally, we discuss current extensions to the system for the
generation of a report on a soccer game that the system is watching.
Here we focus on the problem of incremental, real-time text generation
and the use of a re-representation component that models the assumed
imagination of the listener.

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

Date: Tue, 31 Mar 1987 09:58 EST
From: MINSKY%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Subject: AIList Digest V5 #92

The term "demon" comes from Oliver Selfridge, via the paper,
"Pandemonium: A Paradigm for Learning", published in Symposium of the
mechanization of Thought Processes, November 1858. Selfridge's demons
were small feature-detecting agents, whose inputs were linearly
weighted sums of other signals, with autonomous hill-climbing learning
procedures for determining the weights. Selfridge's demons were
arranged in hierarchical networks; typical demons were constantly
active - and "shrieking" with intensities proportional to their
degrees of arousal; the nonlinear part was that certain "decision
demons"
would "recognize" which of their inputs was most active.

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

Date: Tue 31 Mar 87 15:10:11-PST
From: Rich Alderson <ALDERSON@Score.Stanford.EDU>
Subject: Daemons (and others...)

The following definitions are from a file often distributed with Tops-20 EMACS,
known there as INFO:JARGON.TXT; its origins are the files GLS; JARGON > at
MIT-MC and AIWORD.RF[UP,DOC] at SAIL. This text is from the 1981 version;
later, expanded versions eventually were published as _The Hacker's Dictionary_
around 1984.

DAEMON (day'mun, dee'mun) [archaic form of "demon", which has slightly differ-
ent connotations (q.v.)] n. A program which is not invoked explicitly, but
which lays dormant waiting for some condition(s) to occur. The idea is that
the perpetrator of the condition need not be aware that a daemon is lurking
(though often a program will commit an action only because it knows that it
will implicitly invoke a daemon). For example, writing a file on the lpt
spooler's directory will invoke the spooling daemon, which prints the file.
The advantage is that programs which want (in this example) files printed need
not compete for access to the lpt. They simply enter their implicit requests
and let the daemon decide what to do with them. Daemons are usually spawned
automatically by the system, and may either live forever or be regenerated at
intervals. Usage: DAEMON and DEMON (q.v.) are often used interchangeably,
but seem to have distinct connotations. DAEMON was introduced to computing by
CTSS people (who pronounced it dee'mon) and used it to refer to what is now
called a DRAGON or PHANTOM (q.v.). The meaning and pronunciation have
drifted, and we think this glossary reflects current usage.

DEMON (dee'mun) n. A portion of a program which is not invoked explicitly, but
which lays dormant waiting for some condition(s) to occur. See DAEMON. The
distinction is that demons are usually processes within a program, while
daemons are usually programs running on an operating system. Demons are
particularly common in AI programs. For example, a knowledge manipulation
program might implement inference rules as demons. Whenever a new piece of
knowledge was added, various demons would activate (which demons depends on
the particular piece of data) and would create additional pieces of knowledge
by applying their respective inference rules to the original piece. These new
pieces could in turn activate more demons as the inferences filtered down
through chains of logic. Meanwhile the main program could continue with
whatever its primary task was.

DRAGON n. (MIT) A program similar to a "daemon" (q.v.), except that it is not
invoked at all, but is instead used by the system to perform various secondary
tasks. A typical example would be an accounting program, which keeps track of
who is logged in, accumulates load-average statistics, etc. At MIT, all free
TV's display a list of people logged in, where they are, what they're running,
etc. along with some random picture (such as a unicorn, Snoopy, or the
Enterprise) which is generated by the "NAME DRAGON". See PHANTOM.

PHANTOM n. (Stanford) The SAIL equivalent of a DRAGON (q.v.). Typical
phantoms include the accounting program, the news-wire monitor, and the lpt
and xgp spoolers.

SERVER n. A kind of DAEMON which performs a service for the requester, which
often runs on a computer other than the one on which the server runs.

Rich Alderson
A.Alderson@{Lear, Othello, Hamlet, Macbeth}.Stanford.EDU

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

Date: 31 Mar 1987 15:25-EST
From: DAVSMITH@A.ISI.EDU
Subject: Re: AIList Digest V5 #92

My two cents on the Military AI issue. I totally agree with
KIL's "voice of Reason" - the only reason for the existence
of Arpanet is military sponsorship. I am currently working
on the Pilot's Associate project - and am therefore biased in
my view. Military applications such as this are excellent for
"blowing the fluff away" and finding out which AI technologies
are ready for real applications where need has been demonstrated.

Perhaps a little later, we can digress on some of those findings.
Without the military applications, who in the commercial sector
would attempt to put together cooperating expert systems
in real-time? [ One could broaden the issue and ask
"Who in their right mind would..?"]

The sad fact is that a technology in the university lab can look
very good on viewgraphs, but you would be surprised at the
back-pedalling which occurs when you offer the opportunity to
plug into a real application.

David Smith DAVSMITH@a.isi.edu

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

Date: Wed, 1 Apr 87 11:03:56 PST
From: Ritchey Ruff <ruffwork%oregon-state.csnet@RELAY.CS.NET>
Subject: Teaching Expert Systems

>
> First, the dissemination of Tiny MYCIN sounds interesting.
> I wish I had a convenient Common LISP machine to try it out.
> I realize that TMYCIN is just a tool, but I wonder how good a tool
> it really is. What is the value of learning about this tool
> (to learn about ESs) when you don't have an expert around (rhetorical
> question, obviously some value)? I ask this because I have a relative
> who does research in pathology and got his PhD in bacteriology
> at BYU (any connection with Dugway Proving Ground is not coincidence).
>
> --eugene miya
> NASA Ames Research Center
> eugene@ames-aurora.ARPA

Well, 3 months ago I would have said that an expert system tool in vivo
is not much use, but now...I was a TA (teaching assistant) for an
expert systems course here at Oregon State last term taught by Tom
Dietterich. It was his first time around teaching this subject and
so he decided to go at it from a case study/theory viewpoint (if the
theory of expert systems isn't oxymorphic :-). Thus there was really
nothing said about how to implement systems. The term project though WAS
to implement a small expert system (4 or 5 weeks to do this, and we
DON'T have any expert systems tools - just LISP, PROLOG, and OPS5).
The projects were very impressive overall, but the style/organization/etc.
were generally dismall. Not in a traditional sense but more from
an expert systems sense. The code was documented, modular, etc. but
not in a way that made it easy to analyze as an expert system. It was
often hard to understand WHAT knowledge the system had from code reading.

What is needed is both sides of the coin - the theory/case study, and
a how-to-implement course. Having the proper tools is bound to help
here, but several project in the above languages WERE readable as
knowledge bases (style makes a difference).

IF the TMYCIN tool comes with some GOOD examples (no matter how
toy-ish) I think that a person could learn quite a bit about the
how-to-code end of expert systems - which is just as important
(in its own way) as the theory.

--ritchey ruff (reformed couch potato)
ruffwork%oregon-state@csnet-relay
(soon to be ruffwork@cs.orst.edu)

from the Home for the Artificially Intelligent

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

Date: 31 Mar 87 09:38 PST
From: ghenis.pasa@Xerox.COM
Subject: Special Postings and Digest Title

Regarding the issue of whether source code, bibliographies, etc should
be included in AIList... I realize this would create more work for
Moderator Ken Laws, but what if these special postings always went out
grouped in SEPARATE ISSUES and the "Subject:" line were made MORE
DESCRIPTIVE so readers could skip selectively?

Thus instead of getting

AIList Digest V5 #92

we could get messages titled:

AIList V5 #92 - Source
AIList V5 #92 - Bibliography
AIList V5 #92 - General

or something along those lines (you get the idea)

I would like to see source postings back in AIList, maybe the above
system can satisfy those who would rather skip them. Any comments?

Pablo Ghenis
Xerox Artificial Intelligence Systems
Educational Services


[I could add such a heading, but one result would be longer
delays for some material until enough arrived for a full
digest. Anyway, I'm not sure I see the savings. My mailer,
which is probably the used throughout the Arpanet, doesn't
display enough of the title for the keywords to be visible.
If I read enough of the message to get the full title, I only
have to scroll a few more lines to get the Topics listing.

A better solution is to have independent mailing lists for
different types of material. Even the Stanford bboard is
partitioned now, so why not AIList? The only difficulty
is that I don't want to maintain multiple mailing lists.
It wouldn't be so bad if I had a good database system for
converting request messages into additions and deletions,
but I have to do it by hand and I'm not eager to double or
triple the time this takes.

I've heard of a database server for code distributions that
might be open to the Arpanet; I will investigate. I am
beginning to think, though, that FTP and mail requests are
not such a bad thing. Gordon Novak tells me he has had over
thirty requests for his code, in addition to any FTPs (which
he wouldn't know about). Handling thirty requests is a bit
of a hassle, but also a bit of a thrill. It generates
professional contacts and keeps people in touch. Why, I
can imagine someone disallowing FTP altogether just to keep
track of who is getting the code. To go even further, a
separate interest list could be established. And if a code
author didn't want the hassle at all, s/he could use AIList to
find someone else willing to handle the distribution in
return for access to the code. Isn't this better than having
an impersonal central server stuffed with obsolete, unmaintained
code? Or a broadcast system like AIList? The only real
disadvantage is that code may become inaccesible if the author
leaves his current site, but copies should be available from
somewhere (perhaps via AIList query). -- KIL]

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

Date: 1 Apr 87 13:40:18 GMT
From: Dekang Lindek <mcvax!cs.strath.ac.uk!lindek@seismo.CSS.GOV>
Reply-to: lindek@cs.strath.ac.uk (Dekang Lin)
Subject: Re: What is the color of Clyde?

In article <8703021016.AA22995@stracs.cs.strath.ac.uk>
lindek@seismo.CSS.GOV@cs.strath.ac.uk (Dekang Lindek) writes:

>Look, WORLD, here is a little default reasoning exercise:
>
>95% of elephants have color grey.
>40% of Royal Elephants have color yellow.
>Clyde is a Royal Elephant.
>
>The color of Clyde is likely to be:
> a) Grey b) Yellow c) Red d) Unknown
>

There are several bugs here:
1) 'most likely' should be used in place of 'likely' to make the
question clear.
2) 'Unknown' should not be one of the choices because neither
'likely to be unknown' nor 'most likely to be unknown' makes
any sense. It is a fact that the color of Clyde is unknown,
otherwise we won't need to guess it.
3) 'elephants have color grey' sounds like Next-Generation-Database
English.
4) 'Lindek' is his E-name, not surname.
5) (This place is reserved for future use)

After fixing the first four bugs, we could make the following
inference:
#define confidence probability

proposition confidence
(1) A Royal Elephant is yellow. .40
(2) A Royal Elephant is not yellow .60
(3) (An elephant is not yellow) ==>
(The elephant is grey) .95~1.0
(4) (A Royal elephant is not yellow) ==>
(A Royal elephant is grey) .95~1.0
(5) A Royal Elephant is grey .57~.60
(6) Clyde is a Royal Elephant. 1.0

Conclusion(subject to change without notice):
Clyde is most likely to be GREY.[]

Discussion:
The decision becomes harder to make when the confidence of (1)
is inside the interval of (5).

Comments:
This problem seems too technical to be discussed on the net.
An opinion poll in Glasgow will definitely show that the
color of Clyde is green even though it is blue on the maps.

Dekang Lin
Dept. of CS
Univ. of StrathClyde
26 Richmond Street
Glasgow G1 1XH, U.K.

lindek%uk.ac.strath.cs@ucl-cs.arpa
....!seismo!mcvax!ukc!strath-cs!lindek

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

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