Shvartz, can you help me out?

[Botsareus]

I mean , have we not gave it enough time? , because: DNA is mostly random junk too, But some specfic mutations can make dromatic changes.

[shvarz]

Robots evolve code that works.  That's all evolution cares about.  It does not matter how much junk you have and how many steps you have to go through to get something done as long as you get it done.

[PurpleYouko]

I think the trouble is that DB DNA is a mathematical language so we are mutating different routes by which we can reach a usable mathematical function.

For example sqrt(sqrt(16^2)) is 4 but change any one of the parts and it changes dramatically. Sqrt(sqrt(16^3)) is now equal to 8
Sqrt(sqrt(16^4))  is now equal to 16
Sqrt(sqrt(16^5))  is now equal to 32

Changing this one number has an exponential effect on the final result.

With real DNA you shouldn't get the same level of compounded difference when you change a single small part.

Another point is that real DNA has a very small number of possible values for each point. The complexity is made up by using longer strings of these values. This allows for a massive number of small gradiations that can do more or less the same thing. (correct me if I'm wrong here. I am no Biologist)

In DB we have macro commands which are simply swapped out in their entirety. One single command such as .up is probably the equivalent of a few hundred (or even thousand) base pairs.
Changes in DB are often catastrophic rather than gradual so it is easier to get up a dead end with no way out. The only way out is often to precisely retrace the steps that got you in there in the first place.

In short any kind of mutation that has no direct effect on the way a bot lives, will not be selected against but in later generations it can become largely imutable (as Shvarz said earlier) as any change to it just ...

a.) increases complexity still further but without improving the general fitness.
b.) increases complexity while decreasing general fitness.

I think one possible problem with DB is that the genome always tends to get longer, very quickly. ie. there aren't enough possibilities to delete data points in the evolution code.

[Ulciscor]

Whenever I start a sim I set the delete and change mutations to have a higher probability than the others because I think they lead to more useful muations.

I still think pattern mutations are a solution as in DNA bases are read in patterns, I.e. groups of 3.

[PurpleYouko]

That is pretty much what we do most of the time. "Insert a new condition" will add a 3 part condition and so on.
Of course we can still add or delete single points too.

[Botsareus]

Yea how about insert a new command with complete numbers with the proper range, the label itself and the store command. ex:

-1 .shoot store 'inserted as a whole
25 .aimdx store 'inserted as a whole

I agree with PY on:

Of course we can still add or delete single points too.

And it can change it to out of range if it wants to.

And If you really start to talk about complete numbers with proper range , then insert a new instruction should do range checking as well.

But, If you REALLY want numbers to (almost) always be in range, then good luck , its one bloody long select case to write for each bloody sysvar, I am not doing it  :P

[PurpleYouko]

Yea how about insert a new command with complete numbers with the proper range, the label itself and the store command. ex:

 
-1 .shoot store 'inserted as a whole
25 .aimdx store 'inserted as a whole

It does exactly that now. I wrote the code myself and tested it. Originally it did this but not very efficiently. Now it inserts the entire condition or command with values in the right ballpark for them to work.

Of course we can still add or delete single points too.

And it can change it to out of range if it wants to.

Yes to a degree it can go out of range, however it is designed to keep the value being mutated, somewhere close to the original value

And If you really start to talk about complete numbers with proper range , then insert a new instruction should do range checking as well.

It does, to a dgree. You can't expect it to be in exactly the right range to work perfectly. For example, the value stored into .aimsx can be in pretty much any range as long is its magniude is less than 32000. However .fixpos (and some others) can only take zero and non-zero as inputs. so if the line...

Code: [Select]

187 .aimsx store
should mutate to

Code: [Select]

187 .fixpos store
You can't expect the code to also change the 187 to something meaningful by searching a massive database of suitable ranges.
If the robot evolves such a crappy line of code then it is just going to fix itself to the spot and die. Tough! That's evolution for you.

But, If you REALLY want numbers to (almost) always be in range, then good luck , its one bloody long select case to write for each bloody sysvar, I am not doing it 

You certainly have that right!

But then again I am still waiting to get my hands on a working version of the new code that Num is working on. The stuff he has already given me is so radically different from V2.36.7 that I don't know where to start with debugging it until it is at least mostly working. I would estimate that he is totally re-writing about 10% of the entire code.

[Botsareus]

Good Work, Lets release that version and see what happens. Personally I can’t wait to try it out myself:

I came up with an ultra new ultra hyper way to evolve first bot, but guess what? in the current version this ultra new method crashes the simulation. And the error is so deep in the source code, good luck finding it. (its something to do with not finding some kind of dna term and searching beyond the ubound of the dna stack)

Anyway here is exactly what I was doing and plan to try again (hopefully that error will be fixed, if Num or PY care enough to experiment with the following them selves):

I set plants with no mutations, and First bot with mutations about "200!" <--don’t get scared I gave them a good chance to survive because:

