Register | Sign In


Understanding through Discussion


EvC Forum active members: 45 (9208 total)
1 online now:
Newest Member: anil dahar
Post Volume: Total: 919,519 Year: 6,776/9,624 Month: 116/238 Week: 33/83 Day: 3/6 Hour: 0/0


Thread  Details

Email This Thread
Newer Topic | Older Topic
  
Author Topic:   Percy's Alife Project
Dr Jack
Member (Idle past 136 days)
Posts: 3514
From: Immigrant in the land of Deutsch
Joined: 07-14-2003


Message 31 of 63 (60258)
10-09-2003 10:57 AM
Reply to: Message 30 by Percy
10-09-2003 10:46 AM


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'.

This message is a reply to:
 Message 30 by Percy, posted 10-09-2003 10:46 AM Percy has not replied

Replies to this message:
 Message 32 by NosyNed, posted 10-09-2003 11:38 AM Dr Jack has replied
 Message 33 by awinkisas, posted 10-09-2003 11:51 AM Dr Jack has not replied

  
NosyNed
Member
Posts: 9012
From: Canada
Joined: 04-04-2003


Message 32 of 63 (60262)
10-09-2003 11:38 AM
Reply to: Message 31 by Dr Jack
10-09-2003 10:57 AM


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.
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.

This message is a reply to:
 Message 31 by Dr Jack, posted 10-09-2003 10:57 AM Dr Jack has replied

Replies to this message:
 Message 34 by Dr Jack, posted 10-09-2003 12:10 PM NosyNed has replied

  
awinkisas
Inactive Member


Message 33 of 63 (60263)
10-09-2003 11:51 AM
Reply to: Message 31 by Dr Jack
10-09-2003 10:57 AM


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.

This message is a reply to:
 Message 31 by Dr Jack, posted 10-09-2003 10:57 AM Dr Jack has not replied

  
Dr Jack
Member (Idle past 136 days)
Posts: 3514
From: Immigrant in the land of Deutsch
Joined: 07-14-2003


Message 34 of 63 (60267)
10-09-2003 12:10 PM
Reply to: Message 32 by NosyNed
10-09-2003 11:38 AM


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.

This message is a reply to:
 Message 32 by NosyNed, posted 10-09-2003 11:38 AM NosyNed has replied

Replies to this message:
 Message 35 by NosyNed, posted 10-09-2003 1:39 PM Dr Jack has not replied

  
NosyNed
Member
Posts: 9012
From: Canada
Joined: 04-04-2003


Message 35 of 63 (60286)
10-09-2003 1:39 PM
Reply to: Message 34 by Dr Jack
10-09-2003 12:10 PM


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.

This message is a reply to:
 Message 34 by Dr Jack, posted 10-09-2003 12:10 PM Dr Jack has not replied

Replies to this message:
 Message 36 by awinkisas, posted 10-09-2003 3:30 PM NosyNed has not replied
 Message 39 by Peter, posted 10-10-2003 6:50 AM NosyNed has not replied

  
awinkisas
Inactive Member


Message 36 of 63 (60296)
10-09-2003 3:30 PM
Reply to: Message 35 by NosyNed
10-09-2003 1:39 PM


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?

This message is a reply to:
 Message 35 by NosyNed, posted 10-09-2003 1:39 PM NosyNed has not replied

Replies to this message:
 Message 37 by Percy, posted 10-09-2003 5:21 PM awinkisas has replied

  
Percy
Member
Posts: 22955
From: New Hampshire
Joined: 12-23-2000
Member Rating: 7.1


Message 37 of 63 (60314)
10-09-2003 5:21 PM
Reply to: Message 36 by awinkisas
10-09-2003 3:30 PM


awinikisas writes:
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.
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

This message is a reply to:
 Message 36 by awinkisas, posted 10-09-2003 3:30 PM awinkisas has replied

Replies to this message:
 Message 45 by awinkisas, posted 10-10-2003 12:56 PM Percy has not replied

  
Peter
Member (Idle past 1740 days)
Posts: 2161
From: Cambridgeshire, UK.
Joined: 02-05-2002


Message 38 of 63 (60401)
10-10-2003 6:48 AM
Reply to: Message 1 by Percy
10-06-2003 6:59 PM


Memory efficiency
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.

This message is a reply to:
 Message 1 by Percy, posted 10-06-2003 6:59 PM Percy has not replied

  
Peter
Member (Idle past 1740 days)
Posts: 2161
From: Cambridgeshire, UK.
Joined: 02-05-2002


Message 39 of 63 (60402)
10-10-2003 6:50 AM
Reply to: Message 35 by NosyNed
10-09-2003 1:39 PM


Why OO ?

This message is a reply to:
 Message 35 by NosyNed, posted 10-09-2003 1:39 PM NosyNed has not replied

  
Peter
Member (Idle past 1740 days)
Posts: 2161
From: Cambridgeshire, UK.
Joined: 02-05-2002


Message 40 of 63 (60404)
10-10-2003 7:11 AM
Reply to: Message 26 by Parasomnium
10-08-2003 5:53 AM


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.

This message is a reply to:
 Message 26 by Parasomnium, posted 10-08-2003 5:53 AM Parasomnium has not replied

Replies to this message:
 Message 41 by Dr Jack, posted 10-10-2003 7:21 AM Peter has replied

  
Dr Jack
Member (Idle past 136 days)
Posts: 3514
From: Immigrant in the land of Deutsch
Joined: 07-14-2003


Message 41 of 63 (60405)
10-10-2003 7:21 AM
Reply to: Message 40 by Peter
10-10-2003 7:11 AM


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.

This message is a reply to:
 Message 40 by Peter, posted 10-10-2003 7:11 AM Peter has replied

Replies to this message:
 Message 42 by Peter, posted 10-10-2003 7:52 AM Dr Jack has replied

  
Peter
Member (Idle past 1740 days)
Posts: 2161
From: Cambridgeshire, UK.
Joined: 02-05-2002


Message 42 of 63 (60408)
10-10-2003 7:52 AM
Reply to: Message 41 by Dr Jack
10-10-2003 7:21 AM


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)

This message is a reply to:
 Message 41 by Dr Jack, posted 10-10-2003 7:21 AM Dr Jack has replied

Replies to this message:
 Message 43 by Dr Jack, posted 10-10-2003 9:18 AM Peter has replied

  
Dr Jack
Member (Idle past 136 days)
Posts: 3514
From: Immigrant in the land of Deutsch
Joined: 07-14-2003


Message 43 of 63 (60409)
10-10-2003 9:18 AM
Reply to: Message 42 by Peter
10-10-2003 7:52 AM


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.

This message is a reply to:
 Message 42 by Peter, posted 10-10-2003 7:52 AM Peter has replied

Replies to this message:
 Message 47 by Peter, posted 10-13-2003 7:23 AM Dr Jack has replied

  
Percy
Member
Posts: 22955
From: New Hampshire
Joined: 12-23-2000
Member Rating: 7.1


Message 44 of 63 (60412)
10-10-2003 9:36 AM


On Space
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

Replies to this message:
 Message 46 by Rei, posted 10-13-2003 6:08 AM Percy has not replied

  
awinkisas
Inactive Member


Message 45 of 63 (60427)
10-10-2003 12:56 PM
Reply to: Message 37 by Percy
10-09-2003 5:21 PM


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?

This message is a reply to:
 Message 37 by Percy, posted 10-09-2003 5:21 PM Percy has not replied

  
Newer Topic | Older Topic
Jump to:


Copyright 2001-2023 by EvC Forum, All Rights Reserved

™ Version 4.2
Innovative software from Qwixotic © 2024