Code center > Suggestions
Non-Determinstic Bot DNA flow
Numsgil:
I can accept anything if you're talking about it from the point of view of an option. THe more the merrier. I would definately like to explore an ND DNA execution model, just not for the main course of the program. It's main interest is in evolution sims.
I'll write up another post on how I would improve the ND system you imagined.
Your compromise works exactly like how I invisioned chromomes to work initially, so it's obvious that it's a good solution if more than one person have arrived at it more or less independantly. I certainly support it as the main direction for DB to follow.
Shvarz's two ideas:
1. 50% chance on overwriting existing value: this still creates linearity between genes, with genes comming after other genes more likely to overwrite the one before, which is a problem.
2. Having each gene have a number strength was proposed by Zelos too a while ago for how to figure out dominant/recessive gene pairs. As I said to him, it just creates incentive for a gene to mutate its strength to 32000. There's no downward force on gene strength (unless it's just a bad gene. But then we don't care much about it anyway). Stength or lack there of of a gene or command should be determined intrinsically by the system. Real genes aren't recessive because the genome designed them that way. It's just how it worked out.
For Carlo's idea: having which number to store in case of conflict be random works well enough, but I'm leaning more towards a higher probability for some kinds of instructions over others so recessive/dominance can be established. If you imagine a diploid animal with two identical chromosome pairs except one fires -6 shots and the other -1 shots, picking a random instruction to use results in each being 50/50.
If you have some rule that creates preference for certain kinds of values (I'd probably vote for values closest to 0), then you can create a dominant/recessive pair, and hopefully allow some classic sexual reproduction to be worked into the system.
So the chance of being chosen from the list of conflicting commands should be partly random (favors more frequent commands) and also partly biased (favors certain kinds of commands over others).
A simple slider between the two can allow us to tweak and decide which is best.
Numsgil:
As promised, this is my thoughts on how to improve the ND system.
--- Quote ---This is true. But, as I already told you, I'd prefer a good program that works slowly than a bad program that works faster.
--- End quote ---
Definately. But DB isn't a bad program. At worst it's an ameteurish program. And a large part of what makes it that way isn't the DNA system or mutations, it's the physical speed of the simulation. Avida lets you run whole generations more or less within an hour. DB runs almost at real life clock rates. Sloooow. If I can find ways to bump up its speed, especially on larger simulations, by maybe a factor of 10, the program suddenly becomes competitive to others.
--- Quote ---
--- Quote ---2. You've created race conditions.
--- End quote ---
Can you be more specific about this point?
--- End quote ---
In concurrent programming, racing conditions is when the order of two or more supposedly concurrent actions effects the end action taken by the system. I don't understand it well enough to give you a huge overview, but this is how I understand it:
Suppose two genes both work when nrg 5000 >:
cond
*.nrg 5000 >
start
50 .repro store
stop
cond
*.nrg 5000 >
start
100 .up store
stop
Now, in regular DB both are executed every time. If this is the entire genome, the actions of the cell are quite predictable and consistant.
In ND, one executes then changes the conditions, then another executes. Any of these is possible:
reproduce only
move then reproduce
move several times then reproduce
Which is chosen has absolutely no correlation with anything. By definition, you've made it random. This is called a racing condition, and is generaly agreed to be a flaw in the system. Wether it is in DB or not I have no idea, which is why I said it's probably bad.
I don't know enough about the consequences of racing conditions to know one way or another.
--- Quote ---(bots like the One will never evolve in an evo sim, so there's simply no problem)
...
But, also, it is a problem which can affect only people programming combat bots, since I don't think that evolution will produce super complex genes.
--- End quote ---
They don't in the current system because there's no incentive to do so. Two genes work just as well as one big gene. Over time, simple diffusion will result in a genome that's more spread out into multiple genes.
In a ND system, it's not at all impossible that such a bot would develop. There's certainly nothing stopping it, and incentive to do so. Dropping one gene from a 50 gene bot is hardly noticable, but dropping one gene from a 2 gene bot gives the other double the execution time.
--- Quote ---put a limit to the number of operations that can be performed inside a gene. The limit may be a simple cap or maybe an increasing cost for each subsequent operation.
--- End quote ---
A cap is always a bad option. Sometimes unavoidable, but usually a bad bad idea. The second option is better. You need to create a counter incentive to the one gene geonome. Increased costs works well enough, I'm sure there are other ways as well. You could increase waste generated. Anything really.
--- Quote ---Hmmmm... from a certain point of view you're right. This is how things work in the real world. But on the other hand, we should design the program to produce interesting and meaningful results.
--- End quote ---
There's nothing that a ND system can produce that the calssic system can't. There aren't any new commands, or new ways to mutate the genome. The effects of mutations are a little different, creating different paths for the genome to take, but the end results on the behavior of a bot are more or less the same.
A well designed ND bot does just as well in a ND universe as a well designed classic bot in a classic universe.
--- Quote ---And making behaviours compete for execution time could be interesting. In Avida, one of the most "serious" alife software, organisms compete for cpu time. The real world works differently, but this choice is interesting, and profound.
--- End quote ---
Which is why Avida uses it as its paradigm. There's nothing wrong with it at all, but Avida already does it, and does it better. To the best of my knowledge, no one has tried modelling real life as well as DB has. I think, when possible, we should construct the bots to operate as closely as possible to real organisms. It makes it more interesting both to laymen and hobbyists. We don't really have any proffessional researchers using DB, but I imagine they wouldn't care one way or another.
--- Quote ---
--- Quote ---For instance, your two gene example would work just as well with a sleep command (which I proposed in another thread).
--- End quote ---
Horrible. :lol:
--- End quote ---
What is horrible? The idea of a sleep command or...?
--- Quote ---Backwards compatibility is a stupid thing if referred to a program that nobody uses for work but just to tinker a bit with evolution and robot programming - don't you think so? I find this idea simply intolerable. You know what's better, how the program can become more interesting and be a better alife sim... but you do nothing, because of the back compatibility of a few bots... bah.
--- End quote ---
When people spend hours working on something, they don't like that time to be wasted, no matter wether it was for fun or work. That doesn't mean you are limited to backwards compatibility, just that you should strive for it and only abandon it when the benefits of a new system far outweight the combined grief of the people.
For instance, if a new version of Unreal Tournament comes out that uses a special foot controller, and hand mice aren't allowed anymore, the new foot controller better be way better than the old hand mice system. I've spent alot of time practicing and honing my skills with the hand mouse. That time's wasted if the new foot controller is no better than the hand mouse.
We even considered breaking current bots when we were thinking about an enzyme system, but with a little thought we managed to modify the idea to where existing bots would work just fine (provided default enzymes by the program). Usually not making something backwards compatible is a sign you haven't tried. And I don't think you've really tried.
Okay, here's my comments on the ND system. If you work these out, I think it would be an awesome option (but an option it must remain!)
Real ND languages (the kind you're actually talking about, not the tree kind) only execute one body over another if both conditions evaluate to true. It doesn't try executing a body if its condition isn't true.
So I would scan the genome for all genes that evalutate to true, and then chose one among them to execute. That keeps the basic ND flavor (actually increases it!) while enhancing its capability.
There was something else but it escapes me at the moment.
Last, the original ND idea I'd like to call the 'hard ND' system, and continue discussing its possibilities here.
The compromise system, which is so similar to the chromosome system that they're really the same idea just with some fine differences, I'd call 'soft ND' DNA execution, and really should be discussed in a new thread, perhaps, so we can continue working on the hard ND system in this thread.
Carlo:
--- Quote ---I would definately like to explore an ND DNA execution model, just not for the main course of the program. It's main interest is in evolution sims.
--- End quote ---
But evolution sims ARE the main interest of the program. Any other use is secondary.
--- Quote ---A simple slider between the two can allow us to tweak and decide which is best.
--- End quote ---
The idea of deciding an explicit -and totally arbitrary- method to favour recessive genes seems to me simplistic. Remember that robot in DB are still simply virtual machines storing _values_ in a memory array, NOT bacteria producing this or that _amount_ of proteins or enzymes. Pretending that a value stands for an amount (hmmm ... and what about shoot's -1 and -2? shootval locations? tie messaging? ) is wrong. It adds new intricacies to the way dna works. Things have to be SIMPLE. Clear. You've managed building a program that's every day more and more complex, with more rules, each with its own exceptions. Probably the only way to program a good bot today is to study the source code of the program to have an exhaustive idea of all its intricacies.
And now you want to add a SIMPLE SLIDER which decides how the dna should be interpreted? So that a gene is recessive, provided that the slider is in the correct position? Yeah, let's make it. We'll call it the stupidity slider, and it will have two labels at the two ends: "more" and "less".
Numsgil:
--- Quote ---But evolution sims ARE the main interest of the program. Any other use is secondary.
--- End quote ---
You may have designed it that way, but the current system is very much a dual interest. Evo sims are not either better supproted or more interesting than designing bots. This is a huge benefit of the program. Alot of the new people we get are first and foremost interested in designing bots.
The current system works just as well for either, while the ND system is only really interesting to evo sims. That is what I meant.
--- Quote ---Yeah, let's make it. We'll call it the stupidity slider, and it will have two labels at the two ends: "more" and "less".
--- End quote ---
Okay, first insulting your only supporter (albeit a mild one) is definately "more".
Second, the slider all the way to one side would be the same as just randomly picking one, which is what you're proposing anyway. (I assume you're calling your own idea "less stupid"? Probably not the term I'd use to describe an idea of my own) Seriously, what's the problem with giving the user more choices? The only possible problem is making the program look more intimidating to new users. There's ways to fix that (embedded options controls that are hidden from the user).
--- Quote ---The idea of deciding an explicit -and totally arbitrary- method to favour recessive genes seems to me simplistic. Remember that robot in DB are still simply virtual machines storing _values_ in a memory array, NOT bacteria producing this or that _amount_ of proteins or enzymes. Pretending that a value stands for an amount (hmmm ... and what about shoot's -1 and -2? shootval locations? tie messaging? ) is wrong.
--- End quote ---
You're right, it is arbitrary. But real recessive/dominant aspects to genes, from the point of view of phenotypes (which is where selection occurrs), is also arbitrary.
So what if -1 shots are dominant and -6 shots recessive? 6 fingers is a dominant gene, but it's worse than 5 fingers. (The 6th finger is useless). Dominance and recession is just useful for heterozygousy, which is important in dipolid organisms engaging in sexual reproduction. Having -1 shots being dominant won't mean -6 shots can't develop. It just means when they do they'll be homozygous.
--- Quote ---You've managed building a program that's every day more and more complex, with more rules, each with its own exceptions. Probably the only way to program a good bot today is to study the source code of the program to have an exhaustive idea of all its intricacies.
--- End quote ---
Yes, this is my goal. Complexity. I've said it before and I'll say it again. When I'm done, it'll be impossible for any one person to understand everything in DB! Why? What possible masochistic reason would I have for such a thing?
Complex systems, what ALife is all about.
--- Quote ---Emergence - more is different
What distinguishes a complex system from a merely complicated one is that some behaviors and patterns emerge in complex systems as a result of the patterns of relationship between the elements. Emergence is perhaps the key property of complex systems and a lot of work is being done to try to understand more about its nature and the conditions which will help it to occur.
The behavior of a complex sytem can not be understood in terms of a simple extrapolation of the properties of its components, elements and entities. As P.W. Anderson said in his 1972 science article (Science Vol. 177 No. 4047), more is different. At the macroscopic level of the system, new properties appear which can not be predicted by the properties of microscopic components.
Typically, the relationships between elements in a complex system are both short-range and long-range. The direct local interactions are short-range, that is information is normally received from near neighbours. Through top-down feedback and small-world connections agents can indirect influence all other agents. The richness of the connections means that communications will pass across the system but will probably be modified on the way.
--- End quote ---
Don't you see? Simplicity is death. The sure and simple path leads only to stagnation. That's where many ALife programs fail. In a simple system organisms can adapt quickly, but there's nothing new or unexpected. It's just a solution to a problem. It's stagnant and pointless. Who cares that the things can figure out the right value for 3 sliders?
But complexity. Now there's real interest! Yes, I will keep making the proram more complex. Each and every day! People will cry out in pain that they can't understand how all the parts are working together but the bots know. They know!
Hahaha!
When I added *.thisgene, I only invisioned it for *.thisgene .mkvirus store. But people found new and interesting uses for it in conspec ID, antivirus genes, etc. Each and every new element makes the program so much more than the sum of its parts. The only problem is in balancing them, and what better way than a slider the user can play with?
PurpleYouko:
--- Quote ---Yes, this is my goal. Complexity. I've said it before and I'll say it again. When I'm done, it'll be impossible for any one person to understand everything in DB! Why? What possible masochistic reason would I have for such a thing?
--- End quote ---
In this I am 100% on the side of complexity. It has always been my beleif that DB is WAY to simplistic and I have always argued for adding more complexity to the system.
Where my aim differs a little is in making a lot of the complexity behind the scenes while attempting to make the robot DNA commands somewhat easier to use (not to understand).
I may be primarily a genetic engineer as far as DB goes but I do want to see the evolution side of the game thrive too. For that to work, we could really use some simplified DNA commands. That is why I introduced the recent tie controls and plan on working to find ways to simplify the rest of them to the point where evolutionary adaptations might actually be able to use them.
I think the idea of diploid DNA with recessive/dominant genes is great. If we can't use some sort of user control such as sliders to determine which is which then we are stuck with a choice based solely on the decision of the programmer.
We can't realistically make it just random so we have to have rules.
What better way than to allow the user to define his own rules?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version