After checking and unchecking F1 mode,  I set the number of plants to be displayed on the screen at start up to be "400!". The idea is the robot will mutate and reproduce like crazy, then the plants will stabilize back to F1 conditions, and only the best robots from the ~300 on the screen will stabilize to ~60. (If natural selection indeed exists, and there got to be some mutations that ended up better, not worse, then we should get a better resulting robot.)

 The problem is when the robot population goes over ~100 the simulation crashes, I also see robots with birth ties / ties, when moved from one side of the screen to the other (on the borders) , the ties stretch out for a second all the way across the screen. I mean just by looking on this entire picture you know something’s gunna crash any second now...

[PurpleYouko]

Good Work, Lets release that version and see what happens. Personally I can’t wait to try it out myself:

:blink:

Already did. Ages ago. It was called V2.36.7. I actually modded the mutations code back in 2.36.2 though.  <_<
Num may have changed things a little for .7 but I don't think he got that far into it.

The source code is even up there on both servers. Check it for yourself.

[Botsareus]

Then why is Shvartz having trouble with my little first bot? :/

Shvartz:

Consider this: when we program bots we write "a b store". Bots never evolve things like this. They go through complicated scenarios often involving several genes. Numbers are placed on stack, manipulated in many different ways and finally they are stored into memlocs.

[PurpleYouko]

Then why is Shvartz having trouble with my little first bot? :/

Shvartz:

Consider this: when we program bots we write "a b store". Bots never evolve things like this. They go through complicated scenarios often involving several genes. Numbers are placed on stack, manipulated in many different ways and finally they are stored into memlocs.

This is complete bollox!  :angry:

The robots can and do evolve stuff like a b store.

They evolve it in a single step too.

The "insert command" function makes a space of 3 positions in the DNA array, then it randomizes a value and a sysvar and sticks a store on the end and shoves it all into the space it created

Result = a b store

If the robots are not doing this then somebody has fucked up the code in the last release because I spent a lot of time making sure that this is exactly what would happen!

[Numsgil]

Went on vacation for a few days, now I'm ready to come back and face the new problems.

Bots will sometimes evolve a b store, I've seen it in the more recent versions, but you must remember that it's rather rare for any kind of massive run (3 whole commands!) to be useful at all since they're just picked at random.

Here's the way I see it.  Yeah, a bot that evolves a complex function to just get 4 seems odd.  But remember that the store statement takes the top two values in the stack, and doesn't care how it gets them.

So suppose we call our 500 command function f(x).  we have f(x) b store.  A new mutation may insert an "a" after f(x), making it f(x) a b store, which entirely overrides the whole 500 command f(x).  If the "a" is doing what f(x) used to, f(x) will slowly degrade into something else, maybe junk, maybe useful.  If a single command like that can't replace the whole f(x) thing, then f(x) is obviously doing something that's important.

So I definately don't see this as a problem, since a single mutation can replace large sections of code.  The easiest way to "fix" it so that larger DNAs are selected against is to incurr some built in costs on DNA replication.  Not incredibly difficult to set up and be user definable.

About genes communicating via the stack:  assuming you view this as undesirable (depends on what you're trying to do of course) we could implement a clearst command that erases the stack.  Bots can evolve them or no depending on their usefulness.

Also, the chromosome idea I proposed would allow for seperate stack threads so you can evolve several different DNA threads that can't communicate through the stack except within the same chromosome.

As to the evolution of Bot's bot, I would try running a sim with Zero Momentum mode and largest sim size.  Just decrease costs until the bots can survive  (they can definately survive if nothing costs any energy, so there must be some cost level they can survive on), and then instead of increasing physics constants, increase the costs.  That would select for efficiency.

I'll implement an optional cost-per-DNA-unit (either per reproduction or per cycle) so we can play with downward selective pressure on DNA length.

[Botsareus]

Num, I cant figure this errors out. Can you try the stuff I am talking about: http://s9.invisionfree.com/DarwinBots_Foru...ndpost&p=850925
in that post.


I did not mess with the source code before I got it. But I did debug it, its somthing about searching then dna beiond the ubounds.


As for everything Num and PY have sayed. I totaly agree.

[Numsgil]

Num, I cant figure this errors out. Can you try the stuff I am talking about: http://s9.invisionfree.com/DarwinBots_Foru...ndpost&p=850925
in that post.

I did not mess with the source code before I got it. But I did debug it, its somthing about searching then dna beiond the ubounds.

I have no idea.  I've totally rewritten alot of the DNA parsing routines (consolidating alot of functions inthe process) so I'm not even sure it's relavent anymore.

Does it happen with the latest official release?  If you can reproduce a bug in that, then I can see if it's real or not.  Otherwise I'm at sort of a loss.

[Botsareus]

omg , I toled you what I did in the latest release to get this bug.
All you have to do is follow my instructions and reproduce it for yourself.
Is it so hard?
...

yea lol , dont forget to reproduce it from visual basic and not from the compiled virsion, other wise there is no way to debug it.  :)

...



Edit: Bots is in a sarcastic mood tuday , do not ask.

Edit: I cant really call it sarcasm bc all my directions are lagit, unlike my spelling...