From ca-Request@Think.COM  Tue Jan  2 16:06:41 1990
Received: by fafnir.think.com; Tue, 2 Jan 90 16:06:41 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Tue, 2 Jan 90 16:06:35 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Tue, 2 Jan 90 16:09:10 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA24345; Tue, 2 Jan 90 15:31:27 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 2 Jan 90 14:05:15 GMT
From: mcsun!ukc!tcdcs!tcdmath!dbell@uunet.uu.net  (Derek Bell)
Organization: Maths Dept., Trinity College, Dublin
Subject: Re: Gosper's Algorithm for Life
Message-Id: <1279@hamilton.maths.tcd.ie>
References: <1989Dec27.174849.13469@cs.rochester.edu>
To: ca@Think.COM

In article <1989Dec27.174849.13469@cs.rochester.edu> dietz@cs.rochester.edu (Paul Dietz) writes:
}I would be grateful if someone could send me a copy of an
}implementation of Gosper's algorithm for 2-D cellular automata
}(Physica 10D (1984), pp 75-80), preferably in C or Pascal.  
}
}I'd also be interested in hearing about practical experience with
}his algorithm, and comparisons to other algorithms.


		I'm interested too.


-- 
Derek Bell         |To everyone is given the key to heaven, the same key opens
dbell@maths.tcd.ie | the gates of hell	 --   Ancient proverb
belld@vax1.tcd.ie  |

From ca-Request@Think.COM  Mon Jan  8 00:43:32 1990
Received: by fafnir.think.com; Mon, 8 Jan 90 00:43:32 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Mon, 8 Jan 90 00:43:25 EST
Received: from MITVMA.MIT.EDU by Think.COM; Mon, 8 Jan 90 00:43:26 -0500
Message-Id: <9001080543.AA22837@Think.COM>
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 3211; Mon, 08 Jan 90 00:43:29 EST
Received: by MITVMA (Mailer R2.05) id 2853; Mon, 08 Jan 90 00:43:29 EST
Date:         Mon, 08 Jan 90 00:42:34 EST
From: anthony taylor <S20081@mitvma.mit.edu>
Subject:      subscribe
To: ca@Think.COM

please add me to the list

From ca-Request@Think.COM  Mon Jan  8 02:10:05 1990
Received: by fafnir.think.com; Mon, 8 Jan 90 02:10:05 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Mon, 8 Jan 90 02:10:01 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Mon, 8 Jan 90 02:09:58 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA22838; Mon, 8 Jan 90 01:11:48 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 7 Jan 90 22:27:42 GMT
From: samsung!caesar.cs.montana.edu!ogicse!emory!hubcap!ncrcae!usceast!park@Think.COM  (Kihong Park)
Organization: University of South Carolina, Columbia
Subject: S. Wolfram and computational irreducibility
Message-Id: <3035@usceast.UUCP>
To: ca@Think.COM

Steven Wolfram has coined a term called "computational irreducibility" to
mean(to the best of my interpretation) that for cellular automata 
capable of universal computation, there exist problems concerning their
behavior which are undecidable. That is, to compute the global configuration
of a CA at the n'th iterative step, in general, an algorithm has no
recourse but to compute(i.e., simulate) all the intermediate steps to
arrive at the outcome.

This is all dandy and fine since the undecidability of the halting problem
and other undecidable problems have been known for some time. But here is
the problem that I have: He seems to very well know that the concept of
undecidability is applicable only to problems which have an infinite number
of instances. This means that IN GENERAL, there does not exist an algorithm,
i.e., a halting turing machine which solves the halting problem for any
turing machine / input word pair. But in some of his writings where he
uses the term "computational irreducibility"(a listing is appended), he
makes statements strongly suggesting(this is my subjective impression) that
even for individual problem instances, one has no recourse but to explicitly
simulate a computational process(e.g. CA) to compute its outcome.

Based on this, he makes "matter of fact" claims that many physical systems
are of such character and hence their exact behavior predictable by observation
through explict simulation only. It annoys me that he uses undecidability
results in such a free and rather misleading fashion. Undecidability, and hence
computational irreducibility(as he uses it) are results of a very general 
character and hence not applicable to everyday problem instances. One should not
confuse problems having infinite instances with "one-instance" problems.

Here is a problem where the term "computational irreducibility" takes on a
more comprehensive meaning, but totally different in its implication and
interpretation from what Steven Wolfram has used:
One can write a procedure for computing the decimal expansion of root of 2
which at every interative i'th step outputs the i'th digit of the expansion.
One can then ask a question such as, "will the one-way infinite sequence
associated with this non-halting procedure contain a finite substring of
some specified pattern?". To the best of my knowledge, there do not exist 
known short-cuts to answering this question without peforming the computation
ad infinitum in case the answer to the question is "no".   

For this question, and for any other one-instance problems, undecidability
results are of no use. This is so because undecidability of the halting
problem does not imply that there exist halting problem instances for
which the answer cannot be obtained by effective means. Hence a valid
question and more interesting usage of the term "computational irreducibility"
would be its association with one-instance problems. Thus, a generalization 
of the root of 2 problem would be as follows:
Does there exist a non-halting procedure with its corresponding infinite
sequence such that to compute the n'th symbol of the sequence, the n-1 preceding
output symbols have to be computed, i.e., there does not exist a short-cut?
If indeed this can be proven, then one has good occasion to use the term
"computational irreducibility" to describe this situation. Moreover, one can
modify the infinite procedure so that it halts if and only if the associated
infinite sequence contains a finite subsequence satifying a certain computable
condition. In addition, if one can show that there must exist computable
properties of the associated infinite sequence that are false, one has a proof
of the halting problem.

I would be thankful for comments regarding a proof for the redefined 
"computational irreducibility" concept as illustrated above. Here are some
references to Steven Wolfram's articles:

1. S. Wolfram "Origins of randomness in physical systems", Phys.Rev.Lett.55,
	1985,449.
2. S. Wolfram "Undecidability and intractability in theoretical physics",
	Phys.Rev.Lett.54,1985,735.
3. S. Wolfram "Twenty Problems in the Theory of Cellular Automata", Physica
	Scripta, Vol.T9,170-183,1985.

From ca-Request@Think.COM  Mon Jan  8 03:12:17 1990
Received: by fafnir.think.com; Mon, 8 Jan 90 03:12:17 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Mon, 8 Jan 90 03:12:14 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Mon, 8 Jan 90 03:12:13 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA25095; Mon, 8 Jan 90 02:14:33 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 8 Jan 90 06:56:00 GMT
From: ucrmath!x!baez@ucsd.edu  (john baez)
Organization: University of California, Riverside
Subject: Re: S. Wolfram and computational irreducibility
Message-Id: <3231@ucrmath.UCR.EDU>
References: <3035@usceast.UUCP>
To: ca@Think.COM

In article <3035@usceast.UUCP> park@usceast.uucp.UUCP (Kihong Park) writes:

>Here is a problem where the term "computational irreducibility" takes on a
>more comprehensive meaning, but totally different in its implication and
>interpretation from what Steven Wolfram has used:
>One can write a procedure for computing the decimal expansion of root of 2
>which at every interative i'th step outputs the i'th digit of the expansion.
>One can then ask a question such as, "will the one-way infinite sequence
>associated with this non-halting procedure contain a finite substring of
>some specified pattern?". To the best of my knowledge, there do not exist 
>known short-cuts to answering this question without peforming the computation
>ad infinitum in case the answer to the question is "no".   
>
>For this question, and for any other one-instance problems, undecidability
>results are of no use. This is so because undecidability of the halting
>problem does not imply that there exist halting problem instances for
>which the answer cannot be obtained by effective means. Hence a valid
>question and more interesting usage of the term "computational irreducibility"
>would be its association with one-instance problems. Thus, a generalization 
>of the root of 2 problem would be as follows:
>Does there exist a non-halting procedure with its corresponding infinite
>sequence such that to compute the n'th symbol of the sequence, the n-1 preceding
>output symbols have to be computed, i.e., there does not exist a short-cut?
>If indeed this can be proven, then one has good occasion to use the term
>"computational irreducibility" to describe this situation. Moreover, one can
>modify the infinite procedure so that it halts if and only if the associated
>infinite sequence contains a finite subsequence satifying a certain computable
>condition. In addition, if one can show that there must exist computable
>properties of the associated infinite sequence that are false, one has a proof
>of the halting problem.
>
>I would be thankful for comments regarding a proof for the redefined 
>"computational irreducibility" concept as illustrated above. 

It seems that you are working your way towards the concept of
algorithmic randomness, closely tied to Kolmogorov complexity.
References include: 

Li, M.  and Paul Vitanyi, Kolmogorov Complexity and Its
Applications, in
Handbook of Theoretical Computer Science, (J. van Leeuwen, Ed.)
North-Holland, 1989.
 
A preliminary version of the same work is in the Proceedings
of the 3d IEEE Structure in Complexity Theory Conference, 1988.
 
The same authors have a book out by Addison-Wesley,
An Introduction to Kolmogorov Complexity and its Applications (1989).
   
Chaitin has developed the idea of algorithmic randomness:

Chaitin, G.J., "Randomness and Mathematical Proof"
Scientific American, 232 (May 1975), pp47-52
 
Chaitin, G.J., "Algorithmic Information Theory", IBM J. Res.
Dev. 21, 350-359 (1977)
 
Chaitin, G.J.,  Information, Randomness and Incompleteness.
(World Scientific Pub, 1987)

other surveys are:
Zvonkin, A.K. and L.A. Levin, "The complexity of finite
objects and the development of the concepts of information
and randomness by the means of the Theory of Algorithms",
Russ. Math. Survey 25, 83-124 (1970)
 
Schnorr, C.P., "A survey of the theory of random sequences",
in Basic Problems in Methodology and Linguistics (Butts, R.E. Ed.)
1977, pp. 193-210.
 
If Wolfram hasn't defined `computational irreducibility',
he may have some of these concepts in mind, more or less
vaguely (I haven't read the references you cite).  Perhaps
even more relevant is the notion of `logical depth' due to 
Charles Bennett, which grew out of the above work.  
I have a preprint of his entitled "On the logical "depth"
of sequences and their reducibilities to incompressible 
sequences".  (The title should indicate the relation to
`computational irredubility'.)   

It's late here, so rather than try to explain how I think
these notions could address your (very valid, in my
opinion) complaints, I'll just quote a bit from the 
Bennett paper: `Roughly speaking, a finite object's
information content is the size of its most concise
description, and its "logical depth", or stored 
mathematical work, is the time required to reconstruct it from 
that description [he gives precise definitions].... 
A "deep" or dynamically complex object would then be one whose most
plausible origin, via an effective process, entails a lengthy
computation.'  One could hope to prove that certain 
INDIVIDUAL states or histories of certain cellular automata are
logically deep.


object '

From ca-Request@Think.COM  Mon Jan  8 07:35:20 1990
Received: by fafnir.think.com; Mon, 8 Jan 90 07:35:20 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Mon, 8 Jan 90 07:35:13 EST
Received: from cod.nosc.mil by Think.COM; Mon, 8 Jan 90 07:35:12 -0500
Received: by cod.nosc.mil (5.59/1.27)
	id AA23319; Mon, 8 Jan 90 04:35:07 PST
Date: Mon, 8 Jan 90 04:35:07 PST
From: desmond@cod.nosc.mil (J. Desmond)
Message-Id: <9001081235.AA23319@cod.nosc.mil>
To: ca@Think.COM
Subject: unsubscribe

-------
Please remove me from the list.  Thank you.
-jmd
-------


From ca-Request@Think.COM  Mon Jan  8 15:10:32 1990
Received: by fafnir.think.com; Mon, 8 Jan 90 15:10:32 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Mon, 8 Jan 90 15:10:23 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Mon, 8 Jan 90 15:10:22 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA02204; Mon, 8 Jan 90 15:02:00 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 8 Jan 90 18:02:31 GMT
From: ogicse!emory!hubcap!ncrcae!usceast!park@ucsd.edu  (Kihong Park)
Organization: University of South Carolina, Columbia
Subject: Fo:S. Wolfram and computational irreducibility
Message-Id: <3038@usceast.UUCP>
To: ca@Think.COM

Here are the results that I have corresponding to the problem of revised
definition of "computational irreducibility" which I posted. Results from
algorithmic information theory are utilized to deduce the results:

computational irreducibility of

(1) finite sequences
Given a finite sequence w over some alphabet set, let w be algorithmically
random, i.e., the size of the minimum program generating w on some standard
universal turing machine is approximately |w|. Then any such minimal program
P capable of generating w will more or less "copy" w to the output from
an internal storage, or from its input. No compaction is possible.
Since P is the most compact representation of w, to generate the whole of
w, the amount of computation done by P is the minimum one, and hence
"computationally irreducible". 

The above generalizes straightforwardly to algorithmically non-random
sequences. If w is any such sequence then its minimum program P(need not
be unique) is its most compact representation, and hence to generate the
whole of w, again the amount of computation required by P is 
"computationally irreducible".

(2) infinite sequences
Given an infinite sequence(one-way) w and a minimal program P which generates
it, by the same reasoning as above, the amount of computation needed by
P to produce w is "computationally irreducible". 
By the definition of infinite random sequences, no such program, i.e., a
finitely specifiable procedure can correspond to an infinite random sequence.
We are implicitly implying that the turing machines acting as generators be
deterministic.

As the above definitions show, there exist programs whose corresponding
sequences to generate in full, the amount of work required by the program
is minimum, and hence computationally irreducible.
But here is a problem that even the above given definition carries: 
although to faithfully produce a given sequence w in full, the amount of
computation needed by a corresponding minimal program is "computationally
irreducible", this definition is a more or less obvious observation. When
one investigates "one-instance" problems, one asks questions pertaining
to the properties of the problems, and in case of the root-of-2 problem
described in the previous posting(the question asks whether in the decimal
expansion of root-of-2 there exists a finite substring of some specified
pattern), the definition given above does not imply that to answer this
question one has theoretically no recourse but to explicitly simulate
the algorithm ad infinitum to obtain the answer. As far as I know, 
knowledge about the properties of root-of-2 is still meager, but this
does not mean that a better understanding of this infinite sequence is
not possible.
Hence, in general, when one asks questions about properties of infinite
sequences and their associated generators, these properties are independent
of the generating mechanism, and thus the definition given above is of
little use. By properties of infinite sequences, I will mean computable
functions on the subsequences of the sequence. If we call the above definition
a "weak" computational irreducibility then a "strong" definition would
say that there exist sequences with their generators such that there are
properties of the sequence which can be computed only by explicitly
generating the whole sequence.
I am investigating these issues basically because I am trying to understand
infinite sequences from a computational point of view. Questions arising
in chaos theory deal with infinite processes(iterative equations) whose
behavior one wants to analyze. Hence, understanding the nature of
interesting infinite sequences(a subset of the computable irrational numbers)
seems to be a core problem at hand.
I would appreciate any suggestions corresponding to the definitions and
problems cited above.

From ca-Request@Think.COM  Mon Jan 15 18:08:15 1990
Received: by fafnir.think.com; Mon, 15 Jan 90 18:08:15 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Mon, 15 Jan 90 18:08:08 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Mon, 15 Jan 90 18:08:08 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA09080; Mon, 15 Jan 90 17:49:10 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 15 Jan 90 22:26:25 GMT
From: snorkelwacker!usc!brutus.cs.uiuc.edu!rpi!image.soe.clarkson.edu!sunybcs!uhura.cc.rochester.edu!rochester!dietz@bloom-beacon.mit.edu  (Paul Dietz)
Organization: University of Rochester Computer Science Department
Subject: Re: Gosper's Algorithm for Life
Message-Id: <1990Jan15.222625.19716@cs.rochester.edu>
References: <1989Dec27.174849.13469@cs.rochester.edu>, <1279@hamilton.maths.tcd.ie>
To: ca@Think.COM

Thanks for the folks who sent me a copy of Lucas' C implementation
of Gosper's Hashlife algorithm.

I was wondering how good you could do with other algorithms.  I came
up with an implementation of an algorithm on my Sparcstation 1 that
does all 1103 generations of the R-pentomino, including the gliders,
in 1.3 seconds (no display), and runs

	o.....o.
	..o...o.
	..o..o.o
	.o.o....

(a pattern by Wainright recommended to me by Gosper) out to 10,000
generations in 45 seconds (again, without display).

	Paul

From ca-Request@Think.COM  Thu Jan 18 14:07:14 1990
Received: by fafnir.think.com; Thu, 18 Jan 90 14:07:14 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Thu, 18 Jan 90 14:07:03 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Thu, 18 Jan 90 14:07:00 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA01724; Thu, 18 Jan 90 13:52:06 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 18 Jan 90 00:51:20 GMT
From: cs.utexas.edu!hellgate.utah.edu!mailrus!ukma!xanth!cs.odu.edu!saur@yale-zoo.arpa  (Joseph M. Saur)
Organization: Old Dominion University, Norfolk, VA
Subject: Artificial Life
Message-Id: <11039@xanth.cs.odu.edu>
To: ca@Think.COM


----------------------------------------------------------------------------
     Computer Science graduate student interested in doing Artificial Life
project seeks biology major for joint effort.  Project is to replicate, on
a computer, typical microbial growth patterns.  Currently have four small
programs running, duplicating following experiments dimly remembered from
Microbial Physiology class taken some 20-odd years ago:

            1. comparison of growth on two media, one of which provides
                twice the energy per pixel as the other;
            2. growth on medium where one portion has had heavy metal
                ions (growth inhibitors) added;
            3. growth on a medium consisting of four substrate molecules:
                lactate, ammonia, phosphate, potassium, where approximately
                equal numbers of each is necessary for growth and division;
            4. change in genetic structure over time based on two factors:
                - constant mutation rate,
                - change in enviornment.

Please send mail to:    saur@cs.odu.edu

                        Joseph M. Saur
                        3801 Hearthside Lane
                        Virginia Beach, VA 23456

           or phone:    (804)-444-6669/5982 (w) 
                        (804)-471-7953 
----------------------------------------------------------------------------

From ca-Request@Think.COM  Sun Jan 21 02:07:10 1990
Received: by fafnir.think.com; Sun, 21 Jan 90 02:07:10 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Sun, 21 Jan 90 02:07:07 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Sun, 21 Jan 90 02:07:13 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA24987; Sun, 21 Jan 90 01:29:16 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 21 Jan 90 00:10:47 GMT
From: hpda!hpcuhc!voliva@bloom-beacon.mit.edu  (Val Oliva)
Organization: Hewlett Packard, Cupertino
Subject: CA Lab
Message-Id: <4560002@hpcuhc.HP.COM>
To: ca@Think.COM



     I took a class in Cellular Automata at San Jose State U. under  
Dr. Rudy Rucker. With the class, he used his new package which he
developed while working for Autodesk (famous for AutoCad products).
The package was called CALab.

     I enjoyed the class very much, but I don't know if anybody has
ever used his package. The package is very flexible, since it allows 
the user to develop his own CA experiments with little amount of 
coding. The interface can be written with the use of the ff. languages: 
a) C, b) Pascal , c) Basic, & d) Assembly. It also comes with several
patterns that can be used for seeding CA's. I used an EGA monitor, but 
latter found out that it was more realistic in a VGA screen.

    I can go on and describe the class, but I am curious to how other 
people feel about the package. I want to know especially if they have 
done any experiments on the package. I am also curious at what you 
think about the package. I am willing to share some programs that we 
made during the class (I was known to make programs that was always 
titled "GROWTH". A little class humor, you just have to be there to know
this .)

     You can E-mail me at voliva@hpcuhc.HP.COM. Any review or response 
would be gladly be appreciated.

Thank you,
Val Oliva
   

From ca-Request@Think.COM  Tue Jan 23 11:58:05 1990
Received: by fafnir.think.com; Tue, 23 Jan 90 11:58:05 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Tue, 23 Jan 90 11:58:01 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Tue, 23 Jan 90 11:58:07 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA12253; Tue, 23 Jan 90 11:28:50 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 23 Jan 90 16:23:27 GMT
From: marek@iuvax.cs.indiana.edu  (Marek Lugowski)
Subject: Computational Metabolism on a Connnection Machine and Other Stories...
Message-Id: <33716@iuvax.cs.indiana.edu>
To: ca@Think.COM


     Indiana University Computer Science Departamental Colloquium

   Computational Metabolism on a Connection Machine and Other Stories...
   ---------------------------------------------------------------------
	   Elisabeth M. Freeman, Eric T. Freeman & Marek W. Lugowski
	    graduate students, Computer Science Department
			  Indiana University

		Wednesday, 31 January 1990, 7:30 p.m.
			Ballantine Hall 228
	   Indiana University campus, Bloomington, Indiana


This is work in progress, to be shown at the Artificial Life Workshop II,
Santa Fe, February 5-9, 1990.  Connection Machine (CM) is a supercomputer
for massive parallelism. Computational Metabolism (ComMet) is such computation.
ComMet is a tiling where tiles swap places with neighbors or change their
state when noticing their neighbors.  ComMet is a programmable digital liquid.

Reference: Artificial Life, C. Langton, ed., "Computational Metabolism:
   Towards Biological Geometries for Computing", M. Lugowski, pp. 343-368,
   Addison-Wesley, Reading, MA: 1989, ISBN 0-201-09356-1/paperbound.
		
Emergent mosaics:
----------------
This class of ComMet instances arise from generalizing the known
ComMet solution of Dijkstra's Dutch Flag problem.  This has implications
for cryptology and noise-resistant data encodings.  We observed deterministic
and indeterministic behavior intertwined, apparently a function of geometry.

A preliminary computational theory of metaphor:
----------------------------------------------
We are working on a theory of metaphor as transformations within ComMet.
Metaphor is loosely defined as expressing one entity in terms of another,
and so it must underlie categorization and perception.  We postulate that
well-defined elementary events capable of spawning an emergent computation
are needed to encode the process of metaphor.  We use ComMet to effect this.

A generalization of Prisoner's Dilemma (PD) for computational ethics:
---------------------------------------------------------------------
The emergence of cooperation in iterated PD interactions is known.
We propose a further generalization of PD into a communication between two
potentially complex but not necessarily aware of each other agents.  These
agents are expressed as initial configurations of ComMet spatially arranged
to allow communication through tile propagation and tile state change.

Connection Machine (CM) implementation:
--------------------------------------
We will show a video animation of our results, obtained on a 16k-processor CM,
including emergent mosaics, thus confirmed after we predicted them
theoretically.  Our CM program computes in 3 minutes what took 7 days to do on
a Lisp Machine.  Our output is a 128x128 color pixel map.  Our code will
run in virtual mode, if need be, with up to 32 ComMet tiles per CM processor,
yielding a 2M-tile tiling (over 2 million tiles) on a 64k-processor CM.

From ca-Request@Think.COM  Tue Jan 23 17:50:29 1990
Received: by fafnir.think.com; Tue, 23 Jan 90 17:50:29 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Tue, 23 Jan 90 17:50:23 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Tue, 23 Jan 90 17:50:28 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA29805; Tue, 23 Jan 90 17:49:07 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 23 Jan 90 19:24:57 GMT
From: brunix!man@uunet.uu.net  (Mark H. Nodine)
Organization: Brown University Department of Computer Science
Subject: Re: CA Lab
Message-Id: <26333@brunix.UUCP>
References: <4560002@hpcuhc.HP.COM>
To: ca@Think.COM

The CALab software was featured in A.K. Dewdney's Computer Recreations
column of the January 1990 Scientific American.  He had high praise for
it and described several automata machines that were of interest.

	--Mark

From ca-Request@Think.COM  Tue Jan 23 20:38:34 1990
Received: by fafnir.think.com; Tue, 23 Jan 90 20:38:34 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Tue, 23 Jan 90 20:38:24 EST
Received: from sharkey.cc.umich.edu by Think.COM; Tue, 23 Jan 90 20:38:30 -0500
Received: from ubmts.cc.umich.edu by sharkey.cc.umich.edu (5.61/1123-1.0)
	id AA19778; Tue, 23 Jan 90 20:36:38 -0500
Date: Tue, 23 Jan 90 20:36:54 EST
From: Tony_Audas@ub.cc.umich.edu
To: ca@Think.COM
Message-Id: <4365828@ub.cc.umich.edu>
Subject: review of ca lab

CA Lab from Autodesk, 59.95 list, consists of two programs, rc and ca.
 
RC is by rudy rucker. it operates in text mode (all video modes) and runs variou
s cellular automaton rules on an 8bit cell.  one rule uses the 256 characters
to do a 64k state cell. the built-in rules provide many possibilities, but are
not programmable.  on a 6MHz AT most rules run at a rate fast enuf to 'move'.
lots of parameters to play with in the built-in rules.
 
CA is by john walker. it operates in graphics mode, best in vga.  an 8bit
(256 state) cell is simulated, with 1 bit of 'looking at neighbors'.  a 
state table is used to implement the rule:
 carule = f(cellstate,N,NE,E,SE,S,SW,W,NW)
source is provided to take your function (in c, basic, pascal) and create a 
new state table.  it is also possible to implement (in asm) new evaluators
that can look at more bits or at nonlocal neighbors (action at a distance).
rules provided simulate heat transfer, accretion, lattice gases/diffusion,
and many others
 
the manual is excellent, including good explanations of what is going on,
both mathematically and computerwise.  sections include 'why ca?' and a ca 
history
 
i got mine (at a discount from list) from a local autodesk dealer.
unconditionally recommended.

From ca-Request@Think.COM  Tue Jan 23 22:33:35 1990
Received: by fafnir.think.com; Tue, 23 Jan 90 22:33:35 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Tue, 23 Jan 90 22:33:32 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Tue, 23 Jan 90 22:33:39 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA09066; Tue, 23 Jan 90 21:59:48 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 24 Jan 90 02:34:36 GMT
From: saturn!xanthian@AMES.ARC.NASA.GOV  (Metafont Consultant Account)
Organization: Advanced Decision Systems, Mt. View, CA (415) 960-7300
Subject: Re: CA Lab
Message-Id: <10590@saturn.ADS.COM>
References: <4560002@hpcuhc.HP.COM>, <26333@brunix.UUCP>
To: ca@Think.COM

In article <26333@brunix.UUCP> man@cs.brown.edu (Mark H. Nodine) writes:
>The CALab software was featured in A.K. Dewdney's Computer Recreations
>column of the January 1990 Scientific American.  He had high praise for
>it and described several automata machines that were of interest.
>
>	--Mark


Just in passing, anybody know why the Computer Recreations column was
missing in the Feb 1990 Scientific American?

--
Again, my opinions, not the account furnishers'.

xanthian@well.sf.ca.us  xanthian@ads.com (Kent Paul Dolan)
Kent, the (bionic) man from xanth, now available as a build-a-xanthian
kit at better toy stores near you.  Warning - some parts proven fragile.
-> METAFONT, TeX, graphics programming done on spec -- (415) 964-4486 <-

From ca-Request@Think.COM  Tue Jan 23 22:34:22 1990
Received: by fafnir.think.com; Tue, 23 Jan 90 22:34:22 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Tue, 23 Jan 90 22:34:19 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Tue, 23 Jan 90 22:34:22 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA08956; Tue, 23 Jan 90 21:56:47 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 24 Jan 90 01:36:54 GMT
From: UB.CC.UMICH.EDU!Tony_Audas@bloom-beacon.mit.edu
Organization: The Internet
Subject: review of ca lab
Message-Id: <4365828@ub.cc.umich.edu>
To: ca@Think.COM

CA Lab from Autodesk, 59.95 list, consists of two programs, rc and ca.
 
RC is by rudy rucker. it operates in text mode (all video modes) and runs variou
s cellular automaton rules on an 8bit cell.  one rule uses the 256 characters
to do a 64k state cell. the built-in rules provide many possibilities, but are
not programmable.  on a 6MHz AT most rules run at a rate fast enuf to 'move'.
lots of parameters to play with in the built-in rules.
 
CA is by john walker. it operates in graphics mode, best in vga.  an 8bit
(256 state) cell is simulated, with 1 bit of 'looking at neighbors'.  a 
state table is used to implement the rule:
 carule = f(cellstate,N,NE,E,SE,S,SW,W,NW)
source is provided to take your function (in c, basic, pascal) and create a 
new state table.  it is also possible to implement (in asm) new evaluators
that can look at more bits or at nonlocal neighbors (action at a distance).
rules provided simulate heat transfer, accretion, lattice gases/diffusion,
and many others
 
the manual is excellent, including good explanations of what is going on,
both mathematically and computerwise.  sections include 'why ca?' and a ca 
history
 
i got mine (at a discount from list) from a local autodesk dealer.
unconditionally recommended.

From ca-Request@Think.COM  Tue Jan 23 23:25:10 1990
Received: by fafnir.think.com; Tue, 23 Jan 90 23:25:10 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Tue, 23 Jan 90 23:25:05 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Tue, 23 Jan 90 23:25:12 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA12619; Tue, 23 Jan 90 23:09:05 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 24 Jan 90 03:52:51 GMT
From: zaphod.mps.ohio-state.edu!rpi!rpi.edu!hiebeler@Think.COM  (Dave Hiebeler)
Organization: RPI CS Dept, and LANL Center for Nonlinear Studies
Subject: CA Lab reviews
Message-Id: <HIEBELER.90Jan23225133@turing.cs.rpi.edu>
To: ca@Think.COM


  I was surprised to see Val Oliva (in message
<4560002@hpcuhc.HP.COM>) ask about CA Lab, since Jonathan Mills had
asked about it back in December, in message
<31980@iuvax.cs.indiana.edu>, and a couple of people (including
myself) replied.

  For those who aren't aware of it, archives of this CA newsgroup and
mailing list are kept on the host think.com, which is a very nice
service to have.  The 1989 archive has my review of CA Lab, and a
review by Keith Morgan of Data General Corp.  The reviews were
somewhat negative, depending on what you want to do with CA.  If
you're more of a hobbyist, CA Lab isn't too bad.  If you're seriously
into CA, particularly for physical modeling applications, you might
not like the package so much.

  To get the 1989 archive, you can ftp to think.com (131.239.2.1),
with the username "anonymous" (and your e-mail address for a
password).  The archive is in the directory "mail", and is called
"ca.archive-1989".  It's about 200K bytes.  Archives for other years
are there too, although 1990 doesn't seem to be there yet.  My review
of CA Lab is on line 3802, Keith Morgan's is around line 3915.

  If you FTP the archives, try to do it after hours.  It's very handy
having the archives there, so please don't abuse the service.  (I'm
not associated with Thinking Machines Corp, I'm just a concerned
citizen). :-)

--
Dave Hiebeler                       hiebeler@turing.cs.rpi.edu
Computer Science Dept.              hiebeler@cardinal.lanl.gov
Amos Eaton Bldg.                       "xue zai shao"  -- Huang Ying Ying
Rensselaer Polytechnic Institute / Troy, NY 12180-3590

From ca-Request@Think.COM  Sat Jan 27 15:40:13 1990
Received: by fafnir.think.com; Sat, 27 Jan 90 15:40:13 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Sat, 27 Jan 90 15:40:00 EST
Received: from NSFNET-RELAY.AC.UK by Think.COM; Sat, 27 Jan 90 15:38:43 -0500
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK 
           via Janet with NIFTP  id aa01957; 27 Jan 90 13:44 GMT
Date: Sat, 27 Jan 90 13:44:22 GMT
From: John McMillan <PHY6JEM%cms1.ucs.leeds.ac.uk@NSFnet-Relay.AC.UK>
To: CA <@NSFnet-Relay.AC.UK:CA@think.com>
Message-Id: <27 Jan 90 13:46:43 GMT #1865@UK.AC.LEEDS.CMS1>

Science Progress, 7, pp656-657, 1913

                      REVIEWS

"The Origin of Life: being an account of Experiments with certain
superheated Saline Solutions in Hermetically Sealed Vessels".
By H.Charlton Bastian, M.D., F.R.S. Second Edition. [Pp.98 with 12
plates.] (London: Watts & Co., 1913. Price 3s.6d. net)

Dr.Charlton Bastian is nothing if not persistent.  The volume under
notice is a second edition of his well-known essay, together with an
appendix - termed important on the title-page, this being a paper
read by him, so recently as November 19, 1912, before the Pathology
section of the Royal Society of Medicine.  Apparently he has been
spurred to this fresh effort by the discussion on the Origin of Life
which took place at the British Association in September last.
  Dr.Bastian's essay is a pathetic document, as showing how easy it
is for a man to persuade himself into believing the impossible.
Not a few scientific workers will be in full sympathy with him on
account of the transparent sympathy of his convictions, though they
may refuse altogether to accept his experiments as satisfactory.
[Two paragraphs on Bastian's debate with the Royal Society omitted]
  There is much food for thought in Dr.Bastian's volume.  It would be
wrong to say seriously that it is full of absurdities - and yet such an
expression is almost the only one that does justice to its argument.
The immensity of the problem considered is patent: Dr.Bastian's failure
to appreciate the gravity of the issues his contributions raise is
only too obvious.  Psychologically his attitude is one that deserves most
careful consideration - it illustrates both the difficulty that attends
the interpretation of the complexities of nature and our human tendency
to take ourselves seriously as capable exponents of her workings.
Dr.Bastian claims to have produced 'Torulae' in his latest experiments
from solutions containg only, to each ounce of distilled water, either
a few drops of 'liquor ferri pernitratis' or a few drops each of a dilute
solution of of sodium silicate and dilute phosphoric acid together with a
few grains of ammonia phosphate.  In his latest experiments, he used pure
colloidal silica prepared by Graham's method in place of the silicate.
  In opposing Dr.Bastian, Huxley doubtless was influenced mainly by his
feelings but sustained argument may now be substituted for his
sledge-hammerism.  In the interval we have learned much regarding the
structure of the constituents of the protoplasmic complex - the nature
and functions of enzymes have been made more or less clear to us - even
simple organisms such as Dr.Bastian asks us to believe were produced
'de novo' in his tubes have been shown to be of extraordinarily complex
structure and capable of exercising both the synthetic and analytic
operations characteristic of organisms far higher in the scale - the
chemist has also discovered that Nature has developed extraordinary
powers of selecting out a certain limited set of materials for use in
her building operations: those who understand these things feel that it
is simply inconceivable that life can ever arise from materials such as
Dr.Bastian has used and during times such as were covered by his
experiments.  Bacteriologists have accumulated a vast fund of experience:
if the calling of living things into being were the easy process he
imagines, his observations would have been corroborated and his
contentions admitted over and over again.
  With regret we must conclude that Dr.Bastian has never been a
competent critic of his own proceedings but he is in no way singular.
Much of the so-called research work of our time would never see daylight
if those who perpetrate it were better informed and sufficiently modest
to be conscious of their inability to deal with the tasks which they
have had the temerity to undertake.  This is the coming difficulty in
science; the rank and file will continue to do good hoe and spade work
so long as they are prepared to subordinate themselves to competent
leaders but it will be possible to trust but the very few to deal with
the more comprehensive problems  or to base generalisations upon the
scattered observations of the multitude.  It is in this direction,
we may hope, a regenerate and virile Royal Society will be able to
serve the State - in promoting Natural Knowledge by judiciously
organising, criticising annd controlling the exercise of scientific
effort.

[end of review]

Article found and retyped by John McMillan,
                             Department of Physics,
                             University of Leeds,
                             Leeds LS2 9JT,
                             Great Britain.

                             phy6jem @ cms1.leeds.ac.uk

From ca-Request@Think.COM  Mon Jan 29 21:16:36 1990
Received: by fafnir.think.com; Mon, 29 Jan 90 21:16:36 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Mon, 29 Jan 90 21:16:33 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Mon, 29 Jan 90 21:16:59 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA10939; Mon, 29 Jan 90 20:48:55 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 25 Jan 90 10:12:00 GMT
From: mcsun!ukc!icdoc!qmw-cs!alex@uunet.uu.net  (Alex Kashko)
Organization: Dept. Of Physics. University of Edinburgh. Scotland.
Subject: Re: Cellular Automata Laboratory
Message-Id: <1561@sequent.cs.qmw.ac.uk>
References: <31980@iuvax.cs.indiana.edu>, <1687@xyzzy.UUCP>
To: ca@Think.COM


	Re the CAM. Can some one supply speeds of execution. I have a
prototype version of Toffoli and Margulus automaton "Lichens with death"
running on the AMT DAP510 which takes about 118 seconds CPU time to perform
1000 updates on a 512 by 512 grid, and I'd like to know how this compares with the CAM.  I would also be interested in the public domain automata simulator as I would like to replicate and extend it on the DAP.

From ca-Request@Think.COM  Wed Jan 31 02:13:51 1990
Received: by fafnir.think.com; Wed, 31 Jan 90 02:13:51 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Wed, 31 Jan 90 02:13:47 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Wed, 31 Jan 90 02:14:24 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA17186; Wed, 31 Jan 90 02:00:52 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 31 Jan 90 04:08:18 GMT
From: snorkelwacker!usc!cs.utexas.edu!uwm.edu!rpi!hiebeler@bloom-beacon.mit.edu  (Dave Hiebeler)
Organization: RPI CS Dept, and LANL Center for Nonlinear Studies
Subject: CA on AMT DAP (Was Re: Cellular Automata Laboratory)
Message-Id: <VM16}-@rpi.edu>
References: <1561@sequent.cs.qmw.ac.uk>
To: ca@Think.COM

In article <1561@sequent.cs.qmw.ac.uk> alex@cs.qmw.ac.uk (Alex Kashko) writes:

> 	Re the CAM. Can some one supply speeds of execution. I have a
> prototype version of Toffoli and Margulus automaton "Lichens with death"
> running on the AMT DAP510 which takes about 118 seconds CPU time to perform
> 1000 updates on a 512 by 512 grid, and I'd like to know how this
> compares with the CAM.  I would also be interested in the public
> domain automata simulator as I would like to replicate and extend it
> on the DAP.


  Well, you are taking 0.118 seconds to update an array 4 times as
large as the CAM array (twice as wide, twice as high), so it would
take you (0.118 / 4) or 0.0295 seconds to update the CAM array.

  The CAM does it in about 0.0166 seconds.

  So you'd be getting about 33 frames/second on a 256x256 array, where
CAM gives you 60 frames/second, almost twice as fast.

  Keep in mind that the CAM costs on the order of $2000, and that you
can buy a few of them and plug them in together.  So you could buy
four CAMs and plug them in together to update a 512x512 array at 60
frames/sec, which would be 8 times as fast as the DAP.  Also, the CAM
lets you do some amount of data-processing without slowing down the
simulation (the newer version of CAM, called CAM-PC which will be
coming out from Automatrix, has much better data-analysis capabilities
than CAM-6).

  About how much does a DAP such as the one you are using cost?  We
have one of their machines here at RPI, but I haven't gotten around to
using it yet, although it sounds like a pretty decent machine.  I
generally use the CAM, but I use Connection Machines when I need to
do something too big for CAM.
-- 
Dave Hiebeler                       hiebeler@turing.cs.rpi.edu
Computer Science Dept.              hiebeler@cardinal.lanl.gov
Amos Eaton Bldg.                       "xue zai shao"  -- Huang Ying Ying
Rensselaer Polytechnic Institute / Troy, NY 12180-3590

From ca-Request@Think.COM  Wed Jan 31 03:13:51 1990
Received: by fafnir.think.com; Wed, 31 Jan 90 03:13:51 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Wed, 31 Jan 90 03:13:48 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Wed, 31 Jan 90 03:14:25 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA18450; Wed, 31 Jan 90 02:19:54 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 31 Jan 90 04:24:09 GMT
From: snorkelwacker!usc!chaph.usc.edu!alcor.usc.edu!lyun@CS.BU.EDU  (Lance Sung Yun)
Organization: University of Southern California, Los Angeles, CA
Subject: Help : (regular definition trouble)
Message-Id: <7737@chaph.usc.edu>
To: ca@Think.COM

This may seem ordinary to most of you but it has be baffled.  I would
appreciate it if anybody can e-mail me any thoughts on this subject.
If there is enough interest I will post a summary (I don't want
to waste bandwidth with this simple question)

Also a string in the language {a,b} with an even number of b's and an
odd number of a's.

I am trying to find a regular definition for a language consisting
of all strings of digits.  No digit may be repeated.

And finally a string in the language {a,b} that does not contain the
substring 'aba' .

Thanks in advance!

The --Yunner--
lyun@castor.usc.edu

From ca-Request@Think.COM  Wed Jan 31 17:56:06 1990
Received: by fafnir.think.com; Wed, 31 Jan 90 17:56:06 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Wed, 31 Jan 90 17:55:57 EST
Received: from Oahu.CS.UCLA.EDU by Think.COM; Wed, 31 Jan 90 17:56:33 -0500
Received: by oahu.cs.ucla.edu
	(Sendmail 5.61a+YP/2.25) id AA20406;
	Wed, 31 Jan 90 14:56:17 -0800
Date: Wed, 31 Jan 90 14:56:17 -0800
From: jmg@CS.UCLA.EDU (James M Goodwin)
Message-Id: <9001312256.AA20406@oahu.cs.ucla.edu>
To: ca@Think.COM
Subject: CAM-6 avalibility?  Alternatives?

I have had a CAM-6 on order for nearly a year.  They have not
delivered, and according to our purchasing people will give
no promise on delivery date.  They apparently have no stock,
and wait till they have enough orders to financially justify
another run.  

I would like to know if this is correct, if it is similar to the 
experience of other orderers, and if there is any way to
speed the process.

Several alternatives have been mentioned by correspondents, but
it is unclear to me whether these are (also) vaporware.  Can one
ACTUALLY purchase a funtional CA board and get reasonbly prompt
delivery?  

The board is to be used as part of the new course development
in CA and related areas at a small university (Cal State, Stanislaus,
not UCLA) with a limited budget.  Keeping several
thousand dollars tied up in HOPES of delivery is not reasonable.


From ca-Request@Think.COM  Wed Jan 31 21:44:11 1990
Received: by fafnir.think.com; Wed, 31 Jan 90 21:44:11 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Wed, 31 Jan 90 21:43:57 EST
Received: from p.lanl.gov by Think.COM; Wed, 31 Jan 90 21:44:31 -0500
Received: by p.lanl.gov (5.54/1.14)
	id AA09927; Wed, 31 Jan 90 19:44:19 MST
Received: by cardinal.lanl.gov (3.2/5.17)
	id AA03796; Wed, 31 Jan 90 19:35:05 MST
Date: Wed, 31 Jan 90 19:35:05 MST
From: cgl%cardinal@LANL.GOV (Chris Langton)
Message-Id: <9002010235.AA03796@cardinal.lanl.gov>
To: ca@Think.COM
Subject: CAM-6 availability


Well, well, well...somebody finally asked...here goes...

FLAME-ON!

The company producing the CAM-6 does not give a flying &*%%$
about the CAM-6, selling it, customer satisfaction, or the
customer, for that matter. I ordered mine in Sept 86 and was
told "30 days". After 12 monthly episodes of "30-days..."
with some lame excuse or another, I threatened to get up
in fron of a conference of 150 people I had organized and needed
the board for and tell them never to do any business with
System's Concepts. The president told me to go ahead and hung-up
on me, but the next day I received the board by FED-EXP.

Forget System's concepts, but don't forget the board - it is
really a nicely done piece of equipment, and Toffoli and Margolis
deserve a lot of credit for designing it. They have realized
that they made a mistake in letting Systems Concepts produce it
and have essentially severed relations with them. A newer
version of the board will be produced shortly by Automatrix,
a newly formed company in New York. Contact David Hiebeler
at "hiebeler@turing.cs.rpi.edu" for further information.

It took a threat to get it after a year when System's Concepts
was promising 30 days - imagine how long it will take - and
what kinds of threats will be required - to get it if they are
claiming 1 year. Although there were some good, civil people
working for the company, ost of them have been driven off,
and the president - Mike Leavet - is just not worth the trouble...

Dollars to donuts that an order to Automatrix will come through
before an order to System's concepts, and - hey - we might
as well support people who care about their customers rather
than butt-holes who couldn't care less about us...

FLAME-OFF...

guess that button was waiting to be pushed for a while!

Yours in livelier computing...



Cheers!


Chris Langton

Center for Nonlinear Studies		Phone: 505-667-1444
MS B258					Email: cgl@LANL.GOV
Los Alamos National Laboratory
Los Alamos, New Mexico, USA
87545


From ca-Request@Think.COM  Thu Feb  1 00:15:22 1990
Received: by fafnir.think.com; Thu, 1 Feb 90 00:15:22 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Thu, 1 Feb 90 00:15:18 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Thu, 1 Feb 90 00:15:53 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA18889; Wed, 31 Jan 90 23:22:32 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 1 Feb 90 04:19:08 GMT
From: zaphod.mps.ohio-state.edu!rpi!hiebeler@Think.COM  (Dave Hiebeler)
Organization: RPI CS Dept, and LANL Center for Nonlinear Studies
Subject: flocking behavior
Message-Id: <W_2`R$@rpi.edu>
To: ca@Think.COM


  I am interested in learning some basics about flocking behavior, for
example in birds and fish.  I'm not interested in how the physiology
of particular animals drives flocking.  What I am more interested in
is phenomenology of flocking, that is, classifications of different
types of flocking behavior, some relevant parameters, and maybe some
mathematical models of such behavior.  I am most interested in
"homogeneous" flocking, that is, where there is no "leader", although
that is not a strong requirement.

  So if anyone could point me toward some decent references that might
be what I'm looking for, I'd appreciate it.  So far, I've seen Craig
Reynold's "Boids" article in the 1987 SIGGraph proceedings, and a
handful of articles from the journal "Animal Behaviour", but not much.
References to either good journals that might have this kind of stuff,
or to specific articles/books would be great.

  The reason for my asking is that I am entertaining the notion of a
cellular-automata-like model of flocking, which has been on the mental
"back burner" for 6 months now.  I'd like to absorb some more
background material on flocking in general, so I can see what I can
abstract, to help me analyze/understand/improve my model.

  Since I'm posting this to several newsgroups as well as the cellular
automata mailing-list, replies via e-mail are preferred; I'll post a
summary if I get any info.

-- 
Dave Hiebeler                Internet: hiebeler@turing.cs.rpi.edu (preferred)
Computer Science Dept.         Bitnet: userF3JL@rpitsmts  (last resort)
Amos Eaton Bldg.
Rensselaer Polytechnic Institute / Troy, NY 12180-3590

From ca-Request@Think.COM  Thu Feb  1 04:15:13 1990
Received: by fafnir.think.com; Thu, 1 Feb 90 04:15:13 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Thu, 1 Feb 90 04:15:09 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Thu, 1 Feb 90 04:15:44 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA29548; Thu, 1 Feb 90 03:31:26 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 31 Jan 90 16:05:16 GMT
From: mcsun!ukc!icdoc!qmw-cs!alex@uunet.uu.net  (Alex Kashko)
Organization: Dept Physics. University Of Edinburgh. Scotland.
Subject: Re: CA on AMT DAP (Was Re: Cellular Automata Laboratory)
Message-Id: <1578@sequent.cs.qmw.ac.uk>
References: <1561@sequent.cs.qmw.ac.uk>, <VM16}-@rpi.edu>
To: ca@Think.COM

In article <VM16}-@rpi.edu> hiebeler@cs.rpi.edu (Dave Hiebeler) writes:
>  Well, you are taking 0.118 seconds to update an array 4 times as
>large as the CAM array (twice as wide, twice as high), so it would
>take you (0.118 / 4) or 0.0295 seconds to update the CAM array.
>
>  The CAM does it in about 0.0166 seconds.
>
>  So you'd be getting about 33 frames/second on a 256x256 array, where
>CAM gives you 60 frames/second, almost twice as fast.
	
	Thanks. The reason I said a "version" was that the Lichens with death type pattern arose as a special case of a more general program.
I went back to T&M and programmed exactly what they said they did. I started with a symmetrical seed and so gor symmetrical results rather thatn the random looking result they give in the book (They don't as far as I can tell, mention what seed they used to give their figure 5.2b). I checked the algorithm against the book and it seems ok. This decicated algorithmruns in 43.2 seconds. This is some 2.7 times faster, so the DAP would be faster then the 256 by 256 CAM for this problem. The DAP610 would obvious




ly run 4 times faster than this.

>
>  Keep in mind that the CAM costs on the order of $2000, and that you
>can buy a few of them and plug them in together.  So you could buy
>four CAMs and plug them in together to update a 512x512 array at 60
>frames/sec, which would be 8 times as fast as the DAP.  Also, the CAM


	Or twice as fast as the DAP610.On the revised execution figures above the CAM should still be marginally faster. This is not surprising for the DAP is a general purpose computer, so the dedicated hardware should be faster. The data analysis capacity is something we don't have on the DAP. The Lego `-like extendibility is also missing. I suggested to AMT (Over a lunch break) that such extendibility would be nice, but appartently there are problems.  On the costs above a 1024 by 1024 CAM would cost about $32




,000 which is quite cheap. I must see if my boss will put in for one. Can you email me a contact adress or (and?) other details.
	
>
>  About how much does a DAP such as the one you are using cost?  We
>have one of their machines here at RPI, but I haven't gotten around to
>using it yet, although it sounds like a pretty decent machine.  I
>generally use the CAM, but I use Connection Machines when I need to
>do something too big for CAM.
	I believe a DAP510 is about 100,000 sterling, but dont't quote meas I cound be wrong. There is an academic discount of around 40% (again don't quote me). So on a power per pound basis the CAM wins. But the DAP is more versatile. I am using DAP's for cellular automaton models of Polymers, and growth models are a byproduct of this. 
	If anyone can email me references to cellular automaton and other types of simple polymer modelling (Anything welcome but I am short on electrical and electronic properties in particular) or Langmuir Blodgett films I would be grateful.

>-- 
>Dave Hiebeler                       hiebeler@turing.cs.rpi.edu
>Computer Science Dept.              hiebeler@cardinal.lanl.gov
>Amos Eaton Bldg.                       "xue zai shao"  -- Huang Ying Ying
>Rensselaer Polytechnic Institute / Troy, NY 12180-3590

From bmb@Think.COM  Thu Feb  1 09:03:07 1990
Received: by fafnir.think.com; Thu, 1 Feb 90 09:03:07 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from aldebaran.think.com by fafnir.think.com; Thu, 1 Feb 90 09:02:56 EST
Received: by aldebaran.think.com; Thu, 1 Feb 90 09:02:49 EST
Date: Thu, 1 Feb 90 09:02:49 EST
From: bmb@Think.COM
Message-Id: <9002011402.AA06402@aldebaran.think.com>
To: zaphod.mps.ohio-state.edu!rpi!hiebeler@Think.COM
Cc: ca, bmb, dan@segovia.mit.edu
In-Reply-To: (Dave Hiebeler's message of 1 Feb 90 04:19:08 GMT <W_2`R$@rpi.edu>
Subject: flocking behavior

   Date: 1 Feb 90 04:19:08 GMT
   From: zaphod.mps.ohio-state.edu!rpi!hiebeler@Think.COM  (Dave Hiebeler)


     I am interested in learning some basics about flocking behavior, for
   example in birds and fish.  I'm not interested in how the physiology
   of particular animals drives flocking.  What I am more interested in
   is phenomenology of flocking, that is, classifications of different
   types of flocking behavior, some relevant parameters, and maybe some
   mathematical models of such behavior.  I am most interested in
   "homogeneous" flocking, that is, where there is no "leader", although
   that is not a strong requirement.
   ...

Hi Dave

This is going to sound bizarre, but it's something I've noticed for some time
now and haven't mentioned to anybody (perhaps out of fear of having people
think that I've truly gone off the deep end...)

I've spent quite a bit of time over the last year and a half experimenting with
the Rothman-Keller lattice gas for two-phase Navier Stokes flow (two immiscible
fluids with a surface tension interface).  If you start out with a homogeneous
mixture of the two phases, you can watch them separate like oil and water.  

The model is basically an FHP-type lattice gas where the particles can have one
of two colors, say red and blue.  Red particles, blue particles, and total
momentum are conserved.  Collisions involving particles of the same color are
exactly FHP collisions; collisions involving particles of different color are
chosen to preferentially send each particle toward neighboring sites that are
dominated by like color particles.  (This rule is carefully quantified in the
paper by Rothman and Keller.)  It is this affinity of particles for other
particles of the same color that gives the fluids cohesion and gives the
interface surface tension.

Once two fluids separate, it is interesting to look at their interface.  Though
it is quite stable, there are microscopic fluctuations: Occasionally a particle
of red fluid will break away and wander into the blue fluid, and vice versa.
When this happens, these "vapor" particles execute Brownian motion in the
foreign fluid until they hit the interface again and stick there.  Thus, there
is some small equilibrium level of foreign particles.  This is identical to the
physical phenomenon of vapor pressure.

Once in a great while, two individual vapor particles will come near each other
in the foreign fluid.  When this happens, there is a bit of a tendency for them
to stay together, according to the above rules.  I've watched this happen on
Connection Machine simulations on large grids at a few frames per second.  The
two particles execute a fascinating little dance.  They come together, dance
about, split apart, come back together, dance some more, etc.  I find it
incredibly reminiscent of the way that butterflies and moths flutter about
together while mating.

The biochemistry of mating butterflies and moths is governed by attractant
chemicals called pheromones.  (A neighbor of mine once experimented with using
pheromones to keep gypsy moths out of our neighborhood.  A few drops on a rag
hanging from a tree will keep a flock of butterflies about for quite some
time.)  In any event, it may be possible that the cohesion between like
particles moving in an incompressible Navier-Stokes background fluid in the
Rothman-Keller model is sufficiently similiar to the pheromone-induced
attraction of mating butterflies and moths moving through air (well
approximated by an incompressible Navier-Stokes fluid under most meteorological
conditions) to capture their motion in some qualitative way.

Just a suggestion.

Best regards,

Bruce M. Boghosian                               (617)-876-1111
Thinking Machines Corporation                    bmb@think.com
245 First Street
Cambridge, Massachusetts  02142-1214

From ca-Request@Think.COM  Thu Feb  1 13:32:30 1990
Received: by fafnir.think.com; Thu, 1 Feb 90 13:32:30 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Thu, 1 Feb 90 13:32:18 EST
Received: from uunet.UU.NET by Think.COM; Thu, 1 Feb 90 13:32:51 -0500
Received: from acad.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA22466; Thu, 1 Feb 90 13:32:45 -0500
Received: from megalon.acad.com by acad.uucp  (3.2/SMI-3.2)
	id AA03868; Thu, 1 Feb 90 09:58:17 PST
Received: by megalon.acad.com (3.2/SMI-3.2)
	id AA00742; Thu, 1 Feb 90 09:58:16 PST
Date: Thu, 1 Feb 90 09:58:16 PST
From: acad!megalon!rudy@uunet.UU.NET (Rudy Rucker)
Message-Id: <9002011758.AA00742@megalon.acad.com>
To: ca@Think.COM
Subject: Who needs CAM-6 anymore?
Cc: megalon!rudy@uunet.UU.NET


A bit of hype for my product:

CA Lab, the Rudy Rucker Cellular Automata Laboratory from Autodesk

For $59.95, CA Lab gives you a pure software CA simulator.  On a fast
386, the speed can hit about 10 updates a second, as compared to the
CAM-6's 30 updates a second.

But speed isn't everything.  CA Lab uses 8 bits of state per cell as
opposed to CAM-6's 4 bits per cell, meaning that in CA Lab you can create
considerably more complex rules.  Would you believe a 3 species game of
Wator with shrimps, fish, and sharks each keeping track of how old they
are and how hungry?  

Create rules how?  Not in Forth, for God's sake, in C, Pascal or even
Basic.  Yes, CA Lab allows you to write a short program in one of these
languages calling on language specific include files that we provide.
For the doughtier, we have the option of changing the inner loop where
each cell picks up 16 bits of info from itself and its neighbors.  

Program runs on ANY kind of PC or clone, taking advantage of whatever
graphics are available.  Preferred mode is 256 color 320 x 200 as
available on PS/2s or clones with VGA.

CAM-6 is history, CA Lab is today!

So get out your credit card and phone Autodesk to order today.

(800)525-2763

Rudy Rucker
Autodesk, Inc.
2320 Marinship Way
Sausalito, CA 94965

From ca-Request@Think.COM  Fri Feb  2 21:40:47 1990
Received: by fafnir.think.com; Fri, 2 Feb 90 21:40:47 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Fri, 2 Feb 90 21:40:44 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Fri, 2 Feb 90 21:41:23 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA08730; Fri, 2 Feb 90 20:34:54 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 2 Feb 90 13:12:31 GMT
From: snorkelwacker!usc!cs.utexas.edu!jarvis.csri.toronto.edu!torsqnt!lethe!berner!becker!bdb@bloom-beacon.mit.edu  (Bruce Becker)
Organization: G. T. S., Toronto, Ontario
Subject: Re: Who needs CAM-6 anymore?
Message-Id: <3261@becker.UUCP>
References: <9002011758.AA00742@megalon.acad.com>
To: ca@Think.COM

In article <9002011758.AA00742@megalon.acad.com> rudy@megalon.UUCP (Rudy Rucker) writes:
|
|CA Lab, the Rudy Rucker Cellular Automata Laboratory from Autodesk
|[...]
|Program runs on ANY kind of PC or clone, taking advantage of whatever
|graphics are available.  Preferred mode is 256 color 320 x 200 as
|available on PS/2s or clones with VGA.

	When can we expect:

	1). Amiga version

	2). Mac version

	3). Unix version

	?

-- 
  (__)	 Bruce Becker	Toronto, Ont.
w \@@/	 Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu
 `/v/-e	 BitNet:   BECKER@HUMBER.BITNET
_/  \_	 Well I didn't want to mention it cause it's so silly, but you know how

From ca-Request@Think.COM  Fri Feb  2 23:23:02 1990
Received: by fafnir.think.com; Fri, 2 Feb 90 23:23:02 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Fri, 2 Feb 90 23:22:59 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Fri, 2 Feb 90 23:23:38 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA15527; Fri, 2 Feb 90 22:38:38 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 3 Feb 90 03:35:56 GMT
From: zaphod.mps.ohio-state.edu!rpi!hiebeler@Think.COM  (Dave Hiebeler)
Organization: RPI CS Dept, and LANL Center for Nonlinear Studies
Subject: Who needs what? (was Re: Who needs CAM-6 anymore?)
Message-Id: <G{3*2-@rpi.edu>
References: <9002011758.AA00742@megalon.acad.com>
To: ca@Think.COM


  I'd like to address some points in Rucker's article...

In article <9002011758.AA00742@megalon.acad.com> rudy@megalon.UUCP (Rudy Rucker) writes:

> For $59.95, CA Lab gives you a pure software CA simulator.  On a fast
> 386, the speed can hit about 10 updates a second, as compared to the
> CAM-6's 30 updates a second.

  Well, a minor correction -- CAM-6 goes at 60 updates/sec, on a
256x256 array (you didn't mention what size your timing was done
with).  The speed of CAM-6 does not depend on the speed of the PC it's
plugged into -- it runs just as fast on an AT, XT, whatever.


> But speed isn't everything.  CA Lab uses 8 bits of state per cell as
> opposed to CAM-6's 4 bits per cell, meaning that in CA Lab you can create
> considerably more complex rules.

  Speed isn't everything, you're right.  But then again, it is
something.  I wouldn't exactly want to run FHP fluid-flow simulations
on my Apple II+.  :-)  But seriously, sometimes you want your
simulation to run like mad, so you can do a billion time-steps or so,
other times you want other things.

  Sometimes, I've had to really sit around and think for a while about
how to fit a rule into just four bitplanes, to fit it on CAM-6.
Sometimes, I gave up, and then a year later tried again and found it
very easy.  Sometimes, it just took a few minutes to get it down to 4
bits.  Other rules (say, heat diffusion) need more than CAM's 16
states/cell to work well.  In that case, you need to do one of the
following:
  - use CA Lab
  - use Cellsim (public-domain CA simulator for Suns)
  - use a Connection Machine
  - use CAM, by allocating extra memory buffers and swapping data around
  - or use some other general-purpose CA software not mentioned above,
    either on a small computer or mainframe.

  It really depends on how long you have to run your simulations, and
how much data you usually need per cell, and how much data-analysis
you want to do while running.

> 
> Create rules how?  Not in Forth, for God's sake, in C, Pascal or even
> Basic.  Yes, CA Lab allows you to write a short program in one of these
> languages calling on language specific include files that we provide.

  This is actually an important point.  I know some people who have
refused to use CAM-6 because they'd have to program it in Forth.
A good programming interface for creating rules is handy to have.  The
CAM-6 sure doesn't have what I'd call a good interface, although the
newer version, CAM-PC, will probably have C routines to create rules
(perhaps other languages as well, but I really don't know).

  I think that having a good programming interface for CA rules is a
pretty important subject.  In working on the new versions of Cellsim,
I've tried to improve the rule-generation facilities there, as I found
the rule-generation method in the first release of Cellsim pretty
unbearable.  I'm pretty pleased with the way it is now, although it
still can use some improvements.  [The next release of Cellsim will be
most likely coming out later this Spring, I think, so you can see what
I'm talking about.]

  Another important point is having a good interface for general use,
in addition to rule-programming.  CAM-6 actually wasn't too shabby,
although it was fairly simple.  The early Cellsim was OK, and my first
update was OK but not great.  I think the latest version of Cellsim
(still in progress) is not bad, for a SunView-based CA interface.

  So Rudy's article did bring up some important topics, although it
may have sounded more like a used-car ad. :-)

  I'd be very interested in seeing some discussion here, by people who
have encountered other interfaces (either for general use, or rule
construction) to cellular automata, and what was good and bad about
them.

Disclaimer: I'm speaking for myself, not as an employee/student/whatever.
-- 
Dave Hiebeler                Internet: hiebeler@turing.cs.rpi.edu (preferred)
Computer Science Dept.         Bitnet: userF3JL@rpitsmts  (last resort)
Amos Eaton Bldg.
Rensselaer Polytechnic Institute / Troy, NY 12180-3590

From ca-Request@Think.COM  Sat Feb  3 20:25:31 1990
Received: by fafnir.think.com; Sat, 3 Feb 90 20:25:31 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Sat, 3 Feb 90 20:25:28 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Sat, 3 Feb 90 20:26:08 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA06427; Sat, 3 Feb 90 19:21:53 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 3 Feb 90 23:39:00 GMT
From: apollo!nelson_p@beaver.cs.washington.edu  (Peter Nelson)
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Subject: CA question
Message-Id: <486e5e96.20b6d@apollo.HP.COM>
To: ca@Think.COM





    I've played with cellular automata for some time and have written
    a number of Life-like cellular automatons on my PC in C.

    I thought it might be useful to have a general-purpose cellular
    automata utility with which I could try out different ideas by
    just changing the rules, and perhaps creating a new struct def
    to go with them   Since I just bought the Zortech C++ v2.0 compiler
    I thought that this might also be a good project to experiment 
    with OOP'ing theory, as well.

    But somebody suggested that I should take a look at Autodesk's 
    CA Lab.  Getting technical details from them was like pulling teeth 
    but when I finally did, it was very disappointing:   CA Lab's
    universe is a 64K array where each cell is one byte.  If you
    write your own rules you can read **ONE BIT** from each of 8
    adjacent cells, or 2 bits from each of 4 cells, etc, using their
    library.  No complex data structures here!   BTW, another minus
    for me is that the graphics version does not support Hercules
    monochrome graphics.
                              

    OK, so I was thinking about the idea of a CA utility when I 
    realized that I have a gap in my theoretical understanding of 
    this kind of problem!    Conway's Life - types of simulations 
    are static, i.e., nothing moves from one cell to the next.  
    I was kind of hoping I could use my new utility to simulate 
    systems where "stuff" (information or state or something) does
    move from one cell to another.  This might be useful in simulating
    fluid flow or ecological systems. 

    But my Life-like CA's don't seem to handle this concept very well.
    They all consist of 2 matrices ( or 1 matrix with 2 elements at each
    location) for the states at time T and T+1.   I examine each cell and
    it's neighbors at time T and determine its state at T+1, and then write
    it into the T+1 matrix.   Simple.        
    
    But when stuff moves between cells "collisions" may occur.  The
    problem is not resolving the collision (that's relatively easy).
    The problem is propagating the effects of that resolution through
    the matrix, and doing so in a way which is not dependent on the
    order-of-evaluation.

    -------------------------
    |1    |2    |3    |4    |
    |     |     |     |     |       Say A (in cell 5) and B (in cell 7)
    |     |     |     |     |       are both moving toward cell 6 at
    -------------------------       time T.    If I just compute the
    |5    |6    |7    |8    |       state for time T+1 *sequentially*
    | A-->|     |<--B |     |       then when I get to cell 5 I can't
    |     |     |     |     |       determine its state for time T+1 
     -------------------------      without knowing whether it was 
    |9    |10   |11   |12   |       successful in its attempt to move
    |     |     |     |     |       into cell 6.   But the state of
    |     |     |     |     |       cell 6 for time T+1 is not known  
    -------------------------       yet, and it is also a function of
                                    7 which I haven't evaluated yet.  

    Now, suppose I complicate my algorithm by "following"
    the path of A into cell 6 and evaluating the state of 
    cell 6 for time T+1 *before* evaluating the state of 
    cell 5.   The result of such an evaluation would also
    determine the state of cell 7 for T+1.   Still, although
    this is more complicated than a "Life" algorithm, it
    would handle this particular case.   

    However, say that cell 6 has 'C' in it that wants to move 
    somewhere *else* (to cell 10 in this case).  Then we have
    -------------------------       to keep following that path
    |1    |2    |3    |4    |       wherever it leads in the
    |     |     |     |     |       matrix because whether A is
    |     |     |     |     |       succcessful moving into 6 will
    -------------------------       depend on whether C is successful
    |5    |6 C  |7    |8    |       moving into 10.  And that may need
    | A-->|  |  |<--B |     |       following the path even farther. 
    |     |  V  |     |     |       If the path ever doubles back, 
     -------------------------      say to cells 5 or 6, then I will
    |9    |10   |11   |12   |       be stuck in a loop!
    |     |     |     |     |       
    |     |     |     |     |         
    -------------------------  

    ...So I have doubts about whether this approach can work.
    *IS* there a common algorithmic platform upon which both
    non-moving cell-type simulations such as Conway's Life and
    physical-process or object simulations like fluid flow or
    ecological systems can be based?  (*** This question is
    really the point of my whole posting. ***)

    We have a large technical library here (HP/Apollo, Chelmsford,
    MA) and there are a number of books on simulation.  But they 
    are all very math-y and none of them seem to address cellular
    automata, anyway.   I'm just doing this for fun so I don't 
    want to get too technical.  

    Thanks in advance for any observations or comments.   I'm new
    at much of this so if I'm making lots of stupid assumptions
    feel free to tell me, but be nice, please.  8-)

                                                 ---Peter

From ca-Request@Think.COM  Sat Feb  3 21:41:21 1990
Received: by fafnir.think.com; Sat, 3 Feb 90 21:41:21 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Sat, 3 Feb 90 21:41:17 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Sat, 3 Feb 90 21:41:59 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA10731; Sat, 3 Feb 90 21:12:19 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 4 Feb 90 02:09:56 GMT
From: snorkelwacker!usc!zaphod.mps.ohio-state.edu!rpi!hiebeler@bloom-beacon.mit.edu  (Dave Hiebeler)
Organization: RPI CS Dept, and LANL Center for Nonlinear Studies
Subject: Re: CA question
Message-Id: <L23=~#@rpi.edu>
References: <486e5e96.20b6d@apollo.HP.COM>
To: ca@Think.COM

In article <486e5e96.20b6d@apollo.HP.COM> nelson_p@apollo.HP.COM (Peter Nelson) writes:

> [semi-negative comments about Autodesk's CA lab]

  You might want to check out Cellsim, it is a public-domain cellular
automata program (written in C), which runs under SunView.  I realize
you want something for the PC, but the inner loops for Cellsim are
just pure C, and can be run on pretty much anything.  It lets you get
up to 8 bits from each of 9 neighbors at most, in addition to a couple
of 8-bit "global" parameters.
  Rather than tell you how to get Cellsim, I'd prefer to wait, as I'm
currently working on version 2.5, which is substantially better than
previous versions.  If you're *really* desperate to get the old
versions, send me an e-mail note, although I hate to tell people where
to get the old version, since the new one will be so much better. :-)

>     Conway's Life - types of simulations 
>     are static, i.e., nothing moves from one cell to the next.  
>     I was kind of hoping I could use my new utility to simulate 
>     systems where "stuff" (information or state or something) does
>     move from one cell to another.  This might be useful in simulating
>     fluid flow or ecological systems. 

  Well, in Conway's life (as well as things like the HPP and FHP
lattice gas rules), *information* moves from one cell to another.
That is, a "particle" might be represented as an active cell; an empty
cell that sees a neighbor with a particle moving toward it, will
"create" a new particle while its neighbor "destroys" its particle.
The net effect is an information transfer, or a particle "transfer".

>     But when stuff moves between cells "collisions" may occur.  The
>     problem is not resolving the collision (that's relatively easy).
>     The problem is propagating the effects of that resolution through
>     the matrix, and doing so in a way which is not dependent on the
>     order-of-evaluation.
> [stuff about following the results of possible collisions...]

  You should check out the HPP lattice gas model, this has a simple
example of how to get around this.  The basic solution (on a square
lattice), is as follows (I'll describe it in terms of particles, since
that's the terminology associated with the HPP model):
 1. Each cell can hold up to 4 particles
 2. There cannot be 2 or more particles in the same place moving in the
   same direction.  So a "full" (4-particle) cell would have 1
   particle moving in each direction: up, down, left, right.
 3. If you think about the "worst-case" collision, this would be a cell
  that is full and whose neighbors are all full.  In that case, the
  cell would "destroy" its 4 particles (knowing its neighbors would
  get them), and it would get 1 particle from each of its 4 neighbors.
  That is, the exclusion principle in item 2 above prevents you from
  having more than 4 items try to come into the same cell.  Since each
  cell can hold at most 4 particles, you're safe.

Three sources of information about HPP, which will clarify what I'm
trying to say above are:

J. Hardy, Y. Pomeau, and O. de Pazzis, ``Time Evolution of a
Two-Dimensional Model System.  I.  Invariant states and time
correlation functions'', J. Math. Phys. [14] (1973).

J. Hardy, O. de Pazzis, Y. Pomeau, ``Molecular dynamics of a Classical
Lattice Gas: Transport Properties and Time Correlation Functions,''
Physical Review A, [13] (1976) 1949. 

T. Toffoli and N. Margolus, Cellular Automata Machines: A New
Environment for Modeling, (MIT Press, 1987).

>     Thanks in advance for any observations or comments.   I'm new
>     at much of this so if I'm making lots of stupid assumptions
>     feel free to tell me, but be nice, please.  8-)

  I've been at this for years, and I still make lots of stupid
assumptions and ask stupid questions. :-)


  Note that I'll be away at the 2nd Artificial Life conference next
week, so I'll probably be slow to reply to e-mail queries until Feb
11th or so.

  I'll try to post a summary of interesting stuff I see at the ALife
conference, probably in the following newsgroups:
 comp.theory.cell-automata, comp.theory.self-org-sys, comp.bio
and maybe a couple of other groups, so watch at least one of those
newsgroups around Feb 11-15 or so, if you're interested.

-- 
Dave Hiebeler                Internet: hiebeler@turing.cs.rpi.edu (preferred)
Computer Science Dept.         Bitnet: userF3JL@rpitsmts  (last resort)
Amos Eaton Bldg.
Rensselaer Polytechnic Institute / Troy, NY 12180-3590

From ca-Request@Think.COM  Tue Feb  6 13:59:44 1990
Received: by fafnir.think.com; Tue, 6 Feb 90 13:59:44 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Tue, 6 Feb 90 13:59:33 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Tue, 6 Feb 90 14:00:05 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA01275; Tue, 6 Feb 90 13:29:26 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 6 Feb 90 17:55:03 GMT
From: psuvm!brl102@psuvax1.cs.psu.edu  (Ben Liblit)
Organization: Penn State University
Subject: Re: flocking behavior
Message-Id: <90037.125503BRL102@PSUVM.BITNET>
References: <W_2`R$@rpi.edu>
To: ca@Think.COM


I seem to remember an article in the _Science_Times_ section of _The_New_York_
_Times_  about someone who managed to come up with a computer simulation of a
flying flock of birds.  I can't remember when I saw the article; it may have
been over a year ago -- a well trained librarian should be able to help out.

                      Ben Liblit
                      BRL102 @ psuvm.bitnet -- BRL102 @ psuvm.psu.edu
                      "Fais que tes reves soient plus longs que la nuit."

From ca-Request@Think.COM  Tue Feb  6 19:02:57 1990
Received: by fafnir.think.com; Tue, 6 Feb 90 19:02:57 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Tue, 6 Feb 90 19:02:54 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Tue, 6 Feb 90 19:03:41 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA13931; Tue, 6 Feb 90 17:40:23 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 6 Feb 90 22:34:09 GMT
From: snorkelwacker!apple!apple.com!karakots@bloom-beacon.mit.edu  (Ken Karakotsios)
Organization: Apple Computer Inc.
Subject: Re: Who needs CAM-6 anymore?
Message-Id: <6545@internal.Apple.COM>
References: <3261@becker.UUCP>
To: ca@Think.COM

Bruce Becker asks when a Mac Version of CA Lab will be available...

I am currently finishing up a Mac based CA simulator which I plan to 
market in the $20-30 range (probably as share-ware).  It  runs on any color
MacII.  My goal is to use CAs both as a medium to model physical processes 
and as an art form. This is not a clone of CA Lab, and has a completely
different feature set.  If you think you might be interested in buying a copy, send me Email and I'll tell you more about it.  

Ken Karakotsios
408-974-1942


generic disclaimer... I speak for myself, not apple...

From ca-Request@Think.COM  Tue Feb  6 19:46:52 1990
Received: by fafnir.think.com; Tue, 6 Feb 90 19:46:52 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Tue, 6 Feb 90 19:46:42 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Tue, 6 Feb 90 19:47:25 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA16419; Tue, 6 Feb 90 18:21:50 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 6 Feb 90 23:14:19 GMT
From: bbn.com!aboulang@bbn.com  (Albert Boulanger)
Subject: Re: flocking behavior
Message-Id: <51800@bbn.COM>
References: <W_2`R$@rpi.edu>, <90037.125503BRL102@PSUVM.BITNET>
To: ca@Think.COM


In article <90037.125503BRL102@PSUVM.BITNET> BRL102@psuvm.psu.edu (Ben Liblit) writes:

   I seem to remember an article in the _Science_Times_ section of _The_New_York_
   _Times_  about someone who managed to come up with a computer simulation of a
   flying flock of birds.  I can't remember when I saw the article; it may have
   been over a year ago -- a well trained librarian should be able to help out.

Here is a ref:

"Flocks, Herds, and Schools: A Distributed Behavioral Model"
Craig Reynolds (cwr@symbolics.com)
Computer Graphics, Vol 21, No 4, July 1987, 25-34


Cheers,
Albert Boulanger
BBN Systems & Technologies Corp.
aboulanger@bbn.com

From ca-Request@Think.COM  Wed Feb  7 22:12:10 1990
Received: by fafnir.think.com; Wed, 7 Feb 90 22:12:10 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Wed, 7 Feb 90 22:12:06 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Wed, 7 Feb 90 22:12:47 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA02803; Wed, 7 Feb 90 21:42:55 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 7 Feb 90 15:39:54 GMT
From: usinset!craig@uunet.uu.net  (Craig Hubley)
Organization: CRAIG HUBLEY & ASSOCIATES
Subject: Cooperative automata - I know of one, are there others ?
Message-Id: <20@usinset.inset.com>
To: ca@Think.COM

(somehow a prior copy of this escaped without a body - don't worry, I doubt
this group will win any 'newsgroup volume bandwidth pig awards' anytime soon!)

I am interested in cellular automata where the cells engage in exchanges with
each other - and the rewards/survival reflect their degree of success at 
dealing with each other (sort of a neighborhood simulation).  Axelrod wrote
about this sort of a game in "The Evolution of Cooperation" using the 
Prisoner's dilemma inequality (reward for defection > reward for dual
cooperation > reward for dual-defection > reward for cooperation when the
other defects (sucker's payoff)).  There were some rules for cells to adopt
a neighboring strategy when it was successful - there was a distinction between
the rules that scored best, and those that best convinced their neighbors -
for instance Tit for Tat (cooperate first turn, thereafter do whatever the
other did on the previous turn) was the best overall strategy, but since it
can never score better than any individual opponent, it is never perceived as
'winning' by an individual (which was required by the conversion/growth rule).

I am wondering if anyone else has done anything with cellular automata that hav
such detailed interactions with each other, and if their work is in print
anywhere.

Thanks,
Craig Hubley

From ca-Request@Think.COM  Fri Feb  9 05:45:46 1990
Received: by fafnir.think.com; Fri, 9 Feb 90 05:45:46 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Fri, 9 Feb 90 05:45:43 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Fri, 9 Feb 90 05:46:31 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA28082; Fri, 9 Feb 90 05:05:05 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 9 Feb 90 09:29:59 GMT
From: van-bc!ubc-cs!phillips@ucbvax.berkeley.edu  (George Phillips)
Organization: UBC Department of Computer Science, Vancouver, B.C., Canada
Subject: wireworld patterns
Message-Id: <6713@ubc-cs.UUCP>
To: ca@Think.COM

In the Jan. 1990 issue of Scientific American, A. K. Dewdney describes
the rules for a cellular automata called "wireworld".  For those that
haven't seen it, each cell has 4 possible states: space, wire, electron
head or electron tail.  Cells interact with their 8 neighbours by the
following rules:

- space cells forever remain space cells
- electron tails turn into wire cells
- electron heads turn into electron tails
- wire cells remain wire cells unless bordered by 1 or 2 electron heads

With these rules, electrons composed of heads and tails can move along
wires and you can build diodes, OR gates, NOT gates, memory cells,
wire crossings and so on.

After a couple of really cheap hacks, I played with wireworld on my PC
and Unix and was able to come up with a 6 cycle memory cell, a number of
logical gates and some pulsars which generate electrons at different
rates.  If anyone is interested, I'll post my patterns here and (hopefully)
someone can dazzle me with their discoveries.  If such postings (or
even this posting) are inappropriate here, I'm sure you'll inform me :-).

--
George Phillips phillips@cs.ubc.ca {alberta,uw-beaver,uunet}!ubc-cs!phillips

From ca-Request@Think.COM  Fri Feb  9 17:41:36 1990
Received: by fafnir.think.com; Fri, 9 Feb 90 17:41:36 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Fri, 9 Feb 90 17:41:06 EST
Received: from uunet.UU.NET by Think.COM; Fri, 9 Feb 90 17:41:53 -0500
Received: from acad.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA06622; Fri, 9 Feb 90 17:40:49 -0500
Received: from megalon.acad.com by acad.uucp  (3.2/SMI-3.2)
	id AA01162; Fri, 9 Feb 90 14:30:49 PST
Received: by megalon.acad.com (3.2/SMI-3.2)
	id AA28491; Fri, 9 Feb 90 14:30:48 PST
Date: Fri, 9 Feb 90 14:30:48 PST
From: acad!megalon!rudy@uunet.UU.NET (Rudy Rucker)
Message-Id: <9002092230.AA28491@megalon.acad.com>
To: ca@Think.COM
Subject: add me


Please add me to your mail group.  My email address is

rudy@autodesk.com


From ca-Request@Think.COM  Fri Feb  9 21:27:05 1990
Received: by fafnir.think.com; Fri, 9 Feb 90 21:27:05 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Fri, 9 Feb 90 21:27:01 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Fri, 9 Feb 90 21:27:49 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA12111; Fri, 9 Feb 90 19:52:18 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 10 Feb 90 00:37:34 GMT
From: saturn!xanthian@AMES.ARC.NASA.GOV  (Metafont Consultant Account)
Organization: Advanced Decision Systems, Mt. View, CA (415) 960-7300
Subject: Re: wireworld patterns
Message-Id: <10801@saturn.ADS.COM>
References: <6713@ubc-cs.UUCP>
To: ca@Think.COM

In article <6713@ubc-cs.UUCP> phillips@cs.ubc.ca (George Phillips) writes:

 > In the Jan. 1990 issue of Scientific American, A. K.  Dewdney
 > describes the rules for a cellular automata called "wireworld".
 > For those that haven't seen it, each cell has 4 possible states:
 > space, wire, electron head or electron tail.  Cells interact with
 > their 8 neighbours by the following rules:
 > 
 > - space cells forever remain space cells
 > - electron tails turn into wire cells
 > - electron heads turn into electron tails
 > - wire cells remain wire cells unless bordered by 1 or 2 electron
 >   heads 
 > 
 > With these rules, electrons composed of heads and tails can move
 > along wires and you can build diodes, OR gates, NOT gates, memory
 > cells, wire crossings and so on.
 > 
 > After a couple of really cheap hacks, I played with wireworld on my
 > PC and Unix and was able to come up with a 6 cycle memory cell, a
 > number of logical gates and some pulsars which generate electrons
 > at different rates.  If anyone is interested, I'll post my patterns
 > here and (hopefully) someone can dazzle me with their discoveries.
 > If such postings (or even this posting) are inappropriate here, I'm
 > sure you'll inform me :-).
 > 
 > -- 
 > George Phillips phillips@cs.ubc.ca
 > {alberta,uw-beaver,uunet}!ubc-cs!phillips

Hey, post your cheap hacks, too.  Porting them should be easier than
coming up with them in the first place!  This group is too quiet; a
bit of source code wouldn't hurt a bit.
--
Again, my opinions, not the account furnishers'.

xanthian@well.sf.ca.us (Kent Paul Dolan)
xanthian@ads.com - expiring soon; please use Well address for replies.
Kent, the (bionic) man from xanth, now available as a build-a-xanthian
kit at better toy stores near you.  Warning - some parts proven fragile.
-> METAFONT, TeX, graphics programming done on spec -- (415) 964-4486 <-

From ca-Request@Think.COM  Sun Feb 11 21:21:17 1990
Received: by fafnir.think.com; Sun, 11 Feb 90 21:21:17 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Sun, 11 Feb 90 21:21:13 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Sun, 11 Feb 90 21:22:05 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA04816; Sun, 11 Feb 90 20:24:35 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 11 Feb 90 22:59:00 GMT
From: ucsdhub!hp-sdd!apollo!nelson_p@ucsd.edu  (Peter Nelson)
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Subject: CA program (was: CA Question)
Message-Id: <489676d4.20b6d@apollo.HP.COM>
To: ca@Think.COM


  
 Well, I have a rudimentary version of my little CA tool running
 on my monochrome XT clone (Leading Edge Model D).

 The application currently interfaces to it via  #include's....

 I originally thought I might compile the applications 
 separately and link them in, but I found it better for the
 application to supply a structure definition for the individual
 cells, as a typedef 'CELL', which the CA program uses to define
 and manipulate the arrays.   Also, this way the application
 can customize the CA program with #defines, which can then be 
 used in conditionally compiling certain paths, which results
 in better run-time performance and smaller code than having to 
 check flags at runtime. 

 Currently the application supplies:

1.   an initialization routine, which may either be called on a
     per-cell basis or once for the whole array (or both).  

2.   An "action" routine, which the CA program calls once for 
     each cell being processed.   This implements the rules.

3.   A display routine which decides whether or what to draw 
     for each cell.

4.   Data information:  mostly, a definition of the cell, called
                        CELL, the SIZE of the universe, and
                        the number of generations to run.  The
                        appliaction may also #define conditions
                        here for customizing the CA program.


 The CA program allocates the necessary space.  It calls the 
 init routine(s).  It cycles through every cell in the universe
 for time T and calls the action routine.    

 [ A quick and dirty solution to the "collision" problem that 
   I raised earlier was suggested by one emailer who credits the, "'Wator'
   ecological simulation published long ago in Scientific American's
   Computer Recreations column".  Basically it involves resolving
   collisions on a first-come, first-served basis and minimizing
   order-dependent effects by processing the cells in *random* order.
   I accomplish this by creating a 1d array of size n, where n is
   the total number of cells in the "universe", containing the values
   0 thru n-1 in scrambled order.   This array is used as an index for 
   processing the cells in their arrays.     The disadvantages of this 
   approach are the added memory and processing overhead involved 
   and the the fact that it doesn't "really" solve the problem.
   Also random processing of arrays defeats many compiler optimizers
   out there.    Anyway, the cells are thus processed in random order.  ]

 After processing a generation it draws the results to the screen 
 using the application-supplied graphics rules.  It also copies 
 generation T_plus_1 to T and starts over.

 The CA program supplies a number of utilities to read the states
 of neighboring cells and to do the graphics.   By supplying functions
 for doing the graphics I can offer a simpler graphics interface to 
 the application than the one supplied by Zortech, and also make 
 the application less-dependent on the particular compiler's 
 graphics library.   I expect that I will eventually have a huge
 collection of CA applications and I don't want to have to rewrite
 them if I go to a different platform or compiler.
                
 I've written two applications so far: Life, and a Parity Rule 
 application.  They were very small and took minutes to write using this
 this interface.  


 What next: (besides getting a faster PC, with VGA display   8-)  )

    Graphics input:   I need an easy way to create starting patterns
                      instead of saying things like:
                         cell[32][34].state = 1;     <etc> 
                      ...maybe mouse support?


    File support:     Saving the state of a universe could be helpful 
                      on simulations that run for days, both to avoid 
                      starting 'from scratch'  after crashes or power
                      failures, and also so I can use the computer for
                      other things.

 
    Simple-cell support:  I designed my program for supporting fairly
                      complex definitions of cells, perhaps including     
                      floating point vectors and other state information.
                      So the *minimum* chunk of info per cell is a byte.
                      For many CA applications a bit or two is all that's
                      needed and a byte is the maximum (or more) on many
                      commercial CA's.  If I can find a *SIMPLE* way (for
                      the application interface) to support arrays of a
                      few bits per cell then I can support bigger universes.  

 
    Hard-copy:        I don't have any good way make hardcopies of my
                      hercules graphics screen.  (For you PC people, the 
                      *print screen* function doesn't work with Herc,
                      becuase Herc isn't supported on IBMs)  Being able
                      to convert the state of my universe to a standard
                      graphics file format would be helpful for printing it.

    
    Performance:      This doesn't exactly scream.  "Life" takes about
                      6 seconds to do one generation on a 110 X 110
                      wraparound grid ( on a 7Mhz 8088 ).   Probably 40%
                      of this is graphics bound since I can get a huge
                      speedup by only doing the graphics every nth generation.
                      Still, I think there are other opportunities for
                      efficiency in my program, as well.  The whole design
                      of this has favored simplicity and ease of application
                      writing over performance and I don't want to violate that.
                

    ( suggestions?   Since I've never used a commercial CA program
      I have no idea what they typically offer )



    The whole source is currently less than 200 lines long, including plenty
    of comments.   After I've cleaned it up and improved it I may be willing
    to post it if there is any interest.   


                                                    ---Peter

From ca-Request@Think.COM  Mon Feb 12 00:46:16 1990
Received: by fafnir.think.com; Mon, 12 Feb 90 00:46:16 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Mon, 12 Feb 90 00:46:11 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Mon, 12 Feb 90 00:47:03 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA15940; Sun, 11 Feb 90 23:58:56 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 12 Feb 90 04:53:59 GMT
From: snorkelwacker!usc!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!phillips@bloom-beacon.mit.edu  (George Phillips)
Organization: UBC Department of Computer Science, Vancouver, B.C., Canada
Subject: wireworld simulator for IBM PC
Message-Id: <6741@ubc-cs.UUCP>
To: ca@Think.COM

Here is my wireworld simulator for the PC.  I compiled it using
Turbo-C 2.0, but any version of Turbo-C should do.  It uses text
characters for the display.

WARNING:  This program is almost everything a good program shouldn't be:
inefficient, fragile and inflexible.  It does, however, simulate
wireworld.  It is in the public domain and if you want to claim you
wrote it, please do.

--
George Phillips phillips@cs.ubc.ca {alberta,uw-beaver,uunet}!ubc-cs!phillips

/*
 * wire -- simulate the wireworld as described in "Computer Recreations",
 * Scientific American, Jan. 1990, p. 146
 *
 * A real dumb-o algorithm is used.
 *
 * use: wire wire-file
 *
 * A wire-file uses '=' for a wire cell, '.' or ' ' for a space cell,
 * '#' for an electron head and '-' for an electron tail.
 *
 * The program waits for a key after each generation and quits if it
 * gets a 'q' or ESC.
 */

#include <stdio.h>
#include <conio.h>

#define MX	(80)
#define MY	(24)

#define SPACE	(0)
#define WIRE	(1)
#define HEAD	(2)
#define TAIL	(3)

static char w1[MY][MX];
static char w2[MY][MX];

static char *pretty = " =#-";

static void print_world(void);
static void next_gen(void);

main(int argc, char* argv[])
{
	static char buf[256];
	char* p;
	int	x;
	int	y;
	FILE*	fp;
	int	ch;

	if (argc != 2) {
		fprintf(stderr, "usage: wire file\n");
		exit(1);
	}

	if ((fp = fopen(argv[1], "r")) == NULL) {
		fprintf(stderr, "wire: can't open %s\n", argv[1]);
		exit(1);
	}

	for (x = 0; x < MX; x++)
		for (y = 0; y < MY; y++) {
			w1[y][x] = SPACE;
			w2[y][x] = SPACE;
		}

	y = 1;
	while (fgets(buf, 256, fp) != NULL) {
		x = 1;
		for (p = buf; *p; p++, x++) {
			switch (*p) {
			case '.':
			case ' ':
				w2[y][x] = SPACE;
				break;
			case '=':
				w2[y][x] = WIRE;
				break;
			case '#':
				w2[y][x] = HEAD;
				break;
			case '-':
				w2[y][x] = TAIL;
				break;
			case '\n':
				break;
			default:
				fprintf(stderr, "bad character in input: %c\n", *p);
				exit(1);
			}
		}
		y++;
	}
	fclose(fp);

	clrscr();

	for (;;) {
		print_world();
		next_gen();
		ch = getch();
		if (ch == 'q' || ch == 'Q' || ch == 27)
			break;
	}

	exit(0);
}

static void print_world(void)
{
	int	x;
	int	y;

	for (y = 0; y < MY; y++)
		for (x = 0; x < MX; x++) {
			if (w2[y][x] != w1[y][x]) {
				gotoxy(x + 1, y + 1);
				putch(pretty[w2[y][x]]);
				w1[y][x] = w2[y][x];
			}
		}
}

static void next_gen(void)
{
	int	x;
	int	y;
	int count;

	for (y = 1; y < MY - 1; y++)
		for (x = 1; x < MX - 1; x++) {
			switch (w1[y][x]) {
			case SPACE:
				w2[y][x] = SPACE;
				break;
			case TAIL:
				w2[y][x] = WIRE;
				break;
			case HEAD:
				w2[y][x] = TAIL;
				break;
			case WIRE:
				count = 0;
				if (w1[y - 1][x - 1] == HEAD) count++;
				if (w1[y    ][x - 1] == HEAD) count++;
				if (w1[y + 1][x - 1] == HEAD) count++;
				if (w1[y - 1][x    ] == HEAD) count++;
				if (w1[y + 1][x    ] == HEAD) count++;
				if (w1[y - 1][x + 1] == HEAD) count++;
				if (w1[y    ][x + 1] == HEAD) count++;
				if (w1[y + 1][x + 1] == HEAD) count++;

				if (count == 1 || count == 2)
					w2[y][x] = HEAD;
				else
					w2[y][x] = WIRE;
				break;
			default:
				fprintf(stderr, "uh-oh...\n");
				exit(1);
			}
		}
}

From ca-Request@Think.COM  Mon Feb 12 00:46:28 1990
Received: by fafnir.think.com; Mon, 12 Feb 90 00:46:28 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Mon, 12 Feb 90 00:46:23 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Mon, 12 Feb 90 00:47:14 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA16220; Mon, 12 Feb 90 00:05:25 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 12 Feb 90 04:57:03 GMT
From: snorkelwacker!usc!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!phillips@bloom-beacon.mit.edu  (George Phillips)
Organization: UBC Department of Computer Science, Vancouver, B.C., Canada
Subject: wireworld simulator for UNIX
Message-Id: <6742@ubc-cs.UUCP>
To: ca@Think.COM

Here is my wireworld simulator for UNIX.  It uses curses for the display
so it should work on any reasonable terminal.  I've run it on Sun 3's and
Sun 4's under SunOS 4.0.

WARNING:  This program is almost everything a good program shouldn't be:
inefficient, fragile and inflexible.  It does, however, simulate
wireworld.  It is in the public domain and if you want to claim you
wrote it, please do.

--
George Phillips phillips@cs.ubc.ca {alberta,uw-beaver,uunet}!ubc-cs!phillips

/*
 * wire - simulate the wirewold cellular automaton as described in the
 * Jan. 1990 issue of Scientific American (Computer Recreations, p. 146).
 *
 * The algorithm used is about as stupid as they get.  Big files will
 * almost certainly cause core dumps.  The input file format is rigid.
 *
 *	'='  is a wire
 *  '#'  is an electron head
 *  '-'  is an electron tail
 *  ' '  space
 *  '.'  space, too
 *
 * (watch out for tabs!)
 *
 * Just interrupt the program to quit (^C probably)
 *
 * To compile, use:
 *   cc -o wire wire.c -lcurses -ltermcap
 *
 * (And without the -ltermcap for System V Unix, I think)
 */

#include <stdio.h>
#include <curses.h>
#include <string.h>

char* w1;
char* w2;
char* aworld();

#define SPACE	(0)
#define WIRE	(1)
#define HEAD	(2)
#define TAIL	(3)

main(argc, argv)
int		argc;
char*	argv[];
{
	char	buf[256];
	char*	p;
	char*	q;
	int		line;

	initscr();

	w1 = aworld();
	w2 = aworld();

	line = 1;
	while (fgets(buf, 256, stdin) != NULL) {
		p = w1 + line * COLS + 1;
		for (q = buf; *q; q++) {
			switch (*q) {
			case '=':	*p++ = WIRE; break;
			case '-':	*p++ = TAIL; break;
			case '#':	*p++ = HEAD; break;
			case ' ':
			case '.':	*p++ = SPACE; break;
			case '\n':	break;
			default:
				fprintf(stderr, "bad char (%c) in file\n", *q);
				bye(1);
			}
		}
		line++;
	}

	for (;;) {
		do_gen();
		display();
	}

	bye(0);
}

do_gen()
{
	int	x;
	int	y;
	char* z;
	int count;

#define loc(x, y) (*(w1 + (x) + (y) * COLS))
#define add(x, y) if (loc(x, y) == HEAD) count++

	for (x = 1; x < COLS - 1; x++) {
		for (y = 1; y < LINES - 1; y++) {
			z = w2 + x + y * COLS;
			switch (*(w1 + x + y * COLS)) {
			case SPACE:
				*z = SPACE;
				break;
			case TAIL:
				*z = WIRE;
				break;
			case HEAD:
				*z = TAIL;
				break;
			case WIRE:
				count = 0;
				add(x - 1, y);
				add(x + 1, y);
				add(x - 1, y - 1);
				add(x, y - 1);
				add(x + 1, y - 1);
				add(x - 1, y + 1);
				add(x, y + 1);
				add(x + 1, y + 1);
				if (count == 1 || count == 2)
					*z = HEAD;
				else
					*z = WIRE;
				break;
			default:
				fprintf(stderr, "oops, bad internal character (%d) %c at %d,%d\n",
					*(w1 + x + y * COLS),
					*(w1 + x + y * COLS), x, y);
				sleep(2);
				bye(1);
			}
		}
	}
}

char ch[] = " =#-";

display()
{
	int	x;
	int	y;
	char c;

	for (x = 0; x < COLS; x++)
		for (y = 0; y < LINES; y++) {
			c = *(w2 + x + y * COLS);
			mvaddch(y, x, ch[c]);
			*(w1 + x + y * COLS) = c;
		}
	
	refresh();
}

char* aworld()
{
	char* w;
	int	i;

	w = (char*)malloc(LINES * COLS);
	if (w == NULL) {
		fprintf(stderr, "out of memory!\n");
		bye(1);
	}
	for (i = 0; i < LINES * COLS; i++)
		w[i] = SPACE;

	return(w);
}

bye(ecode)
int	ecode;
{
	mvaddch(LINES - 1, COLS - 1, '\r');
	refresh();
	endwin();
	exit(ecode);
}

From ca-Request@Think.COM  Mon Feb 12 00:46:40 1990
Received: by fafnir.think.com; Mon, 12 Feb 90 00:46:40 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Mon, 12 Feb 90 00:46:35 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Mon, 12 Feb 90 00:47:24 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA16551; Mon, 12 Feb 90 00:11:59 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 12 Feb 90 05:02:06 GMT
From: van-bc!ubc-cs!phillips@ucbvax.berkeley.edu  (George Phillips)
Organization: UBC Department of Computer Science, Vancouver, B.C., Canada
Subject: wireworld patterns
Message-Id: <6743@ubc-cs.UUCP>
To: ca@Think.COM

Here are some of the wireworld patterns I've developed.  A quick legend:

	'=' wire
	' ' or '.' space
	'#' electron head
	'-' electron tail

I avoid using spaces since they may get converted to tabs and my stupid
programs would fail.  Sometimes I'll stick in single tails ('-') just to
indicate where a pulse might be.  Not all of the patterns work, but I'll
try and comment on what should do what.  I suppose I should have put
these in a shar file, but that would have made commentary difficult so
you'll just have to hand edit them.

..................==....
.................=..=......
................===..======#-============.
................=.=.
.................=.=......................
.................=.=.....===-=====-====#-.
...==============.===...=................
...................=...=.................
....============....=#-....................
................=-#..........................
................=..=....................
.................==...................

A six-cycle memory cell.  It is about to remember a
1 and then a 0 and then go back to 1 after a couple cycles.  It has
a small bug in that the "write 0" line causes a single, spurious pulse
on the output, but that could be eliminated fairly easily.

........=
===================
........=
........=
........=
........=

A much improved "OR" gate (output going down):

..-...#..................................................................
.#==.-==.......======-#.......-#====-#==...............=.....=...........
..=...=................=................=.............=.=...=.=..........
..=.=.=...............===..............===............=.#...#.=..........
.=.===.=.............=.=................=..............-.=.=.-...........
.=..=..=..............=.========......==.=======.........=.=.............
.=..=..=.............==..............=.=...............=.=.=.=...........
.=..=..=.............==..............=.-.....-#====-#====...====#-=====-.
.=..=..=............=..=..............#.....=..........=.=.=.=..........=
.=..=..=.............#-.....................=............=.=............=
............................................=...........=...=...........=
............................................=...........=.=.=...........=
......................==....................=............===............#
.....===-#====-#==-#===.==.=................-.............=.............-
......................==..=.=...............=.............=.............=
.........................==..=========....................=.............=
......................==.=................................=..............
.....====-#====-===-#==.=.................................=..............
......................==..................................=..............
..........................................................=..............

In the above file we have a couple of NOT gates (top middle), an XOR gate
(bottom left) and a NAND gate (right).  The inelegant part of these
NOT and NAND gates is that they have internal clocks -- a pulse arriving
must be in sync with the internal clock or the gate will fail to function.
I don't believe this can be helped, but an OR gate only requires that the
incoming pulses be in sync, which is seems to be a much nicer property.
On the other hand, the NAND gate does have a certain visual appeal.

.............................................................................
............=.==...........................................==................
...........===..=.........................................=..=...............
.........==.=.=.=..................====-#=====..........==..===..............
........=.....=.=.................=...........=........=.....=..==...........
=====-#=..==.=..=..=.========......=====#-====.====-#==..==.=.==..=..........
.........#..=..======...................................#..=.....========....
=====-#=..-=.=..=..=.==-...........-====#-====.====-#==..-=.=.==..=..........
........=.....=.=....=..#.........#...........=........=.....=..==.....===...
.........==.=.=.=.....==...........===========..........==..===.....=.=......
...........===..=.........................................=..=...=======.....
............=.==......................=....................==...=...=.=......
........===.........................=.=........................=......==.....
.......=...=.======..............=======.................======.......=......
.......=..===..............-=====...=.=.................=........===..=......
.......#...=......................==..==...............=........=...=.=......
........#==......................=..=.=.......-#====-#=.........=..===.......
................................=..===..........................=...=........
................................=...=...............-#====-#=...====.........
.............................#======.........................===.............

On the left is an AND gate and on the right is a NAND gate being fed test
patterns.  The AND gate on the left is unfortunate:  internally clocked
and is really only A & B = ~(~A | ~B).  Happily, I found a non-clocked
AND gate (bottom right).  The key is the "H" pattern near the output --
it does that actually ANDing.  But 2 '1' pulses break the gate, so the
one signal must be multiplied into 2 electrons (by the G) with the
second electron stopping any out of control oscillations.  

.-...-.......==.....................#..........=...........................#.
#=#.#.=..-..=..-.....................====....===#.......................=====
.=...=..#.=.#..#.......#.............====...=..=....#......==.....==...=...=.
.=.=.=...=..-..=..#...===............====...=..=...====...=..=...=..=..=..=..
=.===.=..=...==..==-...=.=....#......====...=..=....=..=..=.==#..=..=...==...
=..=..=..=.=.=....=.....=....===.....=..=..#===.=..=.==....=.=....===#....=..
=..=..=.=.===.=...=.....=....===.....=..=...=...=..=.......=.....=..=.....=..
=..=..=.=..=..=...=.....=...==.==....=..=.......=..=......=.=.=.=.=.......=..
=..=..=.=..=..=...=.....=..=.=.=.=...=..=.......=..=.....=...===...=......=..
=..=..=.=..=..=...=.....=..=.=.=.=...=..=.......=..=.....=....=....=......=..
=..=..=.=..=..=...=.....=..=.=.=.=...=..=.......=..=......=...=...=.......=..
=..=..=.=..=..=...=.....=..=.=.=.=...=..=.......=..=.......=..=..=........=..
=..=..=.=..=..=...=.....=..=.=.=.=...=..=.......=..=.......=..=..=........=..
=..=..=.=..=..=...=.....=..=.=.=.=...=..=.......=..=.......=..=..=........=..
=..=..=.=..=..=...=.....=..=.=.=.=...=..=.......=..=.......=..=..=........=..
=..=..=.=..=..=...=.....=..=.=.=.=...=..=.......=..=.......=..=..=........=..
=..=..=.=..=..=...=.....=..=.=.=.=...=..=.......=..=.......=..=..=........=..
=..=..=.=..=..=...=.....=..=.=.=.=...=..=.......=..=.......=..=..=........=..
=..=..=.=..=..=...=.....=..=.=.=.=...=..=.......=..=.......=..=..=........=..
=..=..=.=..=..=...=.....=..=.=.=.=...=..=.......=..=.......=..=..=........=..
=..=..=.=..=..=...=.....=..=.=.=.=...=..=.......=..=.......=..=..=........=..

Some pulsars of rates from 3 to 9.  To make it a bit tougher, I decided that
I would have to make the pulsars get their initial electron from an outside
wire rather than having an electron in the loop from creation.  A little
junction which I call an "injector" accomplishes this.  Notice that the
rate 5 pulsar is really a rate 10 pulsar with 2 electrons.  I don't think it
is possible to build a loop which takes 5 generations to traverse.


.==========-#==========...........=====-#=========........................
=......................=.........=................=.......................
=......................=...=.....=................=.......................
=......................====.=....=................=.......................
=......................=....=....=...............===......................
=.....................===...=....=...............=.=......................
=.....................=.=..=......==========#-....=.......................
.#-....................=..===....................===......................
....................==.=...=....................=.=.......................
..===========-#======.=.===.=======.........==.=...=......................
.=................=.==.=...........=....=-#==.===...==============........
.=................=....=...........=...=....==.=.=........................
.=...............=...=.=...........=...=..........=.......................
.=...............=.====............=...=...........=......................
.=................=..=.=...........=...=...........=......................
.#.....................=...............=...........=......................
..-....................=...............=...........=......................
.......................=....===========............=......................
.......................=...=.......................=......................
.......................=....=#-...........................................

Some attempts at wire crossing.  The one on the left stops some pulses
with diodes and splits an incoming pulse so that it suppresses the
pulse which goes down the wrong wire.  The one on the right uses 
injectors to send the puses in the "right" direction with diodes to
stop the rest.  Unfortunately, both have a rather high cycle time.

.........................#.................
..........................=====............
...............................=...........
......................=...=====............
.....................=.=.=.................
.....................=.#.=.=.==............
......................-...===..#............
.....................===.=.=.=-............
......................=..=..................
.........======-#=====.==.==.===...===....
........=................=..=...=.=.......
........=...........-=.=.=.===..=.=.......
........=..........#..===...-....=..........
........=...........==.=.=.#.=..............
........=................=.=.=..............
........=................=..=...............
........=................=..................
........=................=..................
........=................=..................
.........=#-.............=..................

Another attempt at wire crossing.  The idea was to use "power" to make the
circuit faster.  But I ended up with nothing faster than before and
added internal clocking to boot :-(.

..................................
....................=====.........
.................=.=..............
................===...............
...............=.=.=..............
...............=...=..............
................=.=.==.=========..
............==.=.=.=..=...........
.#===========.=.=.=..===..........
-...........==.=.=.=..=...........
................=.=.==............
.................=................
................=.=...............
................===...............
.................#................
.................-................
.................=................
..................=================#-=

Another attempt at a wire crossing.  A pulse from the right will send
electrons slightly staggered to the top wire.  They will then cancel
each other.  But the 2 electrons going to the right do not cancel each
other and send an output to the right.  Similarly for the input on the
bottom.  Diodes keep the other signals in check.  A nice idea, but
still the cycle time is large :-(.  I should hope a better wire crossing
can be constructed...

--
George Phillips phillips@cs.ubc.ca {alberta,uw-beaver,uunet}!ubc-cs!phillips

From ca-Request@Think.COM  Wed Feb 14 06:01:59 1990
Received: by fafnir.think.com; Wed, 14 Feb 90 06:01:59 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Wed, 14 Feb 90 06:01:55 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Wed, 14 Feb 90 06:02:48 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA28766; Wed, 14 Feb 90 04:41:11 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 13 Feb 90 22:08:37 GMT
From: tektronix!reed!minar@bloom-beacon.mit.edu  (Nelson Minar,(???))
Organization: Reed College, Portland, OR
Subject: Basic definition of a CA
Message-Id: <14141@reed.UUCP>
To: ca@Think.COM


I'm toying with the idea of writing a basic template for CA machines: IE one
where the user can specify his own CA machine. This brings up the question
of what exactly defines a CA, and the best way to express this information.

Clearly, a CA is a collection of cells whose states change from tick to tick
according to some algorithm. Two things bear definition here:

'collection of cells' I'm willing to require n-dimensional array structures
here (although alternate geometries could be interesting)

'algorithm' : this is the tough one.  At the most basic level, at each tick
each cell on the grid is set to be some function of cells in the previous
grids. For basic Life 2333 its

become state 0 if previously it was in state 0 and has 1-2 or 4-8 neighbours
                  in an 8 cell neighbourhood or
               if previously it was in state 1 and has 1 or 4-8 neighbours
                  in an 8 cell neighbourhood
become state 1 if previously it was in state 0 and has 3 neighbours in an
                  8 cell neighbourhood or
               if previously it was in state 1 and has 2-3 neighbours
               /* could possibly be shortened "otherwise" */

There are several problems with this 'basic' definition: there is a LOT of
information to specify here: more than your average hack will want to have
to input.  It is not trivial to consolidate this information into terse
symbols, the kind you expect from a programming language.  It is possible
under this scheme to define a conflict, where a cell could become state 2 or
3 the next tick (a bug, to be sure, but hard to detect).  Optimizing this
type of algorithm would be hellish.

is there a nicer way to define a CA?

From ca-Request@Think.COM  Wed Feb 14 09:15:17 1990
Received: by fafnir.think.com; Wed, 14 Feb 90 09:15:17 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Wed, 14 Feb 90 09:15:13 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Wed, 14 Feb 90 09:16:04 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA07758; Wed, 14 Feb 90 08:10:30 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 14 Feb 90 13:07:51 GMT
From: jwmills@iuvax.cs.indiana.edu  (Jonathan Mills)
Organization: Indiana University, Bloomington
Subject: Re: Basic definition of a CA
Message-Id: <35783@iuvax.cs.indiana.edu>
References: <14141@reed.UUCP>
To: ca@Think.COM

In article <14141@reed.UUCP> minar@reed.bitnet (Nelson Minar) writes:
>
>I'm toying with the idea of writing a basic template for CA machines: IE one
>where the user can specify his own CA machine. This brings up the question
>of what exactly defines a CA, and the best way to express this information.
>

Codd, E.F., "Cellular Automata," Academic Press, New York, NY, 1968 has
my preferred definition of a cellular automata.

Mills, Beavers & Daffinger, "Lukasiewicz Logic Arrays", TR 296, Indiana
University Computer Science Department, November 1989 has an extension of
Codd's definitions to the general class of cellular automata that allow
variation of states, neighborhoods, and transition functions between cells
and time instants.  These automata are called "heterogeneous" to distinguish
them from the "homogeneous" CAs discussed by von Neumann in "Theory of Self-
Reproducing Automata," edited by Burks.

I have observed that much of the recent work in more complicated CAs can be
expressed in terms of a CA with some degree of heterogeneity.

>It is not trivial to consolidate this information into terse
>symbols, the kind you expect from a programming language.

Check out Toffoli & Margolus, "Cellular Automata Machines," for descriptions
in CA-Forth that are terse.  CAs can also be defined concisely in Prolog,
which I have used for prototyping CAs recently.  

>It is possible
>under this scheme to define a conflict, where a cell could become state 2 or
>3 the next tick (a bug, to be sure, but hard to detect).

Don't use that scheme.  No conflict should exist in a definition for LIFE.
In fact, if a DFA controls the transition function for a CA, and the
DFA is fully defined for all neighborhood states, no conflict is possible.
The scheme suggested means that two different transitions from some cell state
in the DFA are labelled with the same neighborhood state.

>Optimizing this
>type of algorithm would be hellish.

Hell = place where all interesting optimizations are trivial.  (:-)

>
>is there a nicer way to define a CA?

Have you looked at CellSim (soon-to-be-out in Version 2)?  Or CA Lab (recently
mentioned in this group)?

I am also working on a general graphic/visual CA for the Macintosh that
embodies those features _I_ need & can't find elsewhere...but many of the
existing packages should be useful for you.

From ca-Request@Think.COM  Wed Feb 14 20:20:09 1990
Received: by fafnir.think.com; Wed, 14 Feb 90 20:20:09 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Wed, 14 Feb 90 20:20:05 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Wed, 14 Feb 90 20:21:00 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA28198; Wed, 14 Feb 90 15:31:40 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 14 Feb 90 18:36:01 GMT
From: zephyr.ens.tek.com!tekcrl!brucec@beaver.cs.washington.edu
Organization: Tektronix
Subject: Re: Basic definition of a CA
Message-Id: <5595@tekcrl.LABS.TEK.COM>
References: <14141@reed.UUCP>
To: ca@Think.COM

In article <14141@reed.UUCP> minar@reed.bitnet (Nelson Minar) writes:
>
>I'm toying with the idea of writing a basic template for CA machines: IE one
>where the user can specify his own CA machine. This brings up the question
>of what exactly defines a CA, and the best way to express this information.
>
>Clearly, a CA is a collection of cells whose states change from tick to tick
>according to some algorithm. Two things bear definition here:

>
>'collection of cells' I'm willing to require n-dimensional array structures
>here (although alternate geometries could be interesting)
>
>'algorithm' : this is the tough one.  At the most basic level, at each tick
>each cell on the grid is set to be some function of cells in the previous
>grids. For basic Life 2333 its
>
>become state 0 if previously it was in state 0 and has 1-2 or 4-8 neighbours
>                  in an 8 cell neighbourhood or
>               if previously it was in state 1 and has 1 or 4-8 neighbours
>                  in an 8 cell neighbourhood
>become state 1 if previously it was in state 0 and has 3 neighbours in an
>                  8 cell neighbourhood or
>               if previously it was in state 1 and has 2-3 neighbours
>               /* could possibly be shortened "otherwise" */
>
>There are several problems with this 'basic' definition: there is a LOT of
>information to specify here: more than your average hack will want to have
>to input.  It is not trivial to consolidate this information into terse
>symbols, the kind you expect from a programming language.  It is possible
>under this scheme to define a conflict, where a cell could become state 2 or
>3 the next tick (a bug, to be sure, but hard to detect).  Optimizing this
>type of algorithm would be hellish.
>
>is there a nicer way to define a CA?

About four years ago, while investigating some properties of pyramidal
arrays of processors, I built a simple CA simulator which could handle
arbitrary topologies of cell connections, and arbitrary state transition
functions.  Well, the topologies were theoretically arbitrary, but I must
admit that I never tried to build anything other than 2 & 3D rectangular
meshes and 3D pyramids.

At the time, I didn't have a copy of Codd's book, though I had read it
about 10 or 12 years before, and Toffoli & Margulis' book hadn't yet been
published, so I had to roll my own definition.  The result was to consider
the system as an array of cells, where each cell is a tuple of the form <S,
N, A>, with S a state (an integer), N a set of neighboring cells including
the current cell itself (possibly with some ordering on them, to handle
directed structures like pyramids), and A a deterministic finite automaton
whose state is recorded as S.  If the transition function of A is F(N),
then future states S will always depend deterministically on the current
states of the cell and its neighbors.

Obviously, the hard part is finding a standard way to describe F(N).  Since
I was coding the simulator in Lisp, it seemed reasonable to allow any Lisp
function which was side-effect free (i.e. a pure function), used only the
states of the cell and its neighbors as data and which did not violate the
constraints of any ordering on the neighbors.  In retrospect, I think this
is more than just a programming convention: pure functions are useful
mathematical entities expressible in just about any programming language.

The moral is that you should use the basic mathematical description of an
automaton as the basis of any standard way of describing arbitrary CA's.

Bruce Cohen
brucec@tekcrl.labs.tek.com
Computer Research Lab, Tektronix Laboratories
Tektronix, Inc.
M/S 50-662, P.O. Box 500, Beaverton, OR  97077

From ca-Request@Think.COM  Fri Feb 16 01:43:56 1990
Received: by fafnir.think.com; Fri, 16 Feb 90 01:43:56 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Fri, 16 Feb 90 01:43:53 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Fri, 16 Feb 90 01:44:51 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA09596; Fri, 16 Feb 90 00:50:14 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 15 Feb 90 18:27:55 GMT
From: silver!efreeman@iuvax.cs.indiana.edu  (Eric T. Freeman)
Organization: Indiana University, Bloomington
Subject: New ARTIFICIAL LIFE mailing list
Message-Id: <35953@iuvax.cs.indiana.edu>
To: ca@Think.COM


            New ARTIFICIAL LIFE Email Distribution List
            -------------------------------------------

   At the second workshop for Artificial Life in Santa Fe, February 1990,
the need emerged for an email distribution list to provide a forum for 
discussion, ideas, comments and announcements in the area of Artificial Life 
Research.  

	Artificial Life is the study of man-made systems that exhibit
	behaviors characteristic of natural living systems.  It 
	complements the traditional biological sciences concerned with
	the analysis of living organisms by attempting to synthesize
	life-like behaviors within computers and other
	artificial media.  By extending the empirical foundation
	upon which biology is based beyond the carbon-chain life
	that has evolved on Earth, Artificial Life can contribute
	to theoretical biology by locating life-as-we-know-it 
	within the larger picture of life-as-it-could-be.

		C. Langton 1989

The Artificial Life Research Group at Indiana University has been granted
the responsibility for maintaining and archiving this list.

Send all requests for additions/deletions/general business to:

		alife-request@iuvax.cs.indiana.edu

Send all contributions to the alife list to:
	
		alife@iuvax.cs.indiana.edu


Local re-distribution lists are welcome so long as the local
distribution information is available to the list maintainers
and we are notified beforehand.

Since the list maintainers wish to retain touch with the list subscribers
and maintain accountability for this list, any other re-distribution to 
other lists/boards is prohibited.


		Sincerely,

			Elisabeth Freeman
			Eric Freeman
			Marek Lugowski

			Artificial Life Research Group
			Computer Science Department
			Indiana University
			Bloomington, IN 47405
			U.S.A.

From ca-Request@Think.COM  Fri Feb 16 09:34:12 1990
Received: by fafnir.think.com; Fri, 16 Feb 90 09:34:12 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Fri, 16 Feb 90 09:34:00 EST
Received: from CORNELLC.CIT.CORNELL.EDU by Think.COM; Fri, 16 Feb 90 09:34:56 -0500
Message-Id: <9002161434.AA12827@Think.COM>
Received: from UABTUCC.BITNET by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 0466; Fri, 16 Feb 90 09:35:03 EST
Date: FRI, 16 FEB 90 08:33 CDT
From: BARRY BOWDEN <CSER037%UABTUCC.BITNET@CORNELLC.cit.cornell.edu>
To: ALL <CA@Think.COM>
Subject: 3D LIFE


Where can I find a copy of the Mac program for 3D life that was
mentioned in Scientific American 2-3 years ago? It was written
by someone (I do not remember) fron South Carolina. Can anyone
help me???

Barry Bowden
CSER037@TUCCUAB.BITNET

From ca-Request@Think.COM  Sat Feb 17 02:23:24 1990
Received: by fafnir.think.com; Sat, 17 Feb 90 02:23:24 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Sat, 17 Feb 90 02:23:21 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Sat, 17 Feb 90 02:24:19 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA27271; Sat, 17 Feb 90 01:28:43 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 16 Feb 90 16:13:27 GMT
From: psuvm!hul@psuvax1.cs.psu.edu  (Dean Hickerson)
Organization: Penn State University
Subject: Re: 3D LIFE
Message-Id: <90047.111327HUL@psuvm.psu.edu>
References: <9002161434.AA12827@Think.COM>
To: ca@Think.COM

In article <9002161434.AA12827@Think.COM>, CSER037@UABTUCC.BITNET (BARRY
BOWDEN) says:
>
>Where can I find a copy of the Mac program for 3D life that was
>mentioned in Scientific American 2-3 years ago? It was written
>by someone (I do not remember) fron South Carolina. Can anyone
>help me???

Contact:
        Carter Bays
        Dept. of Computer Science
        LeConte Bldg.
        Univ. of South Carolina
        Columbia, SC  29208

For a while he was publishing a "3-D Life Newsletter"; I don't know if
it's still going.
-------
Dean Hickerson,  Dept. of Math., Penn State Univ., University Park, PA 16802
hul@psuvm.psu.edu

From ca-Request@Think.COM  Sat Feb 17 09:20:11 1990
Received: by fafnir.think.com; Sat, 17 Feb 90 09:20:11 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Sat, 17 Feb 90 09:20:08 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Sat, 17 Feb 90 09:21:06 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA11031; Sat, 17 Feb 90 08:11:41 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 17 Feb 90 00:04:00 GMT
From: ucsdhub!hp-sdd!apollo!nelson_p@ucsd.edu  (Peter Nelson)
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Subject: other related newsgroups
Message-Id: <48afd643.20b6d@apollo.HP.COM>
To: ca@Think.COM


                                       

   I have been reading the postings on comp.theory.cell-automata and
   comp.theory.self-org-sys and, while the quality of the postings
   is very high, the volume is very low.   For instance, currently
   at this site there are only three postings on file for the self-
   org-sys newsgroup and they're all from me!   -   8-)   8-)   - 
   ( you should see the flame wars I have with myself! ) 

   But really, I was wondering if there are any other places where
   there are active discussions on these topics.  For instance, 
   are there any *active* discussion groups on Compuserve, BIX, 
   or other such forums?  

   Are there any journals devoted to these kinds of topics?  
   What is a good way to stay up to date with, and participate
   in discussions on, these topics?

   Thanks in advance.


                                              ---Peter

From ca-Request@Think.COM  Sat Feb 17 09:43:24 1990
Received: by fafnir.think.com; Sat, 17 Feb 90 09:43:24 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Sat, 17 Feb 90 09:43:22 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Sat, 17 Feb 90 09:44:20 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA11993; Sat, 17 Feb 90 08:37:17 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 16 Feb 90 17:32:05 GMT
From: zephyr.ens.tek.com!tekcrl!brucec@uunet.uu.net
Organization: Tektronix
Subject: Re: 3D LIFE
Message-Id: <5609@tekcrl.LABS.TEK.COM>
References: <9002161434.AA12827@Think.COM>
To: ca@Think.COM

In article <9002161434.AA12827@Think.COM> CSER037@UABTUCC.BITNET (BARRY BOWDEN) writes:
>
>Where can I find a copy of the Mac program for 3D life that was
>mentioned in Scientific American 2-3 years ago? It was written
>by someone (I do not remember) fron South Carolina. Can anyone
>help me???
>
>Barry Bowden
>CSER037@TUCCUAB.BITNET

the address I have is:

Carter Bays
Dept. of COmputer Science
LeConte Bldg.
University of South Carolina
Columbia, S.C. 29208

He also put out a newsletter on the subject of 3D life for awhile.  Mine
got boxed in a move a few weeks ago, and haven't been seen since.  If I
find them, I'll check that the address is the same.

Bruce Cohen
brucec@tekcrl.labs.tek.com
Computer Research Lab, Tektronix Laboratories
Tektronix, Inc.
M/S 50-662, P.O. Box 500, Beaverton, OR  97077

From ca-Request@Think.COM  Sat Feb 17 11:57:13 1990
Received: by fafnir.think.com; Sat, 17 Feb 90 11:57:13 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Sat, 17 Feb 90 11:57:02 EST
Received: from VTVM1.CC.VT.EDU by Think.COM; Sat, 17 Feb 90 11:57:58 -0500
Received: from urvax.urich.edu by VTVM1.CC.VT.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 3361; Sat, 17 Feb 90 11:57:40 EST
Received: from lundin.urich.edu by urvax.urich.edu; Sat, 17 Feb 90 12:00 EST
Date: Sat, 17 Feb 90 09:07 EST
From: The PC of John Lundin <lundin%lundin.urich.edu@VTVM1.CC.VT.EDU>
Subject: Re: 3D LIFE
To: BARRY BOWDEN <CSER037@UABTUCC.BITNET>
Cc: CA@Think.COM, lundin@urvax.urich.edu
Errors-To: "KludgeMail 0.2a postmaster" <lundin@urvax.urich.edu>
Reply-To: John Lundin Jr <lundin%urvax.urich.edu@VTVM1.CC.VT.EDU>
Message-Id: <900217001@lundin.urich.edu>
In-Reply-To: Your message of Fri, 16 Feb 90 08:33:00 CDT,
 <D9D3723621DF000094@urvax.urich.edu>
X-Envelope-To: CA@Think.COM

You can try:   Carter Bays
               Dept. of Computer Science
               LeConte Bldg.
               University of South Carolina
               Columbia, S. C.  29208

and good luck.  This address is taken from issue two of the 3-D CA newsletter,
sent out on Aug. 25, 1988 but dated "7/88" internally.  Despite the original
premise, this appears to have been the last issue.

The last letter I sent to Carter Bays went unanswered.  May you have better
luck.  USC is on the net, anyone know if he can be reached by Email?

For that matter, do you know of an MS-Dos version?  Thanks,  -john

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
John Lundin, Jr.        lundin@urvax.bitnet    "Immature programmers imitate,
University of Richmond  lundin@lundin.urich.edu   mature programmers steal"

From ca-Request@Think.COM  Sat Feb 17 14:22:09 1990
Received: by fafnir.think.com; Sat, 17 Feb 90 14:22:09 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Sat, 17 Feb 90 14:22:05 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Sat, 17 Feb 90 14:23:02 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA27725; Sat, 17 Feb 90 14:15:49 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 17 Feb 90 19:12:35 GMT
From: zaphod.mps.ohio-state.edu!rpi!hiebeler@Think.COM  (Dave Hiebeler)
Organization: RPI CS Dept, and LANL Center for Nonlinear Studies
Subject: Re: other related newsgroups
Message-Id: <BW!#?$@rpi.edu>
References: <48afd643.20b6d@apollo.HP.COM>
To: ca@Think.COM

In article <48afd643.20b6d@apollo.HP.COM> nelson_p@apollo.HP.COM (Peter Nelson) writes:

>    Are there any journals devoted to these kinds of topics?  

  The following journals have pretty relevant stuff:
 - Physica D   (journal on nonlinear phenomena)
 - Complex Systems

  Stuff related to CA also shows up somewhat frequently in Dewdney's
column in Scientific American, and his new Algorithm magazine, and
also occasionally in Byte.  But Physica D and Complex Systems are
where a lot of the CA stuff comes out.
  The proceedings of the CA '89 are going to be coming out in an
upcoming Physica D, I believe.

  You may also be interested in the Santa Fe Institute's "Studies in
the Sciences of Complexity" series, published by Addison-Wesley.  The
series has books such as
 - Lattice Gas Methods for PDE's, edited by Gary Doolen et al
 - Artificial Life, edited by Chris Langton
 - Lectures in the Sciences of Complexity, edited by Daniel Stein

-- 
Dave Hiebeler / Computer Science Dept. / Amos Eaton Bldg. /
Rensselaer Polytechnic Institute / Troy, NY 12180-3590 USA
Internet (preferred): hiebeler@turing.cs.rpi.edu   Bitnet: userF3JL@rpitsmts

From ca-Request@Think.COM  Sat Feb 17 17:32:44 1990
Received: by fafnir.think.com; Sat, 17 Feb 90 17:32:44 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Sat, 17 Feb 90 17:32:40 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Sat, 17 Feb 90 17:33:34 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA05901; Sat, 17 Feb 90 16:49:28 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 17 Feb 90 21:46:06 GMT
From: cjoslyn@bingvaxu.cc.binghamton.edu  (Cliff Joslyn)
Organization: SUNY Binghamton, NY
Subject: Re: other related newsgroups
Message-Id: <3025@bingvaxu.cc.binghamton.edu>
References: <48afd643.20b6d@apollo.HP.COM>
To: ca@Think.COM


With regards to related newsgroups, all of these fields are the
intellectual descendants of Systems Science and Cybernetics.  We have a
lively and intelligent discussion group going.  Blurb follows. 

O------------------------------------------------------------------------->
| Cliff Joslyn, Cybernetician at Large, cjoslyn@bingvaxu.cc.binghamton.edu
| Systems Science, SUNY Binghamton, Box 1070, Binghamton NY 13901, USA
V All the world is biscuit shaped. . .

============================================================================

     ANNOUNCING FORMATION OF A MAILING LIST FOR SYSTEMS AND CYBERNETICS
     
     An electronic mailing list dedicated to Systems Science and Cybernetics 
     is currently in operation on the SUNY-Binghamton computer system.  The 
     list is commited to discussing a general understanding of the evolution 
     of complex, multi-level systems like organisms, minds, and societies as 
     informational entities containing possibly circular processes.  Specific 
     subjects include Complex Systems Theory, Self-Organizing Systems Theory, 
     Dynamic Systems Theory, Artificial Intelligence, Network Theory, 
     Semiotics, fractal geometry, Fuzzy Set Theory, Recursive Theory, computer 
     simulation, Information Theory, and more.
     
     The purposes of the list include: 1) facilitating discussion among those 
     working in or just interested in the general fields of Systems and 
     Cybernetics; 2) providing a means of communicating to the general 
     research community about the work that Systems Scientists and 
     Cyberneticians do; 3) housing a repository of electronic files for 
     general distribution concerning Systems and Cybernetics; and 4) providing 
     a central, public directory of working Systems Scientists and 
     Cyberneticians.  The mailing list can store or transmit notes and 
     messages, technical papers, references, calls for papers, computer 
     programs, and pictures and diagrams.
     
     The list is coordinated by members of the Systems Science department of 
     the Watson School at SUNY-Binghamton, and is affiliated with the 
     International Society for the Systems Sciences (ISSS) and the American 
     Society for Cybernetics (ASC).  The list is open to everyone, and we 
     currently have two hundred members from America, Canada, and Europe.  Our 
     subscribers are from both academia and industry, and while many are 
     active researchers, others are just "listening in".  We share in an 
     exciting, ongoing, multi-way conversation about many aspects of Systems 
     and Cybernetics.  Different levels and kinds of knowledge and experience 
     are represented.
     
     We invite all to join the discussion.  To subscribe, you need a computer 
     account with access to one of the international networks (e.g. BITNET, 
     USENET, ARPANET, INTERNET, CSNET).  Send a file containing only the line: 
     'SUB CYBSYS-L Your Full Name' to the list server at the address 
     LISTSERV@BINGVMB.BITNET. 
     
     Once subscribed, please post a message to the list itself at the address 
     CYBSYS-L@BINGVMB.BITNET.  In the message, include your name, affiliation, 
     and a brief description of your work and/or interest in the fields of 
     Systems and Cybernetics. 
     
     List moderator: CYBSYS@BINGVAXU.CC.BINGHAMTON.EDU 
     
     Author: Cliff Joslyn, CJOSLYN@BINGVAXU.CC.BINGHAMTON.EDU
     
  


-- 
O------------------------------------------------------------------------->
| Cliff Joslyn, Cybernetician at Large, cjoslyn@bingvaxu.cc.binghamton.edu
| Systems Science, SUNY Binghamton, Box 1070, Binghamton NY 13901, USA
V All the world is biscuit shaped. . .

From ca-Request@Think.COM  Sat Feb 17 22:09:50 1990
Received: by fafnir.think.com; Sat, 17 Feb 90 22:09:50 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Sat, 17 Feb 90 22:09:39 EST
Received: from uunet.UU.NET by Think.COM; Sat, 17 Feb 90 22:10:36 -0500
Received: from acad.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA01537; Sat, 17 Feb 90 22:09:01 -0500
Received: from megalon.acad.com by acad.uucp  (3.2/SMI-3.2)
	id AA13957; Sat, 17 Feb 90 13:38:12 PST
Received: by megalon.acad.com (3.2/SMI-3.2)
	id AA05017; Sat, 17 Feb 90 13:38:10 PST
Date: Sat, 17 Feb 90 13:38:10 PST
From: acad!megalon!rudy@uunet.UU.NET (Rudy Rucker)
Message-Id: <9002172138.AA05017@megalon.acad.com>
To: ca@Think.COM
Subject: 3D Life


We have  two canned movies of 3D CAs in the CA Lab package from Autodesk.
3D CAs seem clearly to be the next neat thing to look at.  I've never
seen Carter Bays 3D Life program for the Mac, and I don't think anyone
has done a PC version at all.  Once the CAM-8 comes on line (late this
year?) we can look at lots of 3D CAs.  A question which interests me is
what forms 3D Zhabotinsky style reactions will take.  The most obvious
is the "mushroom" where a disk or square pushes out waves which coil
over at the sides.  What I'd rather see, though is a nautilus shell.

rudy@autodesk.com

Rudy Rucker

From ca-Request@Think.COM  Sun Feb 18 05:23:26 1990
Received: by fafnir.think.com; Sun, 18 Feb 90 05:23:26 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Sun, 18 Feb 90 05:23:22 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Sun, 18 Feb 90 05:24:21 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA12829; Sun, 18 Feb 90 05:11:02 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 18 Feb 90 10:09:14 GMT
From: zaphod.mps.ohio-state.edu!rpi!hiebeler@Think.COM  (Dave Hiebeler)
Organization: RPI CS Dept, and LANL Center for Nonlinear Studies
Subject: CAM-8 availability (was Re: 3D Life)
Message-Id: <'^##4+$@rpi.edu>
References: <9002172138.AA05017@megalon.acad.com>
To: ca@Think.COM

In article <9002172138.AA05017@megalon.acad.com> rudy@megalon.UUCP (Rudy Rucker) writes:

> Once the CAM-8 comes on line (late this
> year?) we can look at lots of 3D CAs.

  From what I've heard, I seriously doubt CAM-8 will be commercially
available in less than 2 years.  I don't think there will even be a
strong prototype built within a year, although maybe I'm pushing it
with that claim.

  Anyone who has more solid info, please correct me.  But I think the
Information Mechanics Group designing CAM-8 are having some slight
delays (no problems in the design or anything -- just delays).

  It'll probably be a pretty super machine when it does finally become
available, though!
-- 
Dave Hiebeler / Computer Science Dept. / Amos Eaton Bldg. /
Rensselaer Polytechnic Institute / Troy, NY 12180-3590 USA
Internet (preferred): hiebeler@turing.cs.rpi.edu   Bitnet: userF3JL@rpitsmts

From ca-Request@Think.COM  Mon Feb 19 13:54:44 1990
Received: by fafnir.think.com; Mon, 19 Feb 90 13:54:44 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from grogo.think.com by fafnir.think.com; Mon, 19 Feb 90 13:54:35 EST
Received: by grogo.think.com (4.0/SMI-4.0) id AA00481; Mon, 19 Feb 90 13:54:30 EST
Date: Mon, 19 Feb 90 13:54:30 EST
From: bruce@Think.COM
Message-Id: <9002191854.AA00481@grogo.think.com>
To: cellular-automata@think.com
Subject: administrivia

I have once again caught up with all the requests for mailing list changes.
This is a mass-greeting to the new members and a test of the list as it
stands.

Also, I have made an official name change of the Internet mailing list: we
are now "Cellular-Automata@Think.COM", not "CA@Think.COM".  The latest
List-of-Lists should refer to the new name.

Cellular-Automata-Request@Think.COM is the new place to send administrative
requests.  CA and CA-Request will remain active aliases for a couple of
months, after which they will be invalid.  So far, I have not renamed the
archives.

I made the name change so the list name was more descriptive and to avoid
accidents like the one several months ago when a local user sent random
stuff to "ca" because of a typo.

BITNET users can and should still manage their own subscriptions via the
CA-L list managed by LISTSERV@MITVMA.MIT.EDU.

--Bruce Walker (Nemnich)
  Thinking Machines Corporation, Cambridge, MA
  bruce@think.com; +1 617 876 1111

From ca-Request@Think.COM  Mon Feb 19 16:38:39 1990
Received: by fafnir.think.com; Mon, 19 Feb 90 16:38:39 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Mon, 19 Feb 90 16:38:36 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Mon, 19 Feb 90 16:39:36 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA25380; Mon, 19 Feb 90 16:02:59 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 19 Feb 90 20:59:37 GMT
From: zaphod.mps.ohio-state.edu!rpi!hiebeler@Think.COM  (Dave Hiebeler)
Organization: RPI CS Dept, and LANL Center for Nonlinear Studies
Subject: Re: CAM-8 availability (was Re: 3D Life)
Message-Id: <*7##6S*@rpi.edu>
References: <9002172138.AA05017@megalon.acad.com>, <'^##4+$@rpi.edu>
To: ca@Think.COM

In article <'^##4+$@rpi.edu> I wrote:

>   From what I've heard, I seriously doubt CAM-8 will be commercially
> available in less than 2 years.  I don't think there will even be a
> strong prototype built within a year, although maybe I'm pushing it
> with that claim.

  I think I was indeed going too far with that claim, after thinking
about it for a moment.  I really don't have any official info on
CAM-8's status, and I think I was exagerrating a bit.  I should have
at least added a hefty disclaimer to my message; but it is still early
in the year, so maybe there will be a proto-cam-8 around by the end of
the year.

  I realized this when someone who read my message took it perhaps
more seriously than I intended.

>   It'll probably be a pretty super machine when it does finally become
> available, though!

  This part of the message I still stand by.  :-)

-- 
Dave Hiebeler / Computer Science Dept. / Amos Eaton Bldg. /
Rensselaer Polytechnic Institute / Troy, NY 12180-3590 USA
Internet (preferred): hiebeler@turing.cs.rpi.edu   Bitnet: userF3JL@rpitsmts

From ca-Request@Think.COM  Mon Feb 19 22:46:30 1990
Received: by fafnir.think.com; Mon, 19 Feb 90 22:46:30 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Mon, 19 Feb 90 22:46:26 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Mon, 19 Feb 90 22:47:23 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA07447; Mon, 19 Feb 90 21:39:19 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 20 Feb 90 00:05:27 GMT
From: zephyr.ens.tek.com!tekcrl!brucec@beaver.cs.washington.edu
Organization: Tektronix
Subject: Cam-8 for Macintosh? (was Re: CAM-8 availability)
Message-Id: <5632@tekcrl.LABS.TEK.COM>
References: <9002172138.AA05017@megalon.acad.com>, <'^##4+$@rpi.edu>, <*7##6S*@rpi.edu>
To: ca@Think.COM

Does anyone in netland know if there is a plan for Cam-8 (or any other
version of Cam) to be hosted by a Macintosh instead of a PC  (or maybe
even, dare I say it, a Sun)?  There are a whole host of us out here who
don't use PC's and don't really want to.  For that matter, there are
a number of us who use workstations with high enough prices that adding a
CAM multiplies the sticker by less than 2.0 :-).

Bruce Cohen
brucec@tekcrl.labs.tek.com
Computer Research Lab, Tektronix Laboratories
Tektronix, Inc.
M/S 50-662, P.O. Box 500, Beaverton, OR  97077

From ca-Request@Think.COM  Tue Feb 20 00:06:52 1990
Received: by fafnir.think.com; Tue, 20 Feb 90 00:06:52 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Tue, 20 Feb 90 00:06:48 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Tue, 20 Feb 90 00:07:47 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA08945; Mon, 19 Feb 90 22:31:00 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 15 Feb 90 18:27:55 GMT
From: mcsun!ukc!strath-cs!expya!edu.indiana.ucs.silver@uunet.uu.net  (Eric T. Freeman)
Organization: Indiana University, Bloomington
Subject: New ARTIFICIAL LIFE mailing list
Message-Id: <1601@expya.cs.exeter.ac.uk>
To: ca@Think.COM



            New ARTIFICIAL LIFE Email Distribution List
            -------------------------------------------

   At the second workshop for Artificial Life in Santa Fe, February 1990,
the need emerged for an email distribution list to provide a forum for 
discussion, ideas, comments and announcements in the area of Artificial Life 
Research.  

	Artificial Life is the study of man-made systems that exhibit
	behaviors characteristic of natural living systems.  It 
	complements the traditional biological sciences concerned with
	the analysis of living organisms by attempting to synthesize
	life-like behaviors within computers and other
	artificial media.  By extending the empirical foundation
	upon which biology is based beyond the carbon-chain life
	that has evolved on Earth, Artificial Life can contribute
	to theoretical biology by locating life-as-we-know-it 
	within the larger picture of life-as-it-could-be.

		C. Langton 1989

The Artificial Life Research Group at Indiana University has been granted
the responsibility for maintaining and archiving this list.

Send all requests for additions/deletions/general business to:

		alife-request@iuvax.cs.indiana.edu

Send all contributions to the alife list to:
	
		alife@iuvax.cs.indiana.edu


Local re-distribution lists are welcome so long as the local
distribution information is available to the list maintainers
and we are notified beforehand.

Since the list maintainers wish to retain touch with the list subscribers
and maintain accountability for this list, any other re-distribution to 
other lists/boards is prohibited.


		Sincerely,

			Elisabeth Freeman
			Eric Freeman
			Marek Lugowski

			Artificial Life Research Group
			Computer Science Department
			Indiana University
			Bloomington, IN 47405
			U.S.A.

From ca-Request@Think.COM  Tue Feb 20 10:38:50 1990
Received: by fafnir.think.com; Tue, 20 Feb 90 10:38:50 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Tue, 20 Feb 90 10:38:41 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Tue, 20 Feb 90 10:39:36 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA07627; Tue, 20 Feb 90 09:53:58 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 20 Feb 90 14:44:56 GMT
From: dietrich@bingvaxu.cc.binghamton.edu  (Eric Dietrich)
Organization: SUNY Binghamton, NY
Subject: AI: Dead or Alive
Message-Id: <3041@bingvaxu.cc.binghamton.edu>
To: ca@Think.COM



                  *** Call for papers and discussion ***

------------------------------------------------------------------------
  ARTIFICIAL INTELLIGENCE:  AN EMERGING SCIENCE OR A DYING ART FORM?
------------------------------------------------------------------------
                          June 21-23, 1990

                      A workshop funded by the
     Research Foundation of the State University of New York and the
           American Association for Artificial Intelligence

    What kind of pursuit is artificial intelligence?  Is AI the study of 
intelligence without regard to its realization, or a branch of
psychology which adds computer modeling to the psychologist's
experimental repertoire, or something else entirely?

    There are pragmatic reasons for answering this question.  AI
researchers could better utilize time and funds if their research were
based on a deeper understanding of the nature of their endeavor.  If, for
example, AI is an engineering discipline, then research strategies
based on the view that AI is a science might waste considerable time
and money.

    Beyond pragmatic concerns are the nagging doubts that AI, at least
as it is standardly conceived, is merely a way to keep our hands busy
while the neuroscientists and neural net modelers come up to speed.
This is the view that AI is not only NOT a science, but isn't even a
very good engineering discipline, and will one day be abandoned.  Since 
this is a view that is gaining adherents, it is important to either
refute it or establish its plausibility, and move on.

    The workshop will address these questions.  Four major papers
will be given; the abstracts are below.  Those interested are
invited to submit four copies of an abstract (2 to 7 pages) by May 1,
1990.  To help keep the workshop focused, authors are encouraged to
use one of the four abstracts as a springboard for discussion,
or to address a question of similar scope and content.  Examples of
such questions are:

  1.  Is AI a branch of theoretical biology?  Should AI abandon its
      traditional home in computer science, and seek instead to unify
      models of intelligence that apply to all species and even to 
      species considered as a unit?

  2.  Is it possible to formulate testable hypotheses about intelligence
      which are not solely predictions about human cognitive behavior,
      and then test these hypotheses experimentally?  If not, then how
      important is scientific AI to the study of the human brain and
      the study of human psychology?

If authors prefer structure their paper as a commentary, they can
request an extended abstract 

    The workshop will be kept small -- about 40 participants.  The
contribution of each author will be considered for inclusion as a
chapter in a subsequent edited book, or for a paper in the Journal of 
Experimental and Theoretical Artificial Intelligence.

  Location:        SUNY -- Binghamton, Binghamton, New York; June 21-23, 1990
  Workshop Chair:  Eric Dietrich
                   Department of Philosophy
                   SUNY -- Binghamton
                   Binghamton, New York  13901    (607) 777-2305
          e-mail:  dietrich@bingvaxu.cc.binghamton.edu


  Accomodations:  Can be arranged by calling

           Holiday Inn SUNY                  Patti Koval
           Vestal Parkway East     OR        Conference Coordinator
           Binghamton, NY  13901             Residential Life
           (607) 729-6371                    SUNY -- Binghamton
                                             (607) 777-6200

   For further information, contact the workshop chair.


-----------------------------------------------------------------------
Accompanying four abstracts:


#1
               ARTIFICIAL INTELLIGENCE AND COMPUTATION THEORY

                             Clark Glymour
                       Carnegie Mellon University

Abstract

  Disciplines exist partly to guarantee their members that certain things
don't have to be thought about.  Artificial intelligence has become
sufficiently disciplined that many of its practitioners behave as though
they can ignore large branches of theory.  

  Sometimes they can.  One going enterprise in machine learning is much
like literary interpretation: Some problem area in science or elsewhere
is identified, and one shows that from a reconstruction of the evidence
and the problems of the domain some fairly simple machine algorithm can
solve discovery problems.  Nothing is proved or claimed (usually) about
the optimality or limitations of the algorithm.  The proceedings of the
Machine Learning conferences are filled with papers of this kind.  The
work of Simon's associates provides many examples, and so does much of
the work on learning to plan.  One can think of these efforts as sort of
"toy" expert systems work.  I have nothing against it; some of this work
is clever, some dull.  Some of it is incredibly trivial.

  On the other hand, there is a great deal of work in artificial
intelligence that is not just interpretive and that intends to reveal
better ways to do things of importance.  In this paper, I argue that
work in non-monotonic inference, explanation-based learning,
simulation studies of the superiority of one or another inference
procedure, as well as an abundance of work in "cogntiive science" that
aims to describe human "computational architecture" all suffer from
failures to take account of the frameworks and results of aspects of
computation theory, especially of learning theory.


#2
                           Down with Solipsism! 
                    The Challenge to AI from connectionism

                               J. Hendler
                          Dept. of Computer Science
                             Univ. of Maryland
                          College Park, Md. 20742
                             hendler@cs.umd.edu

   Now, as never before in its short existence as a field, AI is facing a
challenge from the ``cognitivists'' in our ranks.  For too long, too
much of the emphasis in AI research has focused on producing systems
which manipulate arbitrary symbol systems to produce other arbitrary
symbols. The growing interest in connectionist models and neural
networks, however, has been focusing on the perceptual level of
cognition.  The analogy sometimes used is that AI has been looking at
the parts of the cognitive iceberg that are above water.  The bulk of
the iceberg of cognition, however, still underwater, is perception,
emotion, etc.  Can any field of ``intelligence'' become a science
while ignoring the bulk of the issue?

   In this paper I will try to demonstrate some of the rudiments of
cognition which I believe are growing out of the connectionist
paradigm.  Those of us in traditional AI must pay attention to these
results, as well as to cognitive phenomena, which derive from the fact
that intelligent entities are situated in an environment, as opposed
to solipsistic islands unto themselves.  This paper is not, however, a
philosphical treatise on symbol grounding.  Rather, we report on both
experimental and theoretical research being conducted which is aimed
at exploring the differences in representation learned by
connectionist systems, at understanding how well-documented cognitive
phenomena (such as priming) can be replicated in these models, and at
some types of reasoning (particularly in the area of perceptual
similiarity) which must be accounted for in a model of intelligence.  



#3
			  What is Cognitive Science?

				Bill Rapaport
			   Dept of Computer Science
				SUNY Buffalo
			     Buffalo, NY  14260
			   rapaport@cs.buffalo.edu

My paper (as I currently conceive it), which will be based on an
encyclopedia article on cognitive science that I am writing, will survey
the nature of cognitive science as a single discipline with a particular
"outlook".  Although the encyclopedia article tends to the objective and
netural, my paper for the workshop will take a firm stand on several
issues.  I will (1) suggest a distinction between "multidisciplinary" and
"interdisciplinary" research (with examples from one of my own cognitive
science research projects), (2) argue that cognitive science can (or, at
least, should) be considered as a single cohesive discipline that applies
diverse methodologies to a common problem (viz., what is mind/mentality)--
as opposed to most/many other disciplines, which apply a single
methodology to diverse problems, and (3) consider to what extent the
computational view of cognitive science, whether in its weak form (the
computational "metaphor") or its strong form (cognition _is_
computation), leads to a position like that Searle calls "strong AI".
Topics that will briefly be dealt with will include:  the Chinese Room
Argument, the intentional stance, and how syntax can yield semantics.

Reference:

Rapaport, William J. (1988), ``Syntactic Semantics:  Foundations
of Computational Natural-Language Understanding,'' in J. H. Fetzer (ed.)
Aspects of Artificial Intelligence (Dordrecht, Holland:  Kluwer Academic
Publishers):  81-131.


#4
              CRYSTALLIZING THEORIES OUT OF KNOWLEDGE SOUP

                              John F. Sowa
                          IBM Systems Research
                          Thornwood, NY  10594

   In very large knowledge bases, global consistency is practically
impossible to achieve, yet local consistency is essential for deduction
and problem solving.  To preserve local consistency in an environment of
global inconsistency, this paper proposes a two-level structure:  an
enormous reservoir of loosely organized encyclopedic knowledge, called
"knowledge soup"; and floating in the soup, much smaller, tightly
organized theories that resemble the typical microworlds of AI.  The two
kinds of knowledge require two distinct kinds of reasoning:  "abduction"
uses associative search, measures of relevance, and belief revision for
finding appropriate chunks of knowledge in the soup and assembling them
into consistent theories; and "deduction" uses classical theorem-proving
techniques for reasoning within a theory.  The resulting two-level
system can attain the goals of nonmonotonic logic, while retaining the
simplicity of classical logic; it can use statistics for dealing with
uncertainty, while preserving the precision of logic in dealing with
hard-edged facts; and it can relate logics with discrete symbols to
models of continuous systems.

From ca-Request@Think.COM  Wed Feb 21 15:00:26 1990
Received: by fafnir.think.com; Wed, 21 Feb 90 15:00:26 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Wed, 21 Feb 90 15:00:04 EST
Received: from NSFNET-RELAY.AC.UK by Think.COM; Wed, 21 Feb 90 15:00:46 -0500
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK 
           via Janet with NIFTP  id aa28031; 21 Feb 90 18:35 GMT
Via: ctcs.leeds.ac.uk (thrills.ARPA); Wed, 21 Feb 90 16:44:12 GMT
From: Turing Conference <turing%ctcs.leeds.ac.uk@NSFnet-Relay.AC.UK>
Date: Wed, 21 Feb 90 16:42:22 GMT
Message-Id: <4183.9002211642@ctcs.leeds.ac.uk>
To: CA@Think.COM
Subject: Turing 1990 Programme

____________________________________________________________________________

                           TURING 1990 COLLOQUIUM

               At the University of Sussex, Brighton, England

                            3rd - 6th April 1990

              PROGRAMME OF SPEAKERS AND REGISTRATION DOCUMENTS

____________________________________________________________________________


                              INVITED SPEAKERS


Paul CHURCHLAND (Philosophy, University of California at San Diego)

       Title to be announced


Joseph FORD (Physics, Georgia Institute of Technology)

       CHAOS :  ITS PAST, ITS PRESENT, BUT MOSTLY ITS FUTURE


Robin GANDY (Mathematical Institute, Oxford)

       HUMAN VERSUS MECHANICAL INTELLIGENCE


Clark GLYMOUR (Philosophy, Carnegie-Mellon)

       COMPUTABILITY, CONCEPTUAL REVOLUTIONS AND THE LOGIC OF DISCOVERY


Andrew HODGES (Oxford, author of "Alan Turing: the enigma of intelligence")

       BACK TO THE FUTURE :  ALAN TURING IN 1950


Douglas HOFSTADTER (Computer Science, Indiana)

       Title to be announced


J.R. LUCAS (Merton College, Oxford)

       MINDS, MACHINES AND GODEL :  A RETROSPECT


Donald MICHIE (Turing Institute, Glasgow)

       MACHINE INTELLIGENCE - TURING AND AFTER


Christopher PEACOCKE (Magdalen College, Oxford)

       PHILOSOPHICAL AND PSYCHOLOGICAL THEORIES OF CONCEPTS


Herbert SIMON (Computer Science and Psychology, Carnegie-Mellon)

       MACHINE AS MIND

____________________________________________________________________________


                               OTHER SPEAKERS


Most of the papers to be given at the Colloquium are interdisciplinary,  and
should hold considerable interest for those working in any area of Cognitive
Science or related disciplines.   However the papers below will be presented
in paired parallel sessions,  which have been arranged as far as possible to
minimise clashes of subject area,  so  that  those  who  have  predominantly
formal  interests,   for  example,  will be able to attend all of the papers
which are most relevant to their work, and a similar point applies for those
with mainly philosophical, psychological, or purely computational interests.


Jonathan Cohen (The Queen's College, Oxford)
     "Does Belief Exist?"

Mario Compiani (ENIDATA, Bologna, Italy)
     "Remarks on the Paradigms of Connectionism"

Martin Davies (Philosophy, Birkbeck College, London)
     "Facing up to Eliminativism"

Chris Fields (Computing Research Laboratory, New Mexico)
     "Measurement and Computational Description"

Robert French (Center for Research on Concepts and Cognition, Indiana)
     "Subcognition and the Limits of the Turing Test"

Beatrice de Gelder (Psychology and Philosophy, Tilburg, Netherlands)
     "Cognitive Science is Philosophy of Science Writ Small"

Peter Mott (Computer Studies and Philosophy, Leeds)
     "A Grammar Based Approach to Commonsense Reasoning"

Aaron Sloman (Cognitive and Computing Sciences, Sussex)
     "Beyond Turing Equivalence"

Antony Galton (Computer Science, Exeter)
     "The Church-Turing Thesis: its Nature and Status"

Ajit Narayanan (Computer Science, Exeter)
     "The Intentional Stance and the Imitation Game"

Jon Oberlander and Peter Dayan (Centre for Cognitive Science, Edinburgh)
     "Altered States and Virtual Beliefs"

Philip Pettit and Frank Jackson (Social Sciences Research, ANU, Canberra)
     "Causation in the Philosophy of Mind"

Ian Pratt (Computer Science, Manchester)
     "Encoding Psychological Knowledge"

Joop Schopman and Aziz Shawky (Philosophy, Utrecht, Netherlands)
     "Remarks on the Impact of Connectionism on our Thinking about Concepts"

Murray Shanahan (Computing, Imperial College London)
     "Folk Psychology and Naive Physics"

Iain Stewart (Computing Laboratory, Newcastle)
     "The Demise of the Turing Machine in Complexity Theory"

Chris Thornton (Artificial Intelligence, Edinburgh)
     "Why Concept Learning is a Good Idea"

Blay Whitby (Cognitive and Computing Sciences, Sussex)
     "The Turing Test: AI's Biggest Blind Alley?"

____________________________________________________________________________


                           TURING 1990 COLLOQUIUM

               At the University of Sussex, Brighton, England

                            3rd - 6th April 1990


This Conference commemorates the 40th anniversary of the publication in Mind
of Alan Turing's influential paper  "Computing  Machinery and Intelligence". 
It  is hosted by the School of  Cognitive  and  Computing  Sciences  at  the
University of  Sussex  and  held under the auspices of the Mind Association.
Additional  support  has been received  from  the  Analysis  Committee,  the
Aristotelian Society, The  British Logic Colloquium, The International Union
of History and Philosophy  of  Science, POPLOG, Philosophical Quarterly, and
the SERC Logic for IT Initiative.

The aim of the Conference  is to draw together people working in Philosophy,
Logic,  Computer  Science,  Artificial Intelligence, Cognitive  Science  and
related fields, in order  to  celebrate  the  intellectual and technological
developments which owe so much to Turing's seminal  thought.  Papers will be
presented  on  the  following  themes:  Alan  Turing  and the  emergence  of
Artificial Intelligence,  Logic and the Theory of Computation,  The  Church-
Turing  Thesis, The Turing Test, Connectionism, Mind and Content, Philosophy
and Methodology of Artificial Intelligence and Cognitive Science.    Invited
talks  will be  given by  Paul Churchland, Joseph Ford,  Robin Gandy,  Clark
Glymour,  Andrew Hodges,   Douglas Hofstadter,  J.R. Lucas,   Donald Michie,
Christopher Peacocke and Herbert Simon, and there  are  many other prominent
contributors, whose names and papers are listed above.

Anyone wishing to attend this  Conference should complete the form below and
send it to Andy Clark, TURING  1990  Registrations,  School of Cognitive and
Computing  Sciences, University of Sussex, Brighton, BN1 9QH, England, U.K.,
enclosing a  STERLING  cheque  or  money order for the total amount payable,
made out to "Turing 1990".  We regret that we cannot accept payment in other
currencies.  The form should be returned  not  later than Thursday 1st March
1990, after which an extra fee of #5.00 for late registration is payable and
accommodation cannot be guaranteed.

The conference will start after lunch on Tuesday 3rd April 1990, and it will
end on Friday 6th April after tea.  Final details will be sent to registered
participants towards the end of February.


                     Conference Organizing Committee

     Andy Clark (Cognitive and Computing Sciences, Sussex University)
     David Holdcroft (Philosophy, Leeds University)
     Peter Millican (Computer Studies and Philosophy, Leeds University)
     Steve Torrance (Information Systems, Middlesex Polytechnic)

___________________________________________________________________________


                   REGISTRATION DOCUMENT :  TURING 1990


NAME AND TITLE :  __________________________________________________________

INSTITUTION :  _____________________________________________________________

STATUS :    ________________________________________________________________

ADDRESS :   ________________________________________________________________

            ________________________________________________________________

POSTCODE :  _________________       COUNTRY :   ____________________________

Any special requirements (eg. diet, disability) :  _________________________


I wish to register for  the  Turing  1990  Colloquium and enclose a Sterling
cheque  or money order,  payable to  "Turing 1990", for  the   total  amount
listed below :

Please ENTER AMOUNTS as appropriate.


1.  Registration Fee:  Mind Association Members       #30.00  ..............
      (Compulsory)
                       Full-time students             #30.00  ..............
                      (enclose proof of status
                      - e.g. letter from tutor)

                       Academics (including
                        retired academics)            #50.00  ..............

                       Non-Academics                  #80.00  ..............

                       Late Registration Fee           #5.00  ..............
                      (payable after 1st March)



2.  Full Board including all meals from Dinner        #84.00  ..............
    on Tuesday 3rd April to Lunch on Friday
    6th April, except for Thursday evening
                       OR
    All meals from Dinner on Tuesday 3rd April        #33.00  ..............
    to Lunch on Friday 6th April, except for
    Thursday evening



3.  Conference banquet in the Royal Pavilion,         #25.00  ..............
    Brighton on Thursday 5th April
                       OR
    Dinner in the University on Thursday 5th April     #6.00  ..............



4.  Lunch on Tuesday 3rd April                         #6.00  ..............



5.  Dinner on Friday 6th April                         #6.00  ..............


                                                              ______________

                                                        TOTAL   #
                                                              ______________



Signed ________________________________          Date ______________________


Please return this form, with your cheque or money order (payable to "Turing
1990"), to:

                     Dr Andy Clark,
                     Turing 1990 Registrations,
                     Cognitive and Computing Sciences,
                     University of Sussex,
                     Falmer,  Brighton,  BN1 9QH,
                     England.


Email responses to:     turing@uk.ac.sussex.syma
     ( from BITNET:     turing@syma.sussex.ac.uk -NM )

____________________________________________________________________________


IMPORTANT NOTICE FOR STUDENTS AND SUPERVISORS:

The Analysis Committee has kindly  made a donation to subsidise students who
would  benefit from attending the Colloquium  but  who  might  otherwise  be
unable to do so.   The amount of any such subsidy will depend on the overall
demand and  the quality of the candidates,  but it would certainly cover the
registration fee and  probably  a  proportion of the accommodation expenses. 
Interested  parties should write  immediately to  Andy Clark  at the address
above, enclosing a brief supporting comment from a tutor or supervisor.

____________________________________________________________________________


PLEASE SEND ON THIS NOTICE to any researchers,  lecturers or students in the 
fields  of  Artificial Intelligence,  Cognitive  Science,  Computer Science,
Logic, Mathematics, Philosophy or Psychology, in Britain  or  abroad, and to
ANY APPROPRIATE BULLETIN BOARDS which have not previously displayed it.

From ca-Request@Think.COM  Sun Feb 25 02:29:02 1990
Received: by fafnir.think.com; Sun, 25 Feb 90 02:29:02 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Sun, 25 Feb 90 02:28:58 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Sun, 25 Feb 90 02:29:54 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA09586; Sun, 25 Feb 90 01:52:19 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 25 Feb 90 05:01:18 GMT
From: maytag!watcsc!death@iuvax.cs.indiana.edu  (Trevor Green)
Organization: University of Waterloo Computer Science Club
Subject: Wireworld patterns
Message-Id: <1990Feb25.050118.7912@watcsc.waterloo.edu>
To: ca@Think.COM

George Phillips, thank you for posting the source for your wireworld
programme.  When I can drag myself away from creating new patterns I
might try to make it more efficient.  I've been doing wireworld all day
and my mind is a haze of =#-===s, but here are my revisions on George's
patterns:
(Note: I have slightly edited George's patterns for legibility's sake.)

>	'=' wire
>	'.' space
>	'#' electron head
>	'-' electron tail

>   (write 0)
> ..I....
> .===...
> .=.=...
> ..=.=..
>O=.=.=..
> .=.===.
> ....I..
>     (write 1)

>A six-cycle memory cell.

I tried making a 4-cycle memory cell but failed.  Anybody else care to
give it a shot?
Anyone got a 3-cycle memory cell? (-:

> ...
> .=.
> I=I
> .O.
>A much improved "OR" gate.

Thank you.  It makes wireworld that much easier to use.

> .......
>I-#==...
> ....=..
> ...===.
> ....=..
> ..==.==O
> .=.=...
> .=.-...
> ..#....
> .......
> A NOT gate.

The fastest NOT gate of this design is a 5-cycle NOT gate; the gate takes 5
cycles to clear following an input of 0.  The 6-cycle
NOT gate is, however, smaller.  I include both of them here.
Should you require a longer-cycle NOT gate, just replace the pulsar in either
of the gates below with the pulsar of the desired cycle.

(Note: with every diagram I post I include the vital statistics.  Transit
is the number of cycles it takes for a signal to propagate through the device,
IBI (interval between inputs) is the number of cycles the device needs between
inputs so that the output is guaranteed correct, and the size is the X and Y
dimensions of the device.  I is an input line and O is an output line (note:
there may be more than one of either.))
 .........
 .=.O..=..
 I==..=.-.
 .=.==..#.
 ...#...=.
 ....-==..
 .........

 ........
 .=.O....
 I==.....
 .=.===..
 ...#..=.
 ....-=..
 ........
Transit: 3
IBI: (5-cycle) 5
     (6-cycle) 6
Size: (5-cycle) 9x7
      (6-cycle) 8x7

> .......
> .==....
>I==.==.O
> .==..=.
> ....==.
> .==.=..
> I=.=...
> .==....
> .......
> An XOR gate.

The main drawback of this particular XOR gate is that you have to stagger your
pulses.  I have come up with a symmetric XOR gate that also has a lower IBI:

 .......
 .==....
 I=.=...
 .==.==.
 .....=O
 .==.==.
 I=.=...
 .==....
 .......
Transit: 6
IBI: 11
Size: 7x7

>...........
>..=.....=..
>.=.=...=.=.
>.=.#...#.=.
>..-.=.=.-..
>....=.=....
>..=.=.=.=..
>.I==...==I.
>..=.=.=.=..
>....=.=....
>...=...=...
>...=.=.=...
>....===....
>.....O.....
> A NAND gate.
A better NAND gate (5- and 6-cycle versions):

 ...........
 ...-#==....
 ..=....=...
 ...==.-....
 .....#.....
 ....=.=....
 .=.=...=.=.
 I==..=..==I
 .=.=====.=.
 .....O.....

 ...........
 .....=.....
 ....=.=....
 ....=.-....
 .....#.....
 ....=.=....
 .=.=...=.=.
 I==..=..==I
 .=.=====.=.
 .....O.....
Transit: 6
IBI: (5-cycle) 5
     (6-cycle) 6
Size: 11x10

As with NOT, this NAND has a minimum clearing time of 5, but can have any
cycle greater than 4.


The next 2 diagrams were a clocked AND gate (ugh!) and a NAND-gate set up for
testing patterns, so I deleted them.

> ...................
> ..............=.O..
> ...........=======.
> ..........=...=.=..
> .........=......==.
> ...======.......=..
> ..=........===..=..
> .=........=...=.=..
>I=.........=..===...
> ..........=...=....
> .....I=...====.....
> .......===.........
> An AND gate.

This is quite elegant, if a little sloppy.  I cleaned it up and this seems
to be the optimum:

 ..I........
 ...=====...
 ........=..
 ..==...===.
 .=..=...=..
 .=.======O.
 .=..=.=.=..
 .===.......
 I..........
Transit: 9
IBI: 8
Size: 13x10

I tried another design for an AND gate, incorporating the XOR gate above, but
it's larger and slower:

 ..............
 ....==........
 ...==.=.......
 I==.==.==.....
 ........===...
 I.=.==.==..=..
 .=.==.=...===.
 .=..==.....=..
 .=.....====.O.
 ..=====.......
 ..............
Transit: 14
IBI: 11 (same as XOR)
Size: 14x11


>Some pulsars of rates from 3 to 9.
(Patterns deleted)

The minimum-size pulsars:
....           .....
.#..   3. 4x4  ..#..  4. 5x5
.-=.           .-.=.
....           ..=..
               .....
......
..-#.. 5. 6x7
.=..=. 10. 6x7 (just remove an electron)
.=..=.
.=..=.
..#-..
......
>                                                        Notice that the
>rate 5 pulsar is really a rate 10 pulsar with 2 electrons.  I don't think it
>is possible to build a loop which takes 5 generations to traverse.
I think you're right.

.....          ......         ......         ......
..#..  6. 5x6  ..-#.. 7. 6x6  ..-#.. 8. 6x6  ..-#.. 9. 6x7
.-.=.          .=..=.         .=..=.         .=..=.
.=.=.          .=.=..         .=..=.         .=..=.
..=..          ..=...         ..==..         .=.=..
.....          ......         ......         ..=...
                                             ......


>Some attempts at wire crossing.

As the diagrammes were rather large, I edited them out.  However, I shall
make a comment about all of them: they allowed individual signals to cross
fine, but when 2 signals were sent simultaneously they'd cancel each other
out.  To the end of rectifying this, I came up with this rather ugly hack:

 ..............
 .....==.=.....
 .=====.==O....
 I....==.=.....
 ........=.....
 I....==.=.=...
 .=..==.===.=..
 .=.=.==.=..=..
 .=.=......=...
 .=..==...=..O.
 .=....=.=...=.
 ..====...===..
 ..............
Transit: 22 (ugh!)
IBI: 22     (double ugh!)
Size: 14x13

Note the pair of delay loops at the bottom to prevent the signals from
interfering with one another.  It is rather inelegant, but it's the best
I've come up with in two nights of wirehacking.  Anybody got a *real* wire-
crosser out there?

For people attempting a wire-crosser, here's another design I came up with,
with the idea of preventing the signals from colliding while they're in the
device rather than delaying one beforehand and the other afterward.  If
someone can come up with a better bypass, you'll get a better wire-crosser
out of this:

 ............
 ..==..=.....
 .I=.===O....
 ..==..=.....
 .....=====..
 ....=.=...=.
 ...=.....=..
 ..=.=...=...
 ..===...=...
 ...=...===..
 ..=....=.=..
 .=......=...
 ..===.=.=...
 .....===....
 ..==..=.....
 .I=.===O....
 ..==..=.....
 ............
Transit: 19
IBI: 24
Size: 12x18 (aack!)

Have fun!

>George Phillips phillips@cs.ubc.ca {alberta,uw-beaver,uunet}!ubc-cs!phillips

Trevor Green death@csc.waterloo.edu watmath!maytag!watcsc!death

From ca-Request@Think.COM  Sun Feb 25 22:27:44 1990
Received: by fafnir.think.com; Sun, 25 Feb 90 22:27:44 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Sun, 25 Feb 90 22:27:41 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Sun, 25 Feb 90 22:28:44 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA24726; Sun, 25 Feb 90 20:37:47 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 24 Feb 90 23:18:12 GMT
From: mcsun!ukc!tcdcs!swift.cs.tcd.ie!maths.tcd.ie!dbell@uunet.uu.net  (Derek Bell)
Organization: Dept. of Maths, Trinity College, Dublin, Ireland.
Subject: Wireworld-PC wanted
Message-Id: <1990Feb24.231812.12435@maths.tcd.ie>
To: ca@Think.COM


		Would somebody be so kind as to mail me the shar file for
wireworld-pc? 
		Thanks,
			Derek
-- 
Derek Bell
		Either I'm dead or my watch has stopped.
			-- Groucho Marx' last words
dbell@maths.tcd.ie belld@vax1.tcd.ie dbell%maths.tcd.ie@cunyvm.cuny.edu

From ca-Request@Think.COM  Mon Feb 26 03:28:24 1990
Received: by fafnir.think.com; Mon, 26 Feb 90 03:28:24 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Mon, 26 Feb 90 03:28:21 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Mon, 26 Feb 90 03:29:23 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA09499; Mon, 26 Feb 90 01:42:36 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 26 Feb 90 04:51:39 GMT
From: maytag!watcsc!death@iuvax.cs.indiana.edu  (Trevor Green)
Organization: University of Waterloo Computer Science Club
Subject: Wireworld: a better wire-cross
Message-Id: <1990Feb26.045139.11904@watcsc.waterloo.edu>
To: ca@Think.COM

Kudos goes to Rich Schroeppel (rcs@la.tis.com) for suggesting a "conceptually
simpler" wire-cross design which I managed to convert into a practically
simpler wire-cross.  I actually came up with two designs - the first is
smaller and has a shorter transit time, but the second has a *much* lower IBI.
Here they are:

...........
.....==....
.==.=..=...
I=.===..==.
.==.=....=O
.....==.==.
......==...
.....==.==.
.==.=....=O
I=.===..==.
.==.=..=...
.....==....
...........
Transit: 10
IBI: 19
Size: 11x13

..............
.....==.==....
.==.=..==.=...
I=.===..==.==.
.==.=.......=O
.....==.==.==.
......===.=...
.....==.==.==.
.==.=.......=O
I=.===..==.==.
.==.=..==.=...
.....==.==....
..............
Transit: 13
IBI: 13
Size: 14x13

The three diodes that are the difference between the top and bottom diagram
catch electrons that "bounce" back out of the final XORs sooner, clearing
the device for input six cycles sooner.

Trevor Green death@csc.waterloo.edu watmath!maytag!watcsc!death

From ca-Request@Think.COM  Mon Feb 26 10:28:32 1990
Received: by fafnir.think.com; Mon, 26 Feb 90 10:28:32 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Mon, 26 Feb 90 10:28:27 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Mon, 26 Feb 90 10:29:26 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA00204; Mon, 26 Feb 90 09:42:37 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 25 Feb 90 22:43:56 GMT
From: zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!uoft02!grx1042@Think.COM  (Steve Snodgrass)
Subject: Wanted: Life pattern for a glider gun
Message-Id: <4.25e8195c@uoft02.utoledo.edu>
To: ca@Think.COM

Could someone Email me a pattern for a Life glider-gun?  I heard such a beast
exists, which continuously spits out gliders, but I've never seen one.
Thanks!

 +-----------------------------------------------------------------------+
 | Reality: Steve Snodgrass <*> Cyberspace: GRX1042 @ UofT02.UToledo.Edu |
 | "Sleep is a luxury, spare time a myth."  GRX1042 @ UofT02.BITNET      |
 | "Volts embodied intent, and Amps were the runners who carried out     |
 |  those intentions, against the Ohms." -Greg Benford, Tides of Light   |
 `-----------------------------------------------------------------------'

From ca-Request@Think.COM  Mon Feb 26 11:12:15 1990
Received: by fafnir.think.com; Mon, 26 Feb 90 11:12:15 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Mon, 26 Feb 90 11:12:12 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Mon, 26 Feb 90 11:13:11 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA01916; Mon, 26 Feb 90 10:08:16 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 26 Feb 90 14:44:57 GMT
From: rochester!fulk@rutgers.edu  (Mark Fulk)
Organization: U of Rochester, CS Dept, Rochester, NY
Subject: Call for papers: Computational Learning Theory
Message-Id: <1990Feb26.144457.18795@cs.rochester.edu>
To: ca@Think.COM


			CALL FOR PAPERS
			   COLT '90
	   Third Workshop on Computational Learning Theory
			 Rochester, NY
		   August 6 - August 8, 1990

The third workshop on Computational Learning Theory will be held in
Rochester, NY.  The conference will be jointly sponsored by SIGACT and
SIGART, and is expected to be similar in style to the previous such
workshops held at MIT and UC/Santa Cruz.  Registration at COLT '90 is open.

It is expected that most papers will present rigorous formal analyses
of theoretical issues in Machine Learning.  Possible topics include,
but are not limited to: resource and robustness analysis of learning
algorithms, general learnability and non-learnability results in new and
existing computational learning models, theoretical comparisons among
learning models, and papers that connect learning theory with work in
robotics, neural nets, pattern recognition and cryptography. R. Freivalds
(Latvian State University, Riga) has agreed to present an invited talk;
the program committee may consider more such.

Authors should submit an extended abstract that consists of:

	A) cover page with title, authors' names,
	  (postal and e-mail) addresses, and a 200 word summary.  

	B) body not longer than 10 pages in twelve-point font.  

Be sure to include a clear definition of the model used, an overview
of the results, and some discussion of their significance, including
comparison to other work. Proofs or proof sketches should be included
in the technical section.  Authors should send 10 copies of their
abstract to

	John Case
	COLT '90
	Department of Computer and Information Sciences
	103 Smith Hall
	University of Delaware
	Newark, DE  19716.

The deadline for receiving submissions is April 9, 1990.  This deadline
is FIRM.  Authors will be notified by May 22, final camera-ready papers
will be due June 18, and this deadline is ABSOLUTE.  The proceedings will
be published by Morgan-Kaufmann.  For further information about submissions
contact John Case (telephone: 302-451-2711, email: case@cis.udel.edu).

Chair and local arrangements: Mark A. Fulk (U. Rochester).

Program committee:

	    J. Case (Delaware, chair),
	    D. Angluin (Yale),
	    E. Baum (NEC Research, Princeton)
	    S. Ben David (Technion, Israel),
	    M. Fulk (U. Rochester),
	    D. Haussler (UC Santa Cruz),
 	    L. Pitt (U. Illinois),
	    R. Rivest (MIT),
	    C. Smith (Maryland),
	    S. Weinstein (U. Pennsylvania).

Note: papers that have appeared in journals or that are being submitted
to other conferences are not appropriate for submission to COLT with the
exception of papers submitted to the IEEE 31st Symposium on Foundations of 
Computer Science (FOCS).

A joint submission policy coordinated with FOCS permits authors to send
a paper to both conferences; in the event that both conferences accept the
paper, it will be published in the FOCS proceedings, the authors will be
invited to give a talk at both conferences, and a short (one-page) abstract
will be printed in the COLT proceedings.

As the FOCS decisions may be quite late, authors of dual submissions
will be asked to send the abstract with their final copy, so as to
allow the publisher to substitute the abstract upon receiving word of
the FOCS decision.

It is, of course, required that authors notify both committees of the
dual submission by including a note in the cover letters.

From ca-Request@Think.COM  Wed Feb 28 04:28:57 1990
Received: by fafnir.think.com; Wed, 28 Feb 90 04:28:57 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Wed, 28 Feb 90 04:28:53 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Wed, 28 Feb 90 04:29:55 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA08965; Wed, 28 Feb 90 04:13:58 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 28 Feb 90 09:06:33 GMT
From: zaphod.mps.ohio-state.edu!van-bc!ubc-cs!phillips@Think.COM  (George Phillips)
Organization: UBC Department of Computer Science, Vancouver, B.C., Canada
Subject: Wireworld: better cross, xor and and
Message-Id: <6937@ubc-cs.UUCP>
To: ca@Think.COM


About a week ago, Ian Woollard <irw@stl.stc.co.uk> sent me a
wonderful XOR gate he created:

........=
........=
.......===
.......=.=
===-#===.===#-==
.......===

And then used (A^B)^A == B to do a very good wire crossing.
BTW:  my wire crossings _do_ work, but who cares with this around:

...=.....=
...=.....=
..===...===
..=.=...=.=
.==.==.==.==
=.===.=.===.=
=.....=.....=
=....===....=
.=...=.=...=
..=.==.==.=
...=.===.=
...#.....#
...-.....-

While trying to understand the XOR gate, I realized that one of the
tricks was to make each incoming pulse cancel themselves.  I used this
idea to make a faster AND gate:

............==
...........=..=#-====-===#-
......==..===
.....=..=..=..=.=#-===#-====-
....===..==.==.=
....==.........=
====..=========

I don't know if it's me or wireworld, but none of the AND gates are
symmetric.  Hmmmm.  Maybe someone will surprise me -- getting new
patterns from the net is almost as much fun as building them yourself.

George Phillips phillips@cs.ubc.ca {alberta,uw-beaver,uunet}!ubc-cs!phillips

From ca-Request@Think.COM  Wed Feb 28 06:55:05 1990
Received: by fafnir.think.com; Wed, 28 Feb 90 06:55:05 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Wed, 28 Feb 90 06:54:53 EST
Received: from p.lanl.gov by Think.COM; Wed, 28 Feb 90 06:55:56 -0500
Received: by p.lanl.gov (5.54/1.14)
	id AA15371; Wed, 28 Feb 90 04:55:47 MST
Received: by cardinal.lanl.gov (3.2/5.17)
	id AA05858; Wed, 28 Feb 90 04:30:09 MST
Date: Wed, 28 Feb 90 04:30:09 MST
From: cgl%cardinal@LANL.GOV (Chris Langton)
Message-Id: <9002281130.AA05858@cardinal.lanl.gov>
To: ca@Think.COM
Subject: Cellsim 2.5 available!


	       ****************************************
			      ANNOUNCING
	       The Availability of Cellsim version 2.5
	       ****************************************
				  by
			    Chris Langton
			    (cgl@lanl.gov)
				 and
			    Dave Hiebeler
		     (hiebeler@heretic.lanl.gov)

  Version 2.5 of Cellsim is a SunView-based cellular automata simulator
allowing interactive specification, editing, running, and analysis of
1- and 2-D CA's.  It will run on Sun-3's, -4's, and Sparc stations,
color or B&W.

  You can also use Cellsim to attach to a Connection Machine, and use either
the CM Frame Buffer or the Sun to display your images; you can do this either
directly from a CM front-end, or remotely through the network.  Cellsim on the
CM allows you to use arbitrarily complex update-functions and "cells".

  With these recent enhancements, Cellsim is now becoming a tool flexible
enough to use for the exploration of lattice-based systems in general.
Besides running traditional CAs, you can also do things such as run computed
functions of up to 256 states per cell, use floating-point values, or run
large ensembles of 1-D systems.  Running on the Connection Machine also
give you the ability to do complex data-analysis on the fly, in parallel.

Since version 2.0 was never "officially" released, the changes since
version 1.5 are listed below:

1) 256-state "computed-function" rules can now be used, in addition to
   lookup-tables, on both the Sun and CM.  This greatly expands the range
   of rules you can investigate.

2) You can now invoke Cellsim once, and change the neighborhood or number
   of states or image size, without having to call up a new Cellsim.
   Cellsim will also automatically switch into the proper neighborhood
   when you load a rule, or the proper image size when you load an image,
   unless you disable that feature.

3) The "general" random image-generation routine is much more general now.

4) You can create lookup-tables using "Lambda" or "Rho" parameters.
   The Lambda parameter is described in the article "Studying Artificial
   Life with Cellular Automata" by Chris Langton, in Physica 22D (1986),
   and more recently in "Computation at the Edge of Chaos: Phase Transitions
   and Emergent Computation" by C. Langton, in the proceedings of the
   "Emergent Computation" conference, to be published in a special issue of
   Physica D, 1990.

5) The middle mouse-button can be used to reselect the last item selected
   from any of the menus in the control-panel.

6) You can save images in Sun raster format.

7) The process of writing C code to generate lookup tables has been
   made easier.

8) Tilde-expansion is now performed on filenames.  For example, you can
   now specify names such as "~/Images/xyz.64x" when loading or saving
   images, transition tables, colormaps, etc.

9) You can attach to a Connection Machine, and run the actual computations
   on the CM, using either the CM frame-buffer or the Sun to display the
   images.

10) A new "defaults" menu which lets you change some of the behaviors of
    Cellsim.

11) There are 5 user-definable "sequences" which you can "teach" series of
    button-presses or menu-item selections.  So if there is some sequence
    of commands you routinely use, you can define a sequence to hold those
    commands, and call them up with the single press of a mouse-button.

12) You can now draw lines and circles in the array, from the "Draw" menu.
    (The "Draw" menu now contains the "random" image-generation routines).

13) The maximum possible image-size is now 512x512, instead of 256x256

	       ****************************************

You can obtain Cellsim via anonymous FTP to cardinal.lanl.gov (128.165.96.120).
Use the login "anonymous", and your e-mail address as password.  Then,
do the following commands:
  cd pub
  bin
  get cellsim_2.5.tar.Z

That will transfer the tar file in binary mode.  Once you've obtained the
tar file, you should uncompress it and extract its contents as follows:
  uncompress cellsim_2.5.tar.Z
  tar xvf cellsim_2.5.tar

Once you've done that, go to the "V2.5" directory, and follow instructions
in the "README" and "Installation" files there.


  If you are unable to use FTP, then send either a 1/4" or 1/2" tape to:

    Chris Langton
    Theoretical Division
    T-13, MS B213
    Los Alamos National Laboratory
    Los Alamos, NM 87545  USA

If you send 1/2" tape, please specify the density to use.

For those of you in Europe or Japan, we are sending copies of Cellsim to
people who have agreed to serve as distribution sites there (tapes are on
the way, guys!)  We'll follow-up with information on how to get it from them,
once they have received the tapes and verified that they have working copies.

If you obtain Cellsim via FTP, please send Chris Langton (cgl@lanl.gov) a
message, so that you can be placed on a distribution mailing-list for
announcements of bug-fixes, new releases, announcement of new libraries,
and so on.  This is very important, so that you can be kept up-to-date
with Cellsim as it evolves.

Cheers!

Chris Langton
Dave Hiebeler

From ca-Request@Think.COM  Wed Feb 28 13:30:40 1990
Received: by fafnir.think.com; Wed, 28 Feb 90 13:30:40 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Wed, 28 Feb 90 13:30:35 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Wed, 28 Feb 90 13:31:33 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA04015; Wed, 28 Feb 90 13:17:52 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 28 Feb 90 17:15:12 GMT
From: maytag!watcsc!death@iuvax.cs.indiana.edu  (Trevor Green)
Organization: University of Waterloo Computer Science Club
Subject: Re: Wireworld: better cross, xor and and
Message-Id: <1990Feb28.171512.16633@watcsc.waterloo.edu>
References: <6937@ubc-cs.UUCP>
To: ca@Think.COM

In article <6937@ubc-cs.UUCP> phillips@cs.ubc.ca (George Phillips) writes:
>About a week ago, Ian Woollard <irw@stl.stc.co.uk> sent me a
>wonderful XOR gate he created:

..I...
.====.
.=..=O
.====.
..I...
Transit: 3
IBI: 5
Size: 6x5

I like it. This is "the" XOR gate.

>And then used (A^B)^A == B to do a very good wire crossing.
>BTW:  my wire crossings _do_ work, but who cares with this around:
The first half of that BTW is still open to debate.  The second half is
unconditionally true and makes the debate irrelevant.

...........
.....==....
....=..=...
...=..====.
.I=...=..=O
..=...====.
.====..=...
.=..===....
.====..=...
..=...====.
.I=...=..=O
...=..====.
....=..=...
.....==....
...........
Transit: 9
IBI: 5
Size: 11x15

I tried to "simplify" this (it still looks too open for me) and replaced
the final XORs with much simpler structures.  This also entailed adding
two diodes and I wound up upping the IBI to 11 with the size and transit
time remaining about the same.  This appears to be an excellent design.
I'll see if I can improve on it, but I think that this is *the* A^B^A
design.  It'll be a completely different design that beats it.

>While trying to understand the XOR gate, I realized that one of the
>tricks was to make each incoming pulse cancel themselves.  I used this
>idea to make a faster AND gate:
>
>............==
>...........=..=#-====-===#-
>......==..===
>.....=..=..=..=.=#-===#-====-
>....===..==.==.=
>....==.........=
>====..=========

Now, George, you're making me feel like a tinker to your artist.  This
one looked a little sloppy again, so I "fixed" it. (Believe it or not,
the design below is "topologically" identical to the one above, except
for one inconsequential change.)

.I.....
..=....
.===...
..=....
I=.=...
.=..=..
.=.===.
.=..=..
..==.O.
Transit: 7
IBI: 5 (again!)
Size: 7x9

>I don't know if it's me or wireworld, but none of the AND gates are
>symmetric.  Hmmmm.  Maybe someone will surprise me -- getting new
>patterns from the net is almost as much fun as building them yourself.

My original AND gate was symmetric - double each input, XOR the middle
two and then XOR again for the final output (more or less).

................
..=====.........
.=.....====.==..
.=..==.....=..=.
.=.==.=...===.=.
I.=.==.==..=..=.
........===..==O
I.=.==.==..=..=.
.=.==.=...===.=.
.=..==.....=..=.
.=.....====.==..
..=====.........
................

Then I realised  I could do without one of the doubled lines.

.............
...==........
..==.=.......
I=.==.==.....
.......===...
I..==.==..=..
.===.=...===.
.=.==.....=..
.=....====.O.
..====.......
.............

With the better XOR posted above, I have improved it once again, but it doesn't
hold a candle to George's:

.I........
..=.......
.====.....
.=..===...
.====..=..
..=...===.
.I.=...=..
...=..=.O.
....=.=...
.....=....
..........
Transit: 9
IBI: 5
Size: 10x11

The reason for the inefficiency compared to George's AND is that the XOR
can be replaced by the other doohickey (the "implication" one (a&~b)...what'll
we call it?) for an increase in through speed and decrease in size (amazing
how often one follows the other in wireworld).

>George Phillips phillips@cs.ubc.ca {alberta,uw-beaver,uunet}!ubc-cs!phillips
Trevor Green death@csc.waterloo.edu watmath!maytag!watcsc!death

From ca-Request@Think.COM  Wed Feb 28 15:20:57 1990
Received: by fafnir.think.com; Wed, 28 Feb 90 15:20:57 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Wed, 28 Feb 90 15:20:42 EST
Received: from uunet.UU.NET by Think.COM; Wed, 28 Feb 90 15:21:19 -0500
Received: from acad.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA21560; Wed, 28 Feb 90 15:18:43 -0500
Received: from megalon.acad.com by acad.uucp  (3.2/SMI-3.2)
	id AA12055; Wed, 28 Feb 90 10:34:56 PST
Received: by megalon.acad.com (3.2/SMI-3.2)
	id AA07185; Wed, 28 Feb 90 10:34:55 PST
Date: Wed, 28 Feb 90 10:34:55 PST
From: acad!megalon!rudy@uunet.UU.NET (Rudy Rucker)
Message-Id: <9002281834.AA07185@megalon.acad.com>
To: ca@Think.COM
Subject: wireworld


Chip designers do wire crossing by using two different planes of wires, with 
"solder spots" to poke through and let current move from one plane to the
other here and there.  It seems to me the most natural way to accomplish this
in a CA is to have four bits per site, two bits to say whether the cell
holds insulation, wire, electron head wire, or electron tail wire, one bit
to say whether the cell is in plane 0 or in plane 1, and one bit so say if
there is a solder spot.  A better way to use the latter two bits, I guess,
is to have them say whether the cell is in plane 0, plane 1, or in both planes
(solder spot).  Now we write an inner loop routine that at each cycle 
returns eight bits that come in two four bit chunk.  One chunk gives me the
firing eight sum in plane 0 (the nubmer of plane 0 cells which are on) and the
other chunk gives me the firing eightsum in plane 1 (the number of plane 1 
neighbor cells that are on).  These numbers range from 0 to 8, so four bits
are required for each.  The cell's new state is based on the eight bits of
plane0/plane1 firing eightsum info AND on the cell's present state (insulator,
dead wire, head wire, tail wire, plane 0, plane1 or both).  So each cell's
new state is based on a total of 12 bits of info, so a wireworld rule or
any variation on it can be specified by a 4K lookup table.  If anyone wants
to see the CA Lab owncode rule for doing this, I can write it up easily 
enough sometime in the next couple of weeks.  There is nothing sacred about
limiting oneself to Silverman's firing eightsum two bits per cell paradigm
which, although fruitful, should not be engraved in stone.

On a different topic, have you all seen Buckingham's new period 26 Life
oscillator?  Gosper sent me a copy which I can upload if anyone wants it.


From ca-Request@Think.COM  Thu Mar  1 17:40:41 1990
Received: by fafnir.think.com; Thu, 1 Mar 90 17:40:41 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Thu, 1 Mar 90 17:40:37 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Thu, 1 Mar 90 17:41:40 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA00546; Thu, 1 Mar 90 17:28:20 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 1 Mar 90 21:20:08 GMT
From: zaphod.mps.ohio-state.edu!uwm.edu!cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!watserv1!ssingh@Think.COM  ($anjay "lock-on" $ingh - Indy Studies)
Organization: U of Waterloo, Ontario
Subject: 3-d CA code in turbo C
Message-Id: <1298@watserv1.waterloo.edu>
To: ca@Think.COM

I was wondering if anyone had code in C, preferably Turbo C that could
give 3-d displays of a 3-d cellular automaton at work. Thanks.


-- 
"No one had the guts... until now..."  
|-$anjay "lock [+] on" $ingh	ssingh@watserv1.waterloo.edu	N.A.R.C. ]I[-|
"A modern-day warrior, mean mean stride, today's Tom Sawyer, mean mean pride."
!being!mind!self!cogsci!AI!think!nerve!parallel!cybernetix!chaos!fractal!info!

From ca-Request@Think.COM  Thu Mar  1 17:42:07 1990
Received: by fafnir.think.com; Thu, 1 Mar 90 17:42:07 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Thu, 1 Mar 90 17:42:03 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Thu, 1 Mar 90 17:43:04 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA00515; Thu, 1 Mar 90 17:26:50 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 1 Mar 90 14:25:37 GMT
From: mcsun!sunic!dkuug!freja.diku.dk!torbenm@uunet.uu.net  (Torben [gidius Mogensen)
Organization: Department Of Computer Science, University Of Copenhagen
Subject: Re: Wireworld patterns
Message-Id: <1990Mar1.142537.29778@diku.dk>
References: <1990Feb25.050118.7912@watcsc.waterloo.edu>
To: ca@Think.COM

death@watcsc.waterloo.edu (Trevor Green) writes:


> I have come up with a symmetric XOR gate that also has a lower IBI:

> .......
> .==....
> I=.=...
> .==.==.
> .....=O
> .==.==.
> I=.=...
> .==....
> .......
>Transit: 6
>IBI: 11
>Size: 7x7

How about:

..I....
.====..
.=.==O.
.====..
..I....

Transit: 3
IBI: 5

you can add another output opposite the O, which will be the OR'ed signal.


>For people attempting a wire-crosser, here's another design I came up with,
>with the idea of preventing the signals from colliding while they're in the
>device rather than delaying one beforehand and the other afterward.  If
>someone can come up with a better bypass, you'll get a better wire-crosser
>out of this:

> ............
> ..==..=.....
> .I=.===O....
> ..==..=.....
> .....=====..
> ....=.=...=.
> ...=.....=..
> ..=.=...=...
> ..===...=...
> ...=...===..
> ..=....=.=..
> .=......=...
> ..===.=.=...
> .....===....
> ..==..=.....
> .I=.===O....
> ..==..=.....
> ............
>Transit: 19
>IBI: 24
>Size: 12x18 (aack!)

You can make a wire-crosser with 3 EOR gates:

.....==.....
...==..=....
..=...====..
.I....=.==O.
..=...====..
.====..=....
.=.====.....
.====..=....
..=...====..
.I....=.==O.
..=...====..
...==..=....
.....==.....

Transit: 9
IBI: 5 (as the EOR gate)

I have not tried these except on paper, so there might be some bugs,
but I believe not.

>Trevor Green death@csc.waterloo.edu watmath!maytag!watcsc!death

Torben Mogensen (torbenm@diku.dk)

From ca-Request@Think.COM  Thu Mar  1 18:29:24 1990
Received: by fafnir.think.com; Thu, 1 Mar 90 18:29:24 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Thu, 1 Mar 90 18:29:11 EST
Received: from fs3.cs.rpi.edu by Think.COM; Thu, 1 Mar 90 18:30:05 -0500
Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept)
	id AA25052; Thu, 1 Mar 90 18:27:51 EST
Date: Thu, 1 Mar 90 18:27:29 EST
From: hiebeler@turing.cs.rpi.edu (Dave Hiebeler)
Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept)
	id AA22598; Thu, 1 Mar 90 18:27:29 EST
Message-Id: <9003012327.AA22598@turing.cs.rpi.edu>
To: cellular-automata@Think.COM
Subject: CA circuit shrinking (was: wireworld)

  Well, there seems to be a fair amount of enthusiasm about Wireworld
here lately.. so last night, I took a couple of minutes to implement
Wireworld on the CAM and in Cellsim.  I'll post them both in the next
message.

  I haven't played with Wireworld much myself, and don't really have
time to at the moment.  However, I am reminded of some stuff I did
about two years ago.  I implemented a mostly CA-based package which
did simple logic-circuit simulations.  It used 8 bits/cell, to
represent wires (straight, corner, crossover, and fan-out), AND, OR,
NOT, Input, and Output.  It could could do regular simulations, where
you put signals on the inputs and run until signals reached the
outputs.  You could also mark a certain cell with a "fault", and it
would propagate the fault and see which outputs would be affected, and
which inputs would have been faulty to cause such a fault in the
outputs.  Basically you could do forward and backward fault-tracing, I
guess it's called.  (This was really similar to the normal simulation;
under some conditions, the logic gates could "erase" the fault.  For
example, for an AND gate, if one input was 0 and the other was a
fault, the output would be a 0 with no fault; if one input was 1 and
the other was a, fault the output would also be faulty.)

  The real reason for writing all that though, was because we were
experimenting with "circuit shrinking" algorithms -- routines which
would compress the image spatially, without changing the connectivity
of the circuit.  (Timing was not a consideration; logic-gates behaved
more like dataflow I guess, in that they would wait for all inputs to
come in before sending an output.  I don't know much about that area
though, so I'm not really qualified to say).  I came up with 6 or 7
algorithms for shrinking these things, which ran in parallel on our
Sequence Balance 21000.  Some were CA-based, a few were more general
parallel algorithms.  You controlled all this from a SunView program,
which would communicate with the Sequent (somewhat like the way
Cellsim2.5 talks to Connection Machines now).

  I think I wrote a few lines about each step of the shrinking
algorithm somewhere.  If someone's really interested in this, I might
be able to dig it up.  The code is still lying around too, if someone
has a Sun and Sequent Balance.  There are a couple of bugs in it -- I
tested it a few weeks ago to see if it still worked, and I noticed it
didn't shrink one circuit quite as much as it could have -- but most
of it is OK.

  Well, sorry about that little trip down memory lane;  I thought
perhaps some of the Wireworld enthusiasts would be interested.


Dave Hiebeler                       hiebeler@turing.cs.rpi.edu
Computer Science Dept               hiebeler@heretic.lanl.gov
Amos Eaton Bldg.                    hiebeler@rpitsmts.bitnet
Rensselaer Polytechnic Institute
Troy, NY 12180-3590

From ca-Request@Think.COM  Thu Mar  1 19:08:48 1990
Received: by fafnir.think.com; Thu, 1 Mar 90 19:08:48 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Thu, 1 Mar 90 19:08:36 EST
Received: from fs3.cs.rpi.edu by Think.COM; Thu, 1 Mar 90 19:09:10 -0500
Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept)
	id AA25143; Thu, 1 Mar 90 19:06:54 EST
Date: Thu, 1 Mar 90 19:06:30 EST
From: hiebeler@turing.cs.rpi.edu (Dave Hiebeler)
Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept)
	id AA23688; Thu, 1 Mar 90 19:06:30 EST
Message-Id: <9003020006.AA23688@turing.cs.rpi.edu>
To: cellular-automata@Think.COM
Subject: wireworld on CAM and Cellsim

  Here's Wireworld for CAM and for Cellsim.  I only spent a few
minutes writing them, so I won't say they're great, but they seem to
work.  Actually, I'd like to issue a challenge for CAM-users: if you
have a better (which I guess means "more interesting and/or compact")
way of implementing this, I'd like to hear about it!

  The Cellsim version of the rule is easier to read, but the nice
thing about CAM is you can run 60 generations/sec on a 256x256 array,
so you can do large circuits pretty quickly if you want.  Cellsim will
go pretty fast for smaller arrays.  You can't run this rule on the
Connection Machine using Cellsim, because the lookup-table would be
too large for a CM with 8Kbytes/processor (that's what I use now).  Of
course, if you were to re-write it in Paris, it would run at several
hundred generations/sec, if you turn off the display!  I'm not really
motivated to write it in Paris at the moment though..  (Paris is the
Parallel Instruction Set, a semi-low-level language on the CM that you
can call from C, Lisp and Fortran, for those who don't know.)

=====
CAM version of Wireworld
 Wires are on plane 1, electron heads on plane 0, and I store electron
tails on CAM-B.  To non-CAM users, this might look a little scary.
It's written in Forth, a stack-based language.  If you've used an HP
calculator, Forth is nothing fundamentally new.  Plus, you only have
to know a little Forth to use CAM.  So here's the rule.  I hope I
didn't make a typo; I am not able to transfer files from my PC to Sun
right now, so I just scribbled it down on paper from the PC screen and
typed it in here.

\ Wireworld, simple logic-circuits as described in
\ A.K. Dewdney's "Computer Recreations" column in the
\ January 1990 Scientific American.

NEW-EXPERIMENT N/MOORE &/CENTERS
CAM-A
: 8SUM  NORTH SOUTH EAST WEST N.WEST N.EAST S.WEST S.EAST
    + + + + + + + ;
: EH 1 ;  \ Electron Head
: W 2 ;   \ Wire
: WIRERULE
    8SUM { W EH EH W W W W W W } ;
: WIREWORLD  \ If not E-Tail, do normal rule, else become wire
    &CENTER IF W ELSE CENTERS { 0 W WIRERULE 0 } THEN >PLNA ;
MAKE-TABLE WIREWORLD

CAM-B N/MOORE &/CENTERS
: ET-RULE
    &CENTERS EH = IF 1 ELSE 0 THEN >PLN2 ;
MAKE-TABLE ET-RULE


=====
Cellsim version of Wireworld

  Here it is for Cellsim.  It uses the "m4" neighborhood, so it
generates a lookup-table rather than running in computed-function
mode.  This form of the rule is fairly portable, and should be very
easy to plug into CA Lab and other packages, I think.  Of course, this
rule is so simple, it's no big feat to rewrite it for other systems.

/*
 * File: wireworld.m4.c
 *   By: Dave Hiebeler
 *       hiebeler@heretic.lanl.gov
 *       February 1990
 *
 * Wireworld CA rule, as described in A.K. Dewdney's Jan 1990 "Computer
 * Recreations" column, in Scientific American.
 */


#include "nborhood.h"

byte wireworld_rule();

#define EMPTY 0
#define EHEAD 1  /* electron heads on plane 0 */
#define WIRE  2  /* wires on plane 2 */
#define ETAIL 3  /* electron tail is a 1 in both planes */

/* Little boolean macro, equals 1 if cell is e-head, otherwise equals 0 */
#define ehead(cell) ((cell==EHEAD) & 0x01)

void
init_function()
{
    update_function = wireworld_rule;
}


byte
wireworld_rule(nbors)
moore_nbors *nbors;
{
    int eightsum;

    Get_moore_nbors;

    eightsum = ehead(tl) + ehead(l) + ehead(bl) + ehead(t) + ehead(b) +
	ehead(tr) + ehead(r) + ehead(br);
    switch (center) {
      case EMPTY:
	return EMPTY;
	break;
      case EHEAD:
	return ETAIL;
	break;
      case ETAIL:
	return WIRE;
	break;
      case WIRE:
	if ((eightsum == 1) || (eightsum == 2))
	    return EHEAD;
	else
	    return WIRE;
	break;
    }
}


  If someone out there using CAM or Cellsim would like me to crank out
a little program to convert those text-diagrams we've been seeing into
CAM or Cellsim image-format, let me know.  It's easy enough to draw
stuff in both systems, that I haven't bothered writing a program to
convert.  It would only take a couple of minutes to do, though.

Dave Hiebeler                       hiebeler@turing.cs.rpi.edu
Computer Science Dept               hiebeler@heretic.lanl.gov
Amos Eaton Bldg.                    hiebeler@rpitsmts.bitnet
Rensselaer Polytechnic Institute
Troy, NY 12180-3590

From ca-Request@Think.COM  Thu Mar  1 20:30:30 1990
Received: by fafnir.think.com; Thu, 1 Mar 90 20:30:30 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Thu, 1 Mar 90 20:30:26 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Thu, 1 Mar 90 20:31:26 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA07301; Thu, 1 Mar 90 20:01:39 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 1 Mar 90 14:07:37 GMT
From: njin!spcvxa!ben@rutgers.edu  (Ben Cohen)
Organization: St. Peter's College, US
Subject: What _is_ WireWorld?
Message-Id: <21.25ed2caa@spcvxa.spc.edu>
To: ca@Think.COM

Hello, all.
   Our site only recently joined Usenet. I've seen quite a few messages here in
c.t.c-a about something called "WireWorld". This looks interesting, but I'm not
sure what (exactly) is the program under discussion. Could someone please
explain what WireWorld is and where it's available? [E-Mail or posting is fine
by me.]

Ben Cohen			Bitnet:   Ben@SPCVXA
Saint Peter's College		Internet: Ben@spcvxa.spc.edu
Jersey City, NJ  USA		UUCP:	  ...!rutgers!njin!spcvxa!ben
				ICBMnet:  40 42 57 N/74 03 54 W
				ATTnet:	  1-201-451-5959
"Hear me, children of the earth. I have a tale. Believe it if you will...
"But beware. For there are lies in truth and truth in lies...
"And I am Coyote, the Trickster... And I tell both with equal ease."

From ca-Request@Think.COM  Thu Mar  1 20:31:31 1990
Received: by fafnir.think.com; Thu, 1 Mar 90 20:31:31 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Thu, 1 Mar 90 20:31:27 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Thu, 1 Mar 90 20:31:57 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA06918; Thu, 1 Mar 90 19:53:14 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 1 Mar 90 23:27:29 GMT
From: TURING.CS.RPI.EDU!hiebeler@bloom-beacon.mit.edu  (Dave Hiebeler)
Organization: The Internet
Subject: CA circuit shrinking (was: wireworld)
Message-Id: <9003012327.AA22598@turing.cs.rpi.edu>
To: ca@Think.COM

  Well, there seems to be a fair amount of enthusiasm about Wireworld
here lately.. so last night, I took a couple of minutes to implement
Wireworld on the CAM and in Cellsim.  I'll post them both in the next
message.

  I haven't played with Wireworld much myself, and don't really have
time to at the moment.  However, I am reminded of some stuff I did
about two years ago.  I implemented a mostly CA-based package which
did simple logic-circuit simulations.  It used 8 bits/cell, to
represent wires (straight, corner, crossover, and fan-out), AND, OR,
NOT, Input, and Output.  It could could do regular simulations, where
you put signals on the inputs and run until signals reached the
outputs.  You could also mark a certain cell with a "fault", and it
would propagate the fault and see which outputs would be affected, and
which inputs would have been faulty to cause such a fault in the
outputs.  Basically you could do forward and backward fault-tracing, I
guess it's called.  (This was really similar to the normal simulation;
under some conditions, the logic gates could "erase" the fault.  For
example, for an AND gate, if one input was 0 and the other was a
fault, the output would be a 0 with no fault; if one input was 1 and
the other was a, fault the output would also be faulty.)

  The real reason for writing all that though, was because we were
experimenting with "circuit shrinking" algorithms -- routines which
would compress the image spatially, without changing the connectivity
of the circuit.  (Timing was not a consideration; logic-gates behaved
more like dataflow I guess, in that they would wait for all inputs to
come in before sending an output.  I don't know much about that area
though, so I'm not really qualified to say).  I came up with 6 or 7
algorithms for shrinking these things, which ran in parallel on our
Sequence Balance 21000.  Some were CA-based, a few were more general
parallel algorithms.  You controlled all this from a SunView program,
which would communicate with the Sequent (somewhat like the way
Cellsim2.5 talks to Connection Machines now).

  I think I wrote a few lines about each step of the shrinking
algorithm somewhere.  If someone's really interested in this, I might
be able to dig it up.  The code is still lying around too, if someone
has a Sun and Sequent Balance.  There are a couple of bugs in it -- I
tested it a few weeks ago to see if it still worked, and I noticed it
didn't shrink one circuit quite as much as it could have -- but most
of it is OK.

  Well, sorry about that little trip down memory lane;  I thought
perhaps some of the Wireworld enthusiasts would be interested.


Dave Hiebeler                       hiebeler@turing.cs.rpi.edu
Computer Science Dept               hiebeler@heretic.lanl.gov
Amos Eaton Bldg.                    hiebeler@rpitsmts.bitnet
Rensselaer Polytechnic Institute
Troy, NY 12180-3590

From ca-Request@Think.COM  Fri Mar  2 04:35:10 1990
Received: by fafnir.think.com; Fri, 2 Mar 90 04:35:10 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Fri, 2 Mar 90 04:34:56 EST
Received: from uunet.UU.NET by Think.COM; Fri, 2 Mar 90 04:35:52 -0500
Received: from acad.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA26843; Fri, 2 Mar 90 04:34:23 -0500
Received: from megalon.acad.com by acad.uucp  (3.2/SMI-3.2)
	id AA17061; Thu, 1 Mar 90 21:22:29 PST
Received: by megalon.acad.com (3.2/SMI-3.2)
	id AA25938; Thu, 1 Mar 90 21:22:22 PST
Date: Thu, 1 Mar 90 21:22:22 PST
From: acad!megalon!rudy@uunet.UU.NET (Rudy Rucker)
Message-Id: <9003020522.AA25938@megalon.acad.com>
To: ca@Think.COM
Subject: hiebeler's rap
Cc: megalon!tech@uunet.UU.NET


Using a lot of states to represent all components is a nice idea.  You
can have states 0 thru 255, so you can have a cell that is aan and gate,
a cell that is an or gate, a cell that is a source of faults, etc.
So then you can make tiny tiny wireworld circuits.  And animate them.
Chip designers use something like this, I guess, tho they run slowly?

Question: what are some interesting small wireworld circuits?  

ALife idea: alife ants have brains that are small wireworld patches,
say 10 by 20 with 8 bits per cell, kind of like that old game Robotropolis.

Research Guidline Request:  What would be a neat small circuit to build?
Adders are kind of lame, too much like reinventing the wheel.  How about
a circuit to compute pi?  Too hard for starters.  How about a circuit
which will generate the digits of the binary expansion of the square root
of two.  That would be fun, and a very interesting thing to use for the
brain of an alife bopster.

From ca-Request@Think.COM  Fri Mar  2 08:30:34 1990
Received: by fafnir.think.com; Fri, 2 Mar 90 08:30:34 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Fri, 2 Mar 90 08:30:31 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Fri, 2 Mar 90 08:31:34 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA11666; Fri, 2 Mar 90 08:17:59 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 2 Mar 90 13:15:42 GMT
From: jwmills@iuvax.cs.indiana.edu  (Jonathan Mills)
Organization: Indiana University, Bloomington
Subject: VLSI CAs (was Re: hiebeler's rap)
Message-Id: <37683@iuvax.cs.indiana.edu>
References: <9003020522.AA25938@megalon.acad.com>
To: ca@Think.COM

In article <9003020522.AA25938@megalon.acad.com> Rudy Rucker writes:
>
>Using a lot of states to represent all components is a nice idea.  You
>can have states 0 thru 255, so you can have a cell that is aan and gate,
>a cell that is an or gate, a cell that is a source of faults, etc.
>So then you can make tiny tiny wireworld circuits.  And animate them.
>Chip designers use something like this, I guess, tho they run slowly?

I've investigated cellular automata for VLSI simulation and verification,
and am still working with it.  But no tools, either mine or others I am
aware of (various signal-level circuit simulators, digital simulators,
or symbolic simulators) use the wireworld approach of "duelling electrons."

It's cute, but it is too far divorced from the properties of the circuits
to be useful (IMHO; no insults to clever originators of concept or the
wireworld program; flames to /dev/null).

Circuit simulators commonly used solve for increasingly complex sets of
partial differental equations (from what I've seen of Spice documentation),
and attempt to find the fixpoint of that set of equations (i.e., "converge").
Sometimes they don't.

The VLSI CAs I've worked with model various transistors, gates, oscillators,
and networks, and can be compiled from MAGIC layouts -- although I haven't
automated the process.  Their behavior is similar -- but not identical --
to the "real" thing, in part because the model embedded is _much_ less
complex.

Certainly the VLSI CAs _do_ run slowly;  they are not realistic for circuits
of interest.  Consider that university tools (Spice, again) may run for days
to compute the behavior of a complex circuit.

Sincerely,
Jonathan

From ca-Request@Think.COM  Fri Mar  2 14:29:52 1990
Received: by fafnir.think.com; Fri, 2 Mar 90 14:29:52 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Fri, 2 Mar 90 14:29:48 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Fri, 2 Mar 90 14:30:53 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA00327; Fri, 2 Mar 90 14:09:57 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 2 Mar 90 18:37:25 GMT
From: zaphod.mps.ohio-state.edu!rpi!iear.arts.rpi.edu!kyriazis@Think.COM  (George Kyriazis)
Organization: Rensselaer Polytechnic Institute, Troy NY
Subject: Re: hiebeler's rap
Message-Id: <^-+#5%+@rpi.edu>
References: <9003020522.AA25938@megalon.acad.com>
To: ca@Think.COM

In article <9003020522.AA25938@megalon.acad.com> rudy@megalon.UUCP (Rudy Rucker) writes:
>
>Research Guidline Request:  What would be a neat small circuit to build?
>Adders are kind of lame, too much like reinventing the wheel.  How about
>a circuit to compute pi?  Too hard for starters.  How about a circuit
>which will generate the digits of the binary expansion of the square root
>of two.  That would be fun, and a very interesting thing to use for the
>brain of an alife bopster.

Are we talking here about merging CA with computer engineering or better
VLSI design?  I remember talking to Dave (Hiebeler) about it a few
years ago, but then all he had was the CAM machine with not so many bits
per cell.

In VLSI you have several layers of material, eg. diffusion, poly, metal, etc.
Whenever poly crosses diffusion you have a transistor.  The circuit
shrinker can get help from the several layout rules that exist for each
technology. The major question that comes to my mind is:  Will CA's be
eventually fast enough to accurately simulate such a circuit, and if
yes are there any advantages over traditional circuit simulators, like SPICE?

disclaimer:  I am a computer engineer, not a computer scientist.



----------------------------------------------------------------------
  George Kyriazis                 kyriazis@turing.cs.rpi.edu
				  kyriazis@rdrc.rpi.edu
 				  kyriazis@iear.arts.rpi.edu

From ca-Request@Think.COM  Fri Mar  2 15:55:47 1990
Received: by fafnir.think.com; Fri, 2 Mar 90 15:55:47 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Fri, 2 Mar 90 15:55:40 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Fri, 2 Mar 90 15:56:42 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA04230; Fri, 2 Mar 90 15:42:52 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 2 Mar 90 19:27:25 GMT
From: snorkelwacker!apple!apple.com!karakots@bloom-beacon.mit.edu  (Ken Karakotsios)
Organization: Apple Computer Inc.
Subject: Re: VLSI CAs (was Re: hiebeler's rap)
Message-Id: <7012@internal.Apple.COM>
References: <37683@iuvax.cs.indiana.edu>
To: ca@Think.COM

There are several aspects of VLSI design that one uses computers for:  
Logic simulation, timing accurate simulation, layout generation, design 
rule checking, static timing analysis, schematic extraction from a layout 
(for checking to make sure your layout generator did its job), and 
modelling the solid state physics of a single transistor are a few 
examples that come to mind.

Wire world running on a serial computer is many orders of magnitude slower 
than current logic simulators.  Also, the fact that synchronization of 
electorns at gates requires all paths between gates to be the same length 
makes things quite complicated.  However, one company I know of 
(Qucikturn) is using a large cluster of electrically programmable gate 
arrays to actually implement the logic, on the fly, that you want to 
simulate.  This approach sounds about as reasonable as making a special 
electrically programmable wireworld hardware element to do logic 
simulation.  Put a reconfigurable cluster of enough of them together (is 
this a CAM-8?) and you could get one clock cycle of the design you are 
simulating in some small number of clock cycles of the  wireworld 
simulator hardware.  Typical logic simulation of a complex design on a 
serial computer is about a factor of 10^6 slower than the speed of the 
real design.  If you can do better than this with a cheap hardware add-on, 
it could be interesting. 

Perhaps CAs could be applied the problem of generating VLSI layout or 
extracting a schematic from existing layout.  For example, you could use a 
CA which shrinks rectangles down to lines to simplify the topology of a 
VLSI  layout into some "stick" types of patterns.  Perhaps these patterns 
could then be looked up in some "list of possible patterns".

Static timing analysis requires software which can find all possible paths 
which a signal can take through a design.  Maybe "virtual ants" could 
crawl through the netlist and report back to some data structure on what 
all the paths are... 

Ken Karakotsios                 karakots@apple.com
(408) 974-1942                AppleLink: karakots

generic disclaimer... I speak for myself, not Apple...

From ca-Request@Think.COM  Fri Mar  2 18:55:51 1990
Received: by fafnir.think.com; Fri, 2 Mar 90 18:55:51 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Fri, 2 Mar 90 18:55:48 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Fri, 2 Mar 90 18:56:51 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA07395; Fri, 2 Mar 90 18:30:06 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 2 Mar 90 22:18:55 GMT
From: zaphod.mps.ohio-state.edu!rpi!hiebeler@Think.COM  (Dave Hiebeler)
Organization: RPI CS Dept, and LANL Center for Nonlinear Studies
Subject: efficiency and philosophy of CA computer simulation
Message-Id: <K{+#+Y+@rpi.edu>
To: ca@Think.COM


  Two things recently said here led to a few interesting thoughts.
First, the quotes:
1>From kyriazis@iear.arts.rpi.edu (George Kyriazis) Fri Mar  2 16:48:38 1990
1> Will CA's be eventually fast enough to accurately simulate such a
1> circuit...?

and

2>From karakots@apple.com (Ken Karakotsios) Fri Mar  2 16:48:44 1990
2> Wire world running on a serial computer is many orders of magnitude
2> slower than current logic simulators.


  One of the strong incentives to use CA for things like physical
modeling, is that the path between the physics and the computer
simulation is much more direct, i.e. instead of following the
following steps:
 1. make a continuum approximation of the system under study
 2. write some PDE's
 3. turn the PDE's into finite-difference equations on the computer
 4. do lots of rounding off in the process of simulating these
    finite-difference eqns

We just do the following with CA:
 1. "assume" the universe (hence the system under study) is discrete
 2. write a CA rule which captures the essentials of the laws of
    physics, in particular the ones that most strongly affect what
    we're studying, and implement the CA rule exactly on a computer
    (no round-off, etc)

Because the CA approach is more direct, if you build a computer (e.g.
a CAM) using the CA philosophy (local connections, very parallel) you
will be able to do physics simulations very fast, although from a very
different perspective than PDE's.

  Anyways, enough background, which everyone here has heard many
times (I quickly repeated it for the benefit of new people).  What the
2 quotes above got me wondering about was the efficiency of using CAs
to simulate traditional-architecture computers.

  In some sense, it has to be efficient, because the traditional
computer will be implemented in our physical reality, which a CA
corresponds well to.  But is there some advantage to be gained by
using a standard (physically inefficient) serial computer to simulate
another such computer?

  I think not, with the continuing development of CA hardware.  The
folks working on CAM-8 describe future CA machines as being
"programmable matter".  We will be able to do such incredibly detailed
physical simulations, it's almost like having a "holodeck" from the
new Star Trek -- we'll be able to create some virtual physical system,
in some sense.  I'm not getting into the virtual reality topic here;
I'm saying that at some point we'll be able to do things like simulate
a cubic centimeter of air at the molecular level, in something not far
from real-time, using CA technology!

  So a *CA simulation* of a serial computer will approach the speed of a
*physical implementation* of that computer!  At least, it seems that
way to me.  

  This really starts to sound like a lot of philosophical hocus-pocus,
but now that I've already gone that far, I might as well ask the real
philosophical knockout question: do you think it is feasible that we
will someday be able to simulate computers, using CA techniques, so
that they will run *faster* than the physical implementation of the
machines?  That is, maybe CA hardware will develop so well that it
will get ahead of manufacturing technology in some areas?

  I really don't know anything about manufacturing technology, so maybe
it's a ludicrous question.  It does seem like an interesting one
though.  I guess it's safe to say we can't simulate the universe more
efficiently than it "runs" itself, since our CA machine will be
embedded in the universe.  But it does seem theoretically possible, I
think, that we could "beat ourselves" at building things, so to speak.

-- 
Dave Hiebeler / Computer Science Dept. / Amos Eaton Bldg. /
Rensselaer Polytechnic Institute / Troy, NY 12180-3590 USA
Internet (preferred): hiebeler@turing.cs.rpi.edu   Bitnet: userF3JL@rpitsmts
"Off we go, into the wilds you ponder..."

From ca-Request@Think.COM  Fri Mar  2 20:00:39 1990
Received: by fafnir.think.com; Fri, 2 Mar 90 20:00:39 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Fri, 2 Mar 90 20:00:36 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Fri, 2 Mar 90 20:01:38 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA09807; Fri, 2 Mar 90 19:30:06 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 2 Mar 90 23:38:33 GMT
From: zaphod.mps.ohio-state.edu!rpi!iear.arts.rpi.edu!kyriazis@Think.COM  (George Kyriazis)
Organization: Rensselaer Polytechnic Institute, Troy NY
Subject: Re: efficiency and philosophy of CA computer simulation
Message-Id: <&'+#D#|@rpi.edu>
References: <K{+#+Y+@rpi.edu>
To: ca@Think.COM

In article <K{+#+Y+@rpi.edu> hiebeler@cs.rpi.edu (Dave Hiebeler) writes:
>
>We just do the following with CA:
> 1. "assume" the universe (hence the system under study) is discrete
> 2. write a CA rule which captures the essentials of the laws of
>    physics, in particular the ones that most strongly affect what
>    we're studying, and implement the CA rule exactly on a computer
>    (no round-off, etc)
>
Hmm..  I don't know if that will work nicely for circuit simulators.
Since the universe is not discrete (well, physicists can argue that it
is, so it's better to say that the universe is not as 'lumpy' as
today's CA machines assume), I think that the results will
probably be better if the CA rules take into account the discretness
of the CA world.  Doing that of course will increase the computation
per step.


>I'm not getting into the virtual reality topic here;
>I'm saying that at some point we'll be able to do things like simulate
>a cubic centimeter of air at the molecular level, in something not far
>from real-time, using CA technology!
>
This is interesting.  What is more interesting is the following:
There is a concept called the time quantum, which is VERY small
(order of 10^-40 secs?).  You are talking about simulating nature in
close to real-time.  Definetely your time step will be mach larger than
that (I am dreaming of 500 picosecs or so), so some kind of interpolation
(spatial and/or temporal) has to be done.  ODE solving does the same
thing:  It's repetitive and interpolates on the time axis.  So, the
question that comes to mind is:  Is there any fundamental difference
between DE solving and CA?  I don't think there is too much.
Finite element Analysis texts start from fixed grid techniques
(hmm..  it reminds me of the CA grid) and go on with localized grid
refinement and a huge list of other stuff I don't want to think about.

But FEM is for Mech. Engineers!  They deal will stresses and they need
refinement.  Circuit simulation uses experimental results 
(capacitance/unit area, resistance/unit length, etc.)  for simulation
(I am talking about SPICE, etc.).  In VLSI design there is a minimum
feature size that can be used, so NOT refining will work.  


>
>  So a *CA simulation* of a serial computer will approach the speed of a
>*physical implementation* of that computer!  At least, it seems that
>way to me.  
>
Assuming that lots of approximations are made during the simulation,
I agree.


>
>  This really starts to sound like a lot of philosophical hocus-pocus,
>but now that I've already gone that far, I might as well ask the real
>philosophical knockout question: do you think it is feasible that we
>will someday be able to simulate computers, using CA techniques, so
>that they will run *faster* than the physical implementation of the
>machines?  That is, maybe CA hardware will develop so well that it
>will get ahead of manufacturing technology in some areas?
>
If you are willing to stretch your question I think it's already done!
There are some new chips just announced that are called
'Field Programmable Logic Arrays'.  They contain an array PLA's
(Programmable Logic Arrays) that are connected with a programmable
interconnect.  That means that you can program it at run-time.
In other words you can have a bunch of them emulatinga SPARC at one
point in time, then change their mind and reprogram themselves so
they emulate a 68020 equally well, and finally change so they
emulate a small Connection Machine.

Now where does the simulation come into play?  I think it makes the
gap between simulation and implementation VERY small.  What you can
do is design the circuit and instead of simulating it, program it
on an array of FPLA's, see if it works, and then (if necessary) go
back to the drawing board.  Scary isn't it?


>
>-- 
>Dave Hiebeler / Computer Science Dept. / Amos Eaton Bldg. /
>Rensselaer Polytechnic Institute / Troy, NY 12180-3590 USA
>Internet (preferred): hiebeler@turing.cs.rpi.edu   Bitnet: userF3JL@rpitsmts
>"Off we go, into the wilds you ponder..."


----------------------------------------------------------------------
  George Kyriazis                 kyriazis@turing.cs.rpi.edu
				  kyriazis@rdrc.rpi.edu
 				  kyriazis@iear.arts.rpi.edu

From ca-Request@Think.COM  Fri Mar  2 20:29:32 1990
Received: by fafnir.think.com; Fri, 2 Mar 90 20:29:32 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Fri, 2 Mar 90 20:29:21 EST
Received: from MITVMA.MIT.EDU by Think.COM; Fri, 2 Mar 90 20:30:25 -0500
Message-Id: <9003030130.AA25800@Think.COM>
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 4829; Fri, 02 Mar 90 20:29:21 EST
Received: by MITVMA (Mailer R2.05) id 4727; Fri, 02 Mar 90 20:29:20 EST
Date:         Fri, 02 Mar 90 20:28:49 EST
From: anthony taylor <S20081@mitvma.mit.edu>
Subject:      unsubscribe
To: CA@Think.COM

unsubscribe anthony taylor

From ca-Request@Think.COM  Sat Mar  3 23:56:21 1990
Received: by fafnir.think.com; Sat, 3 Mar 90 23:56:21 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Sat, 3 Mar 90 23:56:17 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Sat, 3 Mar 90 23:57:26 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA28017; Sat, 3 Mar 90 23:43:58 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 1 Mar 90 14:25:37 GMT
From: eru!luth!sunic!dkuug!freja.diku.dk!torbenm@bloom-beacon.mit.edu  (Torben [gidius Mogensen)
Organization: Department Of Computer Science, University Of Copenhagen
Subject: Re: Wireworld patterns
Message-Id: <1990Mar1.142537.29778@diku.dk>
References: <1990Feb25.050118.7912@watcsc.waterloo.edu>
To: ca@Think.COM

death@watcsc.waterloo.edu (Trevor Green) writes:


> I have come up with a symmetric XOR gate that also has a lower IBI:

> .......
> .==....
> I=.=...
> .==.==.
> .....=O
> .==.==.
> I=.=...
> .==....
> .......
>Transit: 6
>IBI: 11
>Size: 7x7

How about:

..I....
.====..
.=.==O.
.====..
..I....

Transit: 3
IBI: 5

you can add another output opposite the O, which will be the OR'ed signal.


>For people attempting a wire-crosser, here's another design I came up with,
>with the idea of preventing the signals from colliding while they're in the
>device rather than delaying one beforehand and the other afterward.  If
>someone can come up with a better bypass, you'll get a better wire-crosser
>out of this:

> ............
> ..==..=.....
> .I=.===O....
> ..==..=.....
> .....=====..
> ....=.=...=.
> ...=.....=..
> ..=.=...=...
> ..===...=...
> ...=...===..
> ..=....=.=..
> .=......=...
> ..===.=.=...
> .....===....
> ..==..=.....
> .I=.===O....
> ..==..=.....
> ............
>Transit: 19
>IBI: 24
>Size: 12x18 (aack!)

You can make a wire-crosser with 3 EOR gates:

.....==.....
...==..=....
..=...====..
.I....=.==O.
..=...====..
.====..=....
.=.====.....
.====..=....
..=...====..
.I....=.==O.
..=...====..
...==..=....
.....==.....

Transit: 9
IBI: 5 (as the EOR gate)

I have not tried these except on paper, so there might be some bugs,
but I believe not.

>Trevor Green death@csc.waterloo.edu watmath!maytag!watcsc!death

Torben Mogensen (torbenm@diku.dk)

From ca-Request@Think.COM  Sun Mar  4 01:30:29 1990
Received: by fafnir.think.com; Sun, 4 Mar 90 01:30:29 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Sun, 4 Mar 90 01:30:21 EST
Received: from uunet.UU.NET by Think.COM; Sun, 4 Mar 90 01:31:37 -0500
Received: from acad.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA02745; Fri, 2 Mar 90 13:42:40 -0500
Received: from earth.acad by acad.uucp  (3.2/SMI-3.2)
	id AA13398; Fri, 2 Mar 90 10:04:02 PST
Received: by earth.acad (4.0/SMI-4.0)
	id AA02501; Fri, 2 Mar 90 09:54:38 PST
Date: Fri, 2 Mar 90 09:54:38 PST
From: acad!earth!eric@uunet.UU.NET (Eric Lyons)
Message-Id: <9003021754.AA02501@earth.acad>
To: ca@Think.COM, megalon!rudy@uunet.UU.NET
Subject: Re:  hiebeler's rap

Who is the ca@think.com group?  The original posting sounds like it might have
been interesting.  Or maybe did you just accidentally post your response to
tech?

Eric.

From ca-Request@Think.COM  Fri Mar  9 08:01:25 1990
Received: by fafnir.think.com; Fri, 9 Mar 90 08:01:25 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Fri, 9 Mar 90 08:01:21 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Fri, 9 Mar 90 08:02:38 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA20375; Fri, 9 Mar 90 07:12:33 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 8 Mar 90 10:40:54 GMT
From: snorkelwacker!usc!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uxh.cso.uiuc.edu!wli@bloom-beacon.mit.edu
Subject: Complex Systems (vol , No.2,3,4)
Message-Id: <57700008@uxh.cso.uiuc.edu>
To: ca@Think.COM




##########################################################################
Journal COMPLEX SYSTEMS  devotes to the rapid publication of research on
the science, mathematics, and engineering of systems with simple components
but complex overall behavior.
##########################################################################

        COMPLEX SYSTEMS  

---------------------------------------------------------------------------
Vol. 3 Number 2 (April 1989)
---------------------------------------------------------------------------

"Periodic Points and Entropies for Cellular Automata"
   Rui M.A. Dilao

"Genetic Algorithms and Walsh Functions: Part I,
A Gentle Introduction"
   David E. Goldberg

"Genetic Algorithms and Walsh Functions: Part II,
Deception and Its Analysis"
   David E. Goldberg

"Local Graph Transformations Driven by Lyapunov Functionals"
   Eric Goles


"The Choice Problem: Neural Network Learning, Generalization,
and Geometry"
   Alan J. Katz, Dean R. Collins, Marek Lugowski

"Algebraic Theory of Bounded One-dimensional Cellular Automata"
   N. Pitsianis, G.L. Bleris, Ph. Tsalides, A. Thanailakis,
   H.C. Card

---------------------------------------------------------------------------
Vol. 3 Number 3 (June 1989)
---------------------------------------------------------------------------

"Learning by Minimizing Resources in Neural Networks"
   Pal Rujan and Mario Marchand

"How the Lattice Gas Model for the Navier-Stokes Equation
Improves When a New Speed is Added"
   Shiyi Chen, Hudong Chen, Gary D. Doolen

"Fractal and Recurrent Behavior of Cellular Automata"
   Karel Culik II and Simant Dube

"Energy Functions in Neural Networks with Continuous Local
Functions"
   F. Fogelman-Soulie, C. Mieja, Eric Goles, and S. Martinez

"Using Artificial Neural Nets for Statistical Discovery:
Observations after Using Backpropagation, Expert Systems,
and Multiple-Linear Regression on Clinical Trial Data"
   Erach A. Irani, John P. Matts, John M. Long, James R.
   Slagle, and the POSCH Group

"Comment on 'Abnormal Diffusion in Wind-Tree Lattice Gases"
   B.Th. Bouwens, M.H. Ernst, and P.M. Binder

---------------------------------------------------------------------------
Vol. 3 Number 4 (August 1989)
---------------------------------------------------------------------------

"Lattice Boltzmann Equation for Laminar Boundary Flow"
   Paul Lavalee, Jean Pierre Boon, and Alain Noullez

"Accelerated Bckpropagation Learning: Two Optimization
Methods"
   Roberto Battiti

"One-Dimensional Cellular Automata: Injectivity from
Unambiguity"
   Tom Head

A Focused Backpropagation Algorithm for Temporal Pattern
Recognition"
   Michael C. Mozer

"Cellular Automaton Model for Fluid Flow in Porous Media"
   Paul Papatzacos

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
For more information on the journal COMPLEX SYSTEMS, send mail to
 
Complex Systems Publications, Inc.
P.O.Box 6149                            jcs@complex.ccsr.uiuc.edu (Arpanet) 
Champaign, IL 61821-8149 USA            jcs%complex@uiucuxc.bitnet(Bitnet)
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

From ca-Request@Think.COM  Fri Mar  9 10:02:26 1990
Received: by fafnir.think.com; Fri, 9 Mar 90 10:02:26 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Fri, 9 Mar 90 10:02:23 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Fri, 9 Mar 90 10:03:39 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA24888; Fri, 9 Mar 90 09:37:38 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 8 Mar 90 12:16:03 GMT
From: shelby!portia!portia.stanford.edu!bugboy@decwrl.dec.com  (Michael Frank)
Organization: Stanford University
Subject: Wireworld memory units
Message-Id: <9937@portia.Stanford.EDU>
To: ca@Think.COM

Hi, I just started reading this group and noticed the wireworld discussion,
and I wondered whether anyone had seen before a design that I came up with
for a memory gate.  Here it is:

...=.....
...=.....
..===....
...=.....
..=.=....
..=.=....
====.====
..=......
.........

The wire on the left is the SET input, the wire on top the CLEAR input, and
the wire on the right is the output.  The inputs and outputs are supposed
to be pulsed at 6-cycle intervals.  Here's a run-through:

Initially there are no electrons in the loop.  At a tick which we'll number
0, an electron enters the device as shown:

...=.....
...=.....
..===....
...=.....
..=.=....
..=.=....
-#==.====
..=......
.........

6 cycles later, it leaves the output, and a duplicate rounds the bottom of
the loop for another cycle, so that the memory will continue outputing
the pulse:

...=.....
...=.....
..===....
...=.....
..=.=....
..=.-....
===#.#===
..=......
.........

But, if at this time (or any multiple of 6 cycles afterwards) a pulse
arrives in the CLEAR input,

...#.....
...=.....
..===....
...=.....
..=.=....
..=.-....
===#.#===
..=......
.........

Then two cycles later, the gate will look like this:

...=.....
...-.....
..###....
...=.....
..#.=....
..-.=....
==-=.=-#=
..-......
.........

And the pulse in the loop will go away, and pulses will stop
coming out the output.

What do you guys think?  Anyone seen a memory unit this small before?

Note the use of the tiny OR gate within it, and the NOT gate at top.
OR gate:
.=.
===
.=.
...
Anyway, hope I didn't use too much bandwidth.
Bye!
Mike Frank
bugboy@portia.stanford.edu
bugboy%portia@stanford.bitnet

From ca-Request@Think.COM  Sun Mar 11 00:58:38 1990
Received: by fafnir.think.com; Sun, 11 Mar 90 00:58:38 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Sun, 11 Mar 90 00:58:35 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Sun, 11 Mar 90 00:59:54 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA05391; Sun, 11 Mar 90 00:39:37 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca-list@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 11 Mar 90 05:16:56 GMT
From: mailrus!uwm.edu!ux1.cso.uiuc.edu!happy.csg.uiuc.edu!kurt@purdue.edu  (Kurt)
Organization: Univ of Illinois at Urbana-Champaign
Subject: Where are the Jobs?
Message-Id: <1990Mar11.051656.23363@ux1.cso.uiuc.edu>
To: ca@Think.COM

With the end of the educational tunnel looming in front of
me I (and probably many like me) are looking for jobs.  But,
since the field of complex systems (e.g., CA, genetic algs, etc.)
is not very well defined, trying to find a job working in 
complex systems is also not a well-defined process.  I've
come up with a list of some companies doing at least a little
work in complex systems and i'd like to get comments (as well
as additions to the list) from knowledgable readers of this
newsgroup.  Here's what I have so far:

		Los Alamos National Labs
		Santa Fe Institute
		Thinking Machines 
		BBN
		Philips Labs
		IBM TJ Watson Research Center
		Rowland Institute of Science
		Xerox PARC
		Naval Research Labs
		plus some Wallstreet firms

My list is biased towards the East Coast so I've probably left off
a few California companies.  So, can anyone lengthen this list?  I'm 
also looking for specific contacts at companies working in complex
systems.  I'll post a summary of the responses that I receive.

Btw, does anyone have any information on the new NEC Research
Lab in NJ?  I have heard that they are considering doing some work
in complex systems.  

Thanks.

kurt

-----------------------------------------------------------------------
Kurt Thearling                               1101 W. Springfield Avenue
University of Illinois                                Urbana, Il  61801
Coordinated Science Lab                          kurt@bach.csg.uiuc.edu 
-----------------------------------------------------------------------

From ca-Request@Think.COM  Wed Mar 21 09:42:50 1990
Received: by fafnir.think.com; Wed, 21 Mar 90 09:42:50 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Wed, 21 Mar 90 09:42:40 EST
Received: from cunyvm.cuny.edu by Think.COM; Wed, 21 Mar 90 09:44:08 -0500
Message-Id: <9003211444.AA29000@Think.COM>
Received: from GRPATVX1.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 0985; Wed, 21 Mar 90 09:42:35 EST
Date:    21 Mar 90 16:34:06 EDT
From: "Dionissis Theofilou _ CTI _ GR"   <THEOFIL%GRPATVX1.BITNET@CUNYVM.CUNY.EDU>
Subject:  ... Looking for a job
To: ca@Think.COM

Hi Networkers !

 I'm on the second year of computer engineering and i'm seeking for
a job (within Europe) in computers field for the summer period.
 Mostly for experience rather than money.

 If you know something, or anyone that could help me please send me
a personal mail at :

                          THEOFIL@GRPATVX1

         Any information highly appreciated

                                                   Thanks in advance

 Dionissis Theofilou
 University of Patras
 Computer Engineering
 Department - GREECE
-----------------------------------------------------------------------



From ca-Request@Think.COM  Wed Mar 21 18:00:49 1990
Received: by fafnir.think.com; Wed, 21 Mar 90 18:00:49 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Wed, 21 Mar 90 18:00:40 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Wed, 21 Mar 90 18:02:06 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA25310; Wed, 21 Mar 90 17:17:45 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 21 Mar 90 11:55:23 GMT
From: eru!luth!sunic!tut!router!opmvax!jhaataja@bloom-beacon.mit.edu
Subject: CAM simulators available, anywhere?
Message-Id: <85.26076bab@csc.fi>
To: ca@Think.COM

What kind of cellular automata machines (simulators) are available for
workstations (Sun, Iris, etc.), PC:s, Macintoshes, and Cray supercomputers?
I know this is a long list, but any info is appreciated. If you can 
include some kind of feature lists, contact information (where to buy or
get), or your own views on the matter, all the better.

We are mainly interested in using simulated CAM systems in a workstation
environment, modeling all kinds of phenomena (anything we can think of!)
- in the future we are interested in massively parallel systems as well.

Thanks in advance.

- Juha Haataja         (EARN: LK-JOH AT FINHUT)

From ca-Request@Think.COM  Thu Mar 22 16:51:05 1990
Received: by fafnir.think.com; Thu, 22 Mar 90 16:51:05 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Thu, 22 Mar 90 16:50:45 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Thu, 22 Mar 90 16:02:39 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA03443; Thu, 22 Mar 90 15:59:39 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 22 Mar 90 14:11:36 GMT
From: mcsun!ukc!stc!stl!irw@uunet.uu.net  (Ian Woollard)
Organization: STC Technology Limited, London Road, Harlow, Essex, UK
Subject: Re: Wireworld memory units
Message-Id: <2864@stl.stc.co.uk>
References: <9937@portia.Stanford.EDU>
To: ca@Think.COM

In article <9937@portia.Stanford.EDU> bugboy@portia.Stanford.EDU
 (Michael Frank) writes:
>Hi, I just started reading this group and noticed the wireworld discussion,
>and I wondered whether anyone had seen before a design that I came up with
>for a memory gate.  Here it is:
>
>...=.....
>...=.....
>..===....
>...=.....
>..=.=....
>..=.=....
>====.====
>..=......
>.........
>
                 >Description of operation removed<

That's neat! I like it! Small and perfectly formed...

I can't offer anything that small. However, I'd like to submit my entry for
the fastest IBI memory gate in the wireworld 'competition'...

The following is a negative going edge-triggered flip flop. (Using this
circuit, you can construct counters, dividers and things- though the
Transit time does pose a bit of a problem...)

...O.........
...=...===...
...=.===.==..
....=..=.=.=.
...===.===.=.
...=.=..=..=.
..==.===..=..
.=.===...=...
.=......=....
..======.....
.......=.=...
........===..
.....===.=.=.
....=......=.
.....=======.
...........I.
Transit: 21 (measured from entry of entry of a 'missing' electron)
IBI: 5
Size: 16x13

This is essentially made up of two parts:

A flip flop that toggles with every electron sent in:

...O.........
...=...===...
...=.===.==..
....=..=.=.=.
...===.===.=.
...=.=..=..=.
..==.===..=..
.=.===...=...
.=......=....
..======.....
.......I.....
Transit: 14
IBI: 5
Size: 11x13

This circuit is based on two exclusive-or gates back to back, giving a fast
IBI time.

And the edgifier circuit (left as an exercise to the reader to cut out!).
This emits an electron every time a stream of electrons stops entering it.

           __    o __.  ____    Ian Woollard        (0279) 29531 x2384
                <_(_/|_/ / <_   irw@stl.stc.co.uk   (STC Technology Ltd.)

Extremely long and witty saying reduced to a microdot --> .

From ca-Request@Think.COM  Tue Mar 27 13:13:55 1990
Received: by fafnir.think.com; Tue, 27 Mar 90 13:13:55 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Tue, 27 Mar 90 13:13:40 EST
Received: from smoke.brl.mil by Think.COM; Tue, 27 Mar 90 13:15:07 -0500
Date:     Tue, 27 Mar 90 12:43:45 EST
From: "Dr. William Jackson" <williamj@BRL.MIL>
To: CA@Think.COM
Cc: williamj@BRL.MIL
Subject:  Mailing List
Message-Id:  <9003271243.aa08137@SMOKE.BRL.MIL>

Please remove

  williamj@brl.mil

from the CA Mailing List.
Thank you.
  Sincerely, wj

From ca-Request@Think.COM  Wed Mar 28 20:27:16 1990
Received: by fafnir.think.com; Wed, 28 Mar 90 20:27:16 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Wed, 28 Mar 90 20:27:03 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Wed, 28 Mar 90 20:28:33 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA15619; Wed, 28 Mar 90 20:25:30 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 29 Mar 90 01:04:19 GMT
From: watson!jgsmith@tmc.edu  (James G. Smith)
Subject: Are you guys ready for the real world yet?
Message-Id: <402@gazette.bcm.tmc.edu>
To: ca@Think.COM


Now, before you get your flames warmed up, let me explain what I mean.  I'm
your basic naive but interested (read...very interested) observer waiting to
apply cellular automata theory (as well as network theory...ala neural network)
to my own particular problem...Immunology.  The more I learn, the more I'm 
looking at different kinds of cells chucking out different signals to their
neighbors, each of whom responds to those signals in their own wonderful way,
some of which responses include making new signals and also reproducing to 
make new signal generators, responders, and so on.  Some nighbors have to be
right there, but some can be far away.

My question is, has CA theory gone far enough to start trying to model
physiological cells?  (Maybe we need to know more about the cells...)
I'm going to start collecting a database of intercellular signals, producers,
and responders.  Eventually, I think, we're gonna need each other.  Any 
suggestions on what I'll need to know to produce something useful will be
cheerfully accepted.

*
(jgsmith@bcm.tmc.edu)

From ca-Request@Think.COM  Wed Mar 28 21:16:42 1990
Received: by fafnir.think.com; Wed, 28 Mar 90 21:16:42 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Wed, 28 Mar 90 21:16:27 EST
Received: from hplms2.hpl.hp.com by Think.COM; Wed, 28 Mar 90 21:17:52 -0500
Received: from hplpm.hpl.hp.com by hplms2.hpl.hp.com with SMTP
	(15.11.1.3/15.5+IOS 3.20) id AA00787; Wed, 28 Mar 90 18:17:47 pst
Received: from localhost by hplpm.hpl.hp.com with SMTP
	(15.11/15.5+IOS 3.14) id AA16600; Wed, 28 Mar 90 18:17:37 pst
Message-Id: <9003290217.AA16600@hplpm.hpl.hp.com>
To: watson!jgsmith@tmc.edu (James G. Smith)
Cc: ca@Think.COM
Subject: Re: Are you guys ready for the real world yet? 
In-Reply-To: Your message of "29 Mar 90 01:04:19 PST."
             <402@gazette.bcm.tmc.edu> 
Date: Wed, 28 Mar 90 18:17:32 PST
From: Peter Marvit <marvit@hplpm.hpl.hp.com>

Cal Tech has been using the GENESIS simulator for some time to model
"wet" neural networks.  They claim to be quite successful.  THey note
that their simulator is *not* good for the run-of-the-mill artificial
neural nets.  A cribbed description:

                           GENESIS
             (GEneral NEural SImulation System)
                             and
                            XODUS
    (X-windows Output and Display Utility for Simulations)

 This combined neural simulation system is now available for general
 distribution via FTP from Caltech.  The software was developed to support
 the simulation of neural systems ranging from complex models of single
 neurons to simulations of large networks made up of more abstract
 neuronal components.  For the last two years GENESIS has provided the
 basis for laboratory courses in neural simulation at both Caltech and the
 Marine Biological Laboratory in Woods Hole, MA.  Most current GENESIS
 applications involve realistic simulations of biological neural systems,
 however, it has also been used to model more abstract networks.  The
 system is not, however, a particularly efficient way to construct and run
 simple feedforward back propagation type simulations.  More information
 on the simulator and its interface can be obtained from an article by our
 group in last years NIPS proceedings.  (Wilson, M.A., Bhalla, U.S., Uhley,
 J.D., and Bower, J.M.  1989   GENESIS: A system for simulating neural
 networks. In:  Advances in Neural information processing systems.  D.
 Touretzky, editor. Morgan Kaufmann, San Mateo, CA. 485-492. ).  The
 interface will also be the subject of an oral presentation at the upcoming
 USENIX meeting in Washington D.C.

 GENESIS and XODUS are written in C and run on SUN and DEC graphics work
 stations under UNIX (version 4.0 and up), and X-windows (version 11).  The
 software requires 14 meg of disk space and the tar file is approximately 1
 meg.  Full source for the simulator is available via FTP from
 genesis.cns.caltech.edu (131.215.135.64).  To acquire FTP access to this
 machine it is necessary to first register for distribution by using telnet
 or rlogin to login under user "genesis" and then follow the instructions
 (e.g. 'telnet genesis.cns.caltech.edu' and ' login as 'genesis').  When
 necessary, tapes can be provided for a small handling fee ($50).  Those
 requiring tapes should send requests to genesis-req@caltech.bitnet.  Any
 other questions about the system or its distribution should also be sent to
 this address.

 The current distribution includes full source for both GENESIS and XODUS
 as well as three tutorial simulations (squid axon, multicell, visual
 cortex).  Documentation for these tutorials as well as three papers
 describing the structure of the simulator are also included.  As described in
 more detail in the "readme" file at the FTP address, those interested in
 developing new GENESIS applications are encouraged to become registered
 members of the GENESIS users group (BABEL) for an additional one time
 $200 registration fee.  As a registered user, one is provided
 documentation on the simulator itself (currently in an early stage),
 access to additional simulator components, bug report listings, and access
 to a user's bulletin board.  In addition we are establishing a depository for
 additional completed simulations.

 Finally, it should be noted that this software system, which currently
 consists of approximately 60,000 lines of code, and represents almost
 four years of programing effort, is being provided for general distribution
 as a public service to the neural network and computational neuroscience
 communities.  We make no claims as to the quality or functionality of this
 software for any purpose whatsoever and its release does not constitute a
 commitment on our part to provide support of any kind.

 [originally sent by Jim Bower, one of the authors at Cal Tech]

From ca-Request@Think.COM  Thu Mar 29 07:46:53 1990
Received: by fafnir.think.com; Thu, 29 Mar 90 07:46:53 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Thu, 29 Mar 90 07:46:40 EST
Received: from NSFNET-RELAY.AC.UK by Think.COM; Thu, 29 Mar 90 07:48:08 -0500
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK 
           via Janet with NIFTP  id aa14118; 29 Mar 90 13:20 BST
Via: ctcs.leeds.ac.uk (thrills.ARPA); Thu, 29 Mar 90 13:24:53 GMT
From: Turing Conference <turing%ctcs.leeds.ac.uk@NSFnet-Relay.AC.UK>
Date: Thu, 29 Mar 90 13:23:33 BST
Message-Id: <652.9003291223@ctcs.leeds.ac.uk>
To: CA@Think.COM
Subject: YOUR LAST CHANCE!!


___________________________________________________________________________


                                           Computer Studies and Philosophy,
                                                       University of Leeds,
                                                            LEEDS, LS2 9JT
                                                   Friday, 23rd March 1990


                     TURING 1990 - FINAL REMINDER

       I would be very grateful  if  you  could  bring  this  notice to the
attention  of  the  relevant  academic  staff  and  postgraduates  in  your
department,  as soon as possible.   It concerns a major conference which is
taking place in  Sussex University the week after next (starting on Tuesday
3rd April), and for  which  a limited number of places are still available. 
Because of the uniqueness of the  Conference,  and its magnificent range of
speakers,  we  are  taking  the  unusual step of  providing  a  last-minute
"reminder"  for anyone who may have  either  failed  to  see  our  previous
notices, or  forgotten to register in time.  We are keen to provide a final
opportunity for British  academics  and postgraduates who are interested in
computers and their philosophical significance,  since  it is very unlikely
that such an impressive list of speakers  in  this  subject  area  will  be
assembled on this side of the Atlantic for a long time to come (see below).

       Yours sincerely, and with many thanks,

                        Peter Millican

___________________________________________________________________________


                          INVITED GUEST SPEAKERS

ANDREW HODGES,  author of the much-acclaimed  biography  Alan  Turing:  the
Enigma of  Intelligence,  will  give the opening address at the Conference.
DONALD MICHIE and ROBIN GANDY, both of  whom  knew  Turing personally, will
present the first and last major papers.  Gandy is a prominent mathematical
logician,  while  Michie  is  very  well known in  artificial  intelligence
circles, as well as being chief  scientist  at  Glasgow's Turing Institute. 
The  two other invited British speakers are CHRISTOPHER PEACOCKE, Waynflete
Professor of  Philosophy at Oxford, and J.R. LUCAS, who will be speaking on
the topic of his famous and controversial paper "Minds, Machines and Godel"
in front of  an  audience  which will include some of his fiercest critics! 
One of these, DOUGLAS HOFSTADTER (Indiana), achieved fame with his Pulitzer
Prize winning book Godel, Escher, Bach, which did  much  to provoke general
interest in artificial intelligence.  Other major American visitors include
PAUL CHURCHLAND (California), perhaps the best known connectionist opponent
of folk-psychology; JOSEPH FORD (Georgia), a prominent advocate of  the new
and  exciting  theory  of chaos; CLARK GLYMOUR (Carnegie-Mellon), a notable
philosopher of science, and  last,  but  certainly not least, HERBERT SIMON
(Carnegie-Mellon), one of the founding fathers of the science of artificial
intelligence, and a Nobel laureate in 1978.


                            OTHER CONTRIBUTORS

Authors of the other 18  contributions  include  many  well-known  computer
scientists,  artificial  intelligence  researchers,  and  philosophers from
America, Australia and Europe as well  as  from  Britain.  Their names, and
the titles of their papers, are listed in the programme which follows.

___________________________________________________________________________


                TURING 1990 - LATE REGISTRATION INFORMATION


                                 VENUE

The Conference takes place at  the  University  of Sussex, Falmer, which is
about 4 miles from Brighton (the frequent trains  take about 8 minutes, and
the campus is barely 100 yards from Falmer station).   Registration is from
11 a.m. until 2 p.m. on Tuesday 3rd April at NORWICH HOUSE,  which is where
most  delegates  will  be accommodated.  Those arriving late should ask the
porter at Norwich House for registration materials unless they arrive after
he has gone off  duty,  in which case registration materials, keys etc. can
be collected from the permanent duty porter at the adjacent YORK HOUSE.


                        FIRST AND LAST AFTERNOONS

The Conference opens at 2 p.m.  on Tuesday, with a lecture by Andrew Hodges
in ARTS A2.  This will be followed by coffee at 3.00, and a paper by Donald
Michie (also in Arts A2) at 3.30.   Dinner  is  from 5.00 until 6.30 in the
Refectory,  Level 2,  with a wine reception in the Grapevine Bar (Refectory
building) from 6.00 until 8.00, when Clark Glymour will speak in Arts A2.

On Friday 6th April, Lunch  is from 12.00 p.m. until 2.00, when Robin Gandy
will give the closing speech.  Coffee at 3.30 marks the official end of the
Conference, although at 4.00 Douglas Hofstadter  will  give  an  additional
open lecture entitled "Hiroshima Ma Mignonne".  Dinner on Friday evening is
available for those who require it (at a cost of #6.00).


                   REGISTRATION AND ACCOMMODATION COSTS

For members of the Mind Association  or  the Aristotelian Society, and also
subscribers to Analysis or Philosophical Quarterly, the registration fee is
only #30, thanks to the generous support  which we are receiving from these
bodies.   The  registration fee for students is likewise  #30.   For  other
academics the fee is #50, while for non-academics the fee is #80.

Full board including bed, breakfast  and  all  meals (with the exception of
Thursday evening) from Dinner on Tuesday to Lunch  on  Friday,  costs  #84. 
For  those  wanting these meals alone (and not bed and breakfast), the cost
is #33.  On  Thursday  evening  the  Conference Banquet  takes place at the
Royal Pavilion in Brighton (for  which  we charge only the marginal cost of
#25), but for those not attending the  Banquet,  dinner is available in the
University at a cost of #6.  Please note that  places  at  the  Banquet are
strictly limited, and will be filled on a first come-first served basis.


                          HOW TO REGISTER LATE

Those who wish to book  accommodation for the Conference should ring Judith
Dennison at Sussex University (0273-678379) immediately,  and if she is not
available, should leave on her answerphone full  details  of their meal and
accommodation  requirements, together with A TELEPHONE NUMBER AT WHICH THEY
CAN BE CONTACTED.  Those  who  telephone  by 2.00 p.m. ON FRIDAY 30th MARCH
can probably be guaranteed accommodation  within the University (though not
necessarily in Norwich House), and you are  asked  to meet this deadline if
at all possible (assuming that you are able  to  catch  the  Friday  postal
collection, please also send your cheque and written requirements, by first
class mail, to the address below).  During the following weekend Andy Clark
(0273-722942)  will  be  able  to provide some information on the number of
places remaining, and on Monday  Judith Dennison will do her best to fit in
those who have left their name  in  the  meantime.   Those  who  arrive  on
Tuesday without having booked do so, of course, at their own risk!

CHEQUES AND WRITTEN REQUIREMENTS TO:  Judith Dennison,  School of Cognitive
and Computing Sciences, University of Sussex, Brighton, BN1 9QN (please use
first class post, and do not include cheques if posted after 30th March).


PJRM/23rd March 1990


____________________________________________________________________________

                           TURING 1990 COLLOQUIUM

               At the University of Sussex, Brighton, England

                            3rd - 6th April 1990

                PROGRAMME OF SPEAKERS AND GENERAL INFORMATION

____________________________________________________________________________


                              INVITED SPEAKERS


Paul CHURCHLAND (Philosophy, University of California at San Diego)

       FURTHER THOUGHTS ON LEARNING AND CONCEPTUAL CHANGE


Joseph FORD (Physics, Georgia Institute of Technology)

       CHAOS :  ITS PAST, ITS PRESENT, BUT MOSTLY ITS FUTURE


Robin GANDY (Mathematical Institute, Oxford)

       HUMAN VERSUS MECHANICAL INTELLIGENCE


Clark GLYMOUR (Philosophy, Carnegie-Mellon)

       COMPUTABILITY, CONCEPTUAL REVOLUTIONS AND THE LOGIC OF DISCOVERY


Andrew HODGES (Oxford, author of "Alan Turing: the enigma of intelligence")

       BACK TO THE FUTURE :  ALAN TURING IN 1950


Douglas HOFSTADTER (Computer Science, Indiana)

       MENTAL FLUIDITY AND CREATIVITY


J.R. LUCAS (Merton College, Oxford)

       MINDS, MACHINES AND GODEL :  A RETROSPECT


Donald MICHIE (Turing Institute, Glasgow)

       MACHINE INTELLIGENCE - TURING AND AFTER


Christopher PEACOCKE (Magdalen College, Oxford)

       PHILOSOPHICAL AND PSYCHOLOGICAL THEORIES OF CONCEPTS


Herbert SIMON (Computer Science and Psychology, Carnegie-Mellon)

       MACHINE AS MIND

____________________________________________________________________________


                              OTHER SPEAKERS


Most of the papers to be given at the Colloquium are interdisciplinary,  and
should hold considerable interest for those working in any area of Cognitive
Science or related disciplines.   However the papers below will be presented
in paired parallel sessions,  which have been arranged as far as possible to
minimise clashes of subject area,  so  that  those  who  have  predominantly
formal  interests,   for  example,  will be able to attend all of the papers
which are most relevant to their work, and a similar point applies for those
with mainly philosophical, psychological, or purely computational interests.


Jonathan Cohen (The Queen's College, Oxford)
     "Does Belief Exist?"

Mario Compiani (ENIDATA, Bologna, Italy)
     "Remarks on the Paradigms of Connectionism"

Martin Davies (Philosophy, Birkbeck College, London)
     "Facing up to Eliminativism"

Chris Fields (Computing Research Laboratory, New Mexico)
     "Measurement and Computational Description"

Robert French (Center for Research on Concepts and Cognition, Indiana)
     "Subcognition and the Limits of the Turing Test"

Beatrice de Gelder (Psychology and Philosophy, Tilburg, Netherlands)
     "Cognitive Science is Philosophy of Science Writ Small"

Peter Mott (Computer Studies and Philosophy, Leeds)
     "A Grammar Based Approach to Commonsense Reasoning"

Aaron Sloman (Cognitive and Computing Sciences, Sussex)
     "Beyond Turing Equivalence"

Antony Galton (Computer Science, Exeter)
     "The Church-Turing Thesis: its Nature and Status"

Ajit Narayanan (Computer Science, Exeter)
     "The Intentional Stance and the Imitation Game"

Jon Oberlander and Peter Dayan (Centre for Cognitive Science, Edinburgh)
     "Altered States and Virtual Beliefs"

Philip Pettit and Frank Jackson (Social Sciences Research, ANU, Canberra)
     "Causation in the Philosophy of Mind"

Ian Pratt (Computer Science, Manchester)
     "Encoding Psychological Knowledge"

Joop Schopman and Aziz Shawky (Philosophy, Utrecht, Netherlands)
     "Remarks on the Impact of Connectionism on our Thinking about Concepts"

Murray Shanahan (Computing, Imperial College London)
     "Folk Psychology and Naive Physics"

Iain Stewart (Computing Laboratory, Newcastle)
     "The Demise of the Turing Machine in Complexity Theory"

Chris Thornton (Artificial Intelligence, Edinburgh)
     "Why Concept Learning is a Good Idea"

Blay Whitby (Cognitive and Computing Sciences, Sussex)
     "The Turing Test: AI's Biggest Blind Alley?"

____________________________________________________________________________


                           TURING 1990 COLLOQUIUM

               At the University of Sussex, Brighton, England

                            3rd - 6th April 1990


This Conference commemorates the 40th anniversary of the publication in Mind
of Alan Turing's influential paper  "Computing  Machinery and Intelligence". 
It  is hosted by the School of  Cognitive  and  Computing  Sciences  at  the
University of  Sussex  and  held under the auspices of the Mind Association.
Additional  support  has been received  from  the  Analysis  Committee,  the
Aristotelian Society, The  British Logic Colloquium, The International Union
of History and Philosophy  of  Science, POPLOG, Philosophical Quarterly, and
the SERC Logic for IT Initiative.

The aim of the Conference  is to draw together people working in Philosophy,
Logic,  Computer  Science,  Artificial Intelligence, Cognitive  Science  and
related fields, in order  to  celebrate  the  intellectual and technological
developments which owe so much to Turing's seminal  thought.  Papers will be
presented  on  the  following  themes:  Alan  Turing  and the  emergence  of
Artificial Intelligence,  Logic and the Theory of Computation,  The  Church-
Turing  Thesis, The Turing Test, Connectionism, Mind and Content, Philosophy
and Methodology of Artificial Intelligence and Cognitive Science.    Invited
talks  will be  given by  Paul Churchland, Joseph Ford,  Robin Gandy,  Clark
Glymour,  Andrew Hodges,   Douglas Hofstadter,  J.R. Lucas,   Donald Michie,
Christopher Peacocke and Herbert Simon, and there  are  many other prominent
contributors, whose names and papers are listed above.

The conference will start after  lunch  on  Tuesday  3rd April 1990, and it
will end on Friday 6th April after tea.  ANYONE  WISHING  TO  REGISTER  FOR
THIS CONFERENCE SHOULD SEE THE LATE REGISTRATION INFORMATION ABOVE.


                     Conference Organizing Committee

     Andy Clark (Cognitive and Computing Sciences, Sussex University)
     David Holdcroft (Philosophy, Leeds University)
     Peter Millican (Computer Studies and Philosophy, Leeds University)
     Steve Torrance (Information Systems, Middlesex Polytechnic)

___________________________________________________________________________


PLEASE SEND ON THIS NOTICE to any researchers,  lecturers or students in the 
fields  of  Artificial Intelligence,  Cognitive  Science,  Computer Science,
Logic, Mathematics, Philosophy or Psychology, in Britain  or  abroad, and to
ANY APPROPRIATE BULLETIN BOARDS which have not previously displayed it.


From ca-Request@Think.COM  Thu Mar 29 20:28:23 1990
Received: by fafnir.think.com; Thu, 29 Mar 90 20:28:23 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Thu, 29 Mar 90 20:28:14 EST
Received: from uunet.UU.NET by Think.COM; Thu, 29 Mar 90 20:29:44 -0500
Received: from acad.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA13923; Thu, 29 Mar 90 20:27:49 -0500
Received: from megalon.acad.com by acad.uucp  (3.2/SMI-3.2)
	id AA16109; Thu, 29 Mar 90 17:13:10 PST
Received: by megalon.acad.com (3.2/SMI-3.2)
	id AA07136; Thu, 29 Mar 90 17:13:09 PST
Date: Thu, 29 Mar 90 17:13:09 PST
From: acad!megalon!rudy@uunet.UU.NET (Rudy Rucker)
Message-Id: <9003300113.AA07136@megalon.acad.com>
To: ca@Think.COM
Subject: real world


I'd love some real cell data.  Using owncode rules, the CA Lab PC package
can be tailored to utilize any kind of connectivity.  I'm very interested in
exploiting this; as long as all CAs look only at nearest neighbors, the
rules are perhaps too stereotypical.  Changing connectivity using perhaps
a neural net style humongo matrix might be nice.  You tell me the rule
you want implemented jgsmith, or tell all of us that is, and I'm sure it
can be brought online in either CA Lab or CelSim.



From ca-Request@Think.COM  Thu Mar 29 22:26:52 1990
Received: by fafnir.think.com; Thu, 29 Mar 90 22:26:52 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Thu, 29 Mar 90 22:26:40 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Thu, 29 Mar 90 22:28:11 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA17026; Thu, 29 Mar 90 21:35:12 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 29 Mar 90 13:54:12 GMT
From: mcsun!ukc!acorn!daemon@uunet.uu.net
Subject: LIFE algorithm
Message-Id: <2057@acorn.co.uk>
To: ca@Think.COM

In article <2245@osc.COM>, jgk@osc.COM (Joe Keane) writes:

> [A LIFE] algorithm by Gosper uses a quad-tree representation and a good
> deal of caching to speed things up more.

Can anyone give me a reference to this algorithm, please?

David Seal                           dseal@acorn.co.uk
Acorn Computers Ltd.,
Fulbourn Road,
Cambridge CB1 4JN,
U.K.

<include standard disclaimers>

From ca-Request@Think.COM  Thu Mar 29 22:27:05 1990
Received: by fafnir.think.com; Thu, 29 Mar 90 22:27:05 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Thu, 29 Mar 90 22:26:52 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Thu, 29 Mar 90 22:28:22 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA17040; Thu, 29 Mar 90 21:35:44 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 30 Mar 90 01:13:09 GMT
From: megalon.UUCP!rudy@bloom-beacon.mit.edu  (Rudy Rucker)
Organization: The Internet
Subject: real world
Message-Id: <9003300113.AA07136@megalon.acad.com>
To: ca@Think.COM


I'd love some real cell data.  Using owncode rules, the CA Lab PC package
can be tailored to utilize any kind of connectivity.  I'm very interested in
exploiting this; as long as all CAs look only at nearest neighbors, the
rules are perhaps too stereotypical.  Changing connectivity using perhaps
a neural net style humongo matrix might be nice.  You tell me the rule
you want implemented jgsmith, or tell all of us that is, and I'm sure it
can be brought online in either CA Lab or CelSim.



From ca-Request@Think.COM  Sat Mar 31 18:59:21 1990
Received: by fafnir.think.com; Sat, 31 Mar 90 18:59:21 EST
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Sat, 31 Mar 90 18:59:12 EST
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Sat, 31 Mar 90 19:00:45 -0500
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA17691; Sat, 31 Mar 90 18:47:43 EST
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 31 Mar 90 23:45:20 GMT
From: snorkelwacker!usc!zaphod.mps.ohio-state.edu!rpi!hiebeler@bloom-beacon.mit.edu  (Dave Hiebeler)
Organization: RPI CS Dept, and LANL Center for Nonlinear Studies
Subject: CMs, CAMs, etc
Message-Id: <F#J#SZ_@rpi.edu>
To: ca@Think.COM


  There has been some discussion recently on alt.fractals and
comp.arch about the Connection Machine, how fast it is for
various things, how easy it is to use, and so on.  I've added
comp.theory.cell-automata (and will send a copy to comp.parallel) as
well, since this topic has more than a little relevance to those
groups too.  Please try to restrict follow-up articles to the most
appropriate group(s) only, although these topics do span many
disciplines.

  I'd like to point out a good recent article about the CM, and also
mention some comments by Toffoli and Margolus on the generality of
various types of computers.

  First, I'd like to mention that there is an article
"Computational Physics on the Connection Machine" by Bruce Boghosian,
in the Jan/Feb 1990 issue of "Computers in Physics".  It's a good
overview of the CM, but unlike earlier articles of that type, Bruce
makes some comments about the CM based on his own and other people's
opinions, over the past few years of using the machine.

  In addition to the quick intro to the machine, he talks about how
some of the software primitives on the CM correlate to basic
mathematical operations.  He describes several example applications
that people have used the CM for, and how to avoid some potential
problems in adapting a simulation to the CM (such as deciding what
type of geometry to use, and how to implement different kinds of
boundary conditions).

  He also mentions why it is often *easier* to implement a simulation
on the CM than on traditional machines.  Overall, the article is
definitely worth checking out.

				 ****

  Someone mentioned in a previous article that the CM isn't
good at being used as a "general purpose processor", that it's only
"good for solving certain kinds of problems, not all computable
problems".  This is an important thing to say, but I think it is
very misleading.

  Toffoli (either in one of his articles with Margolus, or in a
presentation at the CA conference, I don't remember which) discussed
this issue as it relates to CAMs (Cellular Automata Machines).  I
think it applies equally to the CM.  Basically, his belief (as I
understand it) is that a CAM is just as general-purpose as a
traditional-architecture computer, but that it is centered on a
different class of applications.  That is, you can make a
computation-universal cellular automaton, so in principle you could
lay out a Sun in a cellular automaton array, and simulate it on a CAM
(or the CM).  It would be *very* inefficient, however.  Similarly, you
can run cellular automata based physics simulations on a Sun, but it
is *also* very inefficient.

  The point of it all is that neither architecture is any more
"general purpose" than the other; they are just centered on different
areas, and do well on different things.  Since CAMs and CMs are pretty
new, right now we have many applications for traditional machines but
not as many for the new machines.  As time goes on, that will change.
It would be foolish to continue to run cellular automata simulations
(and many other computational physics applications) on traditional
architectures; it would simply be a waste of resources.  In my
opinion, this is a *very* important topic.  See Boghosian's article as
well; he does mention why supercomputers (even vector machines such as
Crays) won't pass the teraflops barrier, but massively parallel
machines such as the CM (and cellular automata based machines, such as
the CAMs) will be able to.

  While I'm at it, another good article to check out is:
     "Cellular Automata Machines", by Margolus and Toffoli,
     in the book Lattice Gas Methods for Partial Differential Equations,
     editors Doolen et. al., Addision-Wesley, 1990.
  It discusses the architecure of CAM-8, as they envisioned it in
mid-1989 or so.  (The final CAM-8 may of course differ from the
article, as changes may be decided upon as they get farther along in
implementing it).

  The Lattice Gas PDE book is a good book to have on your shelf
anyway, and the paperback version only costs about $25.

  All opinions expressed in this article are my own; my employers may
or may not agree with any of it.
-- 
Dave Hiebeler / Computer Science Dept. / Amos Eaton Bldg. /
Rensselaer Polytechnic Institute / Troy, NY 12180-3590 USA
Internet (preferred): hiebeler@turing.cs.rpi.edu   Bitnet: userF3JL@rpitsmts
"Off we go, into the wilds you ponder..."

From ca-Request@Think.COM  Sun Apr  1 03:41:08 1990
Received: by fafnir.think.com; Sun, 1 Apr 90 03:41:08 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Sun, 1 Apr 90 03:40:47 EDT
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Sun, 1 Apr 90 04:00:49 -0400
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA07376; Sun, 1 Apr 90 03:54:58 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 1 Apr 90 07:52:12 GMT
From: barmar@Think.COM  (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge MA, USA
Subject: Re: CMs, CAMs, etc
Message-Id: <35186@think.Think.COM>
References: <F#J#SZ_@rpi.edu>
To: ca@Think.COM

In article <F#J#SZ_@rpi.edu> hiebeler@cs.rpi.edu (Dave Hiebeler) writes:
>  Someone mentioned in a previous article that the CM isn't
>good at being used as a "general purpose processor", that it's only
>"good for solving certain kinds of problems, not all computable
>problems".
...
>  The point of it all is that neither architecture is any more
>"general purpose" than the other; they are just centered on different
>areas, and do well on different things.

What do you think "general purpose" means?  To me, a general purpose
machine is one that can run most common programs reasonably well.  What you
described in your article (in the section I edited out) is that cellular
automata and the CM are Turing-equivalent with conventional serial
computers; by this definition, almost all computers are "general purpose".
Since the CM is only well suited for a small (but important) class of
problems (those with a large number of data elements that are all processed
very similarly) it does not seem reasonable to call it "general purpose".
It would be a pretty poor system to run a text editor on, for instance, and
wouldn't be good as an interactive user machine.  It could probably run a
really fast grep, though; I also recall some old papers about the
application of data parallelism to parsing, so it might make a good
compiler processor (I'm can also imagine code generation where each virtual
processor generates code for a quad, and peephole optimization makes use of
communication among neighbors).
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

From ca-Request@Think.COM  Sun Apr  1 23:27:50 1990
Received: by fafnir.think.com; Sun, 1 Apr 90 23:27:50 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Sun, 1 Apr 90 23:27:39 EDT
Received: from saqqara.cis.ohio-state.edu by Think.COM; Sun, 1 Apr 90 23:29:11 -0400
Received: by saqqara.cis.ohio-state.edu (5.61-kk/5.900329)
	id AA10319; Sun, 1 Apr 90 23:28:32 -0400
Date: 01 Apr 90 23:07:09 EDT
From: Elan Moritz <71620.3203@CompuServe.COM>
To: <ca@Think.COM>
Subject: Call for Papers
Message-Id: <"900402030708 71620.3203 EHE97-1"@CompuServe.COM>

please post and distribute to investigators of:
========================== 

        * human and machine intelligence
        * knowledge systems
        * computational linguistics
        * natural languages
        * theoretical biology
        * population genetics
        * ethology / cultural ecology
        * information storage and transfer
        * learning and teaching systems
        * philosophy of knowledge
        * philosophy and history of science

 
        ++++++++++++++++++++++++++++++++++++++++++++++++++

                        NEW JOURNAL ANNOUNCEMENT

                                   &

                            CALL FOR PAPERS

                         ......................
                         .                    .
                         .  JOURNAL of IDEAS  .
                         ......................



         IMR, BOX 16327, PANAMA CITY, FLORIDA 32406, USA

        ++++++++++++++++++++++++++++++++++++++++++++++++++


     The Institute for Memetic Research [IMR] is publishing a new journal
called 'Journal of Ideas'. The main purpose of the journal is to provide an 
archival forum for discussion of the genesis, evolution, competition and death 
of 'ideas' and 'memes'. The term 'idea' is one that requires careful 
discussion. The original term 'meme' [pronounced: meem] is a conceptual
construct introduced by Richard Dawkins to describe units of cultural
transmission  and imitation. IMR uses the term 'meme' as a point of departure
for an area we call 'Memetic Science'. Ultimately, 'meme' requires further
definition and clarification. The primary thesis of Memetic Science is that
'ideas' and 'memes'  are entities that are functionally similar to biological
genes in their ability to replicate, mutate, and undergo natural selection.
What are  sought in Memetic Science are: rigorous quantitative foundations, 
theory, and experimental methodology and measurements. 

     The history of the study  of 'ideas'-as-entities-by-themselves is ancient. 
philosophers, we have a variety of qualitative theories and speculations.
Logic theory, philology, modern linguistics, and computer oriented
technologies, have provided a start in the area of understanding structures,
grammars, and truth conditions of sentences and small collections of 
sentences. Population geneticists and biologists have provided initial models 
for spread of 'cultural' constructs. These models incorporate the techniques
of dominant/recessive allele spreading in  genetic pools and epidemiological
approaches. Some models use compound constructs of 'gene + culture' elements
as the particulate elements that replicate and propagate. While the 
contributions from these diverse disciplines are useful, there are needs for
systematic, robust and, most importantly, quantitative approaches.

     Present day applications of Memetic Science include both human aspects
of replication, mutation, competition, spread and death of ideas and memes, as 
well as their electronic analogs. The 'electronic memes' are beneficial 
messages, reusable subroutines, programs that are freely [or surreptitiously]
copied and modified, computer viruses, worms, trojan horses, etc. 


     To address the needs stated above the Institute for Memetic Research
is launching the Journal of Ideas (first issue printing, September 1990).
The detailed statement of scope, pivotal references, subscription information,
and instruction for authors is available upon written request from:

        Elan Moritz, Editor
        Journal of Ideas
        The Institute for Memetic Research
        Box 16327
        Panama City, Florida  32406, USA


        email address:    INTERNET: 71620.3203@compuserve.com
        or                    INET: 71620.3203@compuserve.com

     The Journal of Ideas will appear [initially] quarterly, and will
contain the following reqular sections:

1) Invited papers, 2) Research Contributions, 3) Rapid Publications
and 4) Discussion of persistence and spread of existing 'Major Ideas'.


Only previously unpublished papers will be accepted.

Page charges for invited papers will be waived.

Brevity, and jargon accessible to interdisciplinary researchers are encouraged.

Standard transfer of copyrights is required prior to printing.
    
     To encourage participation and discussion of this new area, IMR/JoI will 
experiment with two categories of papers. One category will be  strictly
reviewed and refereed, while another will be reviewed by the editor but not 
refereed. Non-refereed papers will be so marked; they will have the advantages 
of rapid publication and possible disadvantages of archival of errors.

      To expedite processing, authors can immediately submit papers prepared
according to a standard professional society [e.g. IEEE, AIP, APS] journal
manuscript format. Three copies are required. On an experimental basis, authors
who would like to submit papers for rapid publication using email may submit 
papers using the internet address [INTERNET: 71620.3203@compuserve.com]. These
papers should consist of ASCII text only, with equations built up carefully
using ASCII text. Papers submitted through email should be followed up by 
submitting a written version via regular postal channels.
 

      Readers of this message are encouraged to suggest topics and individuals
[including themselves] to be considered for invited papers.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


                PLEASE POST:    CALL FOR PAPERS


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 


                                   


From ca-Request@Think.COM  Tue Apr  3 17:00:56 1990
Received: by fafnir.think.com; Tue, 3 Apr 90 17:00:56 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Tue, 3 Apr 90 17:00:45 EDT
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Tue, 3 Apr 90 17:04:49 -0400
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA07436; Tue, 3 Apr 90 16:36:35 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 3 Apr 90 00:08:06 GMT
From: tektronix!reed!trost@bloom-beacon.mit.edu  (Bill Trost,Box 607,ext 640,)
Subject: "General purpose" (was: CMs, CAMs, etc)
Message-Id: <14598@reed.UUCP>
References: <F#J#SZ_@rpi.edu>, <35186@think.Think.COM>
To: ca@Think.COM

barmar@think.com (Barry Margolin) writes:
>hiebeler@cs.rpi.edu (Dave Hiebeler) writes:
>>  The point of it all is that neither architecture is any more
>>"general purpose" than the other; they are just centered on different
>>areas, and do well on different things.
>
>What do you think "general purpose" means?  To me, a general purpose
>machine is one that can run most common programs reasonably well.

But a program becomes common because it is run reasonably well on
common machines.  Less common program don't run as well, so they get
used less often, and become less common.

[I'm trying to come up with the right cliche for this --- "chicken and
egg" comes to mind....]

In any event, my suspicion is that, if a cellular automata had come
into vogue before the serial CPU had become popular, we might have a
totally different notion of what a "common program" is.

And I betcha I could get a decent text editor on a CA --- though
saving files might be a bit slow....   :-)

Then again, disks would be different, too....

From ca-Request@Think.COM  Wed Apr  4 18:47:33 1990
Received: by fafnir.think.com; Wed, 4 Apr 90 18:47:33 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Wed, 4 Apr 90 18:47:16 EDT
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Wed, 4 Apr 90 18:51:20 -0400
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA05171; Wed, 4 Apr 90 17:57:42 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 3 Apr 90 22:48:04 GMT
From: mintaka!ogicse!uwm.edu!rpi!zaphod.mps.ohio-state.edu!hp-sdd!ncr-sd!ncrcae!usceast!park@bloom-beacon.mit.edu  (Kihong Park)
Organization: University of South Carolina, Columbia
Subject: Re: "General purpose" (was: CMs, CAMs, etc)
Message-Id: <3176@usceast.UUCP>
References: <F#J#SZ_@rpi.edu>, <35186@think.Think.COM>, <14598@reed.UUCP>
To: ca@Think.COM

In article <14598@reed.UUCP> trost@reed.bitnet (Bill Trost,Box 607,ext 640,) writes:

>In any event, my suspicion is that, if a cellular automata had come
>into vogue before the serial CPU had become popular, we might have a
>totally different notion of what a "common program" is.

Well, in some sense you are correct since in the search for more speed,
parallelization seems to be the way to go. Thus, conventional serial programs
are being rewritten to run on multi-processor machines. Maybe if we had
been given parallel machines in the 50's and 60's(by some great power?),
we would have a better understanding and array of techniques to construct
parallel programs.

But there is another aspect which is in a qualitative sense 
different from the above. Cellular automata are known to be equivalent in
power(language recognition) to Turing machines. But this doesn't say very
much about the behavior of its subclasses which are not universal machines, or
which do not belong to class IV(Wolfram).

Given certain CA-rules, how can we deal with their behavior in an analytic
fashion without always having to simulate the processes explicitly? These are
the kinds of problems which are being addressed, and which one has to
understand at a deeper level. This is very different from "programming".

Serial programming, or for that matter parallel programming, are mental
strategies that we employ to solve problems. We can just use the term algorithm
for that. This notion of solving problems in a step by step fashion by
decomposing it into smaller ones(using recursion etc.) is something that
comes very "natural" to humans. It existed a long time ago independent of
the advent of computing machines. 

Hence, in some way, serial machines without too much push became THE substrate
of computation. CAs are not just multi-processor machines. They have something
which makes man tread on unfamiliar grounds. To apply the same notion of
algorithmic problem solving to CAs, and using this as a criterion of
evaluation is okay, but I think then one is missing a whole new paradigm
of viewing systems and their computation.

Kihong Park. (park@.cs.scarolina.edu)

From ca-Request@Think.COM  Wed Apr  4 19:48:24 1990
Received: by fafnir.think.com; Wed, 4 Apr 90 19:48:24 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Wed, 4 Apr 90 19:48:15 EDT
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Wed, 4 Apr 90 19:52:21 -0400
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA07522; Wed, 4 Apr 90 19:28:53 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 4 Apr 90 07:34:30 GMT
From: mintaka!ogicse!uwm.edu!rpi!hiebeler@bloom-beacon.mit.edu  (Dave Hiebeler)
Organization: RPI CS Dept, and LANL Center for Nonlinear Studies
Subject: Re: "General purpose" (was: CMs, CAMs, etc)
Message-Id: <=8K#YY&@rpi.edu>
References: <3176@usceast.UUCP>
To: ca@Think.COM

In article <3176@usceast.UUCP> park@usceast.UUCP (Kihong Park) writes:

> Given certain CA-rules, how can we deal with their behavior in an analytic
> fashion without always having to simulate the processes explicitly?
> This is very different from "programming".

  Indeed.  Of course, there has been much work done with statistical
approaches to CA behavior, which seems like a good way to go.  And
Norm Packard did some work where he evolved CA rules to solve a
specific problem (counting active cells in a 1-D array, I believe),
so he developed a CA "algorithm" to solve that problem.  (Yes, I know
I may be abusing some terms when I say that).

  Chris Langton recently proposed in a paper of his that perhaps what
is needed here is some way to augment statistical mechanics with
theory of computation; essentially to combine the two approaches.
This sounds like a great idea, but I don't think I have a deep enough
understanding of either area to see how they might be combined.  Does
anyone here think they might have some ideas about how to begin to
make that connection?

-- 
Dave Hiebeler / Computer Science Dept. / Amos Eaton Bldg. /
Rensselaer Polytechnic Institute / Troy, NY 12180-3590 USA
Internet (preferred): hiebeler@turing.cs.rpi.edu   Bitnet: userF3JL@rpitsmts
"Off we go, into the wilds you ponder..."

From ca-Request@Think.COM  Thu Apr  5 12:03:23 1990
Received: by fafnir.think.com; Thu, 5 Apr 90 12:03:23 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Thu, 5 Apr 90 12:03:14 EDT
Received: from MIRACLE.EDRC.CMU.EDU by Think.COM; Thu, 5 Apr 90 12:07:15 -0400
Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.MIRACLE.EDRC.CMU.EDU.sun3.35
          via MS.5.6.MIRACLE.EDRC.CMU.EDU.sun3_35;
          Thu,  5 Apr 90 12:06:04 -0400 (EDT)
Message-Id: <sa6qngW00hMNFCXnMm@cs.cmu.edu>
Date: Thu,  5 Apr 90 12:06:04 -0400 (EDT)
From: Daniel.Stodolsky@CS.CMU.EDU
To: ca@Think.COM
Subject: remove me 

Please delete me from this mailing list.

Thanks,
              Daniel Stodolsky
               Carnegie Mellon University

From ca-Request@Think.COM  Fri Apr  6 14:13:29 1990
Received: by fafnir.think.com; Fri, 6 Apr 90 14:13:29 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Fri, 6 Apr 90 14:13:18 EDT
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Fri, 6 Apr 90 14:17:17 -0400
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA21707; Thu, 5 Apr 90 03:53:39 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 3 Apr 90 11:23:54 GMT
From: munnari.oz.au!csc!csc3!arp!anucsd!neccan!peter@uunet.uu.net  (Peter Miller)
Organization: NEC Information Systems Australia, Canberra
Subject: period 26 Life oscillator - was it ever posted?
Message-Id: <681@neccan.oz>
To: ca@Think.COM

A while back someone mentioned they had a new period 26
Life oscillator.  What it ever posted?
I would sure like to see it.

Regards
Peter Miller       UUCP    {uunet,mcvax,ukc}!munnari!neccan.oz!pmiller
                   ARPA    pmiller%neccan.oz@uunet.uu.net
/\/\*              CSNET   pmiller%neccan.oz@australia
                   ACSnet  pmiller@neccan.oz
Disclaimer?  These guys have no idea what I am on about!
D

From ca-Request@Think.COM  Fri Apr  6 14:24:05 1990
Received: by fafnir.think.com; Fri, 6 Apr 90 14:24:05 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Fri, 6 Apr 90 14:23:48 EDT
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Fri, 6 Apr 90 14:27:50 -0400
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA03108; Thu, 5 Apr 90 11:19:40 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 5 Apr 90 04:07:18 GMT
From: tektronix!reed!trost@bloom-beacon.mit.edu  (Bill Trost,Box 607,ext 640,)
Subject: Re: von Neumann reference request
Message-Id: <14631@reed.UUCP>
References: <3129@castle.ed.ac.uk>
To: ca@Think.COM

Will this do?  It came from the college's library catalog.

AUTHOR          Von Neumann, John, 1903-1957.
TITLE           Theory of self-reproducing automata. Edited and completed by
                 Arthur W. Burks.
PUBLICATION     Urbana, University of Illinois Press, 1966.
DESCRIPTION     xix, 388 p. illus. 24 cm.
NOTES           Bibliography: p. 297-302.
SUBJECTS        1. Machine theory.
OTHER HEADINGS  I. Burks, Arthur W. (Arthur Walter), 1915- II.
                 Self-reproducing automata.

CALL NUMBER     QA267 .V55

From ca-Request@Think.COM  Fri Apr  6 14:51:55 1990
Received: by fafnir.think.com; Fri, 6 Apr 90 14:51:55 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Fri, 6 Apr 90 14:51:35 EDT
Received: from uunet.UU.NET by Think.COM; Fri, 6 Apr 90 14:54:40 -0400
Received: from acad.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA13797; Fri, 6 Apr 90 14:54:16 -0400
Received: from megalon.acad.com by acad.uucp  (3.2/SMI-3.2)
	id AA04820; Fri, 6 Apr 90 11:13:26 PDT
Received: by megalon.acad.com (3.2/SMI-3.2)
	id AA10018; Fri, 6 Apr 90 11:13:18 PDT
Date: Fri, 6 Apr 90 11:13:18 PDT
From: acad!megalon!rudy@uunet.UU.NET (Rudy Rucker)
Message-Id: <9004061813.AA10018@megalon.acad.com>
To: ca@Think.COM
Subject: general purpose
Cc: megalon!rudy@uunet.UU.NET, megalon!tech@uunet.UU.NET,
        uunet!bronze.ucs.indiana!efreeman@uunet.UU.NET


im sure everyone has heard of thomas kuhns structure of scientific revolution,
and his concept that revolutions in science are preceeded or accompanied by
paradigm shifts.  i think that with cas neural nets and for that matter fractals
we are seeing a paradigm shift about what is a computation.  the fact that
the different types are mutually simulable is distant and abstract.  in practice
writing a ca rule program is entirely different from writing a serial program
( such as eg the serial program you have to write to make a universal ca
simulator such as calab or cellsim ).  there is much more of a casual
"let's see what develops" programming mystique for cas.  if you don't like
the way the rule looks you go back in and tweak things.  but even dumb
mistakes and oversights can and will produce sometimes interesting outputs.
serial programming environment is much more harsh, for there a mistake will
generally produce uncompilable code or mystery crashes.  

in some ways cas are too rigid, and i think the next thing that we want to
do (besides 3D and 4D) is to have alife (artificial life) ca environments
in which agents live upon a ca background.  the agents will be small but 
complex serial processors.  they should be C++ style objects consisting of
a pointer to a data structure and an array of pointers to functions that
are its muscles ( how to move, how to wrap ) and brain ( where to go 
what to do what colors to show ) .  they shoud eat each other and be 
totally vicious and opportunistic.

what the ought to eat is malloc areas and batchmode runtime shares.  the
key thing is that their appearance has to have something to do with their
ability to win out.  this is a point that dawkins made with his blind
watchmaker program, that by external user-aesthetic selection you can
force interesting evolutions, but it would be so much cooler if the evolution
was self-directing.  what is needed according to dawkins is evolvability.

since writing calab I have spent the entire last year writing the software
for James Gleick's Chaos: The Software to appear from autodesk this summer.
I think the alife objects should be things like henon attractors or yorke
attractors, that should be what they do and how they look.  

big question is how do we decide which attractor wins when two meet or get
near each other.  suppose that the churning of the attractor beats up waves
in the ca space.  suppose that each attractor is beating to the rhythm of
say 2 to 4 double params.  there ought to be something about adjusting your
param, tweaking it by only small increments allowable ( or the odd hyperspace
big param change ) and if you can get a beat of the same frequency as the
other guys main fourier series frequency before he can break to your jive
then you've bested him and you then own all his memory area and runcycles.
the thing is, I think, to evolve evolvability, meaning multidimensional
saddlepoints or bifurcation nodes.

are cas even needed for this?  well maybe not.  maybe they were just the
windowdressing that pulled us into the parallel paradigm.  ants programs
generally run on very stark all zeroes background.  but hey that's like
superboring to look at.  the thing with a great ants program, the way I
see it, working at autodesk, is that if its great we can sell 30,000 
copies of it.  so no need to be stingy about making it cool and adding
features.  so yes do put in the ca background, its cheap and who knows
what synergies will occur.  

is this a general purpose computation?  yes, but the point is really
that it can compute things that serial paradigm computations do badly
if at all, ie societies and genetic algorithm development.

one must keep in mind the that import of godel's theorem and chaitin's
refinement of it is that there can in fact be programs as alive and active
and intellignet as we are BUT such a program is PROVABLY ( in the strictest
sense of the word ) more comples than anything which we ( the target
behavior ) can in fact understand or grasp.  to "grasp" a program has
the precise meaning of being able in one's own lifetime to generate in
vacuuo an algorithm for producing said program.  

how are these too complex programs to arise?  by evolving.  we can bring
about conditions where there is enough evolvability for alife to evolve.
see my book infinity and the mind, software, wetware, and mind tools for
the details.  


From ca-Request@Think.COM  Fri Apr  6 17:45:36 1990
Received: by fafnir.think.com; Fri, 6 Apr 90 17:45:36 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from grogo.think.com by fafnir.think.com; Fri, 6 Apr 90 17:45:23 EDT
Received: by grogo.think.com (4.0/SMI-4.0) id AA00876; Fri, 6 Apr 90 17:49:30 EDT
Date: Fri, 6 Apr 90 17:49:30 EDT
From: bruce@Think.COM
Message-Id: <9004062149.AA00876@grogo.think.com>
To: ca@think.com
Cc: whaley@cmvax.nrl.navy.mil
Subject: Student Bodys needed for CA-Acoustics work

Robert,

Don't know any offhand, but I am forwarding this to a Cellular Automata
list on the Internet.

CA people,

I just got this message from the Naval Research Lab in Washington, DC.  If
any of you are interested, you might want to send mail to Robert at the
address below.

--Bruce Walker (Nemnich)
  Thinking Machines Corporation, Cambridge, MA
  bruce@think.com; +1 617 876 1111

Date: Fri, 6 Apr 90 17:37:53 EDT
From: whaley@cmvax.nrl.navy.mil (Robert Whaley)
Subject: Student Bodys needed for CA-Acoustics work

Susan Numrich here at NRL is pretty serious about hiring
some Students to do some CA work on an acoustics problem.
Any pointers to good individuals, or methods of finding
the same, would be greatly appreciated!

Robert


From ca-Request@Think.COM  Sat Apr  7 19:36:18 1990
Received: by fafnir.think.com; Sat, 7 Apr 90 19:36:18 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Sat, 7 Apr 90 19:36:09 EDT
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Sat, 7 Apr 90 19:40:13 -0400
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA28255; Sat, 7 Apr 90 19:09:29 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 7 Apr 90 16:43:42 GMT
From: jb7m+@andrew.cmu.edu  (Jon C. R. Bennett)
Organization: Carnegie Institute of Technology, Carnegie Mellon, Pittsburgh, PA
Subject: Xlife 1.6
Message-Id: <8a7VWye00VQ6MOAUEw@andrew.cmu.edu>
To: ca@Think.COM


	
Xlife version 1.6 is now on expo.lcs.mit.edu

/contrib/xlife.1.6.tar.Z

Changes from v 1.0 to 1.6

	* accepts -geometry and -bw
	* more save file formats. see lifeconv.c and 
		xlife.6 for the details.
	* cursor relative loading
	* cursor relative zoom/unzoom
	* arrow keys work, along with a help key if you have one
	* if for malevolent reasons your keypad is not returning numbers,
		you can now use it for movement and centering of the image.
		The Sun type-4 keyboard is such a beast.
	* diagonal movement via 1357
	* with scale > 3, cells are drawn with a black border

	* FASTER! (much)

jon bennett

it is also in /xlife/xlife.1.6.tar.Z on

fed.expres.cs.cmu.edu 

when you absolutly positivly have to ftp it overnight :-)

if you grab a copy send me some mail so I can add you to my distrbution
list 

From ca-Request@Think.COM  Sun Apr  8 15:18:07 1990
Received: by fafnir.think.com; Sun, 8 Apr 90 15:18:07 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Sun, 8 Apr 90 15:17:59 EDT
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Sun, 8 Apr 90 15:22:08 -0400
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA01767; Sun, 8 Apr 90 15:07:48 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 8 Apr 90 18:55:26 GMT
From: <UNAUTHENTICATED@Think.COM>+@andrew.cmu.edu
Organization: Carnegie Mellon, Pittsburgh, PA
Subject: Re: Xlife 1.6
Message-Id: <Ua7sYS200hMNFMQFIj@cs.cmu.edu>
References: <8a7VWye00VQ6MOAUEw@andrew.cmu.edu>
To: ca@Think.COM

The distribution is missing the file lifeutil.c (either that or the
Imakefile has old/bad references to lifeutil.c and lifeutil.o).  When
you start the make it also complains with something like "Inconsistent
rules for 'clean'".  This was on a sun3 running X11R4.

Damon
(lipp@cs.cmu.edu)

From ca-Request@Think.COM  Mon Apr  9 01:18:11 1990
Received: by fafnir.think.com; Mon, 9 Apr 90 01:18:11 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Mon, 9 Apr 90 01:18:04 EDT
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Mon, 9 Apr 90 01:22:12 -0400
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA01842; Mon, 9 Apr 90 00:59:20 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 6 Apr 90 22:12:17 GMT
From: hpda!cadence!holsz@bloom-beacon.mit.edu  (Wlodzimierz Holsztynski)
Organization: Cadence Design Systems, Inc.
Subject: Re: von Neumann reference request
Message-Id: <1990Apr6.221217.20181@cadence.com>
References: <3129@castle.ed.ac.uk>
To: ca@Think.COM

In article <3129@castle.ed.ac.uk> nbw@castle.ed.ac.uk (N Wilding) writes:
>I'm trying to find out the date and reference for von-Neumann's first
>mention of the CA (or "self-reproducing automata" as I believe he called
>it).
>Can anyone help me?
>Please e-mail responses direct to me. Thanks
>
>                     Nigel Wilding.

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

It was Von Neumann's idea to construct a self reproducing robot.
He meant to CONSTRUCT, like engineers do, out of some components.
This turned out to be too difficult. Then it was Stanislaw Ulam
who brought the idea of the cellular automata in general, and of
the self-reproducing ones in particular. Then it was Von Neumann's
turn again to put ingenuity and hard work into his actuall CA
construction. I can't give a proper reference off hand. I can't
(quickly) find the early history of CA's in  "Essays on Cellular Automata"
edited by  A.W.Burks. But people in Los Alamos or Boulder (Colorado),
where Ulam had spent years, might know. But perhaps Von Neumann's
own account should be about the best reference.

	-- Wlodek

From ca-Request@Think.COM  Mon Apr  9 14:18:54 1990
Received: by fafnir.think.com; Mon, 9 Apr 90 14:18:54 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Mon, 9 Apr 90 14:18:39 EDT
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Mon, 9 Apr 90 14:22:45 -0400
Received:  by BLOOM-BEACON.MIT.EDU (5.61/25-eef)
	id AA04990; Mon, 9 Apr 90 13:59:26 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 9 Apr 90 17:56:23 GMT
From: snorkelwacker!usc!zaphod.mps.ohio-state.edu!rpi!hiebeler@bloom-beacon.mit.edu  (Dave Hiebeler)
Organization: RPI CS Dept, and LANL Center for Nonlinear Studies
Subject: Cellsim2.5 FTP change and bugfixes
Message-Id: <S%P#2=$@rpi.edu>
To: ca@Think.COM

Two pieces of news for Cellsim users.  The FTP site for obtaining
Cellsim has changed, and some bugs in V2.5 have been fixed.
			   ================

Anonymous FTP is no longer available on the machine that Cellsim was
previously being distributed from, so we have moved the distribution
files to another site.  You can now obtain Cellsim (the current
version is V2.5) via anonymous FTP to turing.cs.rpi.edu (128.213.1.1).
Use "anonymous" as username, and your e-mail address as a password.
All Cellsim files are in the directory "pub/cellsim".  The current V2.5
tarfile has had the bugfixes applied to it already.  If you got Cellsim
before April 8, 1990, you should read below to see how to fix your version.

***NOTE***
Be sure to transfer files in binary mode (type "bin" at the FTP prompt
to set binary mode).  Also, please try to restrict your FTP's to the
non-business hours (e.g. after 7pm, before 8am, Eastern time zone).
**********

If you've never heard of Cellsim before, this is briefly what it is: a
SunView-based cellular automata simulator that runs on color and B&W
Sun-3's, Sun-4's, and Sparcstations.  It can run 1-D and 2-D CA, on
array-sizes of up to 512x512, using up to 256 states/cell.  It can
also attach to a Connection Machine either locally or through the
network, and perform the computations there much more quickly.  A copy
of the Cellsim V2.5 announcement, which has some more information including
details on how to obtain the package, is in the FTP directory as
the file "cellsim_2.5.announcement".  If you obtain Cellsim for the first
time, please send a message to one of the authors, so you will be added
to the mailing-list to be notified of future releases or bug fixes.


If you already got Cellsim V2.5 when it was first announced, then you
don't need to generate lots of network traffic by getting the entire
distribution again.  You only need to get a few files through anonymous FTP:
  1. Get the file "2.5fixes.patch.Z".
  2. If you use Cellsim with a Connection Machine, get the file
     "2.5CMfixes.patch.Z".
  2. Get the file "2.5fixes.README", which explains how to apply the patches
     to V2.5.

If you can't FTP, then send a message to hiebeler@turing.cs.rpi.edu, I
will probably be able to mail the files to you (I think they're small enough).


The following bugs were reported in V2.5, and have been fixed:

1. When you did "Run/bound" when attached to CM, the current time was not
   updated in the control panel after running.

2. When you changed the CMFE host in the CM defaults popup, it wouldn't take
   effect until you closed the popup (similarly for CMFE port).  Now it takes
   effect immediately, so you can leave the CM defaults popup open if you
   like.

3. Couldn't turn off CMFB display while running on the CM.

4. When running skip/bounded on CM, it didn't update Sun display at the end,
   even if the Sun display was enabled.

5. "B" wasn't defined in the distributed CMnborhood.h, so if you wanted to
   write a Paris rule that needed B, it wouldn't compile.

6. When you tried to dump a raster image while running on a Sun-3, it
   complained that it was in closeup mode (even when it wasn't!)

7. "Run/bounded" didn't work right in 1-D  (it acted like "screenful").
   "Run/skip" and "Run/skip-bound" also didn't work right in 1-D


Also, the following two features have been added:

1. Added ability to load/save 2-d images, when in 1-d mode.  Previously, only
   the bottom ("current") line of the array would be saved or loaded when in
   1-D mode.  Now, there is a toggle in the "Image" defaults popup which you
   can toggle so that load/save will operate on the entire 2-D image.

2. When running on a Sun, you can now use any array size (up to a maximum of 
   512) that is a multiple of 4.  Previously, the only allowed sizes were
   64, 128, 256 and 512.  Note that if you're attached to the CM, the only
   allowed sizes are still 128, 256, and 512.
   In a future release, we hope to have truly arbitrary array-sizes working
   on the Sun (not just multiples of 4), and perhaps even on the CM although
   that may not be practical.

Note that these two new features are *not* mentioned in the V2.5
documentation.  They weren't going to be available until the next version,
but a user needed these features quickly, so I put them in early.


  Thanks to everyone who has notified us of bugs in Cellsim V2.5.  If
you notice a bug that is not listed here, please let us know.  We also
appreciate suggestions for new features to incorporate into Cellsim;
many of the new features in V2.5 were suggested by the user community!

  Chris Langton                       Dave Hiebeler
  Theoretical Division                hiebeler@heretic.lanl.gov
  T-13, MS B213                        or  hiebeler@turing.cs.rpi.edu
  Los Alamos National Laboratory
  Los Alamos, NM 87545  USA
  cgl@lanl.gov
-- 
Dave Hiebeler / Computer Science Dept. / Amos Eaton Bldg. /
Rensselaer Polytechnic Institute / Troy, NY 12180-3590 USA
Internet (preferred): hiebeler@turing.cs.rpi.edu   Bitnet: userF3JL@rpitsmts
"Off we go, into the wilds you ponder..."

From ca-Request@Think.COM  Tue Apr 10 19:53:24 1990
Received: by fafnir.think.com; Tue, 10 Apr 90 19:53:24 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Tue, 10 Apr 90 19:53:09 EDT
Received: from uunet.UU.NET by Think.COM; Tue, 10 Apr 90 19:57:18 -0400
Received: from acad.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA15357; Tue, 10 Apr 90 19:57:11 -0400
Received: from megalon.acad.com by acad.uucp  (3.2/SMI-3.2)
	id AA26347; Tue, 10 Apr 90 16:47:16 PDT
Received: by megalon.acad.com (3.2/SMI-3.2)
	id AA15385; Tue, 10 Apr 90 16:47:15 PDT
Date: Tue, 10 Apr 90 16:47:15 PDT
From: acad!megalon!rudy@uunet.UU.NET (Rudy Rucker)
Message-Id: <9004102347.AA15385@megalon.acad.com>
To: ca@Think.COM
Subject: von neumann ref


The first discussion von neumann gives of trying to do self reproduction
of automata was in his talk "The General and Logical Theory of Automata"
to a symposium in Pasd{ena, CA in 1948.  See his Collect Works,
Vol. 5, Macmillan, NY , pp. 288 - 328.

Ulam's first published mention of his and von Neumann's plan to use
CAs appears in Ulam's 1950 essay, "Random Processes and Transformations,"
reprinted in his collected owrks, Sets, Numbers and Universes, MIT
press, pp. 326 - 337.

From ca-Request@Think.COM  Thu Apr 12 13:07:26 1990
Received: by fafnir.think.com; Thu, 12 Apr 90 13:07:26 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Thu, 12 Apr 90 13:07:18 EDT
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Thu, 12 Apr 90 13:11:26 -0400
Received:  by bloom-beacon.MIT.EDU (5.61/25-eef)
	id AA09920; Thu, 12 Apr 90 12:48:44 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 11 Apr 90 18:02:07 GMT
From: baker2@husc6.harvard.edu  (James Baker)
Organization: /sc9a/cs163/baker2/.organization
Subject: cellular automata and neural networks
Message-Id: <BAKER2.90Apr11140207@husc9.harvard.edu>
To: ca@Think.COM


Has anyone constructed ``cellular automata'' that learn?

There seems to be some good reasons to explore this possibility:

1.  Arbitrary connections make analyzing neural networks difficult, if
not just impossible.

2.  Cellular automata models are more readily simulated on hyper cube
parallel architectures than conventional neural networks.

Since one would train these models, they would not be cellular automata
in the strict sense; for example, they might use some global reward
signal or noise, in addition to receiving input and target data.

-- Jim

From ca-Request@Think.COM  Thu Apr 12 13:58:15 1990
Received: by fafnir.think.com; Thu, 12 Apr 90 13:58:15 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Thu, 12 Apr 90 13:58:06 EDT
Received: from ee.ecn.purdue.edu by Think.COM; Thu, 12 Apr 90 14:02:12 -0400
Received: from localhost by ee.ecn.purdue.edu (5.61/1.21jrs)
	id AA02795; Thu, 12 Apr 90 13:02:04 -0500
Message-Id: <9004121802.AA02795@ee.ecn.purdue.edu>
To: ca@Think.COM
Subject: cellular automata and neural networks]
Date: Thu, 12 Apr 90 13:02:01 EST
From: Manoel Fernando Tenorio <tenorio@ee.ecn.purdue.edu>


   From:  baker2@husc6.harvard.edu  (James Baker)
   Subject:  cellular automata and neural networks

   
   Has anyone constructed ``cellular automata'' that learn?

I think that before we can answer this question, it should be proceeded by a 
definition of what is and is not a CA. Certainly, learning has been done and
is possible on CA-like machines.

   There seems to be some good reasons to explore this possibility:

   1.  Arbitrary connections make analyzing neural networks difficult, if
   not just impossible.

I don't understand why that is so. We have published and algorithm to do that
in the IEEE Trans in NN. This is how the brain seems to form certain 
subcircuits, specially theone that are experienced based.

   2.  Cellular automata models are more readily simulated on hyper cube
   parallel architectures than conventional neural networks.

I don't understand why that is so. When I think of CA's, I have images of
highly regular structures, but that might not be necessary; but again the
same can be said about NN.

   Since one would train these models, they would not be cellular automata
   in the strict sense; for example, they might use some global reward
   signal or noise, in addition to receiving input and target data.

There have been a number of works on "local" learning rules for NN that can be 
applied here. You could take a look at CA-like machines in NIPS'87: 
Nondeterministic Adaptive Logic ELements by Windecker.

   -- Jim

------- End of Forwarded Message


From ca-Request@Think.COM  Thu Apr 12 19:31:58 1990
Received: by fafnir.think.com; Thu, 12 Apr 90 19:31:58 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Thu, 12 Apr 90 19:31:50 EDT
Received: from NSFNET-RELAY.AC.UK by Think.COM; Thu, 12 Apr 90 19:35:57 -0400
Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK 
           via Janet with NIFTP  id aa02935; 13 Apr 90 0:22 BST
Via: ctcs.leeds.ac.uk (thrills.ARPA); Thu, 12 Apr 90 23:36:53 GMT
From: Turing Conference <turing%ctcs.leeds.ac.uk@NSFnet-Relay.AC.UK>
Date: Thu, 12 Apr 90 23:37:32 BST
Message-Id: <11852.9004122237@ctcs.leeds.ac.uk>
To: CA@Think.COM
Subject: Easter request


I have been asked by a colleague at Leeds to send on this message:



I would be grateful if, like myself, you were able to respond to a letter
received recently, in order to help Craig. He is a 7 year old boy who
is in the Royal Marsden Hospital in London.

Craig Shergold has a tumour on the brain and one on the spine and has very
little time to live.

It is his ambition to have an entry in the Guiness Book of Records for
the largest number of "Get Well" cards ever received by an individual.

Please send a card to:
	Craig Shergold
	56 Selby Road
	CARSHALTON
	Surrey
	SN6 1LD
	United Kingdom

I would be grateful if you could send a copy of this letter to at least
another 10 companies or individuals.

Yours sincerely,

Ian Mitchell Lambert
Department of Theology
University of Kent at Canterbury

From ca-Request@Think.COM  Thu Apr 12 22:55:18 1990
Received: by fafnir.think.com; Thu, 12 Apr 90 22:55:18 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Thu, 12 Apr 90 22:55:10 EDT
Received: from ATHENA.MIT.EDU by Think.COM; Thu, 12 Apr 90 22:59:19 -0400
Received: from M4-035-22.MIT.EDU by ATHENA.MIT.EDU with SMTP
	id AA08430; Thu, 12 Apr 90 22:59:16 EDT
From: hacrat@ATHENA.MIT.EDU
Received: by M4-035-22.MIT.EDU (5.61/4.7) id AA01345; Thu, 12 Apr 90 22:59:13 -0400
Date: Thu, 12 Apr 90 22:59:13 -0400
Message-Id: <9004130259.AA01345@M4-035-22.MIT.EDU>
To: ca@Think.COM
Subject: Dying-boy-wants-cards story bogus?

From: karl_kleinpaste@tut.cis.ohio-state.edu
Newsgroups: news.announce.important
Subject: Re:  "Dying boy wants cards" stories
Message-ID: <15525@cbnews.ATT.COM>
Date: 12 Apr 90 14:09:18 GMT
Lines: 37
Approved: Mark.Horton@ATT.COM

Recently, there has been a rash of postings in numerous newsgroups
(misc.kids, news.misc, soc.misc, possibly others) announcing that a
young boy is dying of a terminal disease, that he has a very short
time to live, and that he is attempting to work his way into the
Guinness Book of World Records by being the recipient of the largest
number of cards ever.  A recent example:

||   Send a card to:
||
||      Craig Shergold
||      Children's Wish Foundation
||      32 Perimeter Center
||      Atlanta, GA 30346
|| 
||   Craig is 7 years old and has a brain tumor. He has a short time to
||live.
||But he has one wish: to break the Guiness World Book Record for card
||receiving: 1,000,265. He is trying to do this by 4/15/90.

This story has acquired the status of urban legend.  It varies from
occurrence to occurrence, but the variations are not significant: The
child has a brain tumor, leukemia, or some other form of cancer; he
lives in Florida, Georgia, or Great Britain (the story appears to have
originated in GB); he is anywhere from 4 to 9 years old.  These
stories have been floating around the Usenet for not less than 5
years.  If the story was ever true, the child must have long since
achieved his goal; and in any event, some of the responses to these
announcements have indicated that Guinness is no longer interested in
pursuing this category, if it ever did in the first place.

Please ignore these notes in the future.
    ----------------

[Note: there have been some indications that this particular round may
be for real, but that they have already received more cards than they
want.  In any case, there is no reason to send additional cards or to
propagate this story.  Please stop! - MRH]

From bmb@Think.COM  Fri Apr 13 09:22:20 1990
Received: by fafnir.think.com; Fri, 13 Apr 90 09:22:20 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from aldebaran.think.com by fafnir.think.com; Fri, 13 Apr 90 09:22:12 EDT
Received: by aldebaran.think.com; Fri, 13 Apr 90 09:22:07 EDT
Date: Fri, 13 Apr 90 09:22:07 EDT
From: bmb@Think.COM
Message-Id: <9004131322.AA07712@aldebaran.think.com>
To: turing%ctcs.leeds.ac.uk@NSFnet-Relay.AC.UK
Cc: CA@Think.COM, bmb
In-Reply-To: Turing Conference's message of Thu, 12 Apr 90 23:37:32 BST <11852.9004122237@ctcs.leeds.ac.uk>
Subject: Easter request

   From: Turing Conference <turing%ctcs.leeds.ac.uk@NSFnet-Relay.AC.UK>
   Date: Thu, 12 Apr 90 23:37:32 BST


   I have been asked by a colleague at Leeds to send on this message:

   I would be grateful if, like myself, you were able to respond to a letter
   received recently, in order to help Craig. He is a 7 year old boy who
   is in the Royal Marsden Hospital in London.

   <...>

Two points about this:

1) Please do *not* use the CA mailing list for chain letters.  Chain
letters are an abuse of the Internet.  Since the CA mailing list is
generously maintained by TMC, the posting of chain letters to it is also
an abuse of TMC's resources.  It was intended to be a means of
information exchange for people involved in CA research, and it should
be restricted to scientific topics.  Those of us who justify its
existence to TMC management do not need to have this sort of thing
happen.

2) This particular chain letter has been the topic of some controversy.
When it was posted to the "connectionists" mailing list, a recipient
noted that the young boy in question recently made the news because he
has been receiving *too* many cards, and he does not want them any more.
Apparently this chain letter has been propagated to quite a few
electronic mailing lists and FAX machines; the boy was receiving order
10^4 cards per day, and had accumulated a mountain of order 10^6 cards.
Thus, it is not a good idea to comply with the request of this chain
letter, or to propagate it any further.

Thanks,
Bruce M. Boghosian
Thinking Machines Corporation
bmb@think.com

From ca-Request@Think.COM  Tue Apr 17 02:13:12 1990
Received: by fafnir.think.com; Tue, 17 Apr 90 02:13:12 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Tue, 17 Apr 90 02:13:03 EDT
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Tue, 17 Apr 90 02:17:10 -0400
Received:  by bloom-beacon.MIT.EDU (5.61/25-eef)
	id AA07051; Sat, 14 Apr 90 04:15:09 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 13 Apr 90 03:26:48 GMT
From: hpda!cadence!holsz@bloom-beacon.mit.edu  (Wlodzimierz Holsztynski)
Organization: Cadence Design Systems, Inc.
Subject: Re: cellular automata and neural networks
Message-Id: <1990Apr13.032648.4987@cadence.com>
References: <BAKER2.90Apr11140207@husc9.harvard.edu>
To: ca@Think.COM

In article <BAKER2.90Apr11140207@husc9.harvard.edu> baker2@husc9.harvard.edu (James Baker) writes:
>...	...	...
>
>2.  Cellular automata models are more readily simulated on hyper cube
>parallel architectures than conventional neural networks.
>
>...	...	...
>-- Jim

Being  "Mr. GAPP"  let me inform you that my invention provides
you with a much more efficient way.  The GAPP chips are available
from  NCR (Fort Collins). They used the old 3 micron technology.
Nevertheless you get 72 cells (a 6 by 12 array) on one chip.
Each cell has its own  128  bits of memory (on the chip).
You might even get  GAPP boards  from Amber Eng. (Santa Barbara,
California).  NCR used to make some toy boards, possibly still does.

I hear that newer variations of my invention are produced (with
an 8 by 16 array) but I don't think they are commercially
available. 

GAPP  stands for  Geometric-Arithmetic Parallel Processor.
I made up this name to emphasize it's two strengths.
It is used in military applications. But besides being practical,
it has pure architecture. It's instruction set forms a simple
language perfect for theoretical research, like for studies in
the computational complexity. (I got Conway's Life in 25 GAPP
instructions and wonder if anybody can lower it. Independently,
about a year after I got my program they independently had
a competition at NCR but got only 30++? result).

-- Wlodek

From ca-Request@Think.COM  Tue Apr 17 02:19:24 1990
Received: by fafnir.think.com; Tue, 17 Apr 90 02:19:24 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Tue, 17 Apr 90 02:19:14 EDT
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Tue, 17 Apr 90 02:23:15 -0400
Received:  by bloom-beacon.MIT.EDU (5.61/25-eef)
	id AA24755; Sat, 14 Apr 90 16:20:46 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 14 Apr 90 17:52:41 GMT
From: mintaka!ogicse!emory!hubcap!ncrcae!usceast!park@bloom-beacon.mit.edu  (Kihong Park)
Organization: University of South Carolina, Columbia
Subject: Re: cellular automata and neural networks
Message-Id: <3199@usceast.UUCP>
References: <BAKER2.90Apr11140207@husc9.harvard.edu>
To: ca@Think.COM

In article <BAKER2.90Apr11140207@husc9.harvard.edu> baker2@husc9.harvard.edu (James Baker) writes:
>Has anyone constructed ``cellular automata'' that learn?

You have to remember that certain types of neural networks can be suitably
represented as cellular automata. It is advantageous that the NN be discrete,
and have nontotal connectivity. But these are not absolute requirements.
You will need to have a cell type which encodes the weights, and another
cell type which encodes the neuron. Again, it's not necessary to view as
there being two cell types because you can always merge them as one ---
a standard trick. If your neurons are modeled to have continuous transfer
functions, this is remedied by incorporating a table of the functional
values with as accurate finite quantization level as one pleases.

>There seems to be some good reasons to explore this possibility:
>
>1.  Arbitrary connections make analyzing neural networks difficult, if
>not just impossible.

I don't quite understand your statement. Even though CAs are "simpler"
systems than NNs, it is very often the case that the latter are analytically
more tractable. That's why you have all this hype surrounding NNs. People
feel that they understand their neural nets to a certain degree. It makes
them semi-confident design/engineers.

>2.  Cellular automata models are more readily simulated on hyper cube
>parallel architectures than conventional neural networks.

Since, as you point out, the CA's neighborhood is often times quite
limited, CAs can be more easily simulated on parallel machines such as
hypercubes. But in many implementations of NNs on multi-processor
machines, in effect, a morphism to a cellular automata structure is
performed anyway. So, even though there exist BIG differences between CAs
and NNs, and they are studied in different contexts, one has to always
remeber that they are close cousins.

>Since one would train these models, they would not be cellular automata
>in the strict sense; for example, they might use some global reward
>signal or noise, in addition to receiving input and target data.

There is a field called systolic arrays which deals with practical design
issues in implementing "easy"-to-parallelize algorithms on CA-like
environments. There exist terminologies such as "global broadcasting"
which would suggest terms you may be looking for.

Kihong Park. (park@cs.scarolina.edu)

From ca-Request@Think.COM  Thu Apr 26 18:37:38 1990
Received: by fafnir.think.com; Thu, 26 Apr 90 18:37:38 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Thu, 26 Apr 90 18:37:23 EDT
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Thu, 26 Apr 90 18:41:22 -0400
Received:  by bloom-beacon.MIT.EDU (5.61/25-eef)
	id AA19258; Thu, 26 Apr 90 18:24:40 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 26 Apr 90 18:56:25 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!tut!mn48903@Think.COM  (Niemel{ Martti)
Organization: Tampere University of Technology, Finland
Subject: Mist met as a morning rozer, what did, woke ?
Message-Id: <3495@tutor.tut.fi>
To: ca@Think.COM


         Brother Green

  Days and yet days out of the rain though not without as I
am without humidity, what do I see that you, really you are
doing these very moments of the preferance me to me, plainly.
  Even brother green, at seldom times though, though is been
given the, how should I say, the joy of heart, is it that you
are been too forgotten the rain and a good moment of dancing
as the eawes so did plain enough do.  My heart grows sad when
I see: ou are but been given nourishment" - known she as if
were - "Where did I meet you".
  Flow are been quite, quite so often, meeting here, these re-
gions of the forest that as you better know is called what, is
raining like pouring ? Though as if I knew, as I know I do not
that she would, as would say I want it to rain more or less,
but here, where as I have been, but told it is not raining here.
  So, ever so, so we: Brother Green and I have been meeting these
very the very same difficulty in our lives - nourishment on the
soil in, but a degree me by regarded as good enough, though only
not nourishment is enough - each of us as if it so seems : we are
in need of differentia in the distributation of the known humidity
- generally regarded as agregation or natural phenomena raining -
we meet unneccessarily only if we are not to solv these hardships,
is this a truth to you, and out counted are you if so not so is met.
  As I see you a her if you so were : "You are giving him artificial
shit and shine of our glow, but as you already know better you need
to give him the water your self" - these moments at's he's why's, but's
been given only the artifactual nourishment and no both water in the
plenty, shame on your task force. Though mister Green is a joy to my
eyey, so young and handsome as she thinks, does she ?


  These are but mere reinvitation to you the holder and keeper
of my heart in these lonely moments of this fine an evening.

From ca-Request@Think.COM  Sun Apr 29 03:26:58 1990
Received: by fafnir.think.com; Sun, 29 Apr 90 03:26:58 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Sun, 29 Apr 90 03:26:36 EDT
Received: from uunet.UU.NET by Think.COM; Sun, 29 Apr 90 03:30:34 -0400
Received: from acad.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA25827; Sun, 29 Apr 90 03:30:26 -0400
Received: from megalon.acad.com by acad.uucp  (3.2/SMI-3.2)
	id AA26112; Sun, 29 Apr 90 00:03:52 PDT
Received: by megalon.acad.com (3.2/SMI-3.2)
	id AA03563; Sun, 29 Apr 90 00:03:50 PDT
Date: Sun, 29 Apr 90 00:03:50 PDT
From: acad!megalon!rudy@uunet.UU.NET (Rudy Rucker)
Message-Id: <9004290703.AA03563@megalon.acad.com>
To: ca@Think.COM
Subject: vants and wator, calab, long message

Wator and Vants: Two New CA Lab programs



Wator is the "sharks and fish" game defined in Kee Dewdney's book,

The Armchair Universe, W.H. Freeman, 1988.   Vants is a rule defined by

Chris Langton in his paper "Studying Artificial Life with Cellular

Automata" in Physica D 22, 1986, and discussed again under the name

Turmite in Kee Dewdney's Computer Recreations column in Scientific

American, September, 1989.  The vants, or turmites, are free-ranging

heads of two-dimensional Turing machines.



The Wator which I show here has three species: sharks, fish and shrimp.

As it runs it generates a very loosely coupled zhabotinsky pattern.  The

Vant which I show here has three species of Vants.  



Below are the necessary codes for implementing these rules in the CA Lab

environment.  CA Lab: Rudy Rucker's Cellular Automata Laboratory is a

PC software package availabe from Autodesk, Inc. for $59.95 and can be

ordered by phoning 1-800-525-2763.  The program includes four 360K disks

and a 264 page manual.  720K 3 1/2 inch disks are included as well.



 In order to run wator as shown, one must first assemble the swap.asm

 file using MASM or Turbo  Assembler to produce the file swap.exe.  

> tasm swap

Then one use the DOS exe2bin utility to convert swap to a .com file

with suffix .cao

> exe2bin swap.asm swap.cao

Next the wator.pas must be compiled to wator.exe by using the Turbo

 Pascal compiler.  Note that for the compile to work, one must have

 the Pascal unit camake.tpu which is supplied with CA Lab.

> tpc wator

 Next one runs wator.exe a single time to produce as output the file

wator.ca

> wator

Then one uses a text editor to create a raw ascii file containg the

 wator palette se and nes this fle wator.cac.  Finally

 one uses the CA Lab ca.exe driver.  A good pattern to start with

 here happens to be the CA Lab billbord.cap file.  One can set things

 in motion with a single batch-mode command line:

> ca wator billbord -b



Mutata mutandis, the same steps will produce the files turmite.cao,

 vant.ca, and vant.cac.  What pattern should one run the vants on?  As 

it turns out the states 66, 128, and 192 correspond to the three

 kinds of vants, or turmites.  Using the CA Lab screen editor to

 put some lines of these guys down is an interesting start.  Even

 more interesting is to put a square of state 1 down and to put a

 vant at the square's edge.  The vant will grow lace on the square's

 edge.



Those blindly bent on hacking CAs in non CA Lab environments may in any

case find some useful tricks in the code below.



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

PROGRAM Wator;

{This is a three species version of a "Sharks and Fish" world.

 Wator calls a highspeed owncode, swap.cao.

 Rudy Rucker, May , 1989.}



USES Camake;

{$F+}	  { Required for function argument to genrule. }



FUNCTION Carule(NabeAndMe,a,b,c,d,e,f,g,h,i:integer):integer;

CONST

 	ShrimpBreed  = 8;  ShrimpSterile = 12 ; ShrimpDie   = 15;

        FishBreed    =  3;  FishStarve  =  5;

        SharkBreed   =  2;  SharkStarve =  7;

VAR

	Me,MeAge,MeHunger,MeShrimpAge,MeType,

                Nabe,NabeAge,NabeShrimpAge:integer;

	MeShrimp,MeFish,MeShark,NabeShrimp,NabeFish,NabeShark:Boolean;

BEGIN  {Function}

  	Me  :=lo(NabeAndMe);

  	Nabe:=hi(NabeAndMe);

	MeShrimp := (Me AND 3)=1;

	MeFish:= (Me AND 3)=2;

        MeShark:= (Me AND 3)=3;

	MeAge:= (Me SHR 2) AND 7;

	MeHunger:=Me SHR 5;

        MeShrimpAge:= Me SHR 2;

	NabeShrimp := (Nabe AND 3)=1;

	NabeFish := (Nabe AND 3)=2;

        NabeShark := (Nabe AND 3)=3;

	NabeAge:= (Nabe SHR 2) AND 7;

        NabeShrimpAge:= Nabe SHR 2;

        MeType:= Me AND 3;

  CASE MeType OF

 	0: BEGIN

                CaRule:=0;

                IF NabeShrimp AND (ShrimpBreed<NabeShrimpAge) AND

                   (NabeShrimpAge<ShrimpSterile) THEN CaRule:=1;

		IF NabeFish AND (NabeAge=FishBreed) THEN CaRule:=2;

                IF NabeShark AND (NabeAge=SharkBreed) THEN CaRule:=3;

		END;

	1: BEGIN

                IF NabeFish THEN CaRule:=0 ELSE

			BEGIN

				MeShrimpAge:=(MeShrimpAge+1);

                                IF MeAge=ShrimpDie THEN CaRule:=0 ELSE

				CaRule:=((MeShrimpAge SHL 2)OR 1)AND 255;

			END;

    	   END;

	2: BEGIN

                IF NabeShark THEN CaRule:=0 ELSE

                   BEGIN

                   	IF NabeShrimp THEN MeHunger:=0;

                        IF MeHunger>=FishStarve THEN CaRule:=0 ELSE

			BEGIN

                             MeHunger:=MeHunger+1;

                             MeAge:=(MeAge+1)MOD (FishBreed+1);

                             CaRule:=((MeHunger SHL 5)OR(MeAge SHL 2)OR 2)AND 255;

			END;

                   END;

		END;

        3: BEGIN

             IF NabeFish THEN MeHunger:=0;

                IF MeHunger>=SharkStarve THEN CaRule:=0 ELSE

			BEGIN

                             MeHunger:=MeHunger+1;

                             MeAge:=(MeAge+1)MOD (SharkBreed+1);

                             CaRule:=((MeHunger SHL 5)OR(MeAge SHL 2)OR 3)AND 255;

			END;

            END;

        END;

END;  {Function}



BEGIN {Main}

	WorldType := 13;       {is wrap on.  12 is wrap off}

        OCodeReq := 'swap';

        PalReq   := 'wator';

	GenRule(CaRule)

END.  {Main}

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

;swap.asm 

;First put EveryCell's eight bits in bl and put the eight

;bits of a single randomly selected neighbor into bh and use

;bx is offset into a lookup table in the .CA file generated by the

;program which calls gas.cao.  This will be new EveryCell.

;Then exchange bh and bl and use this as lookup into same .CA to

;find new nabe.  

;Second, after EveryCell's and nabes new cells value are computed,

;Gas swaps these two cell values.

;The rule runs its own randomizer, using Wolfram code 30.



codes segment byte

assume cs:codes

org 100h

naber proc far

	mov	dx,320	;load row length counter

	push si

	mov  si,cs:shiftregister			; reseed shiftregister at

	xor  si,[bp+160]				; start of row.

	xor  si,[bp]

	or   si,cs:counter

	mov  cs:shiftregister,si

	inc  cs:counter

	lbyte:

          mov  si,cs:shiftregister      ; shiftregister is a sixteen    

          mov  ax,si				; bit 1-D CA running Wolfram

		mov  cx,si				; code 30.  si holds C

		ror  ax,1					; ax holds L, cx holds R.

          rol  cx,1					; NewC = L XOR (C OR R)

		or   si,cx				

		xor  si,ax				; each time we read shiftregister

          mov  cs:shiftregister,si		; we update it.

	     and  si,000Eh				; even number 2 to 14

		mov  si,cs:nabetable[si]      ; offset to NW,N,NE,W,E,SW,S,or SE

		mov  bh,[bp+si]			; load nabe in bh

		rol  bh,1					; adjust map state

		mov  bl,[bp]				; get self

	     rol  bl,1                     ; adjust map state

		mov  ah,[bx]                  ; look up new EveryCell state

          xchg bl,bh                    ; now view nabe as center 

 		mov  al,[bx]                  ; and look up new val for nabe

		mov  [bp+si],ah			; copy new to nabe in oldbuff

		mov  bx,di				; offset of EveryCell

          mov  es:[bx+si],ah 	          ; copy new to nabe in newbuff

		mov  [bp],al                  ; copy nabe to self in oldbuff

		stosb					; copy nabe to self in newbuff

		inc  bp					; advance along row

		dec  dx					; more to update?

		jnz  lbyte				; if yes, keep on going

	pop  si

	ret

naber endp

nabetable dw -323,-322,-321,-1,1,321,322,323

shiftregister dw 17h

counter dw 1

codes ends

end naber

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

PROGRAM Vant;

{This program creates a table to be used by Turmite.CAO.  We run

three kinds of virtual ants, or "vants," as Langton calls them.  The

term "turmite" is from Dewdney's Sci Am column of November, 1989.



Turmite's Bit Usage:

7,6   turmite bits.

5     reserved for speed bit.

4,3,2 direction bits.

1,0   tile bits.



Turmite Nomencalture:

 Cell is the cell I update, Source is its state, Target is a cell

 near Cell, Sink is Target's state, Mite & Tile are  new cell values

 turce in bl.So against Turmite bits.  If zero,

    copy Source to Cell in New uffer and exit.

(1) If Sourceas nonzero Turmite bits, use diection bits to select g and load Sink in bh.

(2) Use .CA table to determine Mite state.

(3) Put Mite in Target position in New Buffer.

(4) Mask Source to get Tile and put Tile in Cell in New Buffer.



Here we have three kinds of vants.}



USES Camake;

{$F+}



FUNCTION Carule(TState,a,b,c,d,e,f,g,h,i:integer):integer;

VAR

Source,TurType,Sink,TargTile,NewTargTile,Dir,NewDir,Mite:integer;

BEGIN  {Function}

Source:=TState AND $FF;

Dir:=(Source SHR 2) AND 7;

TurType:=Source SHR 6;

Sink:=TState SHR 8;

TargTile:=Sink AND 1;



Mite:=0;

CASE TurType OF

1:

  BEGIN

    CASE TargTile OF

	0:	BEGIN

		NewDir:=(Dir+2)MOD 8;

		NewTargTile:=1;

		END;

	1:	BEGIN

		NewDir:=(Dir+6)MOD 8;

		NewTargTile:=0;

		END;

    END;

    Mite:=(TurType SHL 6)OR(NewDir SHL 2)OR NewTargTile;

  END;

2:

  BEGIN

    CASE TargTile OF

	0:	BEGIN

		NewDir:=(Dir+6)MOD 8;

		NewTargTile:=1;

		END;

	1:	BEGIN

		NewDir:=(Dir+2)MOD 8;

		NewTargTile:=0;

		END;

    END;

   Mite:=(TurType SHL 6)OR(NewDir SHL 2)OR NewTargTile;

  END;

  3:

  BEGIN

    CASE TargTile OF

	0:	BEGIN

		NewDir:=(Dir+1)MOD 8;

		NewTargTile:=1;

		END;

	1:	BEGIN

		NewDir:=(Dir+7)MOD 8;

		NewTargTile:=0;

		END;

    END;

   Mite:=(TurType SHL 6)OR(NewDir SHL 2)OR NewTargTile;

  END;

END;

CaRule:=Mite;

END;  {Function}



BEGIN {Main}

	WorldType := 13;       {12 is wrap off.  13 is wrap on}

     OCodeReq := 'turmite';

        PalReq := 'vant';

	GenRule(CaRule)

END.  {Main}



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

;turmite.asm

;Bit Usage. 7,6 Turmite bits.  4,3,2 direction.  1,0 tile type.

;(Later I will use bit 5 for speed: 0 is normal speed, 1 is double.)

;As all non-turmite cells will have zero velocity, the state 4 

;will never arise.  I use this state as a "don't update" flag state.

;    Cell is the cell I update, Source is its state, Target is a cell

;    near Cell, Sink is Target's state, Mite & Tile are  new cell values I ;    compute.

;(1) Put Source in bl.  If Source is 4, don't change newbuffer Cell. Exit.

;(2) Else test Source against Turmite bits.  If these bits are zero,

;    copy Source to Cell in new Buffer and exit.

;(3) Else Source has nonzero Turmite bits.  Use direction bits to select

;    Target and load Sink in bh.

;(4) If Sink is a Turmite in oldbuff or in newbuff, reverse direction of

;	Source and put it in Cell.

;(5) Else use Source r ate
Moget Tile and put Tile in Cell i Old and New Buffers.



codes segment byte

assume cs:codes

org 100h

turmite proc far

	mov	dx,320	;load row length counter

	push si

	lbyte:

		xor	bh,bh

		mov	bl,[bp]				; get right rotated Source

		cmp	bl,2					; is rt rot of don't-update-state?

		jne	updatecell			; no, do update.

		inc	di					; yes,adjust for skipped stosb

		jmp	noupdate				; and skip it.

		updatecell:

		mov	al,bl				; keep rt rot source read

		test	bl,60h				; any right rotated turmite bits?

		jz	loadnewcell			; no. copy Source direct.

		xor	al,8					; reverse rt rot Source's direction

		mov	si,bx				; rt rotated Source has 432 in 321

		and	si,000Eh				; 2*direction in si

		mov	si,cs:nabetable[si]		; offset to NW,N,NE,E,SE,S,SW,or W

		mov	bh,[bp+si]			; right rotated Sink

		test	bh,60h				; is Target a turmite in oldbuff?

		jnz	loadnewcell			; yes, don't go there.

		rol	bh,1					; unrotate Sink

		rol	bl,1					; unrotate Source

		mov	ah,[bx]				; look up Mite

		mov	bx,di				; offset of Cell in newbuff

		test byte ptr es:[bx+si],60h	; is Target a turmite in newbuff?

		jnz	loadnewcell			; yes. reversed Source to new Cell

		mov	es:[bx+si],ah			; put Mite in Target in newbuff

		mov	byte ptr [bp+si],2		;dnt-updte-st to Target in oldbuff

		and	al,81h				; mask rt rotated Source to Tile

		mov	[bp],al				; Tile in oldbuff Cell

		loadnewcell:

		stosb					; Source or Tile in newbuff Cell

		noupdate:

		inc	bp					; advance along row

		dec	dx					; more to update?

		jnz	lbyte				; if yes, keep on going

	pop	si

	ret

turmite endp

nabetable dw -323,-322,-321,1,323,322,321,-1

;nw,n,ne,e,se,s,sw,w

;I use this order so nabetable[v XOR 8] is opposite to nabetable[v]

codes ends

end turmite

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

Supplied below are two 256 color palettes; human readers will

probably want to quit out of the document here.

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

;This is the 256 color wator.cap palette for showing the wator rule.

; the first three numbers in each row are the Red, Green, Blue

; intensities to use with VBA Mode 13; the fourth number is a number

; to use if all you have is CGA



3;R    G    B   CGA

  0    0    0    0    ;   0

  63   0    0    1    ;   1

  50  63   50    2    ;   2

  50  50   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   19    2    ;   2

 18   31   63    3    ;   3

  0    0    0    0    ;   0

  25   5    0    1    ;   1

  15  63   1
---------
thats all folks

rudy@autocad.com

From ca-Request@Think.COM  Wed May  2 04:58:50 1990
Received: by fafnir.think.com; Wed, 2 May 90 04:58:50 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Wed, 2 May 90 04:58:37 EDT
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Wed, 2 May 90 05:02:37 -0400
Received:  by bloom-beacon.MIT.EDU (5.61/25-eef)
	id AA18619; Wed, 2 May 90 03:25:44 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 2 May 90 07:22:56 GMT
From: snorkelwacker!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!hiebeler@bloom-beacon.mit.edu  (Dave Hiebeler)
Organization: RPI CS Dept, and LANL Center for Nonlinear Studies
Subject: Re: Vants and CA simulators
Message-Id: <C%4#~!#@rpi.edu>
References: <9004290703.AA03563@megalon.acad.com>
To: ca@Think.COM

Some comments about Vants and about CA Simulators, based on a message
recently posted by Rudy Rucker:


  Thanks for posting Wa-tor and the Vants.  By the way, last summer I
wrote a 2-species vants that is reversible (I find reversible rules
particularly interesting).  It is written for both CAM and Cellsim.
It comes with Cellsim, and will be part of the new CAM's distribution
software, but if anyone on this list doesn't have a copy and would
like one, let me know.

  Like most reversible rules, if you start with anything non-trivial,
entropy has its way and the CA array eventually gets very noisy, but
there is a great deal of fascinating behavior before that happens --
multiple types of gliders that move in different directions and
speeds, and even "wires" of sorts which the vants can construct and
then propagate along.  I have some ideas about enhancing the rule
slightly to give more complex behavior (a simple chemistry of sorts)
and I started fiddling with it on CAM last year, but I've been too
busy to do much with it yet.  I'll say something more about it when I
get time to develop it further.


> Those blindly bent on hacking CAs in non CA Lab environments may in any
> case find some useful tricks in the code below.

  Well, there's no need to insult people who don't use CA Lab.

  I do cellular automata work for Los Alamos Lab, and also for
Automatrix, a company that specializes in cellular automata products.
Which CA simulator I use depends on just what I'm doing.  When I need
80 bits/cell (if you still want to call that a CA), I use the
Connection Machine and Cellsim.  When I don't need that many bits, but
am doing a long experiment where I need to run several thousand steps
per minute while doing real-time data analysis, I use CAM.  If I
needed to do lots of symbolic analysis on the CA, I'd use Mathematica.
Then there's Howard McIntosh's software, which lets you do mean field
theory and local structure theory analysis.

  I hope that doesn't make me "blind" because I don't use CA Lab.  I
do admit that the "owncode" feature of CA Lab is very handy, although
it's unfortunate that it has to be done in assembly language.

Disclaimer: These are my own opinions, my employers may or may not agree.

-- 
Dave Hiebeler               Internet: hiebeler@heretic.lanl.gov
Theoretical Division                  hiebeler@turing.cs.rpi.edu
T-13 MS B213                  Bitnet: userF3JL@rpitsmts
Los Alamos National Laboratory  /  Los Alamos, NM 87545  USA

From ca-Request@Think.COM  Wed May  2 19:58:58 1990
Received: by fafnir.think.com; Wed, 2 May 90 19:58:58 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Wed, 2 May 90 19:58:50 EDT
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Wed, 2 May 90 20:02:59 -0400
Received:  by bloom-beacon.MIT.EDU (5.61/25-eef)
	id AA01336; Wed, 2 May 90 19:09:44 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 2 May 90 23:04:33 GMT
From: snorkelwacker!apple!apple.com!karakots@bloom-beacon.mit.edu  (Ken Karakotsios)
Subject: CASim for the Macintosh is now available!
Message-Id: <8028@goofy.Apple.COM>
To: ca@Think.COM

***** CASim ***** 
the Cellular Automata program for the Macintosh, 
is now available!

About two months ago I announced that I was working on a CA 
simulator for the Macintosh.  ItUs ready!   The price is $29.95, and for 
this price you get:

     - >The CASim application, a 256 state CA simulator for the MacII
     - >9 classes of built in rules (each rule class has many parameters)
        +Wolfram Rules (one dimensional)
        +Totalistic rules:  includes VOTE and Fredkin 
        +NLUKY rules:  includes Life, 3-4 Life, Brian Silverman's Brain 
         rule, and thousands of others.
        +Wire rules:logic simulation rule discussed in  A.K. DewdneyUs 
         December '89 Computer Recreations column.
        +Hodepodge Rules:  Models the spread of disease and
         cyclical chemical reactions
        +Rug:  Models heat-flow and make madala-like images
        +Diffusion/Aggregation:  Model diffusion, fractal crystal growth,
         gas mixing, shock waves, etc.
        +Turmites:Little Turing machines crawl around the screen 
         doing enigmatic computations and leaving behind 
         complex, sometimes organized, patterns. 
        +Ecology:This rule simulates an eco-system with a three 
         member food-chain (Wolves, Sheep, and Grass).
     - > A dialog-based rule editor for creating your own rules
     - > Tools for drawing, saving images, changing the color palette,
          and randomization 
     - > Animation recording and playback, for producing "CA movies"
     - > Built in data logging for post-processing of CA experiments
     - > sample images
     - > sample user-defined rule files
     - > a 100+ page user manual
     - > a discount on future upgrades and new software I write

If you would like to order CASim, send a check for $29.95 to:

          Ken Karakotsios
          1272 Copper Peak Lane
          San Jose, Ca. 95120

If you would like more information, send me mail, either at the 
above address or to:
internet:karakots@apple.com
AppleLink:Karakots

CASim runs on any MacII (II, IIx, IIcx, IIci, IIfx).   256 colors are 
*highly* recommended, but it will run with fewer colors (even black 
& white, but unless you only use 2-state rules like Life, you will be 
missing a lot).  CASim likes to use 2MBytes of memory, but will run 
with 1MByte or less.

From ca-Request@Think.COM  Thu May  3 13:59:25 1990
Received: by fafnir.think.com; Thu, 3 May 90 13:59:25 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Thu, 3 May 90 13:59:17 EDT
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Thu, 3 May 90 14:03:26 -0400
Received:  by bloom-beacon.MIT.EDU (5.61/25-eef)
	id AA20912; Thu, 3 May 90 14:01:48 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 30 Apr 90 12:05:08 GMT
From: samsung!munnari.oz.au!csc!csc3!anucsd!neccan!peter@Think.COM  (Peter Miller)
Organization: NEC Information Systems Australia, Canberra
Subject: Robert T Wainright's address
Message-Id: <703@neccan.oz>
To: ca@Think.COM

Can anybody  tell me the address (e-mail or postal) of
Robert T Wainright, the editor or "Lifeline" and general Life guru?

Regards
Peter Miller       UUCP    {uunet,mcvax,ukc}!munnari!neccan.oz!pmiller
                   ARPA    pmiller%neccan.oz@uunet.uu.net
/\/\*              CSNET   pmiller%neccan.oz@australia
                   ACSnet  pmiller@neccan.oz
Disclaimer?  These guys have no idea what I am on about!
D

From ca-Request@Think.COM  Fri May  4 00:58:57 1990
Received: by fafnir.think.com; Fri, 4 May 90 00:58:57 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Fri, 4 May 90 00:58:48 EDT
Received: from BLOOM-BEACON.MIT.EDU by Think.COM; Fri, 4 May 90 01:02:58 -0400
Received:  by bloom-beacon.MIT.EDU (5.61/25-eef)
	id AA18931; Thu, 3 May 90 23:50:50 EDT
Received: from USENET by bloom-beacon.mit.edu with netnews
	for ca@think.com (ca@think.com)
	(contact usenet@bloom-beacon.mit.edu if you have questions)
Date: 4 May 90 03:42:01 GMT
From: cs.yale.edu!news@yale-zoo.arpa  (Usenet News)
Organization: Yale University Computer Science Dept, New Haven CT  06520-2158
Subject: Re: Robert T Wainright's address
Message-Id: <25000@cs.yale.edu>
References: <703@neccan.oz>
To: ca@Think.COM

In article <703@neccan.oz> peter@neccan.oz (Peter Miller) writes:
>Can anybody  tell me the address (e-mail or postal) of
>Robert T Wainright, the editor or "Lifeline" and general Life guru?

Lifeline
c/o Robert T. Wainwright
12 Longue Vue Ave.
New Rochelle, NY 10804

$15 for complete set of all the Lifelines yet published.

Good stuff.  I wish to hell I hadn't lost the set I ordered... might have
to send him another check sometime....

Rob Jellinghaus                | "Next time you see a lie being spread or a
jellinghaus-robert@CS.Yale.EDU |  bad decision being made out of sheer ignor-
ROBERTJ@{yalecs,yalevm}.BITNET |  ance, pause, and think of hypertext."
{everyone}!decvax!yale!robertj |     -- K. Eric Drexler, _Engines of Creation_

From ca-Request@Think.COM  Fri May  4 15:47:36 1990
Received: by fafnir.think.com; Fri, 4 May 90 15:47:36 EDT
Errors-To: ca-Request@Think.COM
Sender: ca Mailing List <ca-Request@Think.COM>
Received: from Think.COM (gateway.think.com) by fafnir.think.com; Fri, 4 May 90 15:47:26 EDT
Received: from uunet.UU.NET by Think.COM; Fri, 4 May 90 15:51:32 -0400
Received: from acad.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA02499; Fri, 4 May 90 15:51:27 -0400
Received: from megalon.acad.com by acad.uucp  (3.2/SMI-3.2)
	id AA13548; Fri, 4 May 90 12:49:56 PDT
Received: by megalon.acad.com (3.2/SMI-3.2)
	id AA09122; Fri, 4 May 90 12:49:55 PDT
Date: Fri, 4 May 90 12:49:55 PDT
From: acad!megalon!rudy@uunet.UU.NET (Rudy Rucker)
Message-Id: <9005041949.AA09122@megalon.acad.com>
To: ca@Think.COM
Subject: wireworld in CA Lab

Wireworld in CA Lab



Frank Szucs of Buffalo, NY, sent me a suitable ruletable for running

WIREWORLD in the RC module of CA Lab:



					EightSum

Cellstate		0	1	2	3	4	5	6	7	8

________________________________________________________

0   (space) 	0	0	0	0	0	0	0	0	0

1           	0	0	0	0	0	0	0	0	0

2           	0	0	0	0	0	0	0	0	0

3           	0	0	0	0	0	0	0	0	0

4  (tail)   	12	12	12	12	12	12	12	12	12

5           	0	0	0	0	0	0	0	0	0

6           	0	0	0	0	0	0	0	0	0

7           	0	0	0	0	0	0	0	0	0

8           	0	0	0	0	0	0	0	0	0

9           	0	0	0	0	0	0	0	0	0

10          	0	0	0	0	0	0	0	0	0

11          	0	0	0	0	0	0	0	0	0

12 (wire)   	12	15	15	12	12	12	12	12	12

13          	0	0	0	0	0	0	0	0	0

14          	0	0	0	0	0	0	0	0	0

15 (electron)	4	4	4	4	4	4	4	4	4



With this ruletable you can use the Insert key the x key, and the 2

and 1 keys to screen-edit wireworld patterns and feed electrons to them.



Szucs also reports a twenty cell Brian's brain pattern which evolves

into a butterfly gun.  This ties but does not better the existing record.

Both known patterns are made up of a four-cell hauler, seven outriggers,

(five loose and two tight) and two sparks.



Here also is a Pascal program I wrote for generating a wire.ca lookup

table to use in the CA module of CA Lab.  A simple of seeing something

happen is to use the CA Lab screen editor with command o ( for open 

polygon ) to draw a bunch of intersecting state 2 lines and put

some state 1 electron heads on it perhaps with state 4 tails next

to some of the heads.



PROGRAM Wire;

{

Bit usage: 

   Bits 3 thru 8 are unused

   Bit 2 is indicates an electron tail

   Bit 1 tells if you are on a wire or not

   Bit 0 is the firing bit, indicating an electron head

State usage:

   States 5 thru 255 are unused

   State 4 is an electron tail on a wire

   State 3 is unused ( potential photon with State 6 a photon tail )

   State 2 is a wire with nothing on it

   State 1 is a an electron head on a wire

   State 0 is blank nothing

}



 USES Camake;

{$F+}

FUNCTION Carule(Oldstate,NW,N,NE,W,Self,E,SW,S,SE:integer):integer;

VAR

   Eightsum, NewSelf:integer;

BEGIN

  Self := Oldstate;

  Eightsum := NW + N + NE + W + E + SW + S + SE;

  Self := Self AND 7;

  CASE Self OF

       0,3,5,6,7: NewSelf := 0;

       1:       NewSelf := 4;

       2:       IF ( (Eightsum = 1) OR (Eightsum = 2) ) THEN NewSelf := 1

                ELSE NewSelf := 2;

       4:       NewSelf := 2;

  END;

CaRule := NewSelf;

END;



BEGIN

    WorldType := 1;

    GenRule(Carule);

END.



Enjoy



rudy@autodesk.com


