LAWS@SRI-AI.ARPA (12/04/84)
From: AIList Moderator Kenneth Laws <AIList-REQUEST@SRI-AI> 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 ********************