Percy's Alife Project

My advice; don't attempt this in a language you're not familiar with. The task you've set yourself is challenging, adding additional obstacles is not wise.Java is not interpretted, it is compiled to byte code. Well written Java running on a good JIT compiler will be about 80% of the speed of C++ for a typical application. However yours is not a typical application, it is probably more processor heavy and the penalty may be higher. C# is similar in performance to Java.I strongly suggest you don't use any form of compilation to native code for any of your A-life 'organisms'.

If the task is large enough the additional cost of learning a new language isn't a signifcant fraction of the total cost. It presents risks of having to redo early work. It also presents significant risk of finding unexpected roadblocks such as inherent performance limits. But a good plan would be to explore the design with prototypes to determine what will work in the "tight spots" anyway.

I'm a big fan of C# and it is similar enough to C++ to require little or no learning curve. There is even an open source version of the .NET framework available for other platforms, but I don't know if it's complete yet: Home | Mono There is even competing GNU project for those adverse to MS: DotGNU Project C# under the .NET framework gets compiled to MSIL (Microsoft Intermediate Language) similiar to java's bytecode. This gets JIT'd at runtime to native code. It won't run as fast as C++ but it is machine independant. As long as the target platform has a .NET CLR then the app will run.

Statistics show that working (8 hr a day) programmers take six months to get up to speed with a new language, and that code produced in that time takes longer, is buggier and is less efficent.In any case I doubt whether he'd see a big productivity push from changing to Java anyway; C++ is a good language.

I bow to the numbers. Maybe I have a bias because I like trying out new things.I like both languages (and have sort of intermediate skills in both, though rusty). I'm afraid C++ is too loaded with history to be a "good" language. It does have the kind of focus that this project may need; performance and the ability to "twiddle" at very low levels.Of course, this project must use OO.

IMO the major programmatic issue that needs to be resolved early in the process is how to interpret/compile the algorithms attached to objects. It will take a lot of time and effort to create an interpreter. I did some work in this area in university and it is not trivial. We could save a lot of time if the algorithms could be written in an established language and dynamically compiled when needed by an existing compiler. To this end Java and any .NET framework language will do the trick. C++ cannot do this unless you use Managed Extensions for C++ which brings it into the .NET realm.This raises another issue around how the algorithms get modified. The program would have to know how to program. It would need to know about looping, branching, declarations, etc. Or would we go for a sort of GA approach where random changes are made to the code? If it compiles it is a successful mutation otherwise the algorithm is destroyed. Whether the change is beneficial or not will be left up to the success of the organism.There might be a way to eliminate the need for dynamic compilation altogether. I propose that we create a set of simple algorithms, encoded as functions/methods, that can be used in combination to perform more complex tasks. Similar to the 4 base pairs of DNA that can be ordered differently to create different proteins. This way we don’t have to worry about recompiling modified algorithms. Instead larger algorithms are built up out of the smaller base set of predefined algorithms. Sort of like a RISC computing approach. The ordering of the base set algorithms could be modified using the GA paradigm as described above.Any thoughts?

I think you've hit upon the right approach. Are you at a point where you could enumerate a list of what some of these primitive functions might be? I can think of a few, but I'm unsure what level of granularity you had in mind:

• Increment(int& x)
• Decrement(int& x)
• Assign(int &x, Expression)
• Expression(...)
• Conditional(Expression(...))

Is this close to what you were thinking?--Percy

You don't need to store 10^18 of anything.You only need sufficient memory to store all of the objects
in your univers (which could be large, but not as large as
the universe itself).Instead of defining a temperature across your univers you need
to locate heat sources within the universe and calculate temp.
at any location via some radiant heat function (incorporating
heat absorption by other objects).Each object has a place in the univers, rather than each place
in the univers has an object.Physical charateristics are functions of the objects present.

Why OO ?

As i said in a previous post -- it's not a 3d array that
you are running through -- it's an object list each of
which has a 3d coordinate.The universe doesn't exist -- it's just the space that objects
occupy.I used to write text adventures when I was a kid, and had
two separate mapping techniques one very specific (like exit
to the north goes to location 4 etc.) but also had
infinite deserts and forests all within a single location.
Special actions/objects were then related to locations within
the infinite space within a single location object.

With densely populated 'cellular' universes, treating it as a continous array is much more efficent. I don't know which case Percy's vision corresponds to.

I assume you are referring to processing efficiency ...Using a cellular universe means that no matter how many objects
exist within it it takes a broadly similar time for one cycle
and takes as much memory regardless of density.Viewing the universe as a space which has objects in-it means
you only have to store the objects, and iterate over them for a
single cycle.Can't quit see the efficiency problem -- unless it's about locating
adjacent objects....It's a tradeoff between memory and processing speed (as ever)

Yeah, locating adjacent is much more efficent in an array structure. Now since A-life is generally heavily based on seeing what is around, this can be an important consideration. It's slightly more memory efficent too, since co-ordinates do not need to be stored.But, of course, only on a high density array.

The neat thing about a sparse array is that only occupied locations are represented. The sparse array implementation has overhead, and so if you fully populate a sparse array it will take far more space than a normal array, but in that case you shouldn't be using a sparse array. You have to decide ahead of time whether your array is sparsely or densely populated. This was Mr Jack's point.Is our universe sparsely populated? At least initially, I think, the answer is yes. It would be neat to see organisms moving to occupy formerly empty regions.If in a sparsely populated universe you do not use a sparse array but instead just assign objects coordinates with 3D space, then determining adjacency becomes a significant issue, at its simplest involving iterating across all objects checking their position to see if you've collided with them or not, but naturally efficiencies are possible. But determining adjacency in a sparse array is easy.The drawback with a sparse array comes when which locations are occupied is dynamic, which is exactly our situation. I've played with sparse arrays before, but not of this type. But the sparse arrays I've played with have been implemented from associative arrays which are in turn implemented from hash tables, and it feels to me that nulling out a hash location should be easy. In other words, if an object moves from one grid location to an adjacent grid location leaving the former grid location empty, it should be possible to simply change the association in the hash table. Any grid location with a null hash reference is, of course, empty.I'm no expert on sparse arrays. Perhaps someone has experience with more efficient implementations?--Percy

The proper definition of the primitive functions will directly affect the amount of variation that the organisms allow. Since the model you are proposing is roughly based on a molecular/protein level the actions that the primitives perform should be roughly analogous to actions that small molecules can perform. Large molecules/proteins would be represented by groups of objects each enacting their own action script. I think stateless functions i.e. functions that take no parameters, would be most representative of reality, plus they don't require any external storage. So I was thinking of something a little more high level such as:

• MoveXPos - moves in the x axis one unit positively
• MoveYNeg - moves in the x axis one unit negatively
• Same for Y and Z axes
• Spawn - object creates a copy of itself, useful for cell growth
• AttachAdjacent - object attaches itself to adjacent object
• ConsumeAdjacent - consumes adjacent object, useful for metabolic objects
• DestroyAdjacent - destroys adjacent object
• Seek - object moves towards the closest object
• AbsorbEnergy - object absorbs some energy from adjacent object, use for metabolic objects
• GoDormant - object no longer processes actions
• ActivateAdjacent - object "wakes up" adjacent object (enzymes?)

Objects would use a certain amount of energy for each action. When the object has no more energy left it could either become dormant or destroy itself.This is of course a preliminary list and I assumed that certain metabolic processes will be allowed. There are tons of questions regarding how some of these actions would work with respect to each other.What do you think?