Copy Link
Add to Bookmark
Report
AIList Digest Volume 3 Issue 103
AIList Digest Wednesday, 7 Aug 1985 Volume 3 : Issue 103
Today's Topics:
Queries - Zetalisp Menu and Mouse Functions, Networking &
Company Projects & Parallel Processing and Economics &
Theorem Proving,
Education - Architecture and Programming,
Linguistics - Loglan,
Games - Poker,
Expert Systems - Knowledge Bases & Definition
----------------------------------------------------------------------
Date: 01 Aug 85 13:50:38 CDT (Thu)
From: ihnp4!mmm!rouner@mmm.ARPA
Subject: Query - Zetalisp Menu and Mouse Functions, Networking
We are developing expert systems on both the XEROX 1108 (Dandelion Interlisp-D)
and the SYMBOLICS 3640. For a variety of reasons, we would like to develop a
system that runs without modification on both the Symbolics and Dandelion. It
would be great if we could find Zetalisp implementation of the Interlisp-D menu
and mouse functions. Our goal is to emulate the Macintosh interface and its
appearance on both machines, as that is what our users want.
We are aware that KEE which runs on both SYMBOLICS and XEROX has implemented
some of the Interlisp functions in the SYMBOLICS version, but unfortunately the
implementation is incomplete and does not yield equivalent visual display. The
Interlisp Compatibility Package from SYMBOLICS does not support either the menu
or mouse functions.
Has any of this already been done and are there any significant problems in
trying to create a package that will run without modifications on both
machines?
A second need is to develop a password controlled access to the Symbolics
both from the terminal and over TCP/IP network. Additionally, we need to
provide password controlled access to selected files. Has any work been done
in this area? What are the loopholes?
Finally, has anyone developed an Imagen 8/300 printer support package that
works with the Symbolics Hardcopy System over TCP/IP to either UNIX 4.2 VAX
or an IMAGEN host? I wish to have services that are provided by Symbolics
over CHAOSNET with the now-discontinued LGP, including font changes and
screen dumps.
Thanks for your help. If there are sufficient requests, I will post a
summary.
Bill Rouner, USENET address: ihnp4!mmm!rouner
------------------------------
Date: Thu, 1 Aug 85 20:00:33 cdt
From: Raj Doshi <doshi%umn.csnet@csnet-relay.arpa>
Subject: query about company projects...
I was reading the recent issue of AI Magazine (Summer 1985) and
saw a few ads of Companies (ads placed by respective Personnel
Departments), that got me interested.
For example, OLIVETTI's ad said that they are doing work in :
- ICAI
- Inexact Knowledge
- Non-Monotonic Logics.
INFERENCE CORP's ad said they are consultants on projects such as:
- Scheduling & Planning Missions
PERCEPTRONICS ads said that they are working on:
- Planning Aids
- Training Systems & intelligent CAI
- Robotics & Remote Systems.
I want to know more about these projects/oppurtunites. (I did not
want to write to personel for this).
I was wondering if some technical person(s) at the above mentioned
companies, would like to communicate with me ????????
Thanks in advance.
- raj doshi
------------------------------
Date: 02 Aug 85 15:31:01 EDT (Fri)
From: "Emil J. Volcheck" <volcheck@UDel-Dewey.ARPA>
Subject: Parallel Processing and Economics & Theorem Proving
Economists use mathematical models to analyze the behavior of
large systems, in fact some of these models are basically simulations
of an open system in which many individuals are making economic decisions.
If someone can prove theorems pertaining to parallel processing on
distributed systems, these results may carry over to economics, and
vice-versa. Does anyone know of research pertaining to this idea, or
does anyone have thoughts about this?
Also -- Does anyone know of a place in the literature about
theorem-proving where proving a theorem is defined as "The unification of
necessary (given) with sufficient (goal) conditions" ? I'd appreciate
your thoughts on this too.
--Emil Volcheck
------------------------------
Date: 6 Aug 85 14:11:42 PDT (Tuesday)
From: Hoffman.ES@Xerox.ARPA
Subject: Re: Architecture and Programming
Seth Steinberg outlined some intriguing similarities between the
practice of architecture and the practice of programming. The teaching
of both disciplines can also be strikingly similar: architecture
students get about as much structural engineering as programmers get
mathematics or electrical engineering, both are given numerous "toy"
problems as examples and exercises, most learning occurs in the lab
rather than from lecture, no one has a good way to test for natural
talent, and some people can be quite good with little formal training.
--Rodney Hoffman
------------------------------
Date: Tue, 6 Aug 85 11:06:42 PDT
From: Hibbert.pa@Xerox.ARPA
Subject: Re: Loglan
The Loglan Institute's current address is:
The Loglan Institute, Inc.
Route 10, Box 260
Gainesville, FL 32601
The language is undergoing continual revision, and a push is currently
on to scale up a project to increase the vocabulary considerably. There
are plans to Go Public Again sometime in the next year or two. This
means publishing something like the June 1960 Scientific American
article, which would require some major progress on the state of the
languge to be worthwhile.
I can answer questions about the language if anyone is interested. (I'm
not sure AIList is the right place for a long summary of the current
state of the language and the institute. A year ago, when I was on
Usenet, I sent them to net.nlang.)
The editor of the member's newsletter has a uucp address if you want to
talk to someone who's deeply involved in the work: John Lees is
addressible as "ihnp4!umich!cosivax!bugs!jrl"@DECVAX or UCBVAX.
Chris
------------------------------
Date: Tue, 6 Aug 85 10:24:25 edt
From: "Col. G. L. Sicherman" <colonel%buffalo.csnet@csnet-relay.arpa>
Subject: Poker
[See Scientific American, July 1978, for an article on Nicholas
Findler's research into automating poker strategies. I seem to
recall that the project ended before a player was developed that
could detect and bluff the Mathematically Fair Player. -- KIL]
This is correct but misleading. Due to a misconception, we stated in
the article that the Mathematically Fair Player's weakness was that it
could be bluffed out of any hand. Later we realized that this could
not be true, because the M.F.P. decides whether to stay or fold without
considering its opponents' bets! The M.F.P. cannot be bluffed - a clear
sign of weakness to any experienced player.
Of course, the weakness consisted precisely of ignoring the opponents'
behavior. The M.F.P. consistently came out on top in tests where this
flaw did not matter.
Further details appear in M. A. Bramer's recent compilation, _Computer
Game-Playing: Theory and Practice_ (1983).
--G. L. S.
------------------------------
Date: 1 Aug 1985 09:31-EDT
From: Robert.Frederking@CMU-CS-CAD.ARPA
Subject: No Knowledge Bases?
My earlier request for sample AI knowledge bases turned up
exactly zero responses. Does this perhaps confirm what I've suspected
for a while? That people like to build all kinds of fancy KR systems,
with various kinds of inheritance, topologies, etc., but nobody is
interested in "populating" these systems with real AI-type knowledge?
The k-bases I'm familiar with all generally consist of fairly mundane
database information, stuck into fancy AI mechanisms, where the Lisp
code actually contains all the interesting AI-type knowledge
(especially, knowledge of what the nodes in the network mean).
Some might speculate that this implies that the right way to
build AI systems is like any other software system: lots of meticulous
work on normal procedural code. I'd prefer to think that either:
(1) nobody has really put a lot of effort into building a
"real" knowledge base yet, because it wouldn't be at all
enjoyable, or
(2) we still don't have a proper understanding of how to
represent intentional and control knowledge in a declarative
way, not to mention trying to represent domain knowledge in a
declarative way.
------------------------------
Date: Thu 1 Aug 85 08:53:13-PDT
From: Mark Richer <RICHER@SUMEX-AIM.ARPA>
Subject: What is an "expert system"
What is the nature of human expertise? In what sense are current programs
"expert?" Are they "expert" in a sufficiently rich enough sense that they
warrant the usage of this term? Saying a program does something that
requires intelligence or expertise opens one up to including all programs
that do this including ones that use numerical and other techniques that
are not normally associated with AI .. how about a graphics program being
an expert system because it can create a picture that would otherwise
require human expertise.
I prefer the term "knowledge based system," perhaps because it doesn't
imply as much and is more general (e.g., simulations, data bases, etc. can
use AI techniques of KR and inference without solving problems).
I have heard the Flores and Winograd's new book (in press?) has an
interesting discussion on expert systems.
mark
------------------------------
Date: Thu 1 Aug 85 09:58:29-PDT
From: WYLAND@SRI-KL.ARPA
Subject: Expert System Definition
I offer the following candidate definition for expert system
programs, which attempts to differentiate expert system programs
from conventional decision making programs (i.e., any program
with an IF THEN statement.):
An expert system is a computer program that makes decisions
(and/or judgements) according to a set of rules that operate
on a set of facts, and can explain each decision (or
judgement) by giving the sequence of rules and the facts used
to make that decision.
This is different from the concept that an expert system "does
what an expert does", since a conventional FORTRAN program can be
written do do what an expert does, but cannot explain why the
decision was made. For example, an expert may
have a rule that says IF(there is a fire) THEN(turn on the fire
sprinklers). This kind of decision making is done in
conventional programs all the time. The thing that
differentiates expert systems is the possibility of asking for an
explanation of a decision: why a decision is made (or proposed).
Decision explanation is done in conventional expert systems by
using a rule based system design and using the rules and facts
invoked in a decision to "explain" the decision. The rule based
system design consists of rules, facts, and a logic engine that
applies the rules to the facts to make decisions. In its
simplest form, the rules are decision making algorithms with a
specified form, and the facts are input or derived data elements
used by the rules in making decisions. Explanation consists of
listing the rules and facts (in some form) that were used to
reach a given decision (or are being used in an interactive
process of making a decision).
Not all expert systems explain their decisions, but it is the
ability to explain the decisions that is important. A rule based
decision system can have this ability, even though the
explanation mechanism is not built in to the product.
Dave Wyland
WYLAND@SRI-KL
------------------------------
Date: Fri 2 Aug 85 10:25:02-PDT
From: WYLAND@SRI-KL.ARPA
Subject: Expert System Definition
Thanks for the note. I'll try to answer the points you
raised in order.
"If we take that FORTRAN program and add a few steps which
will take an input of "WHY?" after the sprinklers have been
turned on and respond with the string "__BECAUSE THERE WAS A
FIRE" does that then make it an expert system? Why or why not?"
"Is this a dumb question?"
No, it's a SIMPLE question: generally the nastiest, most
difficult, and most interesting kind. (i.e., What is energy?)
If my definition is accurately descriptive, that does
make the FORTRAN program an expert system, since it can explain
its decision. It is a good example because it represents a
marginal case. The problem with the FORTRAN expert system
program you have described is that it doesn't appear to work for
nested rules. Nested rules are where you have more than one rule
invoked in a chain of logic to reach a decision. For example:
IF(the smoke alarm is on) THEN(there is a fire)
IF(the alarm lever is pulled) THEN(there is a fire)
IF(there is a fire) THEN(turn on the sprinklers)
IF(sprinkler test switch is on) THEN(turn on the sprinklers)
The (turn on the sprinklers) decision must be explainable
in terms of the rules actually used in making the decision, and
the explanation must be able to cover all the rules that were
invoked. The first answer to why the sprinklers went off may be
that (there is a fire). The next answer to the repeated question
"why" can be either that (the smoke alarm is on) or (the alarm
lever is pulled) depending on which rule was activated. (The
third answer to "why" is "because!", since there is no prior
rule.)
"(Let me ramble for a minute and correct me where I'm wrong.)
Is the difference between this approach and the more
conventional expert system design the fact that an expert
system can trace back through its decision making process?"
Yes, I think this is the essential feature of expert systems.
"Perhaps I am missing the qualitative difference between an
expert system design and the design of the FORTRAN program.
Does it lie in the fact that the logic engine views rules and
facts SEPERATELY and attempts to apply the one to the other."
No, I think this is a practical requirement of the
explanation process. For example, if you try to do nested rule
explanations in conventional IF THEN format FORTRAN, I think it
will get very messy because you will probably wind up with
indexed arrays, pointers, and variables to tie everything
together. A "rule based" approach to the same program might
start by replacing the IF THEN statements with calls to a
subroutine with the components of the IF THEN statement passed as
parameters and the subroutine performing the IF THEN evaluation.
If the parameters for the various IF THEN rules are arranged in a
list (or FORTRAN array), you now have a simpler structure for
evaluating the rules and keeping track of the results. Further
work in this direction will make it easier to enter the rules and
their explanations, etc. The practical purpose of this exercise
is to make it easier to design the expert system by handling the
rules, their processing, and their explanations in simpler, more
regular fashion.
I hope this helps. Keep asking the simple questions:
they're the ones with the important answers.
Good luck,
Dave Wyland
------------------------------
End of AIList Digest
********************
