Code center > Suggestions

Codules

<< < (3/7) > >>

shvarz:
I think what you are actually proposing would achieve exactly reverse - it will soften the rules.  The way I see it (although I may be mistaken) your proposals differ as follows:

Nums - we don't allow any infinite loops (assume bots with infinite loops immediatey die)
You - we allow bots with infinite loops to be born, but make it so that they die of energy loss

The end result seems to be the same: no bots with infinite loops, but in your proposal we also waste some processor cycles along the way.

EricL:
My understanding of the positions:

Me - allow bots with infinitie loops or other semantic inefficienies to be born, but they tend to die out fast and not reproduce because everything costs something.

Nums - allow bots with infinitie loops or other semantic inefficienies to be born, persist and even reproduce by mitigating the effects of their stupidity by putting limits on things in the name of providing a forgiving environment.  Execute infinite loops only so many times, truncate the maximum values they can store in .up and .dn, etc.

My way is a lot more effecient from a cycle perspective - ineffecient bots die and tend not to reproduce instead of potentially being allowed to survice despite their ineffeciences - but I don't think that is really the main issue which is about keeping the bar to creating/breeding something that successfully lives to reproduce sufficiently low that it stays fun.

shvarz:
Oh, I think I see.  But "infinite loop" is not a semantic inefficiency, it is a dead bot by definition because it can never complete execution of its DNA.  "Infinite loop" is (let me borrow you term) syntaticly incorrect.

Why not combine your two approaches?  Don't allow infinite loops AND charge a little bit for having a loop.  That's pretty much how current system works, it charges bots based on the length of their DNA.

EricL:
It's essentially impossible for the engine to apriori figure out if there is an infinite loop in a bot's DNA.  A bot with a infinite loop IS actually a syntatically correct program I.e there is nothing syntatcially incorrect about the code.  An infinite loop is a semantic error and it's generally computationaly prohibitive to try to figure out if a loop is infinite or not without actually executing the DNA.  You can imagine very convoluted loops

1->3->44->23->6->39->7->8->1

or cases where a loop is only infinite under certian environmental conditions, or certain cases when the recursion doesn't terminate, etc.  These are all run-time things, things you can't determine apriori.  You have to run the bot and even then it may only happen once in a blue moon.

So, there really is no such thing as 'not allowing' infinite loops.  If the language syntax allows for the expression of the right constructs - for recursion, gotos, whiles or other expressions of conditional loops or jumps, infinite loops will be possible.  The only debate is what to do about it when a bot exectes such a loop.

Numsgil:
Look at it from a fitness landscape position.  Mutations that cause immediate deaths are like singularities.  Bots that venture there are immediatly killed, and hence can't continue moving around the fitness landscape.  The more singularities the more unlikely a population of bots is going to make the trek from lows to highs (or highs to lows depending on how you view the fitness landscape).

I'm not against letting the bots do stupid things.  For instance, bots that forget how to feed are going to die.  This is fact, and the simulation isn't going to rescue them.  But that death is going to take a while.

Another way to look at it is in terms of mutation neighborhoods.  Let's say you have a strand of DNA.  A neighborhood is any DNA strand you can get to with a single mutation.  Most are going to be neutral or mildly deleterious.  A few are going to be quite lethal and some are going to be quite good.  Lethal mutations will never produce offspring worth the simulation's time or resources, so we simply don't let the bots mutate them.  It doesn't really change the fitness landscape except to maybe to allow more experimentation.

Bots shouldn't be able to kill themselves with terrible ease.  If this were a bowling game, it's like playing with bumpers in the gutter.  Gutter balls are simply not fun, so you can use bumpers to steer the ball towards some pins.

These goto commands would really be a new category of DNA, so there's no problem adding another costs field for them.  But like the rest of DNA codes I think the cost should be kept quite light.


--- Quote ---1. Are we placing all of DNA into codules? Can DNA exist outside of a codule?
--- End quote ---

All DNA is either in a codule or a root DNA.  (The present DNA system is like the root DNA.)


--- Quote ---2. If DNA in a codule has a goto command the flow of that DNA is stopped and the called codule is executed first, once it's done it comes back to the original DNA and continues right after the goto command. Is that right?
--- End quote ---

That's right.


--- Quote ---3. I'm not sure how you are preventing infinite loops. Let's say codule 1 has the following code:

cond
start
1 goto
stop

I don't see how it can get resolved.
--- End quote ---

Let's say that there can only be 5 instances of any codule on the calling stack at once.  After 4 calls it starts on the 5th.  1 goto checks to see the number of instances of the codule on the stack, and finds that there is already 5.  The goto does nothing (other than removing 1 from the stack of course), and the codule finishes executing.  Then so does the codule that called it, etc.  Each instance pops from the stack.  After each pop another instance of codule 1 is allowed to execute.  The 5 instance limit is like limiting the depth of the calling tree.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version