Bots and Simulations > DNA - General

Bots with Arrays

<< < (3/3)

Prsn828:
When he says that a codule can only appear on the stack once, he means that if the stack looks like: A,B,C : and you add A to the top, you end up with: A,B,C : because the second A is ignored.

Since a codule calling on another codule remains on the stack until all of the codules IT calls AND itself have completed executing, there should be no way to get stuck in an infinite loop.

Numsgil:

--- Quote from: Moonfisher ---
--- Quote from: Numsgil ---Basically you can't call a codule that is already on the call stack
--- End quote ---
But what if I have 3 codules A, B and C, and A calls B, B calls C and C calls A ? (The classic downfall of some Garbage collectors)

--- End quote ---

As Prsn says, it's ignored.  The term I use for this is "fizzle", which is borrowed from the Magic the Gathering card game I played in my youth.  Other commands can fizzle, too.  10 mult, for instance, will leave 10 on the stack (mult fizzles).  false 10 20 store will take 10 and 20 from the stack, but no store action occurs.  (This is in DB3 DNA).


--- Quote ---Well I don't know what you have planned in that area, and it's hard for me to speculate till I've had a look at how the dna will work in DB3.
I imagined the pointer would be usefull for removing infections and for manualy charging virus code. Figured it might make evo sims more interesting.
But it sounds like you may be rethinking the self modifying code idea, and generaly the way viruses work. So it's hard to say anything realy.
--- End quote ---

You can play with basic DB3 DNA using the command line interpreter.  It doesn't have codules or any of the other macro features, though.

Viruses wouldn't get inserted into the DNA.  Instead they'd form a new chromosome, which is essentially another DNA strand which runs in parallel (no interaction is possible between chromosomes except through the bot's memory, and then only during the next cycle).  It would be treated similarly to diploid bots.  I haven't totally decided how conflicting commands from different chromosomes might be resolved.  The idea is that each chromosome is like a separate program.  They have their own protected memory space, but they share the same hardware.  And their protected memory space gets resynced every cycle.

Not sure if I explained any of that well   The two primary purposes for self modifying code I can think of would be either viruses (offense and defense), or aggressive point mutations of a certain "magic number".  I'm specifically trying to prevent the need or ability in regards to viruses, since it tends to promote obtuse code which is robust to viral infections.  My goal is for it to be safe to write simple, straightforward code (there's sort of a maximum behavioral complexity you can write a bot for before the code gets too complicated to deal with).

The point mutations of "magic numbers" is a reasonable use case, but it wouldn't work very well if you had to rely on pointers, since the pointers themselves would drift after insertion/deletion mutations.  One idea might be that bots can specifically "hyper mutate" individual codules.  The codules provide a "handle" to an arbitrary grouping of DNA bps, so a codule might have just a single number in it and the bot can mutate it.  But there are some niceties as far as tracking heritage when DNA is static except for mutations.

Moonfisher:
So... there would be no loops at all...
Only advantage then would be that you can structure your code a litle easyer... I guess it could help evo sims though.
Sounds cool that other commands can fizzle by accident though, will probably make evo bots more interesting and it'll challenge bot coders to create safer code.

And the virus idea sounds good. One idea for determining conflicting actions could be to base it on the strength of the virus shot and the virus defences. So you can be badly hit and the virus has an 80% chance of "winning" an action, or you can suffer a weak hit and it'll only win 10% of the time. So the strength of a virus shot would be worth more than extra lifetime.

And the pointer wouldn't slide too much if locations where relative to the position in the code (Wrapping when exceeding the code length).
Then it would only slide when new code is inserted between the pointer code and the code it's pointing at. And as far as evolution is concerned it may be an advantage at times when a useless pointer suddenly points at something usefull. But mostly I'm thinking of a line like this :
110 inc
100 rnd &110 store

OR

100 rnd & 300 rnd & store

By having commands that execute things from random locations in the code the chances of finding something usefull are higher.
Half the evo bots I've seen use shifting operators to get more random results, and have complex lines that manage to end up with just the right odds to accomplish what needs to be done.
This is the effective code for the zbot I've been running lately. It's been compressed from over 100 bp to 26 (And I cut away the last bits of useless code)

 .tie dec
 .shoot dec
 59 << *.robage 192 ceil >> rnd << << ++ store

I tryed messing with everything on that line, and it's untouchable, I can't even change what seems to be constant values, like 59 <<, I suspect it's because it can be either 118 or 119.
Any changes to it will make it weaker, all the giberish has a clear purpose.
So it seems that evolution actualy prefers confusing and random code, probably because specialists tend to die in the long run.


As for self modifying code I was thinking there are some plusses where evolution is concerned, since a bot can go through a lifespan changing it's dna as it gets older. I would probably sugest seperating the inherited genome from the executed genome and have seperate commands for changing them. Theres a difference between wanting to create different offspring and the evolution of your own genome as you grow "old".
But I can definately also see all the issues of tracking different kinds of changes to the genome and understanding how an evo bot works by having to track it's internal changes. Viruses would be less of an issue if they work the way you described above though.
So I realize it's harder to observe whats realy going on in the code, but I often find *.robage involved in the actions taken by zero bots, so it seems like age is often a factor, and changing behavior can be realy usefull in evolution.
Also being able to change offspring dna could be usefull for adapting offspring to the current environment.

At the very least if self modifying code is off the table then I would sugest changing the way RNA works and allowing you to apply an "offset" to a specific bp in the genome for an offspring to turn it into a different action or value. The offspring can then change or shed the offset in it's code when it produces offspring of it's own. (Again this would work by changing the genome that will be inherited by offspring, except you would apply the change as an offset, so the offspring has the ability to revert back to normal for future offspring.)


Anyway I'll go play with that interpreter...

Navigation

[0] Message Index

[*] Previous page