Register | Sign In


Understanding through Discussion


EvC Forum active members: 60 (9209 total)
1 online now:
Newest Member: Skylink
Post Volume: Total: 919,444 Year: 6,701/9,624 Month: 41/238 Week: 41/22 Day: 8/6 Hour: 1/2


Thread  Details

Email This Thread
Newer Topic | Older Topic
  
Author Topic:   Percy's Alife Project
Rei
Member (Idle past 7264 days)
Posts: 1546
From: Iowa City, IA
Joined: 09-03-2003


Message 61 of 63 (61570)
10-19-2003 3:12 AM
Reply to: Message 60 by TheoMorphic
10-18-2003 9:41 PM


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]

This message is a reply to:
 Message 60 by TheoMorphic, posted 10-18-2003 9:41 PM TheoMorphic has not replied

  
TechnoCore
Inactive Member


Message 62 of 63 (66349)
11-13-2003 5:57 PM


This seems like a insanly computing-time/storage costly project.
I would not use a real grid at all. Just position-vectors to where each object in the world is. Then let every object in your world contain a sub-grid. So a cell (an object) allocates exactly as many gridscells it needs to represent itself in 3d. It also contains a position-vector describing its position in the world. Maybe also a vector describing the radius of a bounding-sphere that completly suurounds the object.(for speeding up distance calculations between objects) Then place all these objects within an oct-tree. (So you only do distance-calculations between objects that are actually close to eachother.) Every "frame" check whichs objects are close enough to eachother to interact. If that is the case, you can apply the same logic you would have had in a true 3d-grid.
Im maybe way off here... didn't read all mails, just the first few and last

  
Percy
Member
Posts: 22938
From: New Hampshire
Joined: 12-23-2000
Member Rating: 6.9


Message 63 of 63 (66351)
11-13-2003 6:16 PM


I should comment that I will be returning to this effort as soon as demands in a couple other areas of my life settle down a bit, probably within a few weeks. Thanks again to everyone for the very helpful feedback and offers of help.
--Percy

  
Newer Topic | Older Topic
Jump to:


Copyright 2001-2023 by EvC Forum, All Rights Reserved

™ Version 4.2
Innovative software from Qwixotic © 2024