Copy Link
Add to Bookmark
Report
AIList Digest Volume 2 Issue 170
AIList Digest Tuesday, 4 Dec 1984 Volume 2 : Issue 170
Today's Topics:
Administrivia- Missing Digest #166 & Digest Sequence,
AI Tools - Franz Lisp -> Common Lisp & Languages for AI,
Knowledge Representation - OPS5 Disjunctions,
Cognition - A Calculus of Elegence,
Seminars - AI Architectures at TI (SMU) &
Karmarkar's Algorithm (SU)
----------------------------------------------------------------------
Date: Mon 3 Dec 84 21:05:48-PST
From: Ken Laws <Laws@SRI-AI.ARPA>
Subject: Missing Digest #166
I have reason to believe that digest V2 #166 did not make it
out to several (many?) sites before it was mysteriously deleted
from my system. Let me know if you need a remailing. The digest
included
Philosophy - Dialectics and Piaget,
Logic Programming - Book Review,
PhD Oral - Nonclausal Logic Programming,
Seminar - Learning Theory and Natural Language (MIT),
Conference - Logics of Programs
It should have gone out Friday or Saturday (Nov. 30 or Dec. 1).
-- Ken Laws
------------------------------
Date: Mon 3 Dec 84 20:49:45-PST
From: Ken Laws <Laws@SRI-AI.ARPA>
Subject: Digest Sequence
Usenet readers may have noticed that digest issues 167-169 are missing.
These issues were sent only to Arpanet readers because they contained
only messages from the net.ai discussion -- the ones since Oct. 23,
when our gateway host went down.
-- Ken Laws
------------------------------
Date: 30 Nov 1984 1219-EST
From: Scott Fahlman <FAHLMAN@CMU-CS-C.ARPA>
Subject: Franz Lisp -> Common Lisp
[Forwarded from the CMU bboard by Laws@SRI-AI.]
A number of people around CMU and CGI have now successfully translated
Franz Lisp programs into Common Lisp. In general, people seem to have
little trouble moving big programs over, but people who have not yet
done this are understandably apprehensive. If the people who have
experience in this area want to send me a brief description of the
things to look out for or that caused them trouble, I will try to merge
these experiences into a short guide for people faced with this kind of
task in the future.
-- Scott
------------------------------
Date: Mon, 3 Dec 84 08:15 EST
From: D E Stevenson <dsteven%clemson.csnet@csnet-relay.arpa>
Subject: Languages for A. I.
I would like to compile a list of all language systems which have been
implemented / proposed for artificial intelligence purposes. I would
appreciate lists, pointers, and vague recollections from anyone within
the community. I will be glad to forward any resulting document.
steve
(803) 656-3444
------------------------------
Date: 2 Dec 1984 2124-PST (Sunday)
From: ricks%ucbic@Berkeley (Rick L Spickelmier)
Subject: OPS5 Disjunctions
I have found the following to be a solution to disjunction
in the type of problem you (neihart) have come up against.
If you are trying to represent a pass-transistor with permutable terminals,
just remove the permutable terminals from the pass-transistor working
memory element and make seperate working memory elements for each permutable
terminal, such as the following:
(passtx ^name <tr1> ^gate <gate>)
(terminal ^parent <tr1> ^name <tag1> ^type sd ^node <sd1>)
(terminal ^parent <tr1> ^name <tag2> ^type sd ^node <sd2>)
Then your rule can be:
(p Dflipflop
{(inv ^name <inv1> ^input <input1> ^output <output1>) <inv1>}
{(inv ^name <inv2> ^input <output1> ^output <output2>) <inv2>}
{(inv ^name <inv3> ^input <enable> ^output <output3>) <inv3>}
{(passtx ^name <tx1> ^gate <enable>) <passtx1>}
{(terminal ^parent <tx1> ^name <tag1> ^type sd ^node <input1>) <term1>}
{(terminal ^parent <tx1> ^name <> <tag1> ^type sd ^node <d>) <term2>}
{(passtx ^name <tx2> ^gate <output3>) <passtx2>}
{(terminal ^parent <tx2> ^name <tag2> ^type sd ^node <output2>) <term3>}
{(terminal ^parent <tx2> ^name <> <tag2> ^type sd ^node <input1>) <term4>}
-->
(make Dff ^name <inv1> ^clock <enable> ^Q <output2> ^Qbar <output1>)
(remove <inv1> <inv2> <inv3>)
(remove <passtx1> <passtx2> <term1> <term2> <term3> <term4>))
Note: I have run examples using the above and using a single working memory
element for a pass-transistor with seperate rules for each allowable
permutation - and in all cases I have tried, adding extra rules gives
better performance than adding more working memory elements
(but if you are interested in readability, the extra working memory
element representation is better).
Rick L Spickelmier (ricks@berkeley)
Electronics Research Laborartory, UC Berkeley
------------------------------
Date: 3 Dec 84 1531 EST (Monday)
From: Lee.Brownston@CMU-CS-A.ARPA
Subject: OPS5 disjunction problem
A better solution is to remove the sd values from the passtx working memory
element. If the name fields of the passtx wme's contain unique values, then
two sd children can be created which point to their common parent.
(literalize passtx
name ; a unique value
gate)
(literalize sd
passtx ; the same value as the "name" field of the passtx parent
value
)
When the passtx is made, the two sd children are linked to it.
-->
...
(make passtx ^name <passtxname>
^gate <passtxgate> )
(make sd ^passtx <passtxname>
^value <sd-value-1> )
(make sd ^passtx <passtxname>
^value <sd-value-2> )
...
Then it is easy to test the disjunction because the sd elements are unordered
(except by time tag, which is not used in matching).
(p Dflipflop
(inv ^name <inv1>
^input <input1>
^output <output1> )
(inv ^name <inv2>
^input <output1>
^output <output2> )
(inv ^name <inv3>
^input <enable>
^output <output3> )
(passtx ^name <tx1>
^gate <enable> )
(sd ^passtx <tx1>
^value <d> ) ; is this where <d> is to be bound?
(sd ^passtx <tx1>
^value { <input1> <> <d> } )
(passtx ^name <tx2>
^gate <output3> )
(sd ^passtx <tx2>
^value <input1> )
(sd ^passtx <tx2>
^value { <output2> <> <input1> } )
-->
(make Dff ^name <inv1>
^clock <enable>
^Q <output2>
^Qbar <output1> )
(remove 1 2 3 4 5 6 7 8 9)
)
Might I take this opportunity to make a plug for a forthcoming book on OPS5?
It is called "Programming Expert Systems in OPS5," and is to be published in
mid-April by Addison-Wesley. The authors are Lee Brownston (CMU), Robert
Farrell (Yale), Elaine Kant (CMU), and Nancy Martin (Wang Institute).
------------------------------
Date: Thu, 29 Nov 84 11:37 EST
From: Steven Gutfreund <gutfreund%umass-cs.csnet@csnet-relay.arpa>
Subject: A calculus of elegence (re: kludge v2 #162)
I found your definition of Kludge very interesting. In the sense you
use it, it seems to be the antonym of Elegance (a term frequently heard
in mathematical circles). The problem is I have never seen a precise
definition of elegance. Would you like to try and produce a definition
for it?
1. What is it about a representation schemas (symbolic/anologic) that
lead mathematicians or programers to consider them to be elegant
representations of a problem?
2. Does elegance extend beyond to domain of symbolic representations
to what David Smith (Pygmallion) called Non-Fregean systems such
as art (paintings)? Do we call this esthetics?
3. Is there a calculus of esthetics? Can we capture its properties
in a formal system (axiomatic) or does it correspond to
reasoning structures inside the brain (a dual of K-lines)?
- Steven Gutfreund
------------------------------
Date: Sat, 1 Dec 1984 01:06 EST
From: MINSKY%MIT-OZ@MIT-MC.ARPA
Subject: A calculus of elegence (re: kludge v2 #162)
Dear Steven,
Mathematical elegance must be a lot of things; generally it includes
economy and surprise: the sense of getting more from something than
one expected. I don't believe it very often pays to "define" a
commonsense word, because it includes too many unrelated things -- or
ones which cannot be related except within some larger psychological
theory. A sounder approach would be to define half a dozen influences
which might contribute, and make separate theories of them. In
Poincare's famous essay on unconscious mathematical creativity, he
leaves open the question of how the unconscious mind decides when its
mathematical efforts have produced a structure which might be worthy
of the conscious mind's attention.
In fact, I would say that, rather than try to define mathematical
elegance, one would better spend the time refining a system which uses
criteria of possible mathematical value -- e.g., Lenat's AM and
Eurisko systems. Then, when we better understand a way to make a
system make mathematical discoveries, we can return to speculate about
how human minds do such things.
As for a calculus of esthetics, that probably reflects even more
varied cultural acquisitions. There was a whole book about this, in
the 1920's I think, called "Esthetic Measure", by Gearge. D. Birkhoff,
a great mathematician. Here are some of my views, from a page in my
not-quite-finished new book.
PAGE 47: STYLE
Why do we like so many things which seem to have no earthly use?
We often speak of this with mixtures of defensiveness and pride.
"Art for Art's sake."
"I find it aesthetically pleasing."
"I just like it."
"There's no accounting for it".
"There's no accounting for" sounds like a guilty child who's been told
to keep accounts. "I just like it" sounds like one is hiding reasons
too unworthy to admit. Why do we take our refuge in such vague,
defiant principles? Indeed, we @B{ought} to feel ashamed of doing
things that have no use -- if it is written in our self-ideals that it
is bad to squander time.
However, there are practical reasons to maintain stylistic
preferences. Here are some reasons why it makes sense to make
choices which are empty in themselves, so long as they are based on
predictable, coherent uniformities.
SIMPLICITY: The legs of a chair work equally well if made square or
round. Then, why do we tend to choose our furniture according to
systematic style or fashions? Because they make it easier to
understand whole scenes; you can more quickly see which things are
similar.
DISTRACTION: The purpose of a picture's frame is normally to
circumscribe its boundary. Too much variety might distract viewers
from the pictures themselves. Thus, the more easily the style of the
frames can be identified -- even if by encrusting them with
ornaments -- the frames themselves can be more easily ignored.
CONVENTION: It makes no difference whether a single car drives on
the left or on the right. But when there are many cars, they must do
the same, one way or the other, or they'll crash. Societies need
rules which make no sense at all for single individuals.
It saves a lot of mental work, to make each choice the way you did
before. To find out what to do, just use find the rule in memory.
Strangely enough, this principle can be the most valuable, when the
situation it applies to is the least critical, because of the
following principle:
FREDKIN'S PARADOX: The more equal seem the two alternatives, the
harder it will be to choose -- yet the more equal they are, the less
the choice matters. Then, the more time spent, the more time lost.
It is no wonder that we find it hard to account for "taste" -- since,
often, it depends on all the rules we use when ordinary reasons
cancel out! Does this mean that Fashion, Style, and Art are all the
same? No, only that they have the common quality that their diverse
forms of sense and reason are further than usual from the surface of
thought. This is why, when we use stylish ways to make decisions, we
often feel a sense of being "free" from practicalities. Those
decisions would seem more constrained, were we aware of how they're
made.
When should one give up reasoning and take resort to rules of style?
Only when we're fairly sure that further thought will just waste
time. What are those fleeting hints of guilt we feel for liking
works of art? Perhaps they're how our minds remind themselves to not
use rules, which we don't understand, too recklessly.
------------------------------
Date: Sat, 1 Dec 84 07:36:16 cst
From: leff@smu (Laurence Leff)
Subject: Seminar - AI Architectures at TI (SMU)
Department of Computer Science and Engineering Seminar
Southern Methodist University
SPEAKER: Dr. Satish Thatte
Computer Science Laboratory Group
Texas Instruments Incorporated
Dallas, Texas
TOPIC: Computer Architectures for Artificial Intelligence
TIME: 3:00-4:00 p.m., Wednesday, December 5, 1984
PLACE: 315 Science Information Center, SMU
ABSTRACT: The seminar will cover the research on computer architecture for
symbolic processing and artificial intelligence at Texas Instruments. Our
work is concentrated on three major areas: memory system architecture,
language and compiler technology, and symbolic processor design. The memory
system research is aimed at developing a "uniform memory abstraction" that
comprehends a very large, recoverable, garbage-collected, virtual memory
system to support short-lived, as well as persistent objects. Such a memory
system is expected to play a crucial role in supporting large,
knowledge-intensive artificial intelligence applications. The language nad
compiler technology is based on the language SCHEME, a powerful and elegant
dialect of LISP. The processor design effort is based on using the Reduced
Instruction Set Computer (RISC) philosophy to implement a virtual machine
that supports the SCHEME language, as well as the uniform memory abstraction.
------------------------------
Date: Sun 2 Dec 84 17:10:28-PST
From: Andrei Broder <Broder@SU-SCORE.ARPA>
Subject: Seminar - Karmarkar's Algorithm (SU)
[Forwarded from the SRI bboard by Laws@SRI-AI.]
12/6/84 - Irvin Lustig (OR Dept. - Stanford)
"Karmarkar's Algorithm: Theory, Practice, and Unfinished Business"
Recent articles in Science Magazine and the New York Times have
brought to light a new algorithm for Linear Programming by N.
Karmarkar. The excitement created by this discovery in the Operations
Research and Computer Science communities is understandable,
considering the spectacular nature of the reported results. In my
talk, I will discuss the theoretical result of Karmarkar, some of the
practical considerations of the algorithm, and how this algorithm is
leading to new heuristics for Linear Programming. I will also explain
how the result has not yet been shown to be practically efficient,
even though fairly good results have been reported in the news media.
Time and place: December 6, 12:30 pm in MJ352 (Bldg. 460)
- Andrei Broder
------------------------------
End of AIList Digest
********************
