Code center > Suggestions
Non-Determinstic Bot DNA flow
Numsgil:
The basic design philosophy is that the bots are like a giant switch board, like those old fashioned telephone operators.
The DNA is like the telephone operator.
The DNA connects various bits of memory to other various bits of memory.
Each memory bit is simple, as you say Griz, this is sort of the purpose of compelx adaptive systems.
The memory bits are things like xpos, ypos, amount of body, go forward, shoot, etc. Really basic, basic building blocks.
The potential complexity comes in the fact that the DNA is Turing Complete (I haven't proven this yet but I believe it to be so... May be some issues with not being able to access it's own operating memory space...)
Numsgil:
We may be just arguing over simantics. Griz, perhaps you could point something out specifically that pushes the program in the wrong direction in your opinion, if even slightly.
As far as I can tell, the worst (any generic, not specifically Griz) you can argue is that our priorities are misplaced, that we waste time working on frivelous features instead of working on core features (that you want).
But the core features themselves aren't regressing, and the adding of new features (minus introduced bugs obviously) doesn't hurt the unworked-on older features.
Darwinbots should be an everything-to-everyone platform. A kind of swiss-army knife of the ALIfe community. And I see no reason why it shouldn't be just that. If a feature you want to see implemented hasn't been, a good place to start is to look at the code yourself.
I'm actually working about 50/50 between adding core things (like a diploid DNA in the future, which the current 2.4 DNA reworking was essential for).
Greven:
OMG, atleast I got one supporter.
I always thought that I was stupid about thinking DB going more into combat that evolution.
Well atleast I haven't left the DB community to it self, I am the invisible stalker of you scared nightmares combat people... ;)
Okay back to reality. Griz you are saying exactly what I had in mind, but never were able to write. Well it is hard to make ALife simulations, it not just something you just sit down and do overnight, or over week. It takes a very long time.
I think for DB, it has lost the ability to evolve truely interesting behavior. Something like a WOW-experince. But on the other hand, it is very good (or could be) at modeling eco-systems, without interference from mutations. Mutations in DB are almost lethal becuase of the highly complex structure of the vitual bot CPU (the bots internal building, the stack and the memory.) and the DNA language. Mullers Rachet what ever you all put into this haven't even been proven in real biological creatures and have only partial been proven in digital organisms.
I could continue, but in short, when you put more complexity into DB (Griz's term, Intelligent Design, uh I love that word ;)) you only make evolution weaker, hard & lesslikely to produce something useful.
I have high regards about the two main figures in DB now -->
PY & Numsgil.
But we all have different tastes and I think you two (PY & NUM, NOT INSULTING!!!! some please) have worked so long for this project (especially PY) that you have become narrowminded.
Were is the GRID everyone has been talking about since the dawn of time?
Were is the metabolism everyone has been talking about since everyonce began talking about the grid?
Were is this and were is that?
Instead we get --> planteaters singularities, smiliy-mode, shapes-mode, electricity (not implemented yet, but who knows), even Num began discussion Relativity Mode, Zelos began a thread about naming DB-units, Distributed Programming the list goes ever on....
I havent been the best my self, but come on, lets begin discussion the details in the grid, metabolism, no longer have an veggies definition, that bots can turn veggies and vice versa.
Or can it be that it will be confusing with all this to the combat sims, and thereby being left out???
And don't give me an answer about porting the code to C, or that it is boring.
....
Greven:
Well Num came first...
Oh crap pushed the back button, and swihcehasfjk all my writing were gone!!!!!
Ah I hate that!
But DB as
--- Quote ---A kind of swiss-army knife of the ALIfe community
--- End quote ---
Well Num, a swiss-army knife is a nice tool. But how often do you use a swiss-army knife to cut down a tree?
or
Build a brigde?
For a brigde you need two things (atleast):
-Rope & Tree
If you have the rope, you can use the swiss-army knife to cut it in pieces.
But what about the tree. You could cut down a tree, but it will take you a very long time, and then cut the tree out in planks take even longer.
Well you could cheat and buy some prefabricated tree, then it is easy to make a brigde, but you are cheating. Well an axes would actually have been a better tool for making this brigde.
This is what DB does, cheating, gives out the tree, not letting evolution figure out that it would be better to have an axe and cut down a tree.
In short when generalizing, you lose much specialization ( :P ). You can do a little of this, and a little of that and so on. But nothing more.
And even the above quote don't even give any meaning. Artificial Life is much more that just simulation, what about GP, EP, other GA's etc.
Botsareus:
Carlo the main problem (sorry, I am using vb) is: what if you have:
--- Quote ---If cond then
x = x + 1
End If
If cond2 then
y = y + 1
End If
If cond3 then
moo() 'just to make sure there is no 50 , 50 chance possible
End If
If cond4 then
moo() 'just to make sure there is no 50 , 50 chance possible
End If
--- End quote ---
If the genes are executed at random then we have:
x = 1 y = 20 , or y = 1 x = 20 , or y = 11 x = 5
but to get x = 10 y = 10 is almost impossible...
otherwise your method works fine...
A possible solution will be to use some Ensteins stuff:
Calculate the length of each gene of each robot, and execute some robots more times then others , but execute them with x = x + 0.1 or somthing. The actual cycles will be actualy 10 cycles for some robots, 20 cycles for some robots , and 2 cycles for some robots. But the end result was that each robot increased there x correctly.
But here I am moving to what Numsgil is already done brainstorming about. And my method seems more cpu hungry then Numsgils anyway...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version