quote:
quote:
I... wouldn't recommend that. Virtually everything will be a special case for z=1 (actually, typical worlds are either zero-indexed, or indexed over a wide numeric range in both directions. For non-floating point worlds, I prefer zero-indexed, as you can use inherent wraparound of your variables).
Not sure what you mean by zero-indexed in the context of sparse arrays - I'm probably being dense. As described in earlier posts, I'm planning to use a sparse array,
My apologies, I don't think I was very clear. You said for z=1. In general, a 3d universe either runs from z=0 to z=some positive value, or from z=some negative value to z=some positive value. If you're storing your coordinates in fixed-point format (instead of floating point format), there are often cases where you can simply let your variables wrap around on their own, saving you precious CPU cycles. But I think this is a bit of a sidetrack - whatever coordinate system you use to store your data in will be fine - the key is that starting a universe in 2d and expanding to 3d often works out harder than starting in 3d to begin with, because in 2d, most things work out to special cases in a 3d world - for an example, you'd never notice Gimbal locking in a 2d world.
quote:
Someone mentioned octants - I haven't investigated this yet, but just guessing at what it means the concept seems good.
That was me. It's a pretty effective method. In the simplest model, you can picture the world evenly bisected along each axis, thus leaving 8 octants. Each octant is a hash table entry - each has a list of all organisms (or organism components) that are inside of them. If you take a step further, you can subdivide each of those octants into 8 octants, and have each of those store a much smaller list. You can keep doing this until you only have a organisms per octant. You can then compare with everything within a certain number of octants away.
quote:
What I'd like to do is represent every unique evolutionary pathway. Oftentimes many objects would have the same pathway, and all such objects would include a pointer to a class holding both the pathway name and the functions and parameters representing that object type. I'm not planning to have any compilation step as part of the simulation.
Ok, so you're just going to store it in a string then (i.e., not class inheritance) - that's reasonable, so long as you're going to truncate its length. Picture it this way: evolution occurs on the order of tens of thousands, hundreds of thousands, millions, billions of generations. There's no way you could dream of holding a very long evolutionary pathway string for each organism.
quote:
My experience has been that careful design allows you to move more efficient implementations beneath well designed interfaces. I work in an industry whose products tend to have hundreds of thousands of lines of code, and which are used on machines with gigabytes of RAM and terabytes of disk, and which nonetheless oftentimes take a week to run. Adding efficiency and performance to a new feature after initial introduction is something we often do. I share the memory and performance concerns, but would prefer not to let such considerations overly influence the initial specification.
And my experience from alife sims is that they tend to gobble up memory
I'd just try to make sure that this isn't an afterthought.
quote:
It's interesting that simple rules can replicate some things about real life, but that doesn't mean that real life is following anything like the same rules.
Please keep in mind that the amout of evolution you will see is relative to the speed that the application runs. Thus, speed is utterly, completely critical to a good sim. So, even if the rules are simpler, if they run faster, you may well see more complex behavior.
quote:
I personally don't believe that the immense variety and sheer richness of real life cell behavior emerges from cellular automata.
I don't know... even Conway's Game of Life is turing-complete.
Conway's biggest problem is that it suffers from a lack of entropy, but that doesn't mean that all cellular automata must.
quote:
So by the same token, while I would like to have *a* physics, it wouldn't be *the* physics
A perfectly reasonable notion. But I would recomend that "a" physics that you chose include the ability for one part of an organism to drag others with it.
By the way, I really don't mean to sound overly critical here. It's always great to see more people work on different ideas for alife and genetic algorithms.
I started work on one a week ago based on primitive bases that act roughly like amino acids, to see what we can get to link up, starting with a random arrangement and different kinds of energy input. I'll post it on here when I get it done.
------------------
"Illuminant light,
illuminate me."
[This message has been edited by Rei, 10-19-2003]