Code center > Darwinbots3
Bot DNA
Numsgil:
--- Quote from: googlyeyesultra ---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.
--- End quote ---
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:
--- Code: ---10 DoStuff 20 DoStuff 30 DoStuff
--- End code ---
You just want to prevent something like this:
--- Code: ---DoStuff:
5 sub DoStuff
--- End code ---
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.
--- Quote ---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.
--- End quote ---
Depends on how you define nested. If you see it as one condition checking previous conditions, I think it's possible.
--- Quote ---Besides, if messin' with the closing bracket is a deleterious mutation, the bot will likely die soon, and it wouldn't really matter.
--- End quote ---
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.
--- Quote ---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?
--- End quote ---
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.
googlyeyesultra:
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.
Numsgil:
Heh, I can just imagine
googlyeyesultra:
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.
Numsgil:
--- Quote from: googlyeyesultra ---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.
--- End quote ---
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.
--- Quote ---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?
--- End quote ---
I'll see what I can do
--- Quote ---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?).
--- End quote ---
That is a danger of debating with me. I'm pretty good at this
--- Quote ---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.
--- End quote ---
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:
--- Quote ---*.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
--- End quote ---
Now, suppose that nested condition decides (through a fortuitous mutation) that it doesn't want to be nested anymore. The above code turns into:
--- Quote ---*.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
--- End quote ---
And the original code could also be rewritten as:
--- Code: --- *.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
--- End code ---
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.
--- Quote ---*.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
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version