Code center > Suggestions

Nested Conditions

<< < (3/3)

Numsgil:

--- Quote ---That's what we have in version 2.4.  Nums does not like it for some reason (unknown to me).
--- End quote ---
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: ---53:
cond
  *.age 5000 >
start
  50 .repro store
else
  100 .mkshell store
stop
--- End code ---

A bit of code that would call subfunction 53 might look like:


--- Code: ---cond
  *.nrg 10000 >
start
  53 gosub
stop
--- End code ---

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.

Navigation

[0] Message Index

[*] Previous page

Go to full version