Copy Link
Add to Bookmark
Report
AIList Digest Volume 2 Issue 025
AIList Digest Tuesday, 6 Mar 1984 Volume 2 : Issue 25
Today's Topics:
Review - Laws of Form,
Brain Theory - Parallelism,
AI Reports - Stanford Acquisitions,
Administrivia - New Location for List-of-Lists,
AI Software - Portability of C-Prolog
----------------------------------------------------------------------
Date: Sat, 3 Mar 84 18:36:25 PST
From: Charlie Crummer <crummer@AEROSPACE>
Subject: Laws of Form
I don't pretend to be an expert on LoF but I think there are at least two
interesting aspects to it. One is that it provides a calculus that can be used
to "compile" a set of syllogisms (page 124 of the Dutton 1979 edition). A
second is that it does away with Russell and Whitehead's cumbersome Theory
of Types. All orders of self-referential sets of statements can be evaluated
within the set of "imaginary" values.
You can argue that the compilation of syllogism sets (rule sets) can already
be done using truth tables. I think that the benefit of Spencer-Brown's
calculus is that it is much more efficient and should run much faster.
Those who are really interested should loosen up and plow through the book
a few times with an open mind. It is really very thought-provoking.
--Charlie
------------------------------
Date: Mon 5 Mar 84 20:34:27-EST
From: David Rogers <DRogers%MIT-OZ@MIT-MC.ARPA>
Subject: parallel minds?
For a very good (if 3 years old) discussion on parallism
in the brain, refer to Hinton and Anderson's book "Parallel
Models of Associative Memory, pages 32-44 [Hin 81]. The
applicable section is entitled "Parallelism and Distribution
in the Mammalian Nervous System". Structurally, paralleism is
inherent throughout the nervous system, making simple
sequential models of human low-level cognition highly
suspect.
Though it was not openly stated in the discussion on this list,
there seems to be two issues of parallelism involved here:
low-level parallelism, and parallelism at some higher
"intellectual" level. The latter subject is rightly the domain
for experimentalists, and should not be approached with
simple AI techniques as introspection ("Well, I *feel*
sequential when I think...").
One known experimental fact does suggest a high degree of
parallelism, even in higher cognitive functions. Since
the firing rate of a neuron is on the order of
2-3 milliseconds, and some highly complex tasks (such as
face recognition) are performed in about 300 ms, it seems
clear that the brain uses massive parallelism, not just
in the visual system but throughout [Fel 79].
I would suggest that future discussions offer the reader
a few more experimental details, lest the experimental
psychologists in our midst feel unappreciated.
---------
[Hin 81]
"Parallel Models of Associative Memory, G. Hinton,
J. Anderson, eds, Laurence Earlbaum Assoc., 1981, pages 32-44.
[Fel 79]
"A Distributed Information Processing Model of Visual
Memory", J.A. Feldman, University of Rochester Computer
Science Department, TR52, December 1979.
------------------------------
Date: Sun 4 Mar 84 21:56:21-PST
From: C.S./Math Library <LIBRARY@SU-SCORE.ARPA>
Subject: Latest Math & CS Library "New Reports List" posted on-line.
[Every month or two Stanford announces its new CS report acquisitions.
I culled and sorted many of the citations for an earlier set of AIList
issues, but I have not gotten around to doing so for the last six
months or so. Instead, I am forwarding this notice as an example
of the notices you can get by contacting LIBRARY@SU-SCORE. For those
interested in FTPing the report listings, I would characterize them
as being lengthy, somewhat cryptic and inconveniently formatted, and
usually divided about equally between AI-related topics and non-AI
math/CS topics (VLSI design, hardware concepts, operating systems,
networking, office automation, etc.). -- KIL]
The latest Math & Computer Science Library "New Reports List" has been
posted on-line. The file is "<LIBRARY>NEWTRS" at SCORE, "NEWTRS[LIB,DOC]"
at SAIL, "<CSD-REPORTS>NEWTRS" at SUMEX, and "<LIBRARY>NEWTRS" at SIERRA.
In case you miss a reports list, the old lists are being copied to
"<LIBRARY>OLDTRS" at SCORE and "<LIBRARY>OLDTRS" at SIERRA where they will
be saved for about six months.
If you want to see any of the reports listed in the "New Reports List,"
either come by the library during the display period mentioned or send a
message to LIBRARY at SCORE, giving your departmental address and the
six-digit accession numbers of the reports you want to see, and we will
check them out in your name and send them to you as soon as they are available.
The library receives technical reports from over a hundred universities
and other institutions. The current batch includes - among others -
reports from:
Eidgenoessische Technische Hochschule Zuerich. Instituet fuer Informatik.
IBM. Research Division.
Institut National de Recherche en Informatique et en Automatique (INRIA).
New York University. Courant Institute of Mathematical Sciences.
U.K. National Physical Laboratory. Division of Information Technology
and Computing.
Universite de Montreal. Departement d'Informatique et de Recherche
Operationnelle.
University of Edinburgh. Department of Computer Science.
University of Southern California. Information Sciences Institute.
University of Wisconsin-Madison. Computer Sciences Department.
- Richard Manuck
Math & Computer Science Library
Building 380 - 4th Floor
LIBRARY at SCORE
------------------------------
Date: 1 Mar 1984 2142-PST
From: Zellich@OFFICE-3 (Rich Zellich)
Subject: New location for list-of-lists (Interest-Groups.TXT)
File Interest-Groups.TXT has been moved from OFFICE-3 and is now
available on the SRI-NIC host in file <NETINFO>INTEREST-GROUPS.TXT
Requests for copies of the list, updates to the list, etc., should be
sent to ZELLICH@SRI-NIC in the future, instead of ZELLICH@OFFICE-3 or
RICH.GVT@OFFICE-3.
Cheers,
Rich
------------------------------
Date: Wednesday, 22-Feb-84 23:45:00-GMT
From: O'Keefe HPS (on ERCC DEC-10) <OKeefe%EDXA@UCL-CS>
Subject: Portability of C-Prolog
[The following is forwarded from the Prolog digest. I consider
it an interesting account of the difficulties of making AI
software available on different systems. The message is
8K characters, so I have put it last in the digest for those
who want to skip over it. -- KIL]
There was a question in this Digest about whether C-Prolog had
been ported to Apollos. I don't know about that, but I have had a
great deal to do with C-Prolog, so I can say what might give trouble
and what shouldn't.
The first thing to beware of is that there are two main versions
of C-Prolog drifting around. The one most people have is the one
distributed by EdCAAD (which is where Fernando Pereira wrote it), and
while that runs under VAX/UNIX and VAX/VMS both, and is said to run
on at least one 68000 box, V7 C compilers don't like it much. The
other version is distributed by EdAI on a very informal basis, but it
should be available from Silogic in a couple of weeks. The EdAI
version has been ported to the Perq (running ICL's C-machine micro-
code and their PaNiX port of V7 UNIX) and to another C-machine called
the Orion (that compiler isn't a derivative of PCC). C-Prolog has
something like one cast per line, the EdAI version has stronger type
declarations so that the compiler produces no warning messages. Both
versions are essentially the same, so EdAI cannot distribute their
version to anyone who hasn't got a licence for the EdCAAD version.
What C-Prolog v1.4d.edai requires is
[1] a V7 or later C compiler
[2] pointers should be 32 bits long
[3] the compiler should support 32 bit integer arithmetic, and
floats should be storable in 32 bits. (In fact if anyone has
a decent C compiler for the Dec-10 [a] please can we have a copy
and [b] C-Prolog should run quite happily on it.)
[4] It needs to steal 3 bits out of floats, so it needs to know a bit
about the floating-point storage format. IEEE and VAX-11 are ok.
[5] I/O uses <stdio> exclusively.
C-Prolog supports ~username/X and $envvar/X expansion, but if the
"unix" identifier is not defined it knows not to ask.
[6] brk() and sbrk() are needed. If you haven't got them, you could
declare a huge array and use that, but that would require source
hacking.
[7] The MAJOR portability problem is that C-Prolog assumes that all
pointers into the area managed by brk() and sbrk() look like
POSITIVE integers. It doesn't matter if the stack or text areas
lie in negative address space (in fact the stack IS in negative
address space on the Perq and Orion). Getting around this would
be a major exercise, not to be undertaken by anyone without a
thorough understanding of the way C-Prolog works. Since we have
a GEC series 63 machine, and since there is some political
pressure to adopt this as a UK IKBS machine (to which application
it is NOT suited, nor any other), and since that machine puts
everything in negative address space, we may produce a version of
C-Prolog which can handle this. But don't hold your breath.
The Perq (running C) and the Orion are both word-addressed. This is
no problem. Getting C-Prolog running on the Orion was a matter of
telling it where to look for its files and saying "make", but then
the Orion, though nothing like a VAX, runs 4.1bsd. Getting it going
on a Perq was harder, but the bugs were in the Perq software, not in
C-Prolog. The main thing anyone porting C-Prolog to a new machine
with a decent C and positive address space should have to worry about
is the sizes of the data areas, in the file parms.c.
To give this message some interest for people who couldn't care
less about porting C-Prolog, here are some general notes on porting
Prolog interpreters written in C. (I've seen seven of them, but not
UNH Prolog.)
A well written Prolog interpreter uses the stdio library, so that
I/O shouldn't be too much of a problem. But it may also want to
rename and/or delete files, to change the working directory, or to
call the command interpreter. These operations should be in one file
and clearly labelled as being operating-system dependent. Porting
from one version of UNIX to another should cause no difficulty, but
there is a problem with calling the shell: people using ?.?bsd will
expect the C-shell, and an interpreter written for V7 may not know
about that. If you change it, be sure to use the environment
variable SHELL to determine what shell to use. (Ports to S3 should
do this too, so that users who are supposed to be restricted to rsh
can't escape to sh via prolog.)
No Prolog implementor worth his salt would dream of using malloc.
As a result, a Prolog interpreter is pretty well bound to use brk()
and/or sbrk(). It may do so only at start-up (C-Prolog does this),
or it may do so dynamically (a Prolog with a garbage collector, and
pitifully few of them have, will probably do this). In either case
allocation is virtually certain to be word-aligned and in units of
words, where a word is a machine pointer.
There are two ways of telling what sort of thing a pointer is
pointing to. One way is to use TAGS, that is to reserve part of the
word to hold a code saying (integer,pointer to atom,pointer to clause
pointer to variable,&c). This is particularly tempting on machines
like the M68000 where part of an address is spare anyway. The other
way is to divide the address space into a number of partitions, such
as (integers, atoms, clauses, global stack, local stack, trail), and
to tell what something points to by checking *where* it points.
C-Prolog could be described as "semi-tagged": integers, floats,
pointers to clauses, and pointers to records all live in the virtual
partition [-2^31,0) and are tagged, pointers to real objects are
discriminated by where they point. Other things being equal, tagged
systems are likely to be slower. But tagged systems should be immune
to the "positive address space problem". So you have to check which
sort your system is. If it is tagged, you should check the macros
for converting between tagged form and machine addresses VERY VERY
carefully. They may not work on your machine, and it may be possible
to do better. Here is an example of what can go wrong.
/* Macro to convert a 24-bit byte pointer and a 6-bit tag to a
32-bit tagged pointer
*/
#define Cons(tag,ptr) (((int)(ptr)<<8) | tag)
/* Macro to extract the tag of a tagged pointer */
#define Tag(tptr) ((tptr)&255)
/* Macro to convert a tagged pointer to a machine pointer */
#define Ptr(tptr) (pointertype)(tptr>>8)
/* Macro to find the number of words between two tagged
pointers
*/
#define Delta(tp1,tp2) (((tp1)-(tp2))>>8)
DRAT! That was meant to be >>10 not >>8.
What can go wrong with this? Well, Delta can go wrong if the machine
uses word addresses rather than byte addresses, in which case it
should be >>8 as I first wrote instead of >>10. Cons can go wrong
if the top bits of a pointer are significant. (On the Orion the top
2 bits and the bottom 24 bits are significant.) Ptr can go wrong
if addresses are positive and user addresses can go over 2^23, in
which case an arithmetic right shift may do horrid things. I have
seen at least two tagged Prolog interpreters which would go wrong on
the Orion.
Prolog interpreters tend to be written by people who do not know
all the obscure tricks they can get up to in C, so at least you ought
not be plagued by the "dereferencing 0" problem.
If anyone reading this Digest has problems porting C-Prolog other
than the positive address space problem, please tell me. I may be
able to help. There is one machine with a C compiler that someone
tried to port it to, and failed, and that is a Z8000 box where the
user's address space is divided up into a lot of 64kbyte chunks, and
the chunks aren7t contiguous! A tagged system could handle that,
though with some pain. C-Prolog can't handle it at all.
If anyone has already ported some version of C-Prolog to another
machine (not a VAX, Perq/UNIX, Orion, or M68000/UNIX) please let me
know so that we can maintain a list of C-Prolog versions, saying
what machine, what problems, and whether your version is available to
people holding an EdCAAD licence.
------------------------------
End of AIList Digest
********************
