Darwinbots Forum
Code center => Darwinbots3 => Topic started by: Numsgil on July 16, 2007, 02:38:01 AM
-
I'm hoping to encourage some brainstorming about new DNA forms here. I'll start with some of my own observations and ideas:
1. First, the current DNA system has lead me to a strong conclusion. The stack is very easily manipulated by evolution. The memory locations much less so. A new system should take advantage of the stack more fully, and reduce or eliminate dependence on memory locations.
2. Viruses are key to most evo sims. They should be encouraged. But their method of propagation is a little overpowered in the current system, I think. It should be easier for bots to spread viruses, and more difficult for viruses to enter a non receptive host.
3. The linear nature of current DNA is limiting. It should be easier for bots to run several much shorter strands in "parallel" than one long, linear one. Especially with something like viruses, induced behavior should be additive and not necessarily disrupt existing behavior.
4. Conditions shouldn't be separated from the stores that they influence. Something like:
cond
*.nrg 5000 >
start
50 .repro store
stop
Would be better off looking like this:
*nrg 5000 > 50 .repro store
Maybe remove all the flow commands, or keep just start and stop (for junk DNA purposes). I'm not quite sure how a system like this would work, but probably the condition operators (>, <, etc.) toggle whether stores work or not.
Probably there would be a parallel boolean stack (as there is now), and stores simply check against the top of this stack to see if they are active or not.
5. DNA commands should be easily performed and understood by a human. Things like the bitwise operators tend to make the DNA look even more indecipherable than is necessary. Evolution will use whatever tools it has at hand, but humans don't like doing bitwise ANDing in their heads.
6. Codules (http://www.darwinbots.com/Forum/index.php?showtopic=1186) (basically sub functions that can't be set up recursively) are important for allowing branching logic. I'm further advancing the idea that there would be "core" codules that interact in very defined ways, passing control to each other, and lesser codules, that act simply as functions, returning when they're done to where they were called.
7. Probably something like half of the sysvars relate to vectors in one way or another. I'm playing with the idea of using vectors as the basic type instead of integers. But it's not as easy to do as I would like, so I may just sit on this idea. Basically, it would be alot better to do something like:
*.refvel .move store
instead of
*.refvelup .up store
*.refveldx .dx store
8. It's unrealistic to know exact details about your position, orientation, etc. I'd move sysvars towards being entirely relative. Sysvars would return information as if the bot is stationary and at the world origin (0,0).
9. Arbitrary values need to be removed where appropriate. For instance, instead of 100 .shootval store -2 .shoot store you might do something like 100 .nrgshot store. Eyes also should probably be redone to return values representing distance more accurately.
10. Most sysvars should be reworked to accept and return values in a normalized range. Something like -1000, 1000.
11. I was also playing with the idea of having all values be floating point in the range -1 to 1, but there are some places where this doesn't work out well (such as .body for instance)
12. Where possible, sysvars should give and return information. That is, act as both input and output.
13. As a general rule, passing A to a sysvar and passing B to a sysvar should mean that passing their average gives a result that is related to A and B. For instance, while -2 and -6 shots are both feeding shots, -4 is not.
14. Where possible, choices should be dumbed down where these choices aren't important. I was toying with the idea of making ties strictly for aggressive feeding and allowing only a single tie to be created per bot. (The connective properties of ties would be moved to another mechanism). Then instead of creating a tie and remembering its number, you'd just have to create a tie. Feeding wouldn't need to know about which tie to use, because there would be only one.
Haven't worked through all the consequences of this yet, but it's the track of thinking I'm on.
Structure
This is the big one. There are several ideas I've toyed with:- The first involves creating a linear assembly line of codules. Something like a pipeline. After one codule is finished executing, it passes control to the next one, until finally the last one somehow gives values to sysvars to cause action. Mutations could change the order of the codules being executed. The result is somewhat similar to the evolution of metabolic pathways, but it's still too linear for my liking.
- The second involves a web of codules. Each cycle, a codule would receive a stack filled with its input parameters, manipulate those parameters, and produce an output stack (the stack after it's done executing). Codules could be connected to other codules by connecting one's output to another's input. Sysvars would be simple codules that give output and receive input.
The problem is that it would then take several cycles for data to be processed from the inputing sysvars, through the DNA, to the outputing sysvars. Also, this creates a problem when it takes one calculation 2 cycles to do, while a more sophisticated, branching calculation can take 10 or more. DNA would be encouraged to sacrifice sophistication for simplicity, which is backwards of what I'd like to aim to achieve.
- An alternative is to run the DNA several times in a cycle, but here there are issues with how many times to run the DNA.
- Another idea is to simply prevent any looping at all (no recursion), which collapses the web into more of a feed forward neural net. This is what I'm currently thinking.
Input sysvars would pass their values to any codules they're connected to. These codules process their data and send it to the next codule. But I'm not sure how to set it up so that the different execution paths don't end up with a racing condition (http://en.wikipedia.org/wiki/Race_condition) against each other.
-------------------------------------------------------------
That's pretty much all I have at the moment.
-
Alrighty, I'll through in my two cents. Or however much this turns out to be.
1) I have no strong opinions here, as I rarely run evolutions.
2) Ensure that viruses are still viable for F1 competition. After all, a virus loses not only its offensive power, but also its ability to spread through other bots (even if you don't kill them with it) if you make it too hard to infect other species.
3) I don't do evolutions much, but I can imagine shear havoc with parallel threads. For instance, two threads running simultaneously like this would be havoc (since they'd run infinite numbers of themselves, which presumably would be allowed, since you can run multiple threads at a time).
Here's an example in psuedocode:
Thread1
run parallel Thread2
run parallel Thread2
endthread
Thread 2
run parallel Thread1
run parallel Thread1
endthread
Not only would this be an infinite loop, but it's also going to start running ridiculous numbers of threads until the game either crashes or decides to kill the offending bot. So, I'd say a single thread at a time.
4) Make this optional, so that both forms of code are supported. This would actually allow for nested conditionals, and for more options and more control.
5) Humans don't like doing crazy logic operations? What? All those SG bots in the league weren't evolved, you know. Humans can create equally illegible code as evolution can. Besides, someone, someday will think of a use for that kind of thing en masse. No harm to having more sysvars, but there might be harm if they are removed.
6) Definitely agreed. Codules are a must. I'd say unless they use a goto command, have them pass control to the next codule linearly. Also, add a variable that allows a codule to reference what codule activated it, so that it would be able to pass control back to that, or to the codule after it.
7) Might be nice. Don't know. Would break most old bots, though.
8) I'm plus minus on this. Although it is a bit strange for a bot to know its exact locations, presumably a bot would be able to say "Oh, look, that's the big tree/lake/oasis/whatever! I know I'm not near any walls, 'cause I've been here before."
9) Eyes can be redone. I mildly disagree with changing shots, however. Personally, I don't consider the current system particularly bad, but it's really not a big deal.
10) Meh, 32000 is easy enough to remember. Once again, really either way would work. Just probably not worth spending time programming compared to things like metabolism, E-grid, etc.
11) Please, please don't. Please? Completely and totally break every scrap of bot code in existance? Not to mention we'd have to remember that we need to accelerate at .75, as apposed to a more standard 750.
12) Would probably work, so long as we can get the specifics ironed out. Would a bot ever be able to read the value it had placed in the variable, or only the readback value?
13) I honestly don't like this. A bit overcomplicated for you to read our minds and figure out what we all consider averages for variables. Besides, I'm still against multi-threading, so it would never be called on at the same time, and a lot of bots depend on later code overwriting earlier code. Not to mention this makes defensive genes worthless, as it would place the average in (which would still be likely detrimental to the bot).
14) What if you are tied to a bot, and another bot tied to you? How can you reference the tie you were attacked with to delete/leach from it? I am interested in any ideas for structural replacements to ties, as sophisticated multibots are nearly impossible, and mostly suck in combat.
15) Wait, you didn't have a #15. Oh, well.
Structure:
Use number two (the web), but let a bot run all of it's codules in one cycle. After all, we've already got SG bots. Do we really need further single codule bots? Also, making a codule per cycle means that shipping data off to small functions to perform common operations is ridiculously wasteful, which is relatively backwards to me. Copy and pasting the same formulas repeatedly should be more costly than making one function that repeatedly handles it.
By different execution paths, do you mean multi-threaded DNA? If so, well, you hopefully already know my opinion on simultaneous code threads.
Somehow I think that was more than 2 cents.
-
Edit: I don't know why the quotes aren't working, but I have to leave, so I'm not going to try to figure it out now.
I'm hoping to encourage some brainstorming about new DNA forms here. I'll start with some of my own observations and ideas:
1. First, the current DNA system has lead me to a strong conclusion. The stack is very easily manipulated by evolution. The memory locations much less so. A new system should take advantage of the stack more fully, and reduce or eliminate dependence on memory locations.
It might be better to streamline stores by eliminating the store operator. If referencing an address with a . caused a store, then evolution might manage to evolve stores more often. This would make SGizing conditions impossible, though, unless there's a command to toggle between the old and new behavior.
2. Viruses are key to most evo sims. They should be encouraged. But their method of propagation is a little overpowered in the current system, I think. It should be easier for bots to spread viruses, and more difficult for viruses to enter a non receptive host.
I've been considering how to implement an antivirus for an evo sim without disrupting zerobot evolution. I was thinking a shepherd bot that would destroy any bots which are making viruses. The main reason is because virus-spreading isn't subject to mutation (as far as I know).
Also, I'm finding it a pain to deliberately infect a particular bot with a virus, since the virus shot actually flies off in a random direction, and completely ignores aim commands (I checked the source to verify that - the documentation on vshoot is wrong).
3. The linear nature of current DNA is limiting. It should be easier for bots to run several much shorter strands in "parallel" than one long, linear one. Especially with something like viruses, induced behavior should be additive and not necessarily disrupt existing behavior.
If they run in parallel, coordinating numerous parallel code strands, making their conditions not conflict, and making them not fight over the same variables, would be a major pain in the ass.
4. Conditions shouldn't be separated from the stores that they influence. Something like:
cond
*.nrg 5000 >
start
50 .repro store
stop
Would be better off looking like this:
*nrg 5000 > 50 .repro store
This is essentially what SGizing is about, and with PyBot I can take it a step further.
I write this: setaim when (aim!=315) = 315
and it turns into this: 315 .setaim *.aim 315 sub sgn abs mult store
Which stores 315 into .setaim if *.aim doesn't already hold 315.
I also have almost all the stores in Guardian set up to only do the store if the variable isn't already set to whatever's going to be written to it. This slows down the sim further but reduces energy costs. Guardian is very energy efficient (except it splurges on movement speed and defenses) and very CPU inefficient (much of the reason is because the CPU inefficiency is necessary to make it so energy efficient).
Maybe remove all the flow commands, or keep just start and stop (for junk DNA purposes). I'm not quite sure how a system like this would work, but probably the condition operators (>, <, etc.) toggle whether stores work or not.
As long as the condition operators continue to cost energy, and regular math and bitwise operators don't, it would still be more (energy) efficient for bot authors to use SGizing instead of the actual condition operators. As for evolution, I'm not sure how to make it work better. It seems to me that it works fairly well as-is. Real evolution generally takes thousands of years or more to evolve new abilities (like eyes, or thumbs, etc).
5. DNA commands should be easily performed and understood by a human. Things like the bitwise operators tend to make the DNA look even more indecipherable than is necessary. Evolution will use whatever tools it has at hand, but humans don't like doing bitwise ANDing in their heads.
I for one use bitwise anding, both for SGized conditions, and for using a variable to store bitflags indicating what features in the bot should be toggled on. What's really indecipherable is when an evolved bot is shooting and turning and crap, and there's not a single store or reference to .shoot in the entire DNA. It's powered by a simple 'angle inc' or 'angle dec' at the beginning of a start. (dist would work too)
6. Codules (http://www.darwinbots.com/Forum/index.php?showtopic=1186) (basically sub functions that can't be set up recursively) are important for allowing branching logic. I'm further advancing the idea that there would be "core" codules that interact in very defined ways, passing control to each other, and lesser codules, that act simply as functions, returning when they're done to where they were called.
While it could be useful to have functions (I already do something similar, but it's really more like macros), I don't think allowing something like goto and gosub would be a good idea. It would encourage evolution to create utterly unreadable spaghetti code. I would much rather it be linear, at least then you can try to follow it in your mind.
7. Probably something like half of the sysvars relate to vectors in one way or another. I'm playing with the idea of using vectors as the basic type instead of integers. But it's not as easy to do as I would like, so I may just sit on this idea. Basically, it would be alot better to do something like:
*.refvel .move store
I'm not sure if this is a good idea or a bad idea. Wouldn't it make some bots slower, from every multiplication, division, etc, being performed on two numbers instead of just one?
8. It's unrealistic to know exact details about your position, orientation, etc. I'd move sysvars towards being entirely relative. Sysvars would return information as if the bot is stationary and at the world origin (0,0).
Having refveldn and the like be relative is already a pain in the ass, and having aimshoot be relative to your current angle is an even bigger one (since angle isn't, apparently). Making more things relative would not be a good thing, in my opinion.
9. Arbitrary values need to be removed where appropriate. For instance, instead of 100 .shootval store -2 .shoot store you might do something like 100 .nrgshot store. Eyes also should probably be redone to return values representing distance more accurately.
This might make it harder for evolution to evolve bots that fire a variety of different shots. But who knows. The only shooting I've seen evolved so far was from .shoot dec.
10. Most sysvars should be reworked to accept and return values in a normalized range. Something like -1000, 1000.
Which sysvars? This could make things more confusing, but I don't know which ones you're talking about.
11. I was also playing with the idea of having all values be floating point in the range -1 to 1, but there are some places where this doesn't work out well (such as .body for instance)
Haha. Yeah. This would break so many things.
12. Where possible, sysvars should give and return information. That is, act as both input and output.
That would be nice. It would also be nice if it were possible for a bot to tell if another bot is shooting things by looking at .shoot (I've tried, it's always 0).
13. As a general rule, passing A to a sysvar and passing B to a sysvar should mean that passing their average gives a result that is related to A and B. For instance, while -2 and -6 shots are both feeding shots, -4 is not.
I don't think this is feasible in practice. For example, shootval with info shots.
14. Where possible, choices should be dumbed down where these choices aren't important. I was toying with the idea of making ties strictly for aggressive feeding and allowing only a single tie to be created per bot. (The connective properties of ties would be moved to another mechanism). Then instead of creating a tie and remembering its number, you'd just have to create a tie. Feeding wouldn't need to know about which tie to use, because there would be only one.
How about instead making tie commands default to tiepres if tienum is not set? This would help evolution without screwing up multibots and such. (I note that Guardian will tie to a hostile to destroy it even when it is already tied to a friendly or veggie)
As for structure changes, it seems to me that the current structure works decently well. I'm trying evolution with zerobots with ridiculously large genomes now too, to see how that works out (15k, quite close to Guardian's size).
I would suggest that info shots and memory writing with ties should set the variable after the rest of the cycle has run, so that on the next cycle, the bot can try to fix it if it is coded to. Right now they can instakill, and there's no way to stop it besides instakilling the attacker first.
-
Edit: I don't know why the quotes aren't working, but I have to leave, so I'm not going to try to figure it out now.
The forum only allows a certain number of quotes per post IIRC, try splitting your post in half or thirds and I'll move this one, or replace some of your quotes with [code]
It might be better to streamline stores by eliminating the store operator. If referencing an address with a . caused a store, then evolution might manage to evolve stores more often. This would make SGizing conditions impossible, though,
Still a good idea IMO, 1G bots and the current evo bots can be a real pain to read.
Also, I'm finding it a pain to deliberately infect a particular bot with a virus, since the virus shot actually flies off in a random direction, and completely ignores aim commands (I checked the source to verify that - the documentation on vshoot is wrong).
The game was meant to have been changed to work like that, added to known bugs.
I'm also a fan of making bots own input relative.
Not a fan of any form of instakill, sysvars have been changed before because of that so I hope the mkshell/slime variable gets sorted.
-
3) I don't do evolutions much, but I can imagine shear havoc with parallel threads. For instance, two threads running simultaneously like this would be havoc (since they'd run infinite numbers of themselves, which presumably would be allowed, since you can run multiple threads at a time).
Here's an example in psuedocode:
Thread1
run parallel Thread2
run parallel Thread2
endthread
Thread 2
run parallel Thread1
run parallel Thread1
endthread
For threads, I'm imagining they don't communicate with each other. They don't spawn new threads. They just receive input from sysvars and output data to other sysvars. Multiple data sent to the same sysvar is averaged together (which is why it's important that averaging two pieces of data results in a number that is related to the two pieces). This is important because it allows a bot to receive additional DNA from another source and have its original DNA still be untouched. Only its behavior will change.
So threading is more like having several extra people in identical cockpits driving the same robot you are. The end robot behavior is like a democratic vote between all the pilots.
5) Humans don't like doing crazy logic operations? What? All those SG bots in the league weren't evolved, you know. Humans can create equally illegible code as evolution can. Besides, someone, someday will think of a use for that kind of thing en masse. No harm to having more sysvars, but there might be harm if they are removed.
Humans can write complex things just fine. It's reading them that's a pain. Doubly so if it's an evolved bot. Ideally a human should have little problem reverse engineering a section of DNA and understanding what it does. This way evolution can become transparent. This is one area where there's a conflict between the needs of Darwinbots as an evolution simulator, and the needs of Darwinbots as a battle bot arena.
6) Definitely agreed. Codules are a must. I'd say unless they use a goto command, have them pass control to the next codule linearly. Also, add a variable that allows a codule to reference what codule activated it, so that it would be able to pass control back to that, or to the codule after it.
There are two methods I'm imagining for passing control from one codule to the next. The first is like a pure goto statement. Full control is moved from the first codule to the second. The other method is more similar to the way functions work. A secondary codule is called, manipulates the stack, and returns control to the codule that called it, where it called it.
In both cases, looping needs to be strictly impossible, or you'll end up with the possibility for an infinite loop in the DNA and a hung simulation. Bad all around.
7) Might be nice. Don't know. Would break most old bots, though.
I'm not too concerned about backwards compatibility. I'm imagining something like "Darwinbots 3". A whole new iteration of the program. So many things changed that older bots just can't feasibly be moved to the new version in any sort of easy manner.
8) I'm plus minus on this. Although it is a bit strange for a bot to know its exact locations, presumably a bot would be able to say "Oh, look, that's the big tree/lake/oasis/whatever! I know I'm not near any walls, 'cause I've been here before."
I'm hoping to come up with a reasonable system to address this problem. Maybe something like pheremone markers bots can lay down.
10) Meh, 32000 is easy enough to remember. Once again, really either way would work. Just probably not worth spending time programming compared to things like metabolism, E-grid, etc.
The problem is that not all sysvars use the whole 32000 range. Again, this is more closely tied with evolution that bot writing. I feel it's important for evolution when the output for a commnd or sysvar can act as the raw input for another input or sysvar and produce reasonable results.
11) Please, please don't. Please? Completely and totally break every scrap of bot code in existance? Not to mention we'd have to remember that we need to accelerate at .75, as apposed to a more standard 750.
The main problem is that there are areas where it doesn't make sense. Addition wouldn't really work, for instance. Again, I'm not too concerned about backwards compatibility.
12) Would probably work, so long as we can get the specifics ironed out. Would a bot ever be able to read the value it had placed in the variable, or only the readback value?
I'm thinking sysvars would start out with the input value, and if a bot changes this value, then it acts as a write command.
13) I honestly don't like this. A bit overcomplicated for you to read our minds and figure out what we all consider averages for variables. Besides, I'm still against multi-threading, so it would never be called on at the same time, and a lot of bots depend on later code overwriting earlier code. Not to mention this makes defensive genes worthless, as it would place the average in (which would still be likely detrimental to the bot).
This depends on the variable. I'd say 80% of sysvars are already averagable. There are just a few exceptions. .shoot comes to mind (but that's easy enough to split into several shooting sysvars). As far as defensive genes go, I think primary defenses should be made more effective so the need for defensive genes is reduced.
14) What if you are tied to a bot, and another bot tied to you? How can you reference the tie you were attacked with to delete/leach from it? I am interested in any ideas for structural replacements to ties, as sophisticated multibots are nearly impossible, and mostly suck in combat.
This is still pretty raw in my mind, but at the moment I'm imagining having ties last only for a single cycle, or maybe be extremely brittle. But either way, bots can't modify or delete ties made to itself. A bot that is being sucked to death would need to find another means of removing the offending bot. Maybe shooting it, or accelerating fast enough to break the tie, or brushing against another bot or shape to scrape the other bot off.
Basically, I'm imagining a combat system where it's better to leech on a bot that's much larger than you, shoot at a bot that's roughly the same size as you, and ingest (phagocytosis) a bot that is smaller than you.
Structure:
Use number two (the web), but let a bot run all of it's codules in one cycle. After all, we've already got SG bots. Do we really need further single codule bots? Also, making a codule per cycle means that shipping data off to small functions to perform common operations is ridiculously wasteful, which is relatively backwards to me. Copy and pasting the same formulas repeatedly should be more costly than making one function that repeatedly handles it.
Right, definately a problem.
By different execution paths, do you mean multi-threaded DNA? If so, well, you hopefully already know my opinion on simultaneous code threads.
Hopefully I've persuaded you with my above argument.
-
I still don't like multi-threads. Can you imagine how hard it would be to debug a bot in? Not only would you have to check the last gene that had activated that referenced the misbehaving variable, but every single one that activated and referenced it (which, in large bots, could be a ridiculous amount). Does that also mean that 30 .repro store 70 .repro store will make 50 .repro store, even if done in one gene?
-
It might be better to streamline stores by eliminating the store operator. If referencing an address with a . caused a store, then evolution might manage to evolve stores more often. This would make SGizing conditions impossible, though, unless there's a command to toggle between the old and new behavior.
This is an interesting idea, I'll work through the consequences on paper and see how it would work. Maybe every sysvar is just a command.
I've been considering how to implement an antivirus for an evo sim without disrupting zerobot evolution. I was thinking a shepherd bot that would destroy any bots which are making viruses. The main reason is because virus-spreading isn't subject to mutation (as far as I know).
Also, I'm finding it a pain to deliberately infect a particular bot with a virus, since the virus shot actually flies off in a random direction, and completely ignores aim commands (I checked the source to verify that - the documentation on vshoot is wrong).
This is a really delicate area. Viruses are probably one of the best features-- they work really well in both evo sims and battle bots. But I think having a bot police its own genome is just too difficult and has too many problems. I was talking with shvarz about it once, and he said that real organisms don't really have a method of dealing with viral infection other than dying so that the virus doesn't spread.
So I'm thinking that viral defense should be stronger, and internal methods of removing viruses (.delgene) removed altogether. The effect is basically the same, and we can even make viruses easier to control as a weapon without overpowering them too much.
I might even make a way for a virus to convert its entire host into new viral particles and have them all explode out in a fiery explosion! Hehe, woudln't that be a fun way to spread a virus
If they run in parallel, coordinating numerous parallel code strands, making their conditions not conflict, and making them not fight over the same variables, would be a major pain in the ass.
I'm imagining that there's no communication between strands except if they write to the same sysvar. If there's a conflict, I'd like to average the values. The only problem is with sysvars that don't average well. .shoot, for instance. Which is why it's important to try and convert as many sysvars as possible to a system where averaging results in average behavior.
This is essentially what SGizing is about, and with PyBot I can take it a step further.
I write this: setaim when (aim!=315) = 315
and it turns into this: 315 .setaim *.aim 315 sub sgn abs mult store
Which stores 315 into .setaim if *.aim doesn't already hold 315.
I also have almost all the stores in Guardian set up to only do the store if the variable isn't already set to whatever's going to be written to it. This slows down the sim further but reduces energy costs. Guardian is very energy efficient (except it splurges on movement speed and defenses) and very CPU inefficient (much of the reason is because the CPU inefficiency is necessary to make it so energy efficient).
I'd like to see SG methods become the primary supported method (it's how evolution likes to work, too), easier to read, and less hacky. Maybe instead of storing to 0 as a free action, you can use some nice conditions that just happen to be inserted into the body of the gene. I'm still working out how it would work.
As long as the condition operators continue to cost energy, and regular math and bitwise operators don't, it would still be more (energy) efficient for bot authors to use SGizing instead of the actual condition operators. As for evolution, I'm not sure how to make it work better. It seems to me that it works fairly well as-is. Real evolution generally takes thousands of years or more to evolve new abilities (like eyes, or thumbs, etc).
Eric and I had a discussion a while ago about what sorts of DNA costs are good. After reading through other simulators' code and forums, all signs point to the idea that you shouldn't charge bots for the length or complexity of their genome because you invariably favor shorter, stupider behavior. I'd like to move to dumbing down the costs for DNA. Just enough to prevent runaway genome growth that slows the program to a crawl.
I for one use bitwise anding, both for SGized conditions, and for using a variable to store bitflags indicating what features in the bot should be toggled on.
You could also use memory locations for this. I dunno, I do see some places where bitwise is good, but it just makes the DNA look too Greek. And you can really produce the same behavior with other commands.
What's really indecipherable is when an evolved bot is shooting and turning and crap, and there's not a single store or reference to .shoot in the entire DNA. It's powered by a simple 'angle inc' or 'angle dec' at the beginning of a start. (dist would work too)
Yeah, this is definately an issue.
While it could be useful to have functions (I already do something similar, but it's really more like macros), I don't think allowing something like goto and gosub would be a good idea. It would encourage evolution to create utterly unreadable spaghetti code. I would much rather it be linear, at least then you can try to follow it in your mind.
I think a raw goto statement would be bad for this reason. Within a codule, the program flow should be readily understandable. Only when a codule gets to the end of itself should it pass full control to another codule.
I'm not sure if this is a good idea or a bad idea. Wouldn't it make some bots slower, from every multiplication, division, etc, being performed on two numbers instead of just one?
Speed isn't the primary issue. I can probably even write some sort of DNA analyzer that trims DNA down when it's time to run it so you're not running junk. My primary concern is with dot and cross products. They both return scalars in 2D. I guess I need to examine some existing robots and see how they would work if they were vectors.
Having refveldn and the like be relative is already a pain in the ass, and having aimshoot be relative to your current angle is an even bigger one (since angle isn't, apparently). Making more things relative would not be a good thing, in my opinion.
Wouldn't it be easier if everything was relative? Then you wouldn't need to convert between absolute and relative. It would be an entirely self consistant way of observing the universe.
That would be nice. It would also be nice if it were possible for a bot to tell if another bot is shooting things by looking at .shoot (I've tried, it's always 0).
That sounds reasonable.
I don't think this is feasible in practice. For example, shootval with info shots.
Yeah, I'm not sure how to address things like this.
As for structure changes, it seems to me that the current structure works decently well. I'm trying evolution with zerobots with ridiculously large genomes now too, to see how that works out (15k, quite close to Guardian's size).
It's alright. Definately better than most other simulators where agents can only run X many commands per cycle. But I think it can be improved to allow for some added complexity and features (sexual reproduction becomes alot easier if the DNA isn't quite so linear).
I would suggest that info shots and memory writing with ties should set the variable after the rest of the cycle has run, so that on the next cycle, the bot can try to fix it if it is coded to. Right now they can instakill, and there's no way to stop it besides instakilling the attacker first.
Yeah, this is definately an issue. But if bots can override ties and info shots, then it makes them largely useless since a bot could just explicitly set every single sysvar.
-
I still don't like multi-threads. Can you imagine how hard it would be to debug a bot in? Not only would you have to check the last gene that had activated that referenced the misbehaving variable, but every single one that activated and referenced it (which, in large bots, could be a ridiculous amount). Does that also mean that 30 .repro store 70 .repro store will make 50 .repro store, even if done in one gene?
Threads wouldn't interfere with each other. Only their end results would have any interaction. And within a thread, it's as if the thread has total control of the bot. So 30 .repro store 70 .repro store would result in 70 .repro store for that thread. After all threads are executed, their final effects are averaged, but until that time a thread has no inkling of what other threads are doing.
-
Would this be a seperate command from goto and codules? If so, no further objections. I could live with it, and maybe use it from time to time. Still, having no ability to not use multi-threading when it doesn't serve a purpose well would be quite annoying.
-
Yes and no. I'm thinking that instead of a single root codule that calls other codules, you have several codules that are considered to be roots, with each starting it's own execution path.
-
So if I didn't want the multi-threading features, I could just use one root with a lot of branches?
-
Why not make store take 3 values and only work when there is a non zero value on the stack.
And change >, <, = etc. to take two values and place 1 on the stack if the condition is true and 0 if it isn't. Like the mult operator.
Then 50 .repro *.nrg 5000 > store would work.
-
So if I didn't want the multi-threading features, I could just use one root with a lot of branches?
Right
Why not make store take 3 values and only work when there is a non zero value on the stack.
And change >, <, = etc. to take two values and place 1 on the stack if the condition is true and 0 if it isn't. Like the mult operator.
Then CODE50 .repro *.nrg 5000 > store
But then wouldn't it be difficult to have a single condition control multiple store statements?
-
But then wouldn't it be difficult to have a single condition control multiple store statements?
I was thinking that we could have this and genes.
cond
*.eye5 25 >
*.refeye *.myeye !=
*.refpoison *.refshell =>
start
16 .shootval store
-6 .shoot store
stop
cond
*.eye5 25 >
*.refeye *.myeye !=
*.refpoison *.refshell <
start
16 .shootval store
-1 .shoot store
stop
would become
cond
*.eye5 25 >
*.refeye *.myeye !=
start
16 .shootval store
-6 .shoot .*.refpoison *.refshell => store
-1 .shoot *.refpoison *.refshell < store
stop
Which is a lot more readable. It would also make Single Gene bots less complicated. But then we should leave the bitwise operators.
For example
cond
*.eye5 30 >
start
-1
.shoot
*.memval -2 =
*.refeye 0 = |
store 'Shoot if the bot is hit with venom or if its a veggie (Checking with .memloc, .memval)
stop
Which would be a good use for bitwise operators.
-
I humbly ask that you read this ridiculously long post.
Alright. Now understanding the general plan for multithreading, I'd be willing to go with it. No objections there.
Ultimately, for conditions, I'd like a multi-tiered system. At the top, we'd have root codules that would be executed every cycle. In those would be simple genes that called other codules. Thus, root codules to standard codules. Standard codules could and should link to a multitude of other standard codules. Then, in codules, genes should still have the "cond" statement to allow conditions to apply to all operations in that gene. Then, you could have conditions attached to each statement, like "*.nrg 1500 > 50 .repro store". One tricky bit would be deciding when the condition section ended, since we can't assume it ends at a store (some genes merely add values to the stack to be processed later). Perhaps a "condstop" operator could be used, of some sort, inside of the start/stop section of a gene. Essentially, it would look like "*.nrg 1500 > 50 .repro store condstop". That would also mean that you could attach non-stores to conditions without creating lots of genes, like "*.eye5 0 > 50 mult condstop", which would multiply the top stack value by 50 and place that on the stack, if eye5 say something. It would also allow for easy nested conditionals, as the condstop could encompass multiple lines, if needed.
Alright. The above method would certainly allow quite a bit of SG-ifying, but SG-ifying wouldn't really make the bot better in any way (you are still spending energy on condition checking, and viruses are probably receiving an overhaul, so I doubt .delgene inc .delgene inc will really be valid.)
I suppose the thing preventing threads from interacting with each other until they had already finished would prevent the racing condition problem.
To deal with shots, change .shoot to a universal shoot command. It would take the first to values on the stack to determine what kind of shot it was, and the second value to determine it's shootval. Essentially, shoot wouldn't need a store anymore. So a energy feeding shot with a shootval of 50 would be "50 -1 shoot". We'd probably have to do the same thing with quite a few other variables, and turn things into commands. Store, obviously, would still remain, for usage in any variables that don't support the command-ized form, or for free variables to store information. For multi-threading, perhaps we could do some sort of randomization for ones that don't mix well (so if codule1 tried to use an energy shot and codule2 tried to use a body shot, it would randomly choose one. Variables/commands that are more easily averaged (like up) could simply be averaged.
While we're speaking of new commands, try to include some basic trig functions (for fancy aiming), logarithmic functions (for calculating how much damage shots should do), and any other obscure ones you can think of that I have missed. Also, even if things like refxpos and refypos are relative to your own bot, you should be able to calculate angle from different locations (still relative to your own bot, once again, for aiming).
I still think that raw gotos and gotosubs are essential. Say, if I've got a function that determines how much I should power up a shot. Perhaps a multi-gene one. I can't exactly wait until the end of the shooting gene/codule is over before I call that function. We could always disable these in mutations, and have a third command that would goto as soon as the gene/codule finished. Maybe gotoafter?
How will a bot react when it finishes a codule that has no goto commands? Will it automatically continue on to the next codule, or will it just end the program then? In theory, if the former is true, then could you end DNA execution early by creating a blank codule at the end of the DNA and call that?
With the whole vector vs. integer thing, allow both. Sometimes, for instance, to prevent orbiting, you solely want a certain direction (like *.veldx -1 mult .dx store), or when you only want to accelerate towards a bot in one direction, and only match it's sideways velocity. A lot of the time, it would be a lot faster and easier just to use it as a vector, however.
Erm, yes, I think I'm done rambling. For now.
Edit: I'm not done rambling!
If you split the .shoot into a plethora of things like .vshoot .wasteshoot .nrgshoot, .medicshoot, .infoshoot, .venomsoot, and .bodyshoot, what mechanism would be implemented to prevent me from firing every single one of them in one cycle? Essentially, bots could start throwing everything but the kitchen sink at their target and would no longer have to strategically decide which is better at a certain time.
-
I humbly ask that you read this ridiculously long post.
Heh, you're in good company around here.
Ultimately, for conditions, I'd like a multi-tiered system. At the top, we'd have root codules that would be executed every cycle. In those would be simple genes that called other codules. Thus, root codules to standard codules. Standard codules could and should link to a multitude of other standard codules.
That's what I'm thinking too. I'd probably use something like a call stack to prevent infinite looping from indirect recursion.
Then, in codules, genes should still have the "cond" statement to allow conditions to apply to all operations in that gene. Then, you could have conditions attached to each statement, like "*.nrg 1500 > 50 .repro store". One tricky bit would be deciding when the condition section ended, since we can't assume it ends at a store (some genes merely add values to the stack to be processed later). Perhaps a "condstop" operator could be used, of some sort, inside of the start/stop section of a gene. Essentially, it would look like "*.nrg 1500 > 50 .repro store condstop".
That would also mean that you could attach non-stores to conditions without creating lots of genes, like "*.eye5 0 > 50 mult condstop", which would multiply the top stack value by 50 and place that on the stack, if eye5 say something. It would also allow for easy nested conditionals, as the condstop could encompass multiple lines, if needed.
I was thinking something like a stack for booleans. Which would allow some easy nesting of conditions. Values could be combined using logical operators (and, or, etc.)
Something like:
*.eye5 0 > *.refeye *.myeye = and 314 .aimdx store else *.revelup .up store
Probably would need some stack manipulation commands for the boolean stack (duplication, popping, swapping maybe).
To deal with shots, change .shoot to a universal shoot command. It would take the first to values on the stack to determine what kind of shot it was, and the second value to determine it's shootval. Essentially, shoot wouldn't need a store anymore. So a energy feeding shot with a shootval of 50 would be "50 -1 shoot". We'd probably have to do the same thing with quite a few other variables, and turn things into commands. Store, obviously, would still remain, for usage in any variables that don't support the command-ized form, or for free variables to store information. For multi-threading, perhaps we could do some sort of randomization for ones that don't mix well (so if codule1 tried to use an energy shot and codule2 tried to use a body shot, it would randomly choose one. Variables/commands that are more easily averaged (like up) could simply be averaged.
I've thought about making all the sysvars commands in the past. It's an interesting idea, I might pursue it. We could have some sysvars output into the boolean stack I was talking about above.
For shots, I'm thinking of splittling up the shoot command into several commands for different types of shots. One sysvar for body shots, another for venom, etc. For sysvars that don't average well, we could probably set up a voting system.
I still think that raw gotos and gotosubs are essential. Say, if I've got a function that determines how much I should power up a shot. Perhaps a multi-gene one. I can't exactly wait until the end of the shooting gene/codule is over before I call that function. We could always disable these in mutations, and have a third command that would goto as soon as the gene/codule finished. Maybe gotoafter?
How will a bot react when it finishes a codule that has no goto commands? Will it automatically continue on to the next codule, or will it just end the program then? In theory, if the former is true, then could you end DNA execution early by creating a blank codule at the end of the DNA and call that?
I'm not sure what the name is of what I'm thinking (functional programming?), but basically you create a call graph from codule to codule. At the end of a codule, control is returned to the calling codule.
Alternatively, I'm thinking of a top level graph, where maybe root codules execute and return control to one another. But I dunno if it'll work right or not.
If you split the .shoot into a plethora of things like .vshoot .wasteshoot .nrgshoot, .medicshoot, .infoshoot, .venomsoot, and .bodyshoot, what mechanism would be implemented to prevent me from firing every single one of them in one cycle? Essentially, bots could start throwing everything but the kitchen sink at their target and would no longer have to strategically decide which is better at a certain time.
I'm not sure yet. We could make it prohibitively expensive, or maybe make a priority list. I'm still working through how it would work.
-
I'm not entirely sure how expensive you could make it. After all, with venom or info shots, I can force you to give me energy. Then I can use energy shots to feed. Then I can use body shots to feed. That's feeding three times as fast. How much are you thinkin' in terms of costs for shooting? It'd have to be exponential, because otherwise tieing would be the only real way to eat (or just biting their head off, if you're large enough).
I could see control being returned to the root after every codule is completed, so long as it returns to the position that codule is called. It wouldn't be very powerful, but I could deal with it. Mostly would just need a lot more conditions and gotos in the root gene and less in other places. Not my particular style, but it would work either way.
One way, of course, would be to combine the two options. Allow gotos, and after the codule called was completed, it would return to the codule that called it the line after the goto. Then, after that codule had completed, if it was called by the root, then the root would call it back.
So it would work like:
Root -> Codule1 -> Codule2 -> Codule3
Then, after codule three had completed:
Codule3 -> Codule2 -> Codule1 -> Root
(each codule being given a chance to finish before returning to the one that called it). Anyways, just my opinion.
This is what you are thinking of, correct? If so, then I'd say we are now in agreement as to how codule calling should work.
With multi-threading, I still see little use to it, and if it were me, wouldn't bother programming it. Still, at least I can not use it should I want to. I am curious as what applications for multi-threading you were thinking of people using.
Oh, and a bit earlier, I believe you mentioned something like "code defenses shouldn't be as useful, and should be replaced with better physical defenses". I don't remember the exact words, and I'm too lazy to look it up. I strongly disagree here. I should be able to place a superiorly coded bot into a sim and watch it win, even if the other, worse bots have built up significant amounts of slime, shell, etc. Essentially, code defenses don't cost much (only a store), but they only protect against 1 or 2 very specific things. However, if you just wanted a more generic defense, say, against all info shots, you could add in some shell or poison or whatever it is. If you wanted a specific defense against, say, Icarus' turning shot, then you could implement some code to protect against that.
In terms of preventing ridiculous numbers of loops, you could set it so that if a bot executes a single codule a certain large number of times in one cycle (1000? Larger?) then either that specific codule could be deleted, the codules that called it could be deleted, or the bot could be killed. I don't know which.
Your example of in-gene conditions (*.eye5 0 > *.refeye *.myeye = and 314 .aimdx store else *.revelup .up store) has some pluses and minuses. First of all, I like the ands and elses (and presumably elseifs, xors, ors, etc.) However, this assumes that after the last else you always want to stop at a store (or maybe it's the end of a line, but then you are making different forms of whitespace different, which is a big no-no. Like MUMPS. Bad, making whitespace different than whitespace). What if I just want to perform stack manipulations? Or if I want to perform multiple stores? We really need some sort of an operator that says "Stop checkin' this condition/this else." Else would also act as a condstop. Or are you assuming that it should follow the above condition until a new one is instated? That makes nesting impossible, however.
Essentially, I'd like it something like the following:
*.eye5 0 > *.refeye *.myeye != and 50 -1 shoot else *.eye5 0 > *.refeye *.myeye = 20 .aimdx store *.eye5 30 > 30 .dn store condstop condstop
And here's the same thing commented:
*.eye5 0 > *.refeye *.myeye != and 'Checks that both eye5 is greater than 0 and that you aren't one of me.
50 -1 shoot 'Shoots an energy shot with a shootval of 50.
else 'Ends the previous condition, checks a new one that is equal to NOT the previous condition.
*.eye5 0 > *.refeye *.myeye = and 'If eye5 is greater than zero and you are one of me.
20 .aimdx store 'Turn.
*.eye5 30 > 'A nested condition. Activates if the else is true and eye5 is greater than 30.
30 .dn store 'Goes in reverse.
condstop 'Tells the nested condition that it's over.
condstop 'Tells the else condition that it's over.
Anyone reading this, please contribute to the discussion. Please. I think we probably need more than two or three people's inputs on such a radical and important change.
-
I am following this Googlyeye, as best I can, codules and multi threading are a bit beyond my ken though!
I worry that the new code will be difficult for your average Joe to follow. Then again it was difficult reading the current code when I first started so that's probably not much of a problem.
Other than that the ability of bots to use tan or sin to accurately calculate trajectory and shot angle seems a bit more than the bots should have.
But I have trust in Nums ability to choose wisely, he has put a lot of work in to researching the ins and outs of different possibilities (as he is now). He's taken my opinion and ideas onboard in the past as he has with many other people. This is a thread about bots coding though and it's best left to people who have a good understanding of such things IMO.
-
I'm not entirely sure how expensive you could make it. After all, with venom or info shots, I can force you to give me energy. Then I can use energy shots to feed. Then I can use body shots to feed. That's feeding three times as fast. How much are you thinkin' in terms of costs for shooting? It'd have to be exponential, because otherwise tieing would be the only real way to eat (or just biting their head off, if you're large enough).
Costs aren't my favorite option. I'll be revisiting the combat system in the future as well, adding some new combat ideas people've discussed over time. This may end up a moot point. Venom and poison, for instance, could be used as a method involved with Phagocytosis (http://www.darwinbots.com/Forum/index.php?showtopic=861). Meaning they wouldn't use shots as they do now. In the end it might turn out that there's only one or two shot types. It's an area I need to explore some more, but it's a bit off topic here so I'll save it for another time.
I could see control being returned to the root after every codule is completed, so long as it returns to the position that codule is called. It wouldn't be very powerful, but I could deal with it. Mostly would just need a lot more conditions and gotos in the root gene and less in other places. Not my particular style, but it would work either way.
I'm thinking a call stack. Codule A calls Codule B, which calls Codule C. When C is finished, it returns control to Codule B where it was called. And likewise with B to A. So a top level root codule could do some very gross conditions (do I see anything?), and then pass what to do in these cases on to codules.
I'm also imagining another system that works above this, the connects codules together in a large web structure. But I'm still on the fence about if it's a good idea and how it would work.
This is what you are thinking of, correct? If so, then I'd say we are now in agreement as to how codule calling should work.
I think so, if I understand you right.
With multi-threading, I still see little use to it, and if it were me, wouldn't bother programming it. Still, at least I can not use it should I want to. I am curious as what applications for multi-threading you were thinking of people using.
It's not so much for people. It's primarily for two areas: viruses and diploidness (IMO important for setting up sex that mirrors biology (which is a weak point IMO in other alife sims)). A virus would get injected as another thread. Runaway virus propogation would also be pretty easy to simulate, since you'd just have to count the number of identical viruses, run the virus once, and weight the results. This would be more complicated in the current system. There also wouldn't be the ordering issue of where in the genome a virus gets inserted like there is now. And for diploidness, you'd just end up running two versions of the same codule at first. Over time, though, the two identical threads would diverge, and you could implement some crossing-over to mix them. Haploid bots that "fuse" (this is basically how sex works for fungi and primitive plants) are basically agreeing to share control over a single body. Threads allow a reasonable and fair way to share control.
For bot authors, I can't imagine it making much of a difference one way or another.
Oh, and a bit earlier, I believe you mentioned something like "code defenses shouldn't be as useful, and should be replaced with better physical defenses". I don't remember the exact words, and I'm too lazy to look it up. I strongly disagree here. I should be able to place a superiorly coded bot into a sim and watch it win, even if the other, worse bots have built up significant amounts of slime, shell, etc. Essentially, code defenses don't cost much (only a store), but they only protect against 1 or 2 very specific things. However, if you just wanted a more generic defense, say, against all info shots, you could add in some shell or poison or whatever it is. If you wanted a specific defense against, say, Icarus' turning shot, then you could implement some code to protect against that.
The issue here is that the genome then becomes part of the phenotype. It's like using the blueprints for wallpaper in a building. I think it's good to create a degree of seperation between the body and the brain of a creature. The problem is that allowing a bot to, say, delete genes, or preempt a virus from working by being a single gene bot, is that it encourages the genomes to become rather monolithic. A single, huge, self policing, black box finite state machine. Nothing wrong with that per se, but it's just too dense for most people to decode and understand. I think we'd see better results if the genomes were more modular. If it wasn't a huge disadvantage to split computations into different discrete groups, it would allow less coupling between behaviors, and hopefully provide some extra wiggle room for evolution or authors.
When your DNA becomes part of the structure of a bot, I think it decreases readability. Though there's certainly an amount of fun writing code that makes others weep
In terms of preventing ridiculous numbers of loops, you could set it so that if a bot executes a single codule a certain large number of times in one cycle (1000? Larger?) then either that specific codule could be deleted, the codules that called it could be deleted, or the bot could be killed. I don't know which.
I've played around with these ideas, but none really satisfied me. I think the idea of "fizzling" a call to a codule if it's already in the call stack is the best. There are some really convoluted examples I can cook up that are truly terrifying if recursion (direct and indirect) was allowed with codules, even if its depth was restricted.
Related to looping, at the moment I'm playing with the idea of having a sort of event driven architecture for some DNA functions. Something like calling a codule with different arguments for everything in a bot's vision radius. Like the foreach loop in C#. I'm still working through how a bot would determine which cases to throw out and which to keep, but I think the idea of having some limited, hardwired looping is okay. It's just when the language allows bots to form loops in its DNA that things fall apart.
Your example of in-gene conditions (*.eye5 0 > *.refeye *.myeye = and 314 .aimdx store else *.revelup .up store) has some pluses and minuses. First of all, I like the ands and elses (and presumably elseifs, xors, ors, etc.) However, this assumes that after the last else you always want to stop at a store (or maybe it's the end of a line, but then you are making different forms of whitespace different, which is a big no-no. Like MUMPS. Bad, making whitespace different than whitespace). What if I just want to perform stack manipulations? Or if I want to perform multiple stores? We really need some sort of an operator that says "Stop checkin' this condition/this else." Else would also act as a condstop. Or are you assuming that it should follow the above condition until a new one is instated? That makes nesting impossible, however.
I was thinking something like a popbool command. Pops the top boolean off the stack. Have the bool stack default to true if there's nothing underneath. The only downside compared with how things are now is that you couldn't just issue a string of conditions and have them automatically be anded. The way something like this works, else and not are basically the same command.
And, compared with other methods, you couldn't use conditions to push specific values onto the regular stack. Something like *.nrg 5000 > 50 else 10 doesn't work (at least not as I'm imagining it at the moment). After all, you need that integer stack to stay active even when a condition evalutes to false so that you can set up for the next condition. Conditions don't so much cause the DNA parser to jump over parts of code (like it works now), but to cause certain key commands to "fizzle".
Of course, if we set up codule calls to work with conditions too, you could do something like this:
*.nrg 5000 > .Fifty call else .ten call
end
Fifty:
50
end
Ten:
10 end
The code structure is similar to the way that genes work right now, but explicitly stated.
Essentially, I'd like it something like the following:
*.eye5 0 > *.refeye *.myeye != and 50 -1 shoot else *.eye5 0 > *.refeye *.myeye = 20 .aimdx store *.eye5 30 > 30 .dn store condstop condstop
And here's the same thing commented:
*.eye5 0 > *.refeye *.myeye != and 'Checks that both eye5 is greater than 0 and that you aren't one of me.
50 -1 shoot 'Shoots an energy shot with a shootval of 50.
else 'Ends the previous condition, checks a new one that is equal to NOT the previous condition.
*.eye5 0 > *.refeye *.myeye = and 'If eye5 is greater than zero and you are one of me.
20 .aimdx store 'Turn.
*.eye5 30 > 'A nested condition. Activates if the else is true and eye5 is greater than 30.
30 .dn store 'Goes in reverse.
condstop 'Tells the nested condition that it's over.
condstop 'Tells the else condition that it's over.
[quote]
I'd like to move away from requiring a "closing brace" or something similar. They work fine when a human is writing, but when you get a random string of evolved DNA, a small change upstream can change the way an entire length of DNA is executed. Meaning it's very brittle.
Take, for instance:
[code]
A {
do things
}
B {
do things2
C {
do things 3
}
}
Now, remove A's closing brace. Suddenly B and C become nested entirely in A. B and C are totally at the mercy of A. Now, imagine that A, B and C are pushing and popping values from a stack, or something similar. Now B and C can remain in charge of themselves by not digging too far down the stack. If they want to AND with A's condition, they can. If not, it's as if B and C have formed their own cohesive gene that happens to be inside of A, but isn't influenced by it. There are still some issues with B and C interfering with A (by not cleaning up after themselves), so I think this still needs to be refined. But now nesting is at the control of the nester instead of the nestee (if you see what I mean). It gives strips of DNA stronger control over when and how they get expressed. Self determination from the tyranny of upstream DNA
Probably a dup command for the bool stack would be imperitive here, along with a pop command, to allow nested DNA to return the stack to the way it found it. Or maybe I can come up with something similar to the OpenGL Matrix stack operations, where you can push and pop matricies. (Push the bool stack, and you get a new empty stack that defaults to the top value of the old stack. Pop the stack, and you get back your old stack. Like a stack of stacks.)
-
Insta-fizzing anything that is already in the call stack isn't that useful. What if I need to run a formula at multiple points of a bot's code? If I only needed it once, then I could just copy and paste it in.
Alright, then, for multi-threading. Just for viruses and modeling, then.
I see what you mean by closing braces screwing up in mutations, but there isn't much of a choice if you want nested conditions. Besides, if messin' with the closing bracket is a deleterious mutation, the bot will likely die soon, and it wouldn't really matter.
As a side note, does the fact that you wrote the codule names in your example as text instead of numbers mean we will likely get to name our codules? Pretty pweases?
-
Insta-fizzing anything that is already in the call stack isn't that useful. What if I need to run a formula at multiple points of a bot's code? If I only needed it once, then I could just copy and paste it in.
Remember that it's a call stack. Meaning that once a codule returns control to the calling codule, it's popped from the stack. Something like this would work just fine:
10 DoStuff 20 DoStuff 30 DoStuff
You just want to prevent something like this:
DoStuff:
5 sub DoStuff
Recursion = very, very bad. It shouldn't limit the DNA that much. Recursive functions can be rewritten using iterative versions without too much effort usually.
I see what you mean by closing braces screwing up in mutations, but there isn't much of a choice if you want nested conditions.
Depends on how you define nested. If you see it as one condition checking previous conditions, I think it's possible.
Besides, if messin' with the closing bracket is a deleterious mutation, the bot will likely die soon, and it wouldn't really matter.
Most mutations are bad, but if we can reduce the number of bad mutations without limiting the expressiveness of the language, I think we'll see some better evo sims.
As a side note, does the fact that you wrote the codule names in your example as text instead of numbers mean we will likely get to name our codules? Pretty pweases?
Part of me really wants this. You could basically write some custom codules that act like any missing math functions, and there wouldn't be any difference between them and the default ones. You could write a custom distance function, for instance. You could just call it with something like 0 30 10 20 dist and it would find the distance between <0,30> and <10,20>.
On the other hand, evo bots aren't going to be inventing reasonable names anytime soon. It'll probably work like sysvars. Custom labels that are called, but that evaluate to numbers. I still have to work out the best way to do it I think.
-
We could totally program in evobots a series of possible codule names. Would be hilarious.
Like:
cond
start
call Darwinbots_Awesome_>
stop
It would crack me up if I saw evobots naming codules like that.
-
Heh, I can just imagine
-
Furthering the discussion on physical defenses or code defenses, code defenses does NOT necessarily mean illegibility. They can be as simple as zeroing things that you aren't using if your gene count goes up. Honestly, I agree. Stab the SG bots. However, code defenses really ought to stay. It would take a lot of ingenuity, for instance, to make a bot that could recognize when it had been turned by an info shot (maybe by storing how much it turned last turn into a free var and the same with last turn's orientation, and if it didn't fit right, turn back). Seriously, we should be promoting ingenuity, not demoting it. It's a lot more fun to see bots using complex behaviors to protect against things like this (especially since a lot of attacks specifically attack behaviors, ala info shots and viruses), then it is to just write 100 .mkslime store. Still, those are just my own (rather strong) viewpoints.
Custom labels would work, probably. You could also just make evobots name the codules from a list, which, could either as an easter egg be populated with joke names, or they could just be things like a, b, aa, etc. Either would honestly work, but defining codule names wouldn't allow any funny easter eggs in the game, would it?
Understanding your idea on the call stack makes a lot of sense, now. I agree with that approach (Why do I feel like I'm being converted, somehow?).
You also mentioned that nested conditions could be done without ending braces. The only way I can think of this would be having ridiculous numbers of codules pointing at each other, each representing one condition. Kinda like programming nested if-then-elses on my TI-83: you can do it, but only if you jury-rig it with a boatload of goto commands.
In terms of pop and push commands for recalling old stacks... It'd have to entirely repopulate the stack multiple times in one cycle for each and every bot if someone wrote something that called the pop command multiple times. I don't know if this would be a major performance hit, but even a small one, with enough bots doing it, would be kinda awful.
-
Furthering the discussion on physical defenses or code defenses, code defenses does NOT necessarily mean illegibility. They can be as simple as zeroing things that you aren't using if your gene count goes up. Honestly, I agree. Stab the SG bots. However, code defenses really ought to stay. It would take a lot of ingenuity, for instance, to make a bot that could recognize when it had been turned by an info shot (maybe by storing how much it turned last turn into a free var and the same with last turn's orientation, and if it didn't fit right, turn back). Seriously, we should be promoting ingenuity, not demoting it. It's a lot more fun to see bots using complex behaviors to protect against things like this (especially since a lot of attacks specifically attack behaviors, ala info shots and viruses), then it is to just write 100 .mkslime store. Still, those are just my own (rather strong) viewpoints.
Those aren't so much the defenses I'm concerned about. That tends to be more cleaning up after the damage has been done. It's things where there's two equally valid ways to write a feature for your bot, and you choose to write it in a more obscure way because it gives you an advantage against viruses or something else similar. Don't use any eyes (but still read from the eye locations) so it looks like you're a veggy, for instance. SGing your bot so that it's stronger against viruses is another example. I'd like to section the DNA away from the body so that these aren't really issues anymore. Info shots and viruses are still going to wreck havoc inside the genome, but you can deal with that damage in many ways. Primary defenses on the outside, cleanup work on the inside.
Custom labels would work, probably. You could also just make evobots name the codules from a list, which, could either as an easter egg be populated with joke names, or they could just be things like a, b, aa, etc. Either would honestly work, but defining codule names wouldn't allow any funny easter eggs in the game, would it?
I'll see what I can do
Understanding your idea on the call stack makes a lot of sense, now. I agree with that approach (Why do I feel like I'm being converted, somehow?).
That is a danger of debating with me. I'm pretty good at this
You also mentioned that nested conditions could be done without ending braces. The only way I can think of this would be having ridiculous numbers of codules pointing at each other, each representing one condition. Kinda like programming nested if-then-elses on my TI-83: you can do it, but only if you jury-rig it with a boatload of goto commands.
In terms of pop and push commands for recalling old stacks... It'd have to entirely repopulate the stack multiple times in one cycle for each and every bot if someone wrote something that called the pop command multiple times. I don't know if this would be a major performance hit, but even a small one, with enough bots doing it, would be kinda awful.
The way the program works, things like physics and bot vision are going to take like 98% of the CPU time for larger sims, because they have a O(n log n) growth curve (when they're optimized, O(n^2) otherwise). In general, it's not worth sweating things that happens a constant number of times per bot. It just hardly impacts the simulation speed. Of course, a 15K bp monstrousity is something of an exception to that rule
But if the DNA is expressive enough you should be able to collapse that down anyway.
Here's an imaginary sample of using pushbool and popbool that simulates nesting:
*.nrg 5000 >
'basically a nested condition:
pushbool 'save a copy of the current bool stack and start a new one
*.eye5 0 = and
50 .repro store
else '(could also use "not". Same thing)
100 .dn store
popbool 'restore the saved copy of the bool stack
10 .strbody store
Now, suppose that nested condition decides (through a fortuitous mutation) that it doesn't want to be nested anymore. The above code turns into:
*.nrg 5000 >
'basically a nested condition:
pushbool 'save a copy of the current bool stack and start a new one
*.eye5 0 =
50 .repro store
else '(could also use "not". Same thing)
100 .dn store
popbool 'restore the saved copy of the bool stack
10 .strbody store
And the original code could also be rewritten as:
*.nrg 5000 >
'basically a nested condition:
pushbool 'save a copy of the current bool stack and start a new one
A
popbool 'restore the saved copy of the bool stack
10 .strbody store
end
A:
*.eye5 0 =
50 .repro store
else '(could also use "not". Same thing)
100 .dn store
To simulate a more human like method of coding. The primary weakness is that you have to remember to both push and pop the conditions stack. It's not necessarily reasonable to assume that evolution would always use them in pairs. Of course, evolution might not even like to use strictly nested conditions like this, so it's hard to say.
It's still related to a closing brace, but it inverts the control structure. Hope I've explained it well.
As a summary example, this shows a shorter method of writing the above that achieves the same effect, but without the need to push and pop the bool stack.
*.nrg 5000 >
'basically a nested condition:
dupbool 'duplicates the top boolean value in the bool stack
*.eye5 0 = and
50 .repro store
else '(could also use "not". Same thing)
100 .dn store
'clear the top value in the bool stack
10 .strbody store
Not sure if we'd need a new command to clear the top value in the bool stack or if we could do it using AND, OR, NOT and XOR.
-
I fail to see how doubling the number of commands a mutated bot needs to successfully nest conditions would actually reduce problems. Seriously, if it's gotta put pushbool in the right place, and popbool in the right place, wouldn't it be easier just to put one closing-brace esque command in the right place? I mean, the code would work, but it seems like an awfully complicated system. I thought we were trying to make it simpler so that mutations could actually have a chance?
In short (kindof), it's a neat solution, but I don't see how it would improve from the more basic option. I'd think that it'd be less intuitive for humans and harder for evo-bots to develop.
-
Not sure if we'd need a new command to clear the top value in the bool stack or if we could do it using AND, OR, NOT and XOR.
I don't think you could really pop something with just those.
The way I pop something on the regular stack is 'dup xor inc', or if I need to pop several things at once, I put adds (though ands, ors, or whatever would work too) before that statement. To pop 3 things: add add dup xor inc
(dup xor zeroes whatever's on the top of the stack, so that the inc will be working on no memory location)
-
I fail to see how doubling the number of commands a mutated bot needs to successfully nest conditions would actually reduce problems. Seriously, if it's gotta put pushbool in the right place, and popbool in the right place, wouldn't it be easier just to put one closing-brace esque command in the right place? I mean, the code would work, but it seems like an awfully complicated system. I thought we were trying to make it simpler so that mutations could actually have a chance?
In short (kindof), it's a neat solution, but I don't see how it would improve from the more basic option. I'd think that it'd be less intuitive for humans and harder for evo-bots to develop.
It's actually not that different from a closing brace type system. The pushbool and popbool are like opening and closing braces. Primarily the difference is a matter of control. In a more conventional system, condition A is commanding condition B on wether it can execute or not. In this system, condition A is suggesting to condition B wether it should execute or not. It's the job of condition B to follow that suggestion or not.
If we wanted multiple conditions in a single block, you would still need an opening brace to show that you're starting the body of the condition. And if yoo lose a closing brace, then the entire genome beneath you becomes part of your condition.
I'm not so much trying to find the easiest method for nested conditions. I'm trying to find a method for nesting conditions that is robust to mutations. Take the current system. If you had:
cond
start
cond
start
cond
start
And you lost the second cond, it just means that the second gene gets controlled by the condition right above it. Mutations don't end up effecting global changes in the flow the DNA.
-
I've just been thinking. . . Does it matter so much how we implement nested conditions? After all, mutations will almost never evolve conditions, much less complex/nested ones, and conditionals are often the first things to break. That is, unless you are planning a major overhaul in that respect, bots will break conditions, no matter how you nest 'em.
-
They don't really break every single condition, some conditions are just too dangerous for them to break. The reproduction and turning conditions usually last forever. Other stuff like shooting constantly makes sense if there's enough food around. Breaking things like defense storage makes since they're surrounded by "friendlies" most of the time.
I do think "equals" might be highly susceptable to mutations. Basically it's less likely two random numbers are going to be equal than it is that one is going to be greater or less than the other. Either the condition will be broken or the "equals" will be changed. Think alot of our problems stem from a disconnect between human and evolutionary logic. Evolution is based on likely/unlikely probabilities, human logic is based on certainity.
-
As far as I can tell, conditions are almost always deletrious to an evobot. Take this simple gene, for example:
cond
*.nrg 500 >
start
50 .repro store
stop
There's 6 commands in there, not counting the cond, start, and stop. If any of them in the conditions section is changed, the bot will probably die very quickly. For instance:
*.nrg 500 <
Well, we've now got a bot that suicides if it's hungry. Not particularly smart, unless it's a veggie.
*.robage 500 >
This one will go cancer after a few hundred cycles. Not particularly bright of a bot to do, is it?
*.tmemloc 500 >
Something like this will pretty much make the bot sterile, as in an evolved enviroment, how often are you going to see tmemloc and tmemval be used?
Not only are conditions remarkably fragile, but no matter whether they work or not, they charge the bot energy (at least under most configurations). That essentially means, that unless every condition is really important, it's gonna get dropped fairly fast. Essentially, evo-bots are encouraged to kill off complex decision making and just run around randomly and shoot.
We really need a way of encouraging conditional logic. I suspect that removing or lessening the costs to check conditions under default/F1 settings would aid this (as well as make conditionless bots less uber, hoorah!). I've even toyed around with the idea of using negative costs to encourage conditions, movement, and things like that.
-
"cond
*.tmemval *.setbuoy >=
Can I have my free energy now?"
Evolution will take advantage of negative costs, creating junk DNA to grab the rewards with the minimum of effort. There's nothing in the contract that says the condition has to be useful! Zero costs are good, since then there's no selective pressure away from conditions (useful ones included).
-
The fragility of contional DNA logic is related to the the issue of the low probability of evolving it in a sim complex enough to select for it's maintance. As Googlyfinglongname correctly points out, it takes a long sequence of base pairs, correctly orderred to convey useful conditional logic. Thus, the probability of evolving DNA with a useful conditional is low and the probability of destroying it is high. But this is only part of the problem. Evolving conditional logic in a sim complex enough to provide selective pressures to maintain it once it does evolve (or is hand coded to begin with) is highly unlikly today given the simplisitic natures of the sims we can run. This is why zerobots don't evolve conditional logic and why hand coded bots loose it over time. Our sims are just to simple to select for the evoloution or maintence of complex behaviour, conditional or otherwise
We need several things. More sim complexity is key - evironment grid stuff, abilitiy for specialization and evolution towards niches, more simultanious bots per sim (perf perf perf) larger sims in general, topological separation for long periods of time, etc.
I might also suggest some structal changes to DNA which make the evolution of conditional logic more likely. Higher level commands that impart conditional logic in fewer base pairs for example or mutation logic that respects gene structure so copy mutations preserve useful conditional sequences intact.....
-
Would it be possible to allow different levels of variables?
A sim-wide level(most of these being read only), a radius based level around individual bots(to allow things like sound), and an MB level to allow easier communication to all the other bots in a MB.
Might also be an idea to allow bots to create basically a searchable array of features for the bots they are tied to. Then they could affect a variable in just that bot or bots.
-
Would it be possible to allow different levels of variables?
A sim-wide level(most of these being read only), a radius based level around individual bots(to allow things like sound), and an MB level to allow easier communication to all the other bots in a MB.
I'm planning on creating a simple "smell" sense. Smells would be used to communicate over sim-wide levels. Most other senses will be rather local in all probability.
For MBs, I'm strongly working towards a system that dramatically increases the amount of information that can be communicated.
-
Cool
Definitly need an easier system for MB's.
-
The ideal system for MBs would let a cell at one end of a worm communicate freely with a cell 100 cells down on the worm in a single cycle. That way the size of the MB doesn't effect its response time.
-
how about rahter than rewriting the dna toatly use the same one but with the new stuff and move up move down turn up and turn down.
also ties could be grappling hook things when they are shot the pull the bots together
-
There are non-backward compatible changes I want/need to make. The system is still largely based on existing DNA. I don't know what you mean by "move up move down turn up and turn down".
-
want there something about db3 being in 3d?
-
want there something about db3 being in 3d?
Physics engine (http://www.darwinbots.com/Forum/index.php?showtopic=2332)
Eh, no.
-
3D is a distant idea I'm toying with. The initial version won't be.
-
oh fair enought I heard something about it being in 3d sorry.
also im a bot master now the warmness and fizziness is starting to work
-
also im a bot master now the warmness and fizziness is starting to work
Alright.., Ha, me botlord, me higher.
And now I am wondering what post count stands for the point you get blue stars.
-
The ideal system for MBs would let a cell at one end of a worm communicate freely with a cell 100 cells down on the worm in a single cycle. That way the size of the MB doesn't effect its response time.
So in this system are you planning on letting any cell know the values of any memory location on any other cell, just doing something like:
start
10 .cell store
*.pain 60 store
*.mycell .cell store
60 *.pain >
10 .cell store
100 .give store
stopWould cell X give cell 10 100 nrg (ok, yeah I made up a few sysvars, but I think you get the point)
If so, sysvars that returned the cell number highest or lowest values (or the values for all of the bots in an array, but this is just wishful thinking and probably too complex) would be very useful.
-
Would be nice if the bots had some sort of access to micro-arrays. Not sure how they could easily be handled though, in terms of processing speed or access.
-
The ideal system for MBs would let a cell at one end of a worm communicate freely with a cell 100 cells down on the worm in a single cycle. That way the size of the MB doesn't effect its response time.
So in this system are you planning on letting any cell know the values of any memory location on any other cell, just doing something like:
start
10 .cell store
*.pain 60 store
*.mycell .cell store
60 *.pain >
10 .cell store
100 .give store
stopWould cell X give cell 10 100 nrg (ok, yeah I made up a few sysvars, but I think you get the point)
If so, sysvars that returned the cell number highest or lowest values (or the values for all of the bots in an array, but this is just wishful thinking and probably too complex) would be very useful.
I'm still working on the logistics, but the goal is something like this:
1. Bots can totally manipulate the memory of attached bots that are adjacent to it in a MB. Read/write, etc. just like it can with its own memory.
2. Bots can be designated as relays. Signals they recieve would propogate under certain rules during a cycle. Sort of like a long game of telephone.
So a "brain" bot could communicate through lots of "nerve" bots to "motor" bots, all in the same cycle.
--------------------------------------------
Would be nice if the bots had some sort of access to micro-arrays. Not sure how they could easily be handled though, in terms of processing speed or access.
Yeah, that's another issue I'm trying to figure out. Some sort of fixed-size arrays that can be manipulated using something like a foreach would make all sorts of things easier. I have no idea how to accomplish it right now, though.
-
Had an idea about possibly combining a basic genetic algorithm in with standard DB dna. Basically the GA would allow evolution to easily get over the initial hump of becoming a self replicator, allowing a low level of replication. It could also handle a basic method of feeding and perhaps a determine bot shapes. Still not sure how you'd determine when the GA should relinquish control over to the rest of the dna. Might just wind up having the bot easily become a replicator only to face another hurdle.
-
Maybe I'm just repeating someone else because I was too lazy to read through the whole list, but here are some points I would like to see changed:
- Instead of messing round with memval/memloc and tmemval/tmemloc, could we simply reduce them to the commands <pos> read and <pos> tread?
- I agree with the conditional operators being merged with the execution code; it would make for much more readable 1-gene bots
- .shoot values are confusing; can't it just all be like .vshoot eg. .bodyshot, .memshot, .feedshot?
-
Maybe I'm just repeating someone else because I was too lazy to read through the whole list, but here are some points I would like to see changed:
- Instead of messing round with memval/memloc and tmemval/tmemloc, could we simply reduce them to the commands <pos> read and <pos> tread?
- I agree with the conditional operators being merged with the execution code; it would make for much more readable 1-gene bots
- .shoot values are confusing; can't it just all be like .vshoot eg. .bodyshot, .memshot, .feedshot?
Yep, that's more or less what I'm planning.
Had an idea about possibly combining a basic genetic algorithm in with standard DB dna. Basically the GA would allow evolution to easily get over the initial hump of becoming a self replicator, allowing a low level of replication. It could also handle a basic method of feeding and perhaps a determine bot shapes. Still not sure how you'd determine when the GA should relinquish control over to the rest of the dna. Might just wind up having the bot easily become a replicator only to face another hurdle.
The system is set up in a more or less modable way. It shouldn't be hard to create a different DNA system that some bots use and others don't.
-
Will there be chromosomes and Alleles for Dominance and Recesive genes? This might make sex-repro more ineresting.
-
I haven't implemented it yet, but my plan is to have several concurrent "threads" that all operate on the bot's memory at the same time. At the end of execution, all their effects are averaged (or something similar) together. A recessive gene in a situation like that might simply be a gene that doesn't store as high a value.
-
I was thinking more along the lines of allowing a designer to control dominance and recessiveness. What if we used division of the two instead? In such an instance co-dominance could occur. That sounds complicated to implement as a defaulting thing. I say let the designer choose for their own species. Otherwise there could be problems with crossbreading. I also think it might be best to simply use a common-limiter. A value that limits potential crosses between species to require similar refvars. This could be used to prevent adaptations from occuring through sexrepro taht are not wanted, such as shooting or sight.
-
Part of the problem here is that your idea is a force-fed version of dominance and recession taught as part of intro biology. Real genetics is a bit more... involved. Genes aren't magically "dominant" and "recessive". It's more like the gene for skin pigment comes in two varieties: one produces a lot, the other produces a little. The one that produces a little is overwhelmed by the one that produces a lot, making it recessive in expression.
Think of it like two faucets filling a bathtub. If both faucets are off or mostly off, you won't have a lot of water in the bathtub. That's a recessive phenotype. If one faucet is on at full blast and the other is off, you'll still fill the bathtub. That's a dominant phenotype. If both faucets are on at full blast, well, that might not make any difference (maybe someone's monitoring the bathtub and can turn it off) or it could mean a very wet house. Or if one faucet produces red paint and the other produces blue paint. The end effect might be very different from what either faucet intends. That's where the idea of co-dominance comes from, and other wacky things like that.
On top of that, most phenotypes aren't controlled by a single gene, and many genes have more than one effect, so the whole thing gets really muddy.
-
Ah, I was thinkning genophenically, not expression. I meant a Gene that caused the recessive to be turned off. A sort of built in switch when it comes ot crossing.
-
I'm not sure I understand what you mean.
-
Say for a multibot you have three sets of genes. One of them is for the entire species, they have no value of dominance. The other two have dominance. One of the other two can be set recessive, so the gene is only activated when a copy of it is present elsewhere in the dna. This means a multibot could sexrepro without much problems with internal switches.
-
It just wouldn't work with the way the DNA is set up. I'm specifically trying to avoid a bot programmer needing to specify any information on the gene level. The idea of a gene in the new DNA is just too nebulous. A bot author could wrap a large section of DNA in a toggle, though, and have that toggle be set in such a way that it gets turned on/off depending on what gene it gets during a crossing over event.
-
I'm worried about the way 3 dimensions are handled. For example, motion would not be an angle of bearing-velocity system, but an angle of bearing-velocity-angle of elevation system or something like that. Methods such as angle and dist would have to be rewritten, eyes would not work properly anymore etc.
-
I don't have a good plan for 3D, to be honest. Spherical coordinates (ie: two angles and a distance) are the most straightforward, but it's not necessarily the easiest to program with. Of course, the current physics engine I'm working on is also written pretty strictly in 2D (moving to 3D would be possible, just some extra work), so I think 3D isn't going to be a feature any time soon.
-
I think you can use Sperical harmonics for the eyes... but don't ask me how it works...
But it seems like making it 3D would make it tougher to run... I don't know how detailed the physics are suposd to be, but it seems to me like making everything 3D would make sims slow down a lot in crowded sims. When too many bots are coliding or tied... and if the bots can have different shapes in DB3 it'll get even slower.
It seems like a big project to me... or the physics would have to be very simple...
Not that 3D wouldn't be cool, but it seems to me like running evo sims would take ages.