Re: cellular automata and OOP
- To: mathgroup at smc.vnet.net
- Subject: [mg21727] Re: cellular automata and OOP
- From: Jens-Peer Kuska <kuska at informatik.uni-leipzig.de>
- Date: Wed, 26 Jan 2000 03:45:29 -0500 (EST)
- Organization: Universitaet Leipzig
- References: <86g137$hds@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
Hi, the mose efficient version is a C-Program like Gaylord et. al. do it. Beside the fact that object oriented programming is on of the most supid inventions ever made, it is a cummulation of foolishness to use oop in such a beautiful functional logic language like Mathematica. The OOP example from R. M"ader was (original) created for lectures of computer science students. It is just to show "dear students, you can get the full range of computer science with Mathematica". If you want to do OOP programming you should use SmallTalk, if you prefere functional logic programming you should use Mathematica and if you need efficient code you should use C. Hope that helps Jens Atul Sharma wrote: > > I would like to set up a cellular automata, but one that differs somewhat > from the standard described (for example) in the useful books by Gaylord et > al. The main difference is that multiple entities can coexist on the same > lattice sites, with interactions permitted only between entities on the same > sites. Ultimately, this may involve hundreds of entities on a given lattice > site, with 5-6 different entities permitted, each interacting with only a > subset of the remainder and each free to diffuse at each time step. In > addition, some of the entities will have internal dynamics requiring updates > at each time step. > > My question is this: > > What is the most efficient approach to implementing such a project in Mathematica. > My initial though was to set up OOP code as described by Maeder in the > Mathematica Programmer, with a constructor that assigns properties > (including lattice position) to each entity. Interactions would be handled > as events, with updates signalled by the 'time step' event. > > I have little experience in this area, and this may well be the most > inefficient design imaginable:) Any suggestions or examples would be > appreciated. > > Thanks. > > A. Sharma