Nested Conditions

[Numsgil]

This is one of those things that have bugged me to no end.

The only thing that Darwinbots can't do smoothly in the DNA (well, there are some others too, but this is a big one) is nested conditions.  Things like:

if nrg > 4000
  if age > 2000
     'do stuff for age > 2000 and nrg > 4000
  else
     'do stuff for age <= 2000 and nrg > 4000
end if

There are ways around this, but they tend to be messy and ineligant.
 
Anyway, this is how I'm thinking to modify the DNA flow control structure to allow nested conditions.

When the program comes across the first cond statement, it checks if it's true or false.  If it's false, it finds the next stop statement that doesn't have a corresponding cond.

That's probably confusing.  It's like this (cond in this represents an entire condition like we're used to):

cond <-evaluates to false, read until 1 stop is found

cond <- will not be evaluated, read until 2 stops are found
stop  <- one stop found, read until 1 stops are found...

cond
stop

cond
stop

stop <- stop found, start normal execution again.

If cond evaluates to true:

cond <-- evaluates to true

cond <--evaluates to false
some code in the middle <-- isn't executed
stop

cond <-- evaluates to true
some junk DNA that isn't executed
start
program code that's executed
stop

cond <--evaluates to false
start
<--some code that isn't executed
else
code that's executed
stop
stop

I think that demonstrates all of it.  (<-- are comments if you didn't catch that...)

so basically stop now hooks up with cond instead of with start and else, and cond interrupts the flow of start and else.

not terribly difficult to do.

Allows nested conditions without breaking existing bots.

[shvarz]

Before I address the proposed system:  I really think we should make a rule of adding new features only if they allow something that is not possible without them.  

As for your system, I see one major problem with it.  It is going to tie a genome into a very specific structure, that is going to be almost impossible to mutate.  Any mutation that does not introduce a corresponding pair of "cond" and "stop" is going to mess up the whole genome.  

This is very obvious to me, cause I've done some web-site editing and the system of <open tag> blah-blah</close tag> has the same problems: you miss one <open> or </close> tags and the whole page goes to hell.

Here is another way to describe it:  Imagine a formula with a lot of parenthesis, like:

2*(((2+2)*2)+2)*((2+(2*2-2))*2)  Adding a new single parenthesis almost anywhere in this formula is going to drastically change the result of the formula.

Do you see the problem?  Or should I explain it in more details.  it is kind of an obvious thing to me and obvious things are sometimes the most difficult ones to explain :)

[Numsgil]

Yes, I recognize the problem...  A change way upstream could effect the entire genome.

When you describe it like that, it makes me think of the reverse polish notation the rest of the code uses.  I wonder if there's something you could do with that...

Let me think on it for a while.

[shvarz]

What is wrong with "cond start else" system we discussed before?  Together with conditions stack that seemed to be quite adequate...

[Numsgil]

You mean the system present in 2.4, or was there something else we discussed that I didn't implement?

It is adequate in the same way that writing without punctutation is adequate.  For instance, in ancient writings.  But all those "and"s and 'it came to pass"es get old after a while.

just because your wheel rolls doesn't mean you can't make it better.  Like by strapping a rocket engine to it.

[shvarz]

Well, that's how real life works.  About two centuries ago it's been said that "nature is scarce in innovation and generous in variation", and it still holds true today.  When something works, nature tries all possible variations.

It is silly to introduce a whole new system just to make it easier for us to create bots.  It can easily be replaced by a tool that converts some more sohisticated programming langauge into "DNA language".  If something is not possible to do, then introduce it.  But if it's just "not convinient", then I say: "Suck it up"

[Numsgil]

I'm going to have to disagree on this point.

I can understand your position mind you, I just don't agree with it.  In my mind, the more complex the tools, the more complex the behaviors we can expect to see from the bots.  There's nothing inherant about complex systems that demand only the simplest toolset.  Economics is a good example.  The forces involved in economics are by no means simple.  They are as complex as the human psyche.

I do think a good question to consider is: would this hurt or help evolution, or neither?  I think mutations that can disable code (alot of code) downstream is potentially problematic.  I'm not sure.

I'll keep thinking on it.

[MrMound]

if nrg > 4000
if age > 2000
'do stuff for age > 2000 and nrg > 4000
else
'do stuff for age <= 2000 and nrg > 4000
end if


I am not very good with the dna code.what does this do?

[shvarz]

That's what we have in version 2.4.  Nums does not like it for some reason (unknown to me).

To me it seems like even the system we have in 2.37 is nice:

if nrg > 4000
if age > 2000
'do stuff for age > 2000 and nrg > 4000

if nrg < 4000
if age < 2000
'do stuff for age <= 2000 and nrg < 4000

Of course, what Nums wants is a small region of DNA that controls large chunks of DNA, which can have many different conditions and genes.  I can understand it to some degree.

[PurpleYouko]

if nrg > 4000
if age > 2000
'do stuff for age > 2000 and nrg > 4000

if nrg < 4000
if age < 2000
'do stuff for age <= 2000 and nrg < 4000

or in DB DNA

Code: [Select]

cond
  *.nrg 4000 >
  *.robage 2000 >
start
  'do stuff
end

cond
  *.nrg 4000 <
  *.robage 2000 <
start
  'do stuff
end
Conditions are "anded" by default in 2.37 and earlier

[Numsgil]

That's what we have in version 2.4.  Nums does not like it for some reason (unknown to me).

Rather, that's what I want to happen but doesn't currently.

As shvarz showed, if you want a variety of things to happen when some single condition is met, you need to specify it in every single gene.

[Numsgil]

As promised, I have thought about it.

Here's what I propse.  It actually kills two birds with one stone.

"below" the normal DNA that we're used to there are a number of sub functions.  These sub functions are labeled with numbers.  For instance:

Code: [Select]

53:
cond
  *.age 5000 >
start
  50 .repro store
else
  100 .mkshell store
stop
A bit of code that would call subfunction 53 might look like:

Code: [Select]

cond
  *.nrg 10000 >
start
  53 gosub
stop
Obviously this allows for nested conditions.  An interesting note is that a sub function can call another sub function, creating a long line, or tree, of functions being called by other functions.

Here are some rules I see as necessary:

• Call stack - Each time a function is "gosub"ed, it's value is placed on a call stack.  Every time a function ends, its value is poped from a call stack.  If a gosub is found, the call stack is searched to see if it contains the value the gosub is attempting to jump to.  If it does, that sub function call is ignored.
  
  This prevents sub functions from creating any infinite loops.  The call tree from function to function will never repeat itself.
  
• I'm not sure how this would interact with the proposed diploidity and chromosomes I suggested a while ago.  I'm thinking each chromosome gets its own set of sub functions maybe.
• I'm thinking these sub functions are what get transfered in viruses and horizontal gene transfer.
  
• Approximate Value Function Jumps - seeing as how there could be a simply gigantic number of values accepted (in the range of -2billion to 2billion) values that don't correspond to an existing sub function should be routed to one that does exist.
  
  For instance, suppose we have functions 1, 10, and 86.  If the DNA tries to do: 6 gosub, it should be rerouted to either 1, 10, or 86.  The reason being simply that otherwise it's extremely unlikely for evolution to correctly stumble upon an existing sub function.
  
  So we'd need some function that takes values that don't point to an existing sub function and reroutes them.  The requirements for such a function:
  
  1.   Non-ambigous calls must always map to the same subfunction.  For instance, 86 should always point to function 86 if it exists.
  2.   All ambigous calls should point to some function.  A call to 6, if sub function 6 does not exist, must be routed to some subfunction that does exist.
  3.   The value being routed to must be the same over multiple cycles unless the number of functions changes (for instance, a new function added or an old one deleted).  That is, 6 will always point to 86 over multiple cycles.  It shouldn't suddenly point to 10 unless the number of functions is changing.
  4.  This value must be computable.  That is, it's unfeasible to store this value for every possible miss call.  There's not enough memory for that.  It needs to be determinable on the fly.
  5.  It should change very little as other functions are added/deleted through mutations.  For instance, if 6 gets mapped to 86, and a new function with label 90 gets created, 6 should not end up pointing at 10.  From mutations' point of view, 6 is a relatively "stable" way to call function 86.
  
  The only time 6 should change what it points to is if what it points to gets deleted --or-- a new function is created that is "closer" to 6 than 86 is.
  
  6.  The value should have a uniform probability of pointing to any existing function.  That is, if there are 1, 10, and 86, 6 should have .33 chance of pointing at 1, 10 or 86.
  I think that covers all the major points.  Simply finding the closest value (in our example, 6 is closest to 10) violates the last point I made above, so I need something more clever.