Darwinbots Forum
Code center => Suggestions => Topic started by: Carlo on May 29, 2005, 06:45:10 AM
-
First of all, I want to comment on Carlo's notion that we already have junk DNA. This is not exactly true, becasue true junk DNA is not expressed at all, while any "junk code" that evolved bots acquire actually does affect bot's behaviour - at the very least it places some numbers on the stack, which may affect real genes later on. So, when I am talking about junk DNA, I mean DNA that is not processed by program at all.
I really can't understand your point. Junk dna is present in DB in form of copies of genes which have been inactivated by mutations in the cond section. So it is really dna which is not processed at all. Take a look at some of an evolved dna files (for example FilansEvolved, though I don't know if it is in the standard distribution). It is full of genes which are never activated.
duplicate gene >> turn one copy off >> mutate for a while>> turn it back on>> got a new protein.
But then I thought about it some more... In DBs we are forced to use relatively high mutation rates, becasue we don't have time to wait for millions of generations for something good to appear and our population size is several hunderds at most. At these mutation rates, any inactive gene will go into complete mess very quickly and is unlikely to become anything even remotely useful for a bot.
And this is true. This is why, for example, there was (is?) a cap at three conditions per gene in the mutation routines (that is, no mutation can insert new conditions in a gene which already has three conds). The less the conditions, the more probable a gene is executed; and when a gene is executed, selection works on it again, so that it stops accumulating junk. The idea was of making possible and fast this cycle:
working gene -> gene duplication -> gene inactivation -> mutation -> gene activation -> working gene
The less the time between gene inactivation and gene activation, the more probable to select interesting features.
I'd like to propose again the non deterministic execution of genes. This means that only one gene should be executed per cycle. The gene to execute would be chosen randomly among the active genes, those which have true conds for that cycle.
Why:
1) there would be no more the mixture of sequential and non sequential execution of genes. Position in dna would count no more.
2) no more the problem of genes writing values in output location, taking effect only in the next cycle. For example, now if you have a gene which passes information through a tie and at the same time writes a flag in a memory location to tell another gene that it has done its job, you have the problem that the flag is immediately readable by the other gene, but the information won't actually pass through the tie until the next cycle. The other gene is activated by the flag if it comes after in the dna; it will be activated only in the next cyle if it comes before in the dna (I hope you understand what I'm saying, today my english is a real shit :))
3) Number of genes would count. As only one gene is executed randomly at each cycle, if the frequent execution of a gene is really important then for a bot is convenient to have multiple working copies of that gene. It's like evolving reaction times: more prompt reaction to events means more copies of a gene.
4) multiple working copies of a gene means also multiple slightly different copies of that gene working. Now, if you have two working copies, slightly different, of the same gene, the one which comes last in the dna "wins"; with non-determinism, you'd have mixes of the different effects.
5) multiple working copies of genes means faster evolution: changing a working gene can result in a new behaviour without destroying the original behaviour (still produced by the copy).
-
1. We have more than one definition of Junk DNA going around. Here's the list
- DNA that doesn't execute
- DNA that doesn't exist inside a gene
- DNA that codes for non existant commands
So shvarz is mainly talking about the second one in this case, while Carlo is talking about the first one.
2. The only problem with one gene/cycle is bots like The One. It's only a single gene long, and it manages to absolutely pulverize everything else. Yikes.
And also it would decrease the period of time 1 cycle represents. The simulation already runs slowly compared to other ALife sims.
I had an idea for synchornous DNA execution a while back. Here's the post (http://s9.invisionfree.com/DarwinBots_Forum/index.php?showtopic=159&view=findpost&p=244271).
Basically there are two camps.
1. Each chromosome acts as DNA does now. That is, the genes in the same chromosome execute as if they were in the current system. Then, the effects of the chromosomes are applied at the end of DNA execution. (In case of conflict, we'd have to devise some system. Perhaps randomly pick an action, or something along those lines).
We can create a seperate memory array for each chromosome to allow communication between genes in the same chromosome via memory just like what can happen now. Or not.
2. Each gene acts as an independant unit, and can't use the stack to pass values to other genes. All memory events are applied after DNA execution.
I'm in favor of #1, because it allows current bots to still work. I'd probably eliminate the stack's ability to carry over to further cycles, as well as prevent changes to memory from occuring until after DNA execution is over.
-
Regarding Carlo's proposal. We don't have to go as far as executing a single gene per cycle. Executing half of all genes would do the trick almost as well. And then of course the problem is that this may lead to consolidating functions into long complicated genes, that is to completely different outcome than proposed by Carlo.
-
IMO if we were to change the way that the DNA operates such that all of the genes that read TRUE are not always activated then it will completely and utterly screw up any form of bot programming.
All my carefully constructed MBs would be utterly useless as would all functions relying on activation at a precise age. And there are a lot of these.
For me this would make DB a complete waste of time as I am only in it from the genetic engineering side of things. I want my robots to be utterly predictable. I actively use the fact that an internal memory value flag can be used later in the same cycle. Most of my robots wouldn't be able to operate without this.
IMO it is one of the things that makes DB as good as it is.
I like it the way it is now
Comunications could be improved and very likely will be but please not at the expense of programming predictability or else we might just as well have a bunch of randomly moving circles on the screen.
-
When I get around to programming chromosomes, this is what I'd like to do:
PY, tell me if this is a huge pain.
Within each chromosome, genes can communicate using the stack within the same cycle, just like now. Each chromosome has its own stack, and each stack is reset every cycle.
Changes to memory locations are saved in a command stack until after all DNA is executed, so all the chromosomes appear to execute at the same time. (THat is, store, inc, and dec don't affect what appears to be in that memory cell, but the effects are still carried out at the end of the cycle).
So same cycle communication has to use the stack, multicycle communication has to use the memory. Right now both can do either, which seems kind of pointless to me. By specializing each, we can encourage different uses of each.
That's what I'd like to have happen. It would mess up a few bots (mostly yours I bet), but it would allow me to create a diploid DNA system for sexual reproduction, which would be a huge step forward for the evolutionary aspect of the program.
We could have a sexual reproduction system that's more than just shuffling every other gene.
-
What you are suggesting makes a lot of sense Num.
I don't actually care if it stuffs up a bunch of my older bots provided that the structure of the DNA is 100% predictable for writing new ones.
If I program a bot to carry out specific instructions in a specific order then that is the order I want it done in. No random gaps where a bot just spontaineously decides that it doesn't want to carry out a critical step in the program and just skips it.
If I want to send a particular message down tie number 615 on the cycle when the robot is aged exactly 23 then I want it to do precisely that, every time
Only carrying out one gene per cycle and skipping the others? Bad bad bad bad idea
Same for only performing the action from about half of them.
If a condition is met then the gene must always be carried out or else the robots lose all predictablity and become random blobs of crap rather than useful artificial life forms.
I would much rather go back to watching a bowl full of Sea Monkeys than play with such a system
-
I would much rather go back to watching a bowl full of Sea Monkeys than play with such a system
And we learn what PY did before he found Darwinbots.
-
Sea Monkies :boing: ...That explains alot :) :lol: :D
On a more serious note that sounds like the best suggestion, Nums. I honestly didn't know what to think about only executing a single or even half of the genes per cycle, the memory requirements would be unreal :blink: Poor computer is already hurting when running alot of bots.
Would something like:
Chromo1
DNA
Chromo2
DNA
Chromo3
etc.
Be possible for the chromosomes? I don't think anyone would like having to deal with seperate txt files for them.
Endy B)
-
Definately keeping all the chromosomes in the same file. I can see some problems arising though, as the current max DNA length is 32000. That's huge by today's standards, but chromosomes have a way of duplicating whole long stretches of DNA. I may have to raise the limit to a long, which is something like 2 billion. That would be intense. Can you imagine a bot with 2 billion DNA units? That would be like several gigabytes of DNA code.
More likely DNA of lengths around 50 000.
-
IMO if we were to change the way that the DNA operates such that all of the genes that read TRUE are not always activated then it will completely and utterly screw up any form of bot programming.
Your opinion is totally wrong. You're old enough to know well that every deterministic program can be transformed into a perfectly equivalent nondeterministic program. So the new type of execution would not screw up anything, it would just provide MORE possibilities and would be MUCH MORE elegant.
All my carefully constructed MBs would be utterly useless as would all functions relying on activation at a precise age. And there are a lot of these.
Again, totally false. Only one of the genes whose condition evaluates to true will be executed in a cycle; but you can always set conditions so that ONLY THAT particular gene's condition could be true at the right time, to be sure it is executed. The main difference is that you don't have to bother anymore about which gene comes first, which last, genes that take effect only after the complete cycle, genes that have immediate effect. More, EVERY gene which becomes active has an effect: that is, effect are not hidden by subsequent genes. If you have two genes:
cond
...
start
-1 .shoot store
stop
cond
...same cond as above
start
2 .shoot store
5 .shootval store
stop
BOTH will have effect, 50% the first gene and 50% the second gene. The interleaving between the two genes (1 cycle on average) is small enough to give the impression they are executed at the same time. This makes possible subtle tweaking and mixing of different reactions to events, which now are much more difficult to achieve. Would be great not only from the point of view of evolution, but also from the point of view of programming. Remember that if you want to obtain strictly sequential operations, you can do it in a straighforward manner, just by setting the appropriate activation conditions to genes.
I actively use the fact that an internal memory value flag can be used later in the same cycle. Most of my robots wouldn't be able to operate without this.
Are you sure you can't obtain similar, if not exactly the same effect, by breaking operations in different cycles, or grouping them in the same gene? Tell me why you use the "same-cycle" flags.
If a condition is met then the gene must always be carried out or else the robots lose all predictablity and become random blobs of crap rather than useful artificial life forms.
Again, totally false. And by the way, "artificial life" is not about programming combat bots. There's CRobots for that. So "useful alife forms" don't means "F1 bots that act exactly as I programmed them to".
-
Your opinion is totally wrong.
Now children, do I have to seperate you two :P
-
This is for Shvarz.
Shvarz, you've become an expert of evo sims, and probably you're the most expert in this kind of simulations. So, I was thinking of this experiment: would you try to run an evo sim on a version of the last DB modified to be nondeterministic? I think you're the most fit to run the experiment, since you have the best experience in tweaking evolution parameters and analyzing the results. It would be the best way to decide for a type or another of dna improvement (we could try the same also with other proposals).
As for the nondeterministic version, I have the routines ready, and I'm very curious about the result.
So? What do you think about that?
-
Sure, post a version at the FTP or e-mail it to me, whatever works for you. Would old bots work in this program? If not, then you'll have to give me some kind of working bot to start with, I suck at programming.
-
Carlo, if you'd like the darwinbots FTP username and password to upload, send me a PM.
-
Ok, I've uploaded the experimental nondeterministic version. It's on the DarwinBots FTP, in the misc section, just at the bottom.
I've tried a bit myself with a few bots (I flamma, preservans, fish school, and a tie feeder). Robots really seem to act less efficiently and in a less predictable way; but this may just depend on the fact their reaction times are longer, since only a gene per cycle is executed. The tie feeder didn't worked at all, probably relying on the execution of two genes in the same cycle. The fish school seemed to work pretty well.
Anyway, it needs to be tested by someone who knows better the actual program and the actual bots than I do. I even wasn't able to run a decent simulation: for some reason, veggie number (on the bottom bar) was always stuck to 101, except it sometimes suddenly started to grow. Maybe it has something to do with the old settings files in my DB folder or it is a bug of 2.36.
Ok. Shvarz, if you want to run some evo sim and tell us you impressions...
-
Are you sure you can't obtain similar, if not exactly the same effect, by breaking operations in different cycles, or grouping them in the same gene? Tell me why you use the "same-cycle" flags.
One version of DOM Inv uses a system where he sets a tie onto a victim (using a random tie phase which he stores into a memory location) and simultaineously sets a flag to show that the tie has been fired.
Later in the genome he uses the stored flag and tie phase number to feed on the tie that he just fired.
The following cycle he fires a new tie with another random number, overwriting the earlier one.
This is a deliberate technique to prevent the victim from using leach genes with *.tiepres to reverse the energy flow.
At other times with MBs I need to perform several things on the same cycle and while it would be possible to seperate them a little, it is already very difficult to form the entire structure within the 20 cycles that the initial tie remains soft.
First parent gives brth, baby overwrites the tie then rotates, checks that it is clear ahead then reproduces again etc. Try doing this with structures of ten or more robots and get it all to fit inside 20 cycles.
I have no problem with changing it such that the genes are pseudo simultaineous and have no effect on subsequent genes. That I can work around without too much difficulty even though it does directly undermine one of my most powerful combat techniques.
Completely ignoring certain gene activations anfd just choosing one of many that should activate on a given cycle will utterly destroy any robot that I either have made in the past or might make in the future.
Every robot that I have ever designed relies on having more than one activated gene per cycle. Even the most simple food finding routines rely on the fact that it is possible to use course direction changes first then overwrite them with finer direction changes when needed. (like if there is a bot in eye 9 and also one in eye 4)
With a randomly dropped gene activation system this won't work and the robot will go either one way or the other or maybe choose to do neither while it builds body points or maybe it will just stop and make a couple of shell points while it is being bombarded by a predator instead of returning fire or running away.
toatlly crap idea that will destroy DB IMO :(
-
I will download and try out the experimental system and see if my fears are well grounded or not.
-
OK I just downloaded and tried it.
As I feared each and every one of my bots becomes a useless lump of crap, neither moving nor feeding nor even recognizing each other.
They just sit around and die :(
This modification to the game adds nothing to the range of possible variety and takes away everything that ever made it interesting to me.
I can see where this may be useful and fun from an evolutionary point of view but for the combat side of the game it is the worst thing that could ever happen to it short of utterly losing the source code and having to start over again.
Make it an option to run non deterministically if you like but I absolutely hate it. :(
-
Not to harp on the issue, but the chromosome idea I explained above (http://s9.invisionfree.com/DarwinBots_Forum/index.php?showtopic=491&view=findpost&p=677161) and and this one too (http://s9.invisionfree.com/DarwinBots_Forum/index.php?showtopic=491&view=findpost&p=667768) solves all the problems Carlo pointed out, while not removing the deterministic nature of the program.
Non-deterministic languages usually follow a tree structure, that is, something like a non-deterministic turing machine (http://en.wikipedia.org/wiki/Non-deterministic_Turing_machine), which is way beyond the assembly like scope of the darwinbots language. We could add something along those lines, but that could be an ALife program in itself. (or even a doctoral thesis if done well enough).
What I offer is more along the lines of multi-threading. Each chromosome is its own thread, executing simoltaneously on shared resources.
From a strictly programming stand point, multi-threading is far superior. There are established ways on how to build such a system and program within it. Non-deterministic languages are still something of a novelty, and rather poorly studied. Plus, procedural single threaded programming is always possible in a multi-threading environment, so current bots wouldn't break (a huge plus when you can manage it).
That said, I have no problem with a non-deterministic checkbox if the hard work is already done.
-
As I said before Num, I can live with a system which simulates simultaineous gene activation without being able to set and use flags on the same cycle.
I like your idea as you described it above. It would be far more realistic in fact.
It is just when the program just randomly chooses to activate only one gene out of the many that flag true, that I can't deal with it.
-
I uploaded a slightly patched version of DB ND, the activations window was not working properly, and now it is.
I tried to run a sim. I noticed that many bots show some difficulty in moving, as they were in a high friction environment. But it is not an inheritable feature, so I think it's some kind of bug. Probably unrelated with nondeterminism.
I noticed also that reloading original name, mutations and generation from the dna file (the thing about which we discussed a few days ago, for the #shp parameter) worked in version 2.3 but not in version 3.36. Parameters are saved into the dna but aren't loaded back anymore. :angry:
-
That's weird. There are so many subtle bugs in odd areas, none of them really destructive, but not really helping anything either.
I've got a whole wall of sticky notes of things to work on.
-
I've got a whole wall of sticky notes of things to work on.
So that's another one, worse. It seems to me that some mutations aren't correctly reported in the mutations number variable. It seems to be lower than it should, even reporting 0 overall mutations for a dna that's clearly mutated (it had a gene duplication).
And I'm working on the dna parameters bug
-
Uhm, I tried the ND version from Carlo - I can't really start a succesful simulation. The problem (as PY pointed out already) is that current bots are not coded correctly for this version - they require cross-talk between genes. And the more genes they have, the less likely they are to work. My Alga Ternia seemed to be fine though, it ran and reproduced fine - but much slower than usual, which is also expected, because it has 7 genes. Time was flowing 7 times slower for it...
The time flow is the biggest problem with ND version. I think Dom ternia had no chance for survival even if all genes were fixed not to rely on each other. It has 32 genes, so time was flowing 4 times slower for it than for its prey! And it was flowing unpredictably: say you see something and want to follow it - how can you do this accurately if you don't know what is going to happen to you in the next 32 cycles? The next time acceleration gene activates may be "next cycle" or "100 cycles later". In 100 cycles the food is so far, that there is no chance to even find it.
So I think in its current form the undeterministic version is not workable even in theory. I really like the idea of it, and the possibilities it offers, but right now it gives only problems. Undeterministic effects must work on a much-much deeper level than "gene/cycle". Just like in real life - we have non-deterministic effects at quantum level, but they average out and result in continious experience of our consiousness. The way ND version works now is equivalent to us "phasing in and out" of consience: imaging that! You try to grab a pen and next moment you find yourself 3 meters away from the table where your coworkers moved you so that you don't get in the way. This is what current version does for bots.
-
Uhm, I tried the ND version from Carlo - I can't really start a succesful simulation.
I've already run a 1 million cycles simulation starting with e_diplomaticus. It seems to work pretty well.
My Alga Ternia seemed to be fine though, it ran and reproduced fine - but much slower than usual, which is also expected, because it has 7 genes. Time was flowing 7 times slower for it...
No. I dont' know alga ternia, but reproduction is usually triggered by energy level. Energy is still coming at the usual rate. The only difference is that the robot _notices_ it has reached the right energy level with some delay. If, on average, three of the seven genes are active at each cycle, then the delay should be of about 1.5 cycles after the energy is enough to reproduce.
I think Dom ternia had no chance for survival even if all genes were fixed not to rely on each other. It has 32 genes, so time was flowing 4 times slower for it than for its prey!
This makes no sense. The slowing down depends on the average number of simultaneously active genes, not on the number of genes. A 100 genes robot which has only one gene active per cycle, has the same reaction times of a deterministic robot. Probably no more than two or three genes are active on average at the same time in a 32 genes robot. So its _reaction times_ (not its speed) should be at most two times slower.
The next time acceleration gene activates may be "next cycle" or "100 cycles later". In 100 cycles the food is so far, that there is no chance to even find it.
Apart from the exaggerated numbers, this is true. The slower reaction times (nothing to do with 100 or even 10 cycles, anyway, but usually to or three at most) are a problem in a world in rapid change. For example e_diplomaticus has clearly some problems in following its preys, which often go really too fast. I'll try to run some high friction sim to see if, slowing down movements and making them less random (less bounces, etc), the nondeterministic bots work a bit better.
Anyway, I ran a 1 M cycles evo sim with diplomaticus. Nothing complex, but it evolved (it does distinctly better than the unevolved version). I've set very high mutation values for gene duplication and deletion, so that it ended up with 30 genes on average (it started with 10). Most of the genes are working, not junk, because they contribute to the overall behaviour, so there's a selective pressure on them. There's a risk of number of genes increasing in a sort of intra dna arms race (each duplicated gene subtracts a little probability to other simultaneously active genes of being executed) but probably it can be counterbalanced tweaking the cost of copying dna during reproduction.
This evening I'll tweak my sim parameters better.
-
I've fixed (I think) problems with mutation information passing to kids in my working version no one has yet.
Again, I think we should have ND DNA flow as an option, but its effects are just to surreal for most modern 'tweaked' bots except short bots (which by definition have multipurpose genes).
-
Good points, Carlo.
When I said that Alga ternia was slow, I meant that it was running slower. Before it saved 15 in .up on every cycle and now only every 3rd/4th cycle, so of course its speed was lower. I also had to adjust the energy flow, because Alga were now spending 3-4 times less energy/cycle than before.
Here is what I think about the time flow: If on every cycle a bot has 3 active genes, then all it's processes and reactions are 3 times slower than those of a bot with a single active gene. You can equate it to time flowing 3 times slower for it. The more active genes bot has, the slower is the time flow. This is a problem in itself, as you are driving evolution to either reduce the number of potentially active genes or to make each gene more complex. A duplicated copy of a gene is a huge liability, because without contributing much it slows down bot's reaction time. It should not be this way.
In addition, it is impractical from our point of view, because the speed of simulations is essentially slowed down by a factor equal to the average number of active genes.
As I said, in theory the non-deterministic processes should be moved further down into the guts of simulation, so that the execution of different genes appears to be parallel and happening at the same time.
-
Check out this exert from the genome of Hunter 2.2.
'turn towards enemies or food
'*************************
cond
*.eye1 *.eye5 >
*.eye1 *.eye9 >
start
mult mult 140 15
stop
cond
*.eye9 *.eye5 >
*.eye9 *.eye1 >
start
mult mult -140 -15
stop
cond
*.eye3 *.eye5 >
*.eye3 *.eye7 >
start
mult mult 80 7
stop
cond
*.eye7 *.eye5 >
*.eye7 *.eye3 >
start
mult mult -80 -7
stop
cond
*.eye4 *.eye6 >
start
mult mult 40 4
stop
cond
*.eye6 *.eye4 >
start
mult mult -40 -4
stop
'avoid conspecifics
'****************************
cond
*.refeye *.myeye =
start
mult mult 120 0
stop
cond
*.refeye *.myeye =
*.eye5 60 >
start
mult mult 628 0
stop
' Spin back after repro
' ************************
cond
*51 0 !=
start
mult mult 628 0
0 51 store
stop
'reproduce
'*********
cond
*.nrg 2000 >
*.robage 40 <
*.body 20 >
*.eye5 30 <
start
50 .repro store
1 51 store
mult mult 628 0
stop
cond
*.nrg 4000 >
*.body 100 >
*.eye5 30 <
start
70 .repro store
mult mult 628 0
stop
' rotate
' *******
cond
start
.sx store
.aimsx store
stop
Every one of these genes has to be 100% able to operate on every cycle or the robot does absolutely nothing.
Never mind slow reflexes. It just doesn't react to anything... EVER. it just sits there and does absolutely nothing.
It is completely impossible for it to see food and simultaineously turn to follow it. By the definition of the non-deterministic system, only one of these genes can activate in any given cycle, therefore it can never turn at all under any circumstances.
It is also 100% impossible for the carefully designed repro-spinback gene to have any effect whatsoever since this gene cannot ever act on the same cycle as the single gene that actually rotates the robot.
Occasionally one of them moves in a straight line for a while but that is about it.
The same is true of pretty much all the top robots these days.
Simple little things like Diplomaticus Diplo may still work reasonably well but that is because they are incredibly simplistic to start with.
I have given it a fair try and I still have to say that this concept is totally unworkable without utterly destroying DarwinBots.
-
I think the kinds of bots that work in a deterministic universe and a ND universe are incompatible. Which is why it's a neat idea for an option, but unworkable for the default.
-
Yup, I can go along with that. Might be fun for a bit of a play with evolving species but I sure won't be using it much.
-
Every one of these genes has to be 100% able to operate on every cycle or the robot does absolutely nothing.
Never mind slow reflexes. It just doesn't react to anything... EVER. it just sits there and does absolutely nothing.
PY, that's what happens when you use undocumented and deprecated techniques like using the stack to make genes communicate. There's nothing your combat bot can do that a nd bot can't - maybe just a bit slower. But it needs a different kind of programming. You shouldn't be so afraid of changes.
By the definition of the non-deterministic system, only one of these genes can activate in any given cycle, therefore it can never turn at all under any circumstances.
By the definition of a non deterministic system, you can't leave values in the stack for other genes, because it is erased at each cycle!
Simple little things like Diplomaticus Diplo may still work reasonably well but that is because they are incredibly simplistic to start with.
They are perfect for DB. DarwinBots, as the name suggests, is about evolution, not super perfect combat bots. You can use it as a programming game as much as you want, but you can't modify it to be a better programming game or favour combat to evolution. DB is _artificial life_ and that means that every other use you make of it other than evolving robots, is you personal misuse.
-
Before it saved 15 in .up on every cycle and now only every 3rd/4th cycle, so of course its speed was lower. I also had to adjust the energy flow, because Alga were now spending 3-4 times less energy/cycle than before.
Ok, that's normal. Obviously you have to tweak sim parameters to match the changed conditions.
The more active genes bot has, the slower is the time flow. This is a problem in itself, as you are driving evolution to either reduce the number of potentially active genes or to make each gene more complex. A duplicated copy of a gene is a huge liability, because without contributing much it slows down bot's reaction time. It should not be this way.
I don't think so. Say that a robot has three different active genes in a certain condition. Each of the three active genes has 1/3 chances of being executed. Now, if one of the three genes gets duplicated, the active genes become four, each with 1/4 chances of being executed; but, since the two copies of the duplicated gene are identical, now that gene has 1/2 chance of being executed, while the other two have 1/4 chances. So, a gene, duplicating, increases its expression in the phenotype, decreasing that of the other genes. So that an equilibrium will be found between the importance of the various reaction to events. Correctly balanced mixes of different reactions should be easily selected with this system.
Every one of the duplicated genes still contributes to the overall behaviour, because they are under selective pressure. They don't become junk immediately as it is now usual. And a gene that remains functional, is also a gene which has more chances to mutate in an effective way. And mutations contribute to the behaviour. Etc.
In addition, it is impractical from our point of view, because the speed of simulations is essentially slowed down by a factor equal to the average number of active genes.
This is true. However, I'd prefer a more elegant and more effective system working slower than a high speed system which is cludgy and works bad. The problem here is simple to solve: I'd slow down physics. Robots really move too fast in standard conditions for ND execution. I'm running a high friction sim right now, with robot moving MUCH slower... and it's interesting, robots after only 240K cycles adapted perfectly to the new environment, put against the original ones they completely wiped them out.
I've set high values for genes duplication and deletion (1 in 200 for duplication, 1 in 200 for deletion, E_Diplo had 10 genes at start); now the genes are 16, this means that an increase in genes number is positively selected, as I said before.
As I said, in theory the non-deterministic processes should be moved further down into the guts of simulation, so that the execution of different genes appears to be parallel and happening at the same time.
I surely agree. We could, for example, make genes execute each time in a different order. This would _discourage_ relying on the execution of a certain gene before in the same cycle; but on the other hand the execution would actually happen, sometimes. So, what happens if a gene sends a message through a tie, and signals to another gene that the tie now can be destroyed? Sometimes the other gene will read that signal _after_ the message has passed through the tie, but other times they will read it _before_, and destroy the tie before the message passes through it.
-
IF you really want ND to work right, the problem is thus:
1. All commands are executed at the end of every cycle. So complex commands cannot use more than one gene to work properly.
If commands are instead executed every n cycles, where n is roughly the number of genes the bot has, the genes can work together without necessarily communicating. Just an idea.
Obviously another problem is the nature of DNA execution, which leaves modern bots in the grind, so to speak, but that's inherant in the system.
We're reaching a stalemate position, so we should probably just vote and decide if this is the direction we want DB to move in.
I vote nay, for the simple reason that a chromosomal system such as I outlined solves all the same problems with non of the problems (I'm not even sure it has problems.)
-
1. All commands are executed at the end of every cycle. So complex commands cannot use more than one gene to work properly.
If commands are instead executed every n cycles, where n is roughly the number of genes the bot has, the genes can work together without necessarily communicating. Just an idea
No-o. If commands are executed every n-th cycle, things become exactly as they are now. One of the main reasons to move to ND execution, is that this way commands are executed right after the gene execution stopped: this means that the other genes are sure that the operations have been performed and that a physical effect has been produced. DNA now is only partially working like that: if you have two genes, the first is correctly aware of operations made by the second with up to date physics, but the second is not. When I programmed vermis_patavinus, which has a complex structure, I had to program its embryonic development backwards (with genes activating first placed in the last positions of the dna), to be sure that their activation sequence was coherent with the changes in the outside world.
By the way, can you make an example of a complex command that needs more than one gene to work _properly_?
I vote nay, for the simple reason that a chromosomal system such as I outlined solves all the same problems with non of the problems (I'm not even sure it has problems.)
Your chromosome idea moves nondeterminism from the level of the gene to the level of groups of genes. Instead of having one of the active genes executed, you have one of the cromosomes (in fact each a dna on its own) randomly picked and executed. But if an executed gene in my system is, at least, an active gene, why should be a chromosome preferred to another one? Chromosomes aren't active or inactive. You may have two chromosomes, one with just one gene always active (or even without any active genes!) and one plenty of genes. And you'd have each chromosome (and therefore, each gene) executed on average 1/2 of the times. You won't be sure of the execution of a gene, nor of the fact that an executed gene has produced any physical effect. So it seems to me that your system manages in combining together the worst defects of both systems, deterministic and nondeterministic.
-
By the way, can you make an example of a complex command that needs more than one gene to work _properly_?
Well, since The One is a single gene and does just fine, no, I can't.
But there are processes that are made easier by different genes. Forming a multibot being a good example.
Your chromosome idea moves nondeterminism from the level of the gene to the level of groups of genes. Instead of having one of the active genes executed, you have one of the cromosomes (in fact each a dna on its own) randomly picked and executed.
...
So it seems to me that your system manages in combining together the worst defects of both systems, deterministic and nondeterministic.
No, you misunderstand. ALL the chromosomes are executed at the same time. They just can't affect the cell until ALL other genes have executed. So, as far as they're concerned, they're all happening at the same time, which was your original goal, right? The only linearity at all is inside the chromosomes, where the stack allows values to be passed from gene to gene within the cycle.
At first I saw this as a liability. Real chromosomes aren't executed linearly, I thought. Since the proteins they inscribe are floating around in the cell, all can work at the same time, with one not operating before another. But later I learned, researching mutations and crossing-over, that expression of a gene, that is, it's transcription into a protein in the first place, can be changed if it moves location in the chromosome.
This implies that the transcription of genes is at least partly controlled by the genes around it. Probably transcription inhibitors at least partly work for genes around their primary target, or work for large locations of on the chromosome, or something along that line.
So while one gene passing stack values to another isn't 100% realistic, neither is it all that unrealistic, and bots aren't necessarily real creatueres anyway.
Where conflict arises in my system, perhaps two store commands to .up, we have to define a system for which command to follow. Randomly picking one could work, and follows alot of the consequences for ND DNA, but there are other possibilites too. We could give preference to one value over another. We could select the most numerous command every time. We could pick the command closest to zero, or furthest from zero. We could pick the command with a value closest to the bot's nrg levels. We could pick 101 over all other numbers because we like the way it looks. Each has different implications to DNA evolution and bot execution, so we'll have to pick a method carefully.
-
Well, since The One is a single gene and does just fine, no, I can't.
Perfect.
But there are processes that are made easier by different genes. Forming a multibot being a good example.
And this is the worst example you can take. Because multibots are particularly negatively affected by the current system, since they have to strictly coordinate actions which happen both inside and outside the robot, that is, in other robots. How can they manage to do that, if a gene don't know whether something really happened yet or not? As I told you, I had to write the dna of v_patavinus backwards to make it work properly. This wouldn't happen with the new system.
ALL the chromosomes are executed at the same time. They just can't affect the cell until ALL other genes have executed.
Ah. I thought for a long time about a system like that (no need for chromosomes, though, it can perfectly apply to genes only). The problem is that each gene should read values from a memory array and write back to a different memory array. And at the end of each cycle, you'd have to copy all the write memory into the read memory. Horribly time consuming. You may design an appropriate structure to hold the (location, value) couples written by a dna, and then just rewrite them on the true memory array at the end of the execution. Would be fine, but anyway won't solve the other problem, as you point out: that is, in case of conflicts you'd have to choose which value to store in the final memory, and this would be nearly impossible. Which compromise to take between -1 and -2 in the .shoot location? Or between two different tie addresses when using ties? And, finally, PY would cry, anyway.
-
And this is the worst example you can take. Because multibots are particularly negatively affected by the current system, since they have to strictly coordinate actions which happen both inside and outside the robot, that is, in other robots. How can they manage to do that, if a gene don't know whether something really happened yet or not? As I told you, I had to write the dna of v_patavinus backwards to make it work properly. This wouldn't happen with the new system.
Structured multibots would seem to me to be harder to create in a ND universe. Unless you have a drastically different design paradigm. In my experience, multibots work by:
cycle 0: do something
cycle 1: do something
cycle2: do something
all very structured and quite precise, especially for larger multibots.
Ah. I thought for a long time about a system like that (no need for chromosomes, though, it can perfectly apply to genes only).
Yes, you don't have to use chromosomes. But doing so allows both for backward compatibility with PYs stack intensive genes and for more involved reproduction procedures in the DNA, such as realistic meiotic reproduction and crossing over. It's really just a step in a process moving towards a more complete sexual reproduction model, which has always been a hurdle for DB.
You may design an appropriate structure to hold the (location, value) couples written by a dna, and then just rewrite them on the true memory array at the end of the execution. Would be fine, but anyway won't solve the other problem, as you point out: that is, in case of conflicts you'd have to choose which value to store in the final memory, and this would be nearly impossible.
But this problem is well known and understood. Specifically in multithreading theory (http://en.wikipedia.org/wiki/Multithreading). Note how our problem and the problems of singlethreading OSs are similar. Makes sense that a similar solution should be considered.
Actual programs with threads competing for resources have different strategies for which to give preference to. Some favor processor intensive threads, some the opposite. Semaphores can be used to regulate shared data, etc.
We don't have to actually create semaphores (although we could. That's a possible solution I haven't really explored), but we can model the end statistical effects on which commands are executed. And, worst comes to worst, and we don't have any good idea, just picking a random instruction is just about as good as ND DNA as far as removing the linearity between gene execution.
And, finally, PY would cry, anyway.
PY's already acquiesced for a chromosomal sytem, so we don't have to worry there. :P
-
since the two copies of the duplicated gene are identical, now that gene has 1/2 chance of being executed, while the other two have 1/4 chances
Damn, I should have thought of this myself! :)
Well, these are very good points and interesting discussion from everyone. One thing is still not clear for me (because I don't program bots): It seems like the major advantage of ND system would be an appearance of several processes happening at the same time in parallel. Why would we want this? And why is current system so bad? I would like to see some kind of simple example of the power of the new system as compared to the old.
-
And why is current system so bad? I would like to see some kind of simple example of the power of the new system as compared to the old.
I second this completely.
And another thing. Since when is the real universe non-deterministic?
OK so at the quantum level it may be for for all intents and purposes, everything above that is totally deterministic anyway.
Even with that, the argument of whether the universe and everything in it, is 100% deterministic or not, is still raging in the highest echelons of physics research.
Even proponents of non-determinism wouldn't go so far as to suggest that macro-molecules like DNA don't act as if the universe is totally deterministic.
You have to go way below that to find any sign of non-determinism.
If you want realism then I would say that you need determinism along with parallel processing with the end result being the average of all the separate chains of determinism.
Num's proposed system seems to satisfy this pretty well.
I just don't see any realism whatsoever in just arbitrarily picking one or even a few genes to allow to activate on any given cycle. In reality there is nothing truly random about VB. We have been over this before on another thread. By setting the seed number you can exactly reproduce any sim you like. That won't change in the least if you randomly drop perfectly good genes for absolutely no good reason.
I just see absolutely no point in it.
-
OK so at the quantum level it may be for for all intents and purposes, everything above that is totally deterministic anyway.
It's the other way round !! Quantum mechanics is totally deterministic. At higher levels, thermodynamics comes into play and it gets random.
-
No, Quantum Mechanics suffers from a great deal of true uncertainty. It is probably the only science that relies so heavily on probability functions instead of deterministic functions.
From wikipedia for quantum mechanics:
Generally, quantum mechanics does not assign definite values to observables. Instead, it makes predictions about probability distributions; that is, the probability of obtaining each of the possible outcomes from measuring an observable.
It is only on the quantum level that unpredictability, and thus by definition non-determinstic phenomenae, are observable. Wether or not they are really non-deterministic, as PY points out, is still debatable. They could be following laws we don't understand. But at the moment probability functions works well.
The ND nature of electrons can be seen in how some can escape from a black hole through Quantum Tunnelling (http://en.wikipedia.org/wiki/Quantum_tunneling). It's because the electron is not in a deterministic state that it can do this. It's because defining the electrons kinetic energy and position exactly simoltaneously is impossible (or maybe this is a consequence of the former. I'm not sure).
-
No, Quantum Mechanics suffers from a great deal of true uncertainty. It is probably the only science that relies so heavily on probability functions instead of deterministic functions.
No, the quantum evolution of particles is totally deterministic and predictible. It's only when you interface quantum mechanics with classical physics that probabilities intervene. Probability distributions are much more important in statistical physics, for instance.
The ND nature of electrons can be seen in how some can escape from a black hole through Quantum Tunnelling. It's because the electron is not in a deterministic state that it can do this. It's because defining the electrons kinetic energy and position exactly simoltaneously is impossible (or maybe this is a consequence of the former. I'm not sure).
Hmm... I won't discuss electrons tunneling out of a black hole since this requires a quantum theory of gravitation, which doesn't exist, but quantum tunneling in general isn't really related to non-locality (I assume that's what you mean with "non-determinism"). Besides, quantum tunneling is treated perfectly deterministically. The fact that the electron either crosses the barrier or not is a consequence of its subsequent interaction with matter.
-
Determinism isn't the atomicity of a state, it's the determinability of a state. Hence the name.
If I show you an electron, and say 'here's how fast it is, with X certainty, where is it?' you can only give me Y certainty that it's at a location.
That is, Determinism is unerring predictability. And that's something particles don't have on a subatomic level. You can be reasonably certain that a large number of electrons will follow a certain pattern, but the lower your sample size, the less certain you can be on how it's going to behave. (Which reminds me of the Foundation series and psychohistory).
My point with quantum tunneling is any single given electron has a small probability to be in a completely different location, not based on it's Newtonian possibility of getting there. You can't predict if electron Z is going to do it, but you can figure out the end net effects of massive amounts of electrons from a probability function.
Note that quantum tunneling is quite real and is the basis of tunneling electron microscopes, so it's not some crazy theory, but has physical evidence to back it up.
-
Well, let's leave the determinism versus non-determinism aside, it is not really important for our purposes.
To PY: The idea is not to create non-deterministic universe, but to allow parallel processes to occur. What the proposed system wants to accomplish (I guess) is that each cycle is broken down into several mini-cycles. During these minicycles different genes can influence the behaviour of the bot simultaneously. One gene says: let's go forward 10 steps, another gene says: no, let's go backward 3 steps. Both are working during mini-cycles, but when you look at the final result of the cycle, you see that bot moved 7 steps ahead. This is a simple example and can be accomplished in ways that are easier than the one proposed by Carlo. But I assume that there are things that can only be accomplished using Carlo's system and that's why I asked for an example of such a thing. Maybe firing several different shots at the same time (but this too can be accomplished in an easier way).
P.S: The whole thing will remain completely deterministic, that was just a poor choice of words by Carlo. The interaction between different genes will go to hell as a side effect of the new system and I personally would sorely miss that, because it is such a powerful system and nothing of equivalnce is proposed for the new system. :(
-
The whole thing will remain completely deterministic, that was just a poor choice of words by Carlo.
Let's start from here. I noticed some confusion deriving from the use of the term "nondeterminism". Confusion is due to the fact that unfortunately -and strangely enough- there are at least two different uses of the concept of nondeterminacy in computer science. Nondeterministic finite automata and ND Turing machines are models in which the computation follows different branches at the same time. Every time a branch point is encountered, the machine "forks" in two different and parallel computations. This model of computation is sometimes called "angelic nondeterminacy", and clearly it's what you were thinking of (also because it's by far the most known).
A different use of "nondeterministic" have been introduced by Dijkstra in 1975. Dijkstra's nondeterminacy is based on guarded commands, that is, blocks of code activated by a condition. If more than one condition is met, only one of the blocks is randomly chosen and executed. This is called "demonic nondeterminacy". And this is the kind of nondeterminacy I am talking about.
There's a little explanation of how guarded commands work here:
http://en.wikipedia.org/wiki/Guarded_commands (http://en.wikipedia.org/wiki/Guarded_commands)
The interaction between different genes will go to hell as a side effect of the new system and I personally would sorely miss that, because it is such a powerful system and nothing of equivalnce is proposed for the new system.
This is completely false. Interaction between genes would be perfectly possible, using memory locations.
For example, reproduce and shoot one info particle to the son:
cond
*.nrg 6000 >
start
50 .repro store
1 100 store
stop
cond
*100 1 =
start
0 100 store
familyloc .shoot store
myfamily .shootval store
stop
This shows also the elegance of this system. If you want to do the same thing with the current system, you face a few problems. First of all, you have to know that gene 2 is executed right after gene 1, before any external action. Then, you may ask yourself, well, but is the shot created _before_ the son is deployed, or is it created _after_? In the first case, maybe the shot won't hit the son. If you want to be sure of the correct order of the actions, you have to put gene 2 before gene 1 in the dna. This makes you sure that the requested actions are performed in the correct order.
Both are working during mini-cycles, but when you look at the final result of the cycle, you see that bot moved 7 steps ahead. This is a simple example and can be accomplished in ways that are easier than the one proposed by Carlo. But I assume that there are things that can only be accomplished using Carlo's system and that's why I asked for an example of such a thing.
I think there isn't a single example like that you're asking for. You can always find a new way to mix up the results of different genes; you can make a mean or a sum or a complete overwrite of the different values falling in a same memory location, depending on the location; you can make possible to shoot two, three, or one hundred shots within a single cycle; deciding that if the shot is -2 or -1, then shootval is calculated as a mean, if it is >0 then there's an overwrite, and so on. You'd then have the problem of deciding how many shots you can shoot in a single cycle, because shooting 100 shots against the enemy in a single cycle wouldn't be fair. Etc. Then you'd have to do the same thing for every other sysvar or memory location. These solutions are possible, but cludgy, inelegant. When I designed the dna model, I made a mistake. I wanted a daemon system, like that described by Dijkstra, but I made it internally sequential. I thought it was right to have multiple genes activating at the same time. It's not. It's even worse because all the physical actions are taken after a complete cycle has been executed, so that some genes are aware of them (those which come before of the genes producing physical effects, because they will be executed again only in the next cycle) and some not (the genes coming after).
So, the advantages of the nondeterministic system are
1) It's elegant, coherent. Makes understanding DarwinBots much, much simpler. It's a known model.
2) Genes have immediate physical effect. Their order is not important anymore. If a gene which takes at the same time physical and non-physical actions has been executed, you are sure that both actions have been performed.
3) Genes don't cover reciprocally their actions. Each active gene has effect. From the point of view of evolution this is very important, because genes duplications will bring to existence new working genes, not just dead copies, ready to be turned in junk dna.
4) Behaviours will mix. A gene for shooting attack particles can duplicate and mutate in a gene for sending disturb values to the victim. Both will have effect, and effects will mix. The correct balance between the two actions can be reached duplicating further one of the two genes.
5) Time becomes an important factor. A gene duplication changes the power balance of genes inside the genome. Duplicating a gene means giving it more execution time, subtracting it from that of the other genes; more active genes allow more complex or balanced reactions, but at the expense of reaction times.
6) May introduce the new choice between fast'n'simple and complex'n'slow robots. Also specialization may become more probable, because specializing would mean becoming faster. For example (maybe an idea for the future) the sequence of actions needed to perform photosynthesis may slow down a predator too much to let it follow a prey, so that it has to choose between the two ways of feeding.
-
Dijkstra, that crazy guy. It's scientists like him that give the whole field a bad name! I mean, how can anyone take you seriously when you start talking about philosophers eating spaghetti? Is it any wonder I switched to from Computer Science to Mathematics? At least ring theory makes sense, and sounds cool and scientific :P
The system you propose does have some strengths, but let me balance you pro list with a con list:
1. Effective speeds of the already fairly slow program will be lowered. This is a simple consequence of only being able to execute part of your genome at a time, which makes the slice of time a cycle represents lower. The longer your genome, the less each gene gets per cycle, so the slower the bot will appear to react (unless you load up genes with a bunch of unrealted instructions, that is, make all bots short bots).
2. You've created race conditions (http://en.wikipedia.org/wiki/Race_hazard). Which is probably bad. The current system is reliant on the timing of the genes, but it is so in a predictable way, so it doesn't count as a race condition.
3. Genes have clear incentive to multiply in the genome. This can lead to explosive copying of genes and elimination of competitors (delgene everything but yourself). This is not inherintly a bad thing, but the emphasis of the program should be on the behavior of bots more than the competition of genes, and a cancerous runaway gene copying itself could slow the simulation and use up quite a bit of memory.
I've voted against several ideas on the basis of gene competition alone. Keep competition between genes limited. (If you can't see why, I can elaborate further, but my reasons are half forgotten, so I'd have to sit down and reremember it).
4. Bots with one gene work just as well in the current system as in an ND system. Inherantly, you're thinking of genes as one or two command segments, roughly of equal length between all bots. But some modern genes can be monsters. In your example, a gene that does what both genes does is better than the two smaller versions put together.
So in the end you're encouraging bots to either have 50 copies of the same gene or a single gene that does it all. Again, this is not inherintly bad, but I would prefer to see large segments of passive and different DNA develop over large segments of active duplicate DNA. Both are likely to develop something, but if the DNA is encouraged to spread out it makes it more readable and reverse-engineerable.
5. And also there shouldn't be an inordinately huge difference in execution speeds between a single gene bot and a multigene bot, since genes are all supposed to be executing simoltaneosly. In your system a single gene bot gets to execute effectively his entire DNA (which can be just as complex as a multigene bot) while another bot only gets to execute part of his, which implies the genes are running at different clock speeds, which is a fallacy.
That is, you're trying to balance the field by saying each bot gets to execute one gene per cycle, when it should be that each gene gets to execute as often as all other genes, (including genes in other bots). A simple fix is to have a counter for genes that prevent them from activating until after X cycles.
I think you're moving in the direction of sims like Avida, which give organisms a time slice to execute in. For your system to work, all bots must have a finite time slot in which to execute which is roughly equal to all other bots. That is, all 50 of bot A's genes should appear to have executed in the same time period that bot B's one gene did. (Again, all genes happening at the same moment).
This is really the strength of DB. The program isn't making artificial distinctions within the DNA, but the bots end result is what's tested. This is what attracted me to the program. It's so different from all otehr ALife sims that it's found a niche. There's no reason to follow the rest of the crowd when we're doing just fine in our current system.
6. Most of the benefits of your system can be achieved in other ways. For instance, your two gene example would work just as well with a sleep command (which I proposed in another thread). Backwards compatibility is important to maintain when possible. There isn't anything your system can do that we can't adapt the current language to do just as well with a little imagination and time.
-
Maybe the definitions have gotten mixed up.
There may well be more than one defininition of non-determinism in computer science but then that isn't my field so when we start talking about determinism , I see it in terms of physics and chemistry. (my fields)
Determinism at a quantum level is absolute with respect to wave forms and probabilities but it is inherantly impossible to precict the position, and velocity of a single particle so any direct effect that this particle has on any other particle becomes non-deterministic in an absolute sense.
On a macroscopic level, the only thing preventing us from being able to determine the way one single atom of air in one part of the world, effects another single atom in another part of the world, is a lack of information about the all of the physical position, velocity, temperature etc. of all the others in between. If we had the ability to know all of this and the computing power to model it then we would be able to determine the exact effects.
With enough information, we could model all macro-molecule interactions (including DNA/RNA) and see that they become completely predictable based on causality.
The different genes should be found to work in parallel with small strings working in sequence. A particular part of a gene will produce a specific protein based on a specific input. Then that protein can be used for some other action within the sequence.
Sounds like Num's proposed idea and I like it.
I don't see any realism whatsoever in the Daemon system. In a real organism, any gene activates whenever it gets the right input. You can't just arbitrarily stop a chemical reaction! When the right chemicals come together in the right proportions and orientations, THEY WILL REACT
It isn't what I would call elegant. It is closer to what I would call a complete misrepresentation of reality.
Sorry and all that but I hate everything about it.
-
1. Effective speeds of the already fairly slow program will be lowered.
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.
2. You've created race conditions (http://en.wikipedia.org/wiki/Race_hazard).
Can you be more specific about this point?
3. Genes have clear incentive to multiply in the genome.
No. A gene can reproduce itself only making the bot work successfully and reproduce. There's no reason for a gene to duplicate against the advantage of the bot it is in. A gene must be cooperative towards the entire genome (this is the concept of gene pool). Even in the case of a gene able to actively duplicate itself inside the dna of a robot (in case there will be commands for doing so) duplicating too much will subtract energy and _time_ and lead to a rapid death of the whole organism. So, NOW genes have a clear incentive to multiply themselves in the genome, since time is not a resource. Think of viruses: they rapidly spread in the whole population, and can infect a bot with as many copies of themselves as they want.
I've voted against several ideas on the basis of gene competition alone. Keep competition between genes limited.
Again, genes in general won't compete, as their interest is the robot's interest.
4. Bots with one gene work just as well in the current system as in an ND system.
Yes, this is a problem. I haven't tried it, but I know there's a very strong robot having only one gene. For it there would be no difference between deterministic and nondeterministic execution. There would be two possibilities here: either accept this fact (bots like the One will never evolve in an evo sim, so there's simply no problem) or 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.
So in the end you're encouraging bots to either have 50 copies of the same gene or a single gene that does it all. Again, this is not inherintly bad, but I would prefer to see large segments of passive and different DNA develop over large segments of active duplicate DNA. Both are likely to develop something, but if the DNA is encouraged to spread out it makes it more readable and reverse-engineerable.
I'm not sure to understand what you mean. Remember that active copies of the same gene are also subject to mutation. This means that duplicated genes are a good material for evolution. Also, remember that an inactive gene, lacking of any selective pressure, becomes in a few generations a complete junk, and going back from junk to a functional gene is extremely improbable.
In your system a single gene bot gets to execute effectively his entire DNA (which can be just as complex as a multigene bot)
This, again, depends on decisions we may take to discourage too complex genes. 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.
when it should be that each gene gets to execute as often as all other genes, (including genes in other bots).
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. 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. By contrast, the meaningless energy parameter in DB is really a stupid idea.
This is really the strength of DB. The program isn't making artificial distinctions within the DNA, but the bots end result is what's tested. This is what attracted me to the program. It's so different from all otehr ALife sims that it's found a niche.
DB isn't different from other alife sims. It's just what a true alife sim should be. Now, changing the way dnas are executed to a more coherent and elegant system, which, among other things, introduces time as a resource (think carefully about this: the only significant resource in a world in which matter and energy don't exist, it's time) don't seems to me to change the fundamental properties of fairness and open endedness of the simulation.
There's no reason to follow the rest of the crowd when we're doing just fine in our current system.
It's not a matter of crowds or niches, but of what is and what isn't interesting, elegant, coherent.
For instance, your two gene example would work just as well with a sleep command (which I proposed in another thread).
Horrible. :lol:
Backwards compatibility is important to maintain when possible. There isn't anything your system can do that we can't adapt the current language to do just as well with a little imagination and time.
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.
Anyway, seems to me we're blocked. You'd never accept the nd solution. I've thought of a compromise. It should work this way.
All active genes are executed. The values are read from the memory array, but the store command writes to a list of lists. For example: the operations:
1 10 store
2 20 store
2 20 store
5 50 store
6 50 store
7 50 store
will produce the list
10 ->1
20 ->2,2
50 ->5,6,7
At the end of the complete cycle, the memory array is written with values taken from the list. If a location has more than one value associated, the value to write in the memory array is chosen randomly among the values in the list.
This way, we'll have some of the good effects of nondeterminacy (duplicated genes still active, memory and external effects visible at the same time, genes balancing) but executing all active genes at each cycle. The time effect, which I think would have been interesting, won't be present. To prevent communication between genes in the same cycle I'd also reset stack pointer after each gene.
Comments?
-
I also agree that we are stuck, I see good points from both sides and only time can tell who's right. So I'm OK with the compromise. It actually does sound a bit like Nums' chromosome idea (which I am not too fond of either btw).
But I have a suggestion, instead of making a lis of lists, why not just say that a gene has 50% chance of over-writing any value in a given memory location? That way it can be done on the fly. My personal preference would be to allow 100% chance of writing something in a memory location if the current value there is 0.
Also, we can introduce some kind of commands that would define the "efficiency" of a gene. Say some mutatable number located immediately before condition - express it as a percent of 32000 and let it represent the probability of over-writing any values by the gene that follows.
-
But I have a suggestion, instead of making a lis of lists, why not just say that a gene has 50% chance of over-writing any value in a given memory location?
This way, genes with the most chances of having effect would be genes at the end of a dna. If I have four instructions:
1 10 store
2 10 store
3 10 store
4 10 store
4 has 50% probability to be written in 10; 3 has only 25% chances to be written, 1 and two have both 12.5 chances of being written.
Anyway, the idea of always overwriting zeros is unfair (for example, in a counter or a flag 0 and 1 have an equivalent importance); so you'd need anyway a list.
Also, we can introduce some kind of commands that would define the "efficiency" of a gene. Say some mutatable number located immediately before condition
It seems to me that just duplicating genes would be enough...
-
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.
-
As promised, this is my thoughts on how to improve the ND system.
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.
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.
2. You've created race conditions (http://en.wikipedia.org/wiki/Race_hazard).
Can you be more specific about this point?
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.
(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.
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.
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.
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.
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.
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.
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.
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.
For instance, your two gene example would work just as well with a sleep command (which I proposed in another thread).
Horrible. :lol:
What is horrible? The idea of a sleep command or...?
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.
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.
-
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.
But evolution sims ARE the main interest of the program. Any other use is secondary.
A simple slider between the two can allow us to tweak and decide which is best.
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".
-
But evolution sims ARE the main interest of the program. Any other use is secondary.
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.
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".
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).
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.
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.
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.
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 (http://en.wikipedia.org/wiki/Complex_system).
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.
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?
-
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?
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?
-
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.
How can you measure how well the actual system works for evo and combat sims? So how can you say that it works "just as well"? And, what do you mean with "the nd system is really interesting for evo sims"? Are you saying that it would actually work better than the actual, but you don't want to switch because it would be (thing which I don't really believe) a problem for combat sims?
Okay, first insulting your only supporter (albeit a mild one) is definately "more".
Sorry, but I'm tired of discussions. I simply think that DB is loosing day by day what made of it an interesting program, and there's no way to convince you of this.
Seriously, what's the problem with giving the user more choices?
Just seems to me chaotic to leave to the user's choice something which is so low-level as the way dnas are executed. It's always a problem of elegance.
But real recessive/dominant aspects to genes, from the point of view of phenotypes (which is where selection occurrs), is also arbitrary.
I think you shouldn't introduce rules specifically to obtain one result, like in this case. Similarities between biology and simulation are welcome, but I don't like ad hoc solutions.
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?
This is a silly idea of complexity. Complexity arises from few, simple rules combined together in unpredictable ways. Think of Conway's game of life, for instance. How much time will take you to explain the rules of the Conway's universe to a newbie? 1 minute? And cellular automata generate complexity. A predictable complexity, where emergent properties are possible. On the other hand, many rules, some ad hoc, patching other rules here and there, designed to provide only a precise outcome, produce only chaos. How much time would take you to explain how DB works to a newcomer?
The text you quoted defines perfectly what DB is becoming: complicated. Not complex.
Who cares that the things can figure out the right value for 3 sliders?
I absolutely agree with you on this point. Most alife sw out there perform just some kind of optimization, not evolution.
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.
That was a good idea. Others (actually _many_ others) aren't. For example, mkvirus isn't a good idea. You had the opportunity of designing a whole new system for copying genomes and reproducing (an activity which should require a complex activity, and _time_), and just as a side effect create viruses, as well as all the other effect you just mentioned. Mkvirus, by contrast, is really a little, ad hoc idea.
The only problem is in balancing them, and what better way than a slider the user can play with?
Because you have to offer some degree of certainty at the low levels of the simulation. And you must have the courage to make some choices. Otherwise everybody will be playing a different game.
-
How can you measure how well the actual system works for evo and combat sims? So how can you say that it works "just as well"? And, what do you mean with "the nd system is really interesting for evo sims"?
What I mean is that currently, I have just as much fun writing bots as running evo sims. I can run evo sims in any program, but DB allows me to really put my programming skills to the test and make some killer robots.
The ND system is more interesting from an evo sim standpoint. Writing bots in it becomes more difficult because you can't be sure how it's going to act. If you see it not do X, you don't know if it's not doing it because the DNA isn't working or just dumb luck. You quickly become frustrated and give up.
I don't think either system is better or worse for evo sims. Bots will adapt given enough time to any settings. As long as they can survive at all. I don't think ND adds anything to evolution that can't be added in other, more backward compatible ways.
Sorry, but I'm tired of discussions. I simply think that DB is loosing day by day what made of it an interesting program, and there's no way to convince you of this.
Perhaps it's losing what made it interesting to you, but it becomes ever more interesting to me as time goes on. Do you realize that this is the longest I've ever worked on a single project? 6 months. That's incredible for me. So it must hold some allure to me.
I'm sure most other people would agree with me on this. There hasn't been a stable release yet that I find less appealing than the version before. The moment (multiple I suppose) people pine for an older version is the moment we know we've moved in the wrong direction.
At some point you have to accept that you're idea is either wrong or unpopular, which amounts to the same thing in a collaborative effort. Not every idea I've had has been good or popular, and it's only been through half a dozen people telling me so that I've come to realize when this is the case.
The only idea I've refused to give up on is chromosomes and sexual reproduction. For months now I've hammered away at the problem. If you check some old threads, you'll see how my idea has matured as people have continually said "no, and here's why".
Take the criticisms of your idea and fix them. Re examine the original goals and see where a different system can work. As programmers we understand that there's no such thing as a perfect solution. Hammer away again and again at the problem until a solution is found.
What you see as elegant I see as different. While it solves many problems, it creates many new ones. If you can find ways to fix the ultimate unfairness (each gene in the simulation needs to execute as often as all other genes), the idea would then be 'elegant'. Add to that backwards compatibility, and the idea would be brilliant. It would make me cry tears of joy.
Just seems to me chaotic to leave to the user's choice something which is so low-level as the way dnas are executed. It's always a problem of elegance.
This particular slider doesn't dictate how the DNA is executed, but the magnitude of a particular effect. It would be one thing if the slider was between reverse polish notation and Polish notation. Then it really would be stupid. This slider is more for the discrepancy between recessive and dominant genes, which is something that the user has every right to play with. I can imagine many interesting experiments that can be performed using different settings.
Might even be a worthwhile paper. The Effects of Gene Dominance on Adaptive Systems. Might be there's no difference. Might be it makes adaption harder. Might be it makes it easier. I don't know anyone's really played around with it to find out.
I think you shouldn't introduce rules specifically to obtain one result, like in this case. Similarities between biology and simulation are welcome, but I don't like ad hoc solutions.
Speaking of ideas no one likes... This one I've been pushing since before we moved boards. No one likes any idea I can come up with for establishing dominance or recession. I've tried hash functions, arbitrary rules, just about anything I can think of. Notice I keep trying new ideas. Eventually someone will like one of my ideas, or I'll think of something else that allows this as a natural consequence (the golden idea). You just have to keep plunking away until something works that people like.
This is a silly idea of complexity. Complexity arises from few, simple rules combined together in unpredictable ways.
True, but the simpler the rule set, the less complex it is. The real world has so many interconnected rules operating on each other. Most of them don't appear to be related at all (Unified Field Theory aside). Imagine if DB had people who dedicated themselves to combat techniques, or multibot creation, or chasing behavior. When you can get all of DB in your head at once it's too simple. This isn't a game, you don't have to understand all the rules to play.
As PY said, as long as the interface is relatively simple, as long as new systems follow the interfacing patterns of older systems, each and every new element makes the program ever more complex, adds newer and newer shades of grey to a still rather black and white program.
I agree that many systems in DB are adhoc. Viruses are quite an arbitrary add-on. But the core of Darwinbots is very simple, and has remained so. While it would take several hours to explain all of DB to a newbie, it would take only a few minutes to explain everything necessary to either create a bot or run an evo sim.
As long as that base, the absolute minimum, remains fairly clean, even ad hoc addons fit well into the mesh.
If I had designed viruses, likely I would have coupled it with a sexual reproduction system, and gene transferance like between bacteria. But each programmer has a different way of solving a problem, and especially in a free projet like this, time is a factor. I'm pleased enough with viruses as they stand. There's more that can be done in this area, but it's not a bad system at all, and it's simple enough to get working (.mkvirus, .vshoot, .vtimer)
I also agree that reproducing should take more time, but I'm not sure how well such a suggestion would be recieved, so I hold my tongue. It's a minor point that I don't feel is hurting either evolution or leagues, but does upset subtle implications within the program. Much better to concentrate on specific criticisms of the program that are widely held. The big problems that need to be tackled:
1. Speciation isn't possible
2. It's hard to create a predator/prey cycle without veggy population limits or repopulating veggies, both of which are very artificial.
3. Sexual Reproduction isn't possible and/or doesn't work (what we have, no, isn't really sexual reproduction, but a kind of bastard child of sexual and asexual reproduction).
4. The program takes too long to evolve bots for the impatient (simulation speed)
5. And, if you believe what Botsareus keeps going on and on and on and on about, "mutations don't work!!!!1111".
These four (5) problems are where I spend most of my time. Everything else is candy.
Notice when I first tried tackling the removal of the linearity between genes, it was done with the intent of allowing diploid organisms to develop and sexually reproduce with real life rules. Ie: problem 3.
Because you have to offer some degree of certainty at the low levels of the simulation. And you must have the courage to make some choices. Otherwise everybody will be playing a different game.
On some points yes, but constants should always be user defined, except where they're important for speed optimizations (maxspeed makes collision detection bearable).
What the program does can be arbitrary, but to what extent it does whatever it does needs to be user defined. And, of course, good defaults help users make sense of it all.
-
Writing bots in it becomes more difficult because you can't be sure how it's going to act. If you see it not do X, you don't know if it's not doing it because the DNA isn't working or just dumb luck. You quickly become frustrated and give up.
That's your pure supposition, you haven't even tried. If a gene has 1/3 chances of being executed at each cycle, if your sim runs at 30 cycles/second it will be executed 10 times on average each second. This seems to me enough to exclude "dumb luck", from the point of view of the programmer.
Programming ND bots would be a new challenge for the programmer, asking him to take in account also the time/ chances effect, on one end, and the complexity, on the other.
Anyway, I'm not trying to convince you, as this is obviously impossibile...
Do you realize that this is the longest I've ever worked on a single project? 6 months. That's incredible for me. So it must hold some allure to me.
Well, this explains a lot of things. If you had been working on it for six years, probably you'd see things in a different way.
At some point you have to accept that you're idea is either wrong or unpopular, which amounts to the same thing in a collaborative effort.
Yes. And that's why I hate people. :lol: I don't like to remind this to you, but think of the average level of evolution sims around... and you'll understand how much the "popular judgment" is reliable.
True, but the simpler the rule set, the less complex it is.
Balls. Fractals are complex, particle simulations are complex, cellular automata are complex... all examples of complexity generating from a few simple rules. Evolution generates a great amount of complexity, with just two little rules. So, keep in mind that complex systems aren't complicated systems.
Ok. I think this discussion can stop here. I have no more time to devolve to it now (I've lost enough in the last week). Since it is you who are working on the code, you have the final decision. At least, I hope that some idea may have passed (not the ND idea, but the fact that there's something wrong, both from the point of view of coherence, and that of evolution in the way dnas are executed, and the importance of the time factor, and so on).
-
You sure now how to depress a guy. :lol:
I'll play around with it and add ND as an option. There's nothing that says the program can't house every imaginable simulation variety at once. :)
-
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.
How can you measure how well the actual system works for evo and combat sims? So how can you say that it works "just as well"? And, what do you mean with "the nd system is really interesting for evo sims"? Are you saying that it would actually work better than the actual, but you don't want to switch because it would be (thing which I don't really believe) a problem for combat sims?
Okay, first insulting your only supporter (albeit a mild one) is definately "more".
Sorry, but I'm tired of discussions. I simply think that DB is loosing day by day what made of it an interesting program, and there's no way to convince you of this.
Seriously, what's the problem with giving the user more choices?
Just seems to me chaotic to leave to the user's choice something which is so low-level as the way dnas are executed. It's always a problem of elegance.
But real recessive/dominant aspects to genes, from the point of view of phenotypes (which is where selection occurrs), is also arbitrary.
I think you shouldn't introduce rules specifically to obtain one result, like in this case. Similarities between biology and simulation are welcome, but I don't like ad hoc solutions.
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?
This is a silly idea of complexity. Complexity arises from few, simple rules combined together in unpredictable ways. Think of Conway's game of life, for instance. How much time will take you to explain the rules of the Conway's universe to a newbie? 1 minute? And cellular automata generate complexity. A predictable complexity, where emergent properties are possible. On the other hand, many rules, some ad hoc, patching other rules here and there, designed to provide only a precise outcome, produce only chaos. How much time would take you to explain how DB works to a newcomer?
The text you quoted defines perfectly what DB is becoming: complicated. Not complex.
Who cares that the things can figure out the right value for 3 sliders?
I absolutely agree with you on this point. Most alife sw out there perform just some kind of optimization, not evolution.
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.
That was a good idea. Others (actually _many_ others) aren't. For example, mkvirus isn't a good idea. You had the opportunity of designing a whole new system for copying genomes and reproducing (an activity which should require a complex activity, and _time_), and just as a side effect create viruses, as well as all the other effect you just mentioned. Mkvirus, by contrast, is really a little, ad hoc idea.
The only problem is in balancing them, and what better way than a slider the user can play with?
Because you have to offer some degree of certainty at the low levels of the simulation. And you must have the courage to make some choices. Otherwise everybody will be playing a different game.
been spending some time crawling thru the old messages.
got to say ...
Carlos is right on in his take on where DB is headed ...
perhaps it will become a flash physics sim with pretty bots ...
but it's headed for a dead end as far as being an ALIFE sim.
imo.
which doesn't mean anything anyway. ;)
so it goes.
-
I've always felt kind of weird, cause the ALife people accuse me of not making it ALife enough, and the combat sim people accuse me of not making it combat-sim-y enough...
I think the program has a good balance, but then again, I programmed it didn't I.
-
imo ...
they are separate ideas ...
the combat bots more an AI, top down, be in control of everything ...
and the ALife a bottom up, provide the space/environment ... let it evolve idea.
don't think they mix well.
-
I think so far the balance was pretty good. Slightly skewed to combat, but still giving enough to evo people.
-
Au contrare mon ami.
I think the two approaches can be mixed perfectly. IMO, most A-Life sims fail because the actual DNA of the bots is way too simple. More complexity gives better realism.
If what you want is for new exciting behaviours to develop quickly then you need simple rules (unlike DB). Then again if that is what you want then realism is not for you anyway.
DB is quite possibly the most complex A-Life sim out there now and it is getting more and more complex all the time.
The ideal is a highly complex system where almost anything is possible. Programming the bots should be simple for easy behaviour but very difficult for extremely complex behaviour. We also need different niches which can be colonized and this is where DB isn't so good yet. (then again nor are the others). I think we will get there eventually though.
-
Au contrare mon ami.
I think the two approaches can be mixed perfectly. IMO, most A-Life sims fail because the actual DNA of the bots is way too simple. More complexity gives better realism.
If what you want is for new exciting behaviours to develop quickly then you need simple rules (unlike DB). Then again if that is what you want then realism is not for you anyway.
DB is quite possibly the most complex A-Life sim out there now and it is getting more and more complex all the time.
The ideal is a highly complex system where almost anything is possible. Programming the bots should be simple for easy behaviour but very difficult for extremely complex behaviour. We also need different niches which can be colonized and this is where DB isn't so good yet. (then again nor are the others). I think we will get there eventually though.
I couldn't disagree more.
starting from complex is about controlling ...
a top down notion ...
more the 'intellegent design' approach. ;)
evolution is about keeping it simple ...
and 'allowing' complexity to evolve.
very different ideas ...
and easy to see which way DB is going.
THIS is the reason ALife sims fail, btw ...
from folks trying to make them AI things ...
and 'control' the outcomes.
same thing humans try to do to nature ...
but guess what?
ma nature bats last ...
and never strikes out. ;)
but hey ...
it's your program ...
and obviously you guys are going to do what
you want to realize your own vision.
I'm sure it will become a nice physics/bot combat sim ...
but you aren't going to evolve anything.
-
The basic design philosophy is that the bots are like a giant switch board, like those old fashioned telephone operators.
The DNA is like the telephone operator.
The DNA connects various bits of memory to other various bits of memory.
Each memory bit is simple, as you say Griz, this is sort of the purpose of compelx adaptive systems.
The memory bits are things like xpos, ypos, amount of body, go forward, shoot, etc. Really basic, basic building blocks.
The potential complexity comes in the fact that the DNA is Turing Complete (I haven't proven this yet but I believe it to be so... May be some issues with not being able to access it's own operating memory space...)
-
We may be just arguing over simantics. Griz, perhaps you could point something out specifically that pushes the program in the wrong direction in your opinion, if even slightly.
As far as I can tell, the worst (any generic, not specifically Griz) you can argue is that our priorities are misplaced, that we waste time working on frivelous features instead of working on core features (that you want).
But the core features themselves aren't regressing, and the adding of new features (minus introduced bugs obviously) doesn't hurt the unworked-on older features.
Darwinbots should be an everything-to-everyone platform. A kind of swiss-army knife of the ALIfe community. And I see no reason why it shouldn't be just that. If a feature you want to see implemented hasn't been, a good place to start is to look at the code yourself.
I'm actually working about 50/50 between adding core things (like a diploid DNA in the future, which the current 2.4 DNA reworking was essential for).
-
OMG, atleast I got one supporter.
I always thought that I was stupid about thinking DB going more into combat that evolution.
Well atleast I haven't left the DB community to it self, I am the invisible stalker of you scared nightmares combat people... ;)
Okay back to reality. Griz you are saying exactly what I had in mind, but never were able to write. Well it is hard to make ALife simulations, it not just something you just sit down and do overnight, or over week. It takes a very long time.
I think for DB, it has lost the ability to evolve truely interesting behavior. Something like a WOW-experince. But on the other hand, it is very good (or could be) at modeling eco-systems, without interference from mutations. Mutations in DB are almost lethal becuase of the highly complex structure of the vitual bot CPU (the bots internal building, the stack and the memory.) and the DNA language. Mullers Rachet what ever you all put into this haven't even been proven in real biological creatures and have only partial been proven in digital organisms.
I could continue, but in short, when you put more complexity into DB (Griz's term, Intelligent Design, uh I love that word ;)) you only make evolution weaker, hard & lesslikely to produce something useful.
I have high regards about the two main figures in DB now -->
PY & Numsgil.
But we all have different tastes and I think you two (PY & NUM, NOT INSULTING!!!! some please) have worked so long for this project (especially PY) that you have become narrowminded.
Were is the GRID everyone has been talking about since the dawn of time?
Were is the metabolism everyone has been talking about since everyonce began talking about the grid?
Were is this and were is that?
Instead we get --> planteaters singularities, smiliy-mode, shapes-mode, electricity (not implemented yet, but who knows), even Num began discussion Relativity Mode, Zelos began a thread about naming DB-units, Distributed Programming the list goes ever on....
I havent been the best my self, but come on, lets begin discussion the details in the grid, metabolism, no longer have an veggies definition, that bots can turn veggies and vice versa.
Or can it be that it will be confusing with all this to the combat sims, and thereby being left out???
And don't give me an answer about porting the code to C, or that it is boring.
....
-
Well Num came first...
Oh crap pushed the back button, and swihcehasfjk all my writing were gone!!!!!
Ah I hate that!
But DB as
A kind of swiss-army knife of the ALIfe community
Well Num, a swiss-army knife is a nice tool. But how often do you use a swiss-army knife to cut down a tree?
or
Build a brigde?
For a brigde you need two things (atleast):
-Rope & Tree
If you have the rope, you can use the swiss-army knife to cut it in pieces.
But what about the tree. You could cut down a tree, but it will take you a very long time, and then cut the tree out in planks take even longer.
Well you could cheat and buy some prefabricated tree, then it is easy to make a brigde, but you are cheating. Well an axes would actually have been a better tool for making this brigde.
This is what DB does, cheating, gives out the tree, not letting evolution figure out that it would be better to have an axe and cut down a tree.
In short when generalizing, you lose much specialization ( :P ). You can do a little of this, and a little of that and so on. But nothing more.
And even the above quote don't even give any meaning. Artificial Life is much more that just simulation, what about GP, EP, other GA's etc.
-
Carlo the main problem (sorry, I am using vb) is: what if you have:
If cond then
x = x + 1
End If
If cond2 then
y = y + 1
End If
If cond3 then
moo() 'just to make sure there is no 50 , 50 chance possible
End If
If cond4 then
moo() 'just to make sure there is no 50 , 50 chance possible
End If
If the genes are executed at random then we have:
x = 1 y = 20 , or y = 1 x = 20 , or y = 11 x = 5
but to get x = 10 y = 10 is almost impossible...
otherwise your method works fine...
A possible solution will be to use some Ensteins stuff:
Calculate the length of each gene of each robot, and execute some robots more times then others , but execute them with x = x + 0.1 or somthing. The actual cycles will be actualy 10 cycles for some robots, 20 cycles for some robots , and 2 cycles for some robots. But the end result was that each robot increased there x correctly.
But here I am moving to what Numsgil is already done brainstorming about. And my method seems more cpu hungry then Numsgils anyway...
-
(bots like the One will never evolve in an evo sim, so there's simply no problem)
I am not too sure about that from time to time...
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.
I hate that idea Num, and I also hate the fact that you are turning DB into a programers dream vedio game. It is an alife sim after all... I only favor complexity when it gives more solutions then problems. solutions in areas like bioevolution are my main prefereance. (sorry)
5. And, if you believe what Botsareus keeps going on and on and on and on about, "mutations don't work!!!!1111".
Sorry, Scratch that one, I was confused back in my bad english days that "evolution" and "mutation" is the same thing. Mostly back then I was refering to "evolution" not "mutation".
Mullers Rachet what ever you all put into this haven't even been proven in real biological creatures
Greven, I don't think anyone intentonaly put muller's into db. It just happend that way.
But I am really really interested in knowning why it is not proven in real life yet. I hope you have some explonations of that....
-
Mutations in DB are almost lethal becuase of the highly complex structure of the vitual bot CPU (the bots internal building, the stack and the memory.) and the DNA language. Mullers Rachet what ever you all put into this haven't even been proven in real biological creatures and have only partial been proven in digital organisms.
I could be misreading you, but I think you have this totally backwards.
Mueller's ratchet is not explicitly programmed into Darwinbots. It's simply a fact of life for all asexually reproducing creatures.
That is, Darwinbots is subject to Mueller's ratchet because it's an accurate simulation of asexual organisms. Which is encouraging-- sort of.
Real organisms are indeed influenced by Mueller's Ratchet, wiki it if you don't believe me. Most organisms, however, have found ways around it through Sexual reproduction and horizontal gene transfer, which the bots are sort of lacking (sexual repro is disabled in 2.4 because the code needed to be rewritten to conform to the new DNA coding mechanisms).
It is true that many mutations are lethal in DB, but guess what! This is true of real life to! Alot of your DNA is coding for basic things like converting glucose into pyruvate, etc. These have not changed much in millions of years because any mutation in these are quite lethal.
I could be missing the mark, but I'd say that you're really complaining that DB models real life too well. Real life is boring, and real evolution takes a long, long time.
But I've kind of grown attached to real life. Darwinbots is emulating the rules of real life, trying to capture the same essence. Evolution sims take alot of patience. No one expects their E Coli to evolve overnight, and you shouldn't expect the bots to either. Shvarz has run some very convincing simulations in the millions of cycles, and his bots definately show evolution at work.
Were is the GRID everyone has been talking about since the dawn of time?
Were is the metabolism everyone has been talking about since everyonce began talking about the grid?
Bogged down in technical details. Do you realize how much memory it would take to do the grid like how everyone wanted? Several hundred megs of RAM. HUNDRED. And then if DB is ever expanded into 3D...
It's been in the back of my mind, juggling all the pieces. I think it's starting to coallesce, and the answer is baby steps towards full metabolism and the grid. Which is what I've been doing.
Instead we get --> planteaters singularities, smiliy-mode, shapes-mode, electricity (not implemented yet, but who knows), even Num began discussion Relativity Mode, Zelos began a thread about naming DB-units, Distributed Programming the list goes ever on....
Most of those things take no time. Planet Eaters was a sort of "I'm redesigning the physics engine, I could totally throw this in". Took me two hours. That includes debugging. Smiley mode was PY's thing, and was him practicing with different drawing things you can do in VB to see how practical adding a dimension of shape would be to DB.
For every silly idea that's just fun, I program 2 hugely sophisticated features that aren't self evident. Redesigning the DNA system is a huge one. Redesigning mutations to be more in line with natural modes and other ALife programs (like Avida) another.
Those huge things take many, many hours. Should I break down the time I spend programming so you guys get an idea of how it works?
I havent been the best my self, but come on, lets begin discussion the details in the grid, metabolism, no longer have an veggies definition, that bots can turn veggies and vice versa.
Or can it be that it will be confusing with all this to the combat sims, and thereby being left out???
That's what that nice little subforum is for. In suggestions. It's so important it gets its own subforum. Don't blame me if no one posts in there.
And don't give me an answer about porting the code to C, or that it is boring.
Actually, porting it to C has gotten me two other programmers interested in programming. It's going to be well worth the effort.
-
In short when generalizing, you lose much specialization ( :P ). You can do a little of this, and a little of that and so on. But nothing more.
And even the above quote don't even give any meaning. Artificial Life is much more that just simulation, what about GP, EP, other GA's etc.
I only recognize GA (genetic algorithm), don't know the other acronyms...
I think this is where the metaphor breaks down. They say proof by example is fraud... In real life, a swiss army knife can't have, say, a jackhammer attachment. In code, adding new and larger things only increases download size, and sometimes simulation speed. Simulation speed much more rarely, and download size... we're already under 2 megs. So tiny...
Darwinbots is like a swiss army knife with access to hammer space (wiki hammer space if you don't know what it is).
Point to something that is in Darwinbots that specifically precludes the adding of specialization in something else.
I say there is nothing. Again, you may think our priorities are misplaced, but I dare say at worst we are simply not advancing the program, not making it worse.
Point to another ALife sim that has a Turing complete DNA language (say Avida or Tierra, etc.) that allows for something that Darwinbots can not possibly do. Again, I say there is nothing.
There are things that they can do that we aren't doing, but only because we haven't programmed them yet! Their main advantage is speed. Avida can run thousands of generations in a single hour.
That said, Darwinbots can never be like Darwinpond/Genepool, and have incredibly fast evolution. Why? Because Darwinpond/Genepool only mutate maybe 7 variables. There is no behavior evolution, only technique. That is, it's an excercise in optimization.
That is something that Darwinbots is not, and something that any Turing Complete DNA language Alife Sim can never do as well as the simpler simulations. But that's okay, because optimization is only so impressive.
-
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.
I hate that idea Num, and I also hate the fact that you are turning DB into a programers dream vedio game. It is an alife sim after all... I only favor complexity when it gives more solutions then problems. solutions in areas like bioevolution are my main prefereance. (sorry)
PY said that, not me <_< I still agree though...
Everyone thinks I am some rogue programmer, but I'm not! I understand ALife very well. I understand biology quite well, better than most that aren't involved in it. And where I don't know something, I ask. shvarz has been very good at keeping us on track biologically speaking.
If you had any idea how complex even a simple bacteria is...
Darwinbots is simple. So painfully simple. Where you see a jungle I see a desert. I believe I said this before, in this exact same post even.
I will strive each day to make Darwinbots more complex.
I mean this in the proper definition, as apart from Complicated.
I will strive each day to make Darwinbots less complicated and more complex.
edit: Where I said that (http://forum.darwinbots.com/index.php?showtopic=521&view=findpost&p=691232).
-
quoting Greven:
I always thought that I was stupid about thinking DB going more into combat that evolution.
nope ...
unfortunately, I'm afraid you are correct in your
accessment of DB in it's present incarnation.
I'm with Carlo on this ...
his vision of what an alife/evolution sim should be
is right on, imo, and how I envision it as well.
but ...
it doesn't matter ...
it's not going to happen.
and that doesn't matter either ...
it's just a simulation ...
having nothing to do with reality or real life ...
and of no real importance.
ole ma nature is running her own experiment ...
and in that one ...
we all get to be part of it and contribute to where it goes. ;)
-
I could be misreading you, but I think you have this totally backwards.
You did. I cant think of anyway to implentment Müller's Rachet (MR for short), you put biological terms /hypothesis onto DB, that is what I meant. Well MR is still just a hypothesis, not a true rule in nature, like the thermodynamics is for physics (you know what I mean). And Num stop lecturing me if I was some sort of imbecil idiot.
I have read hundreds of books about evolution and thereby biology.
Have healthy pile of books about artificial life.
My only problem is that I have a hard time expressing my self (in english) properbly, so the native speaker of english can fully understand me.
Well you see the DB Algorithm (DBA for short), has one problem.
It is extremely fragile and nowhere near robust.
Example placing 10 in memory slots 299 does nothing, placing it in 301, makes the bot reproduce. There are no correlaction between this, but it happens. The search space for DB is multi-multi-dimensional.
For a minute forget about Genepool etc., I havent even mention them, and actually I dont like them becuase of the optimizition algorithme they really are, nothing (reallly) interesting will ever happen here.
Take Avida in has an instruction set with 28 default instructions. Tierra about the same, cant find the documentation.
(Edit: 32, I am so stupid, I knew that Tierra coded its instruction in a binary string of length 5, damn)
But DB has 48 basic instructions, and here we should then add all the possible numbers. Which I will not do no. That smart thing about DB is the stack, were numbers are placed, and instuctions works on. With this it would have been extremely messy. But 1000 memory cells, is way to much, in the way it works has it is. I cant even imagine how the search space looks like in DB, it is easy enough for Avida. But DB there are so many factores that it is impossible to extract any usefull info. Well I will return later, right now I should make my Examination project in functional programming (Moscow ML / SML if anyone knows that)...
But bytheway:
QUOTE (Greven @ Oct 23 2005, 05:01 PM)
In short when generalizing, you lose much specialization ( ). You can do a little of this, and a little of that and so on. But nothing more.
And even the above quote don't even give any meaning. Artificial Life is much more that just simulation, what about GP, EP, other GA's etc.
I only recognize GA (genetic algorithm), don't know the other acronyms...
GP ~ Genetic Programming
EP ~ Evolutionary Programmering
EA ~ Evolutionary Algorithm
GA ~ Genetic Algorithm
These are mingled and blend into each other and cannot be, on a certain level, distinguised between exactly.
-
And Num stop lecturing me if I was some sort of imbecil idiot.
Well, when you stop sounding like one... :lol:
Okay, that was probably a little too :pokey: and not enough :wub:
But 1000 memory cells, is way to much, in the way it works has it is. I cant even imagine how the search space looks like in DB, it is easy enough for Avida. But DB there are so many factores that it is impossible to extract any usefull info.
Ah, now we're getting to the root of the problem. 1000 memories is probably way too much. But its had 1000 memory spaces per bot since the beginning of DB time.
So that's not really a criticism of how PY or I have modded the program, more a criticism of the basic architecture of the program.
To change it now would really break alot of bots. And whenever I make it so that older bots are even slightly less powerful in newer versions I tend to hear whining <_< ;)
Maybe I should add tags to the DNA so bot programmers can indicate they want their DNA run a certain way...
-
Maybe I should add tags to the DNA so bot programmers can indicate they want their DNA run a certain way...
LOL. This is about trying to CONTROL ...
and that isn't evolution ... that is Intelligent Design ;)
We may be just arguing over simantics. Griz, perhaps you could point something out specifically that pushes the program in the wrong direction in your opinion, if even slightly.
I wish!!!
no ... it is not at all semantics.
and it isn't a light push ... it's a violent shove, imo. ;)
it is a fundamental difference in how we view the process of 'evolution'.
it is exactly what I said above ... you are attempting to 'control' all aspects ...
to tell bots how to act/react rather than allow alife/evoloution to be simulated ...
for bots to develope the interconnections and interdependency that comes from evolving
together within an environment we provide.
as the programmer/user ... we should be setting them up with an environment ...
and the abilities to sense/exist/reproduce and develop within it ...
and then get out of the way ... let them determine what works and what doesn't.
to not impose our own ideas of how they should behave onto them from the get go ...
rather then setting them up to find what works and what does not.
now if you don't see that ...
then there isn't anything I or anyone is going to be able to say
that will reach you ... that you will hear.
so it goes.
but I don't want to rain on your parade ...
it is obviously something that interests you ...
that you are passionate about ...
and that's great.
you have your vision, your perception of how evolution works ...
and perhaps it is exactly as you imagine it to be.
or not. ;) lol
not much I can do about it ...
other then to learn VB for starters and play on my own.
so thanks for the glimpse and the motivation to do so.
-
as the programmer/user ... we should be setting them up with an environment ...
and the abilities to sense/exist/reproduce and develop within it ...
and then get out of the way ... let them determine what works and what doesn't.
to not impose our own ideas of how they should behave onto them from the get go ...
rather then setting them up to find what works and what does not.
The unfortunate thing is that I fully agree with this and I am pretty much 100% certain that Num does too.
In my opinion this is precisely what we are doing too. Everything that we change in the program gives the robots new avenues which they can explore, more variables with which they can experiment with, more options, more ways to fail or succeed.
How can this be control?
We aren't telling them what to do. We are merely expanding the possibilities of the things that they might do. The fact that it is possible to artificially write a DNA package merely shows what it is possible for the bots to do. Artificially written DNA code is most definitely ID but that is entirely beside the point.
I have heard it argued before that we should keep the program very simple.
My answer there is that a simple program can only produce a simple lifeform with an extremely limited range of possible interactions with its universe.
A behaviour simply cannot develop unless the universe in which the bots live, allow it as an option.
In the real world, a microbe can evolve a new enzyme that enables it to feed from a new food source. In DarwinBots (or any other computer sim) this is utterly impossible unless the possibility has been specifically allowed for by the program.
How could a multi-celled organism develop muscles unless we specifically program the possibility to do so?
Simple programs are fine if all you want is simplistic and unrealistic sims.
Simple rules are fine provided you want to place artificial limits on what might be achieved.
Num and I are attempting to make everything possible by expanding the possibilities and complexities. Only that way can anything truly complex ever emerge from the gene pool.
With each layer of complexity we add, we lose more of our control over the creatures who inhabit the DB universe. How can that be wrong? It is simply coming closer to reality.
-
PY ...
I'm sorry ...
it is not about complexity ...
it is about keeping it simple ..
and letting the complexity 'evolve'.
let's look at the results ...
which is really the bottom line.
without going back to 2.21 or before:
do we have a Darwinbots version that actually works ...
one that people can use as an alife/evo sim?
no.
we do not.
I'll check back one of these daze and see it anything
has changed.
maybe by version 2.47.b27.fc101 or something.
but I'm not going to hold my breath.
-
Again, if you could point to a concrete, single feature PY or I have added...
-
Again, if you could point to a concrete, single feature PY or I have added...
it isn't any one feature Nums ...
it is your philosophy on how evolution works.
it's a basic and fundamental misunderstanding, imo ...
but I also know you are not open to hearing that ..
that you think you have it all figured out.
perhaps you have.
then again? ;)
anyway ...
we will see.
if/when you ever make this work ...
I see it going the wrong way ...
getting farther and farther from being a working program.
ok ...
'nuff said ...
no use beating a dead horse.
it's your project ...
go for it.
see ya
-
it is not about complexity ...
it is about keeping it simple ..
and letting the complexity 'evolve'.
Complexity CANNOT evolve in a limited, simple system!
The code CANNOT write itself!
Bots in any environment can only do what the environment allows.
Why doesn't anybody get that? :blink:
Without specific code to allow a robot to reproduce it simply WON'T
If we didn't tell them exactly how fast they could move after sending a movement impulse, based on a complex, realistic set of physical laws, they WOULDN'T move
here is the simplest bit of code you can get...
Let's see you evolve a bot in it.
Nothing happens does it? Because there are no physical laws (or code for that matter)
What? Too simple? See my point?
This is a computer program. Stuff can only happen if it has been specifically programmed to be able to happen.
-
not at what I am saying ...
we aren't reading from the same page here ...
or even in the same book, PY.
but you are going to see it the way you see it so ...
there's really no point to this.
like I said ...
go for it.
we will see.
-
Griz, I am all for evolution and I absolutely want to see complex things evolving from simple elements. In that sense I absolutely agree with you and I've been always opposed to introduction of arbitrary features for bots. Some of things that went through anyway are examples of this kind of approach, like "poison" and "venom" and "waste".
But I've known PY and Nums for a while now and I have to tell you that you are not correct - they do understand how evolution works and they put in a lot of effort into making DB evo-friendly. The reason they don't understand you is because they are programmers who want to know what feature exactly is wrong and how exactly you propose to fix it. I did not see in your posts these things either, so even I don't understand what exactly pisses you off so much. Yes, there are tons of things that can be added, but we only have 1.5 programmers working on this very complex project now - give these 1.5 guys a break :)
-
but you are going to see it the way you see it so ...
there's really no point to this.
Of course there is a point.
I want to know what you are talking about.
I seriously have no idea what you are driving at.
I would just like to know how exactly we can have complex behaviour from simple rules. Give me an example.
-
Here is my point of view:
Griz says Darwinbots is headed in the wrong direction. I disagree.
Griz says that Darwinbots shoudln't try to control bot behavior. I agree.
Griz says that Darwinbots is headed in the direction of controlled behavior. I disagree.
Um, there seems to be a logical inconsistancy somewhere. One of my postulates is wrong.
The most obvious thing that could be wrong is that the program is indeed controlling the bots, and I am wrong in thinking that it doesn't.
Well then, I ask for proof or some counter-example towards this end.
Or is one of my other postulates wrong?
-
I dunno. I want to understand his point of view but I just don't get it. To me, if you exponentially increase the number of possible outomes, assign randomness to those outcomes then you must be exerting less direct control of that outcome
I just don't understand how it can be viewed otherwise and I wish somebody could explain it to me. :wacko:
-
I'll try to explain what I think Griz means. We actually discussed it to death before, but I guess one more time is due:
1. The biggest problem with DB is limited complexity of environments. Create more environments and even currently available DNA commands are going to combine and form complex structures. I completely agree with this.
2. DNA language has to allow such complex interactions that are impossible to program by humans. Like the non-deterministic DNA structure - it can create very complex beaviours that are not almost impossible to program, but are even almost impossible to understand by looking at the DNA. I am not sure I agree with this, as one of the most important reasons for making AL sims is to model (and therefore - understand) complex biological systems.
3. I'll just give an example: Take "venom". Why is it bad? What is the mechanism of its action? How can you develope resistance to it? It is just an arbitrary feature that was introduced to model something that people wanted bots to do. They wanted to have poisonous substances that could be used as weapons and you just added it. This is what Griz means by "controlling" bots behaviour. His (and my) approach would be to create "substances" or "metabolism" with a bunch of molecules and rules for these molecules and their interaction with bots DNA and stack. Then some of these molecules might turn out to be what we consider "poisonous" - they will mess up bot's behaviour. Then some bots may figure out how to deal with these "poisonous" substances and how to deliver them to other bots, creating what we consider to be "venom". I completely agree with this point, but I'm willing to tolerate some shortcuts. If metabolism is not possible right now, well.. let's at least have some arbitrary "venom" and "poison". I am expecting these will simply become obsolete at some point...
-
I would like to point out at this point that I wasn't around for the creation of Venom, Poison, Waste, Shell, Slime, Ties, Shots, Body, or even nrg.
I inherited all that when I started coding. If I had been around, I would likely have wished them to be done differently, more complexly, but then everyone would do the same task differently as someone else, wouldn't they?
-
As far as the poison and venom goes, I agree. They are arbitrary and somewhat unrealistic. I, too would like them replaced by a system of chemical interactions which can develop according to a set of rules.
My problem though is how we implement the way these chemicals work. The actual interactions (creating proteins and so forth) are not too great a problem (theoretically) but the effect they they have on a bot could be.
For example how does Bot A know that substance d is good but substance x is poisonous? At some point there will still need to be arbitrary definitions of what is good and what isn't.
A way around this could be to have the substances poison a reaction rather than directly hurting the bot. That method has some merit but will still be difficult to implement. IMO this may be becoming way too complicated. We will have to hard code a huge number of chemical interactions. I can see benefits to this but also downfalls.
I prefer a simplified approach (enzymes again) to this. Don't model every metabolic pathway in minute detail. just add a simple set of rules that use maybe 64 bits of information with each bit doing its own thing. Combine them for one heck of a lot of possible effects.
Something like that anyway.
I don't get the impression that Griz was being specific about DNA commands though. I felt it was more general than that.
-
a question, if we make a simple program, that can use the all the things on a keyboard and is ordered to write those in random sequens (we use radioactive decay now, so its real random) and then tell the program ti try the program when it have used up all space on the computer. and if it worx it change things in it, else it delete it and begin from scratch, with worx I mean no errors come up, it can just come with a box that tells "hi" and work, wouldnt a million of them in time be able to evolve something very complex? of course a computer cant do that if nothing tells it to randomize
-
But all you are doing is making a long and pretty useless word with a bunch of characters in it.
It can be as complex as you like but it won't have any behaviour
It will just sit there.
Without rules of interaction, it cannot interact with another such complex character string.
-
I would just like to know how exactly we can have complex behaviour from simple rules. Give me an example.
I could well be missing the point entirely here, but emergent behaviour seems to fit the bill. As I find it so interesting I have been reading a bit about it, and it seems to fit exactly what you said [PY] about complexity emerging from a simple set of rules.
Of course, it's "easily" expressed for organisms where interactions are limited. If you think of physics as "emergent physics" where some abstract simple rules built all of the complex rules around us, that's slightly harder to simulate on a computer.
Not really sure if any of this is making sense... :blink:
If I understand [Griz] right he wants to have some set simple rules from which emerge environmental interactions and functions. Instead of making a bot accumulate waste and dying as a result of not expelling it, impose a general rule governing how substances build up, and another to govern how organisms react to an excess of waste material.
Quite possibly I'm missing the issue, or have just spouted a load of random rubbish. It makes sense in my head anyway. :pengysmiley:
-
What you are saying makes sense Ulc. No problems there.
The unfortunate fact is that within a computer simulation, you simply can't just have stuff start to happen. You have to program the ability for it to happen.
In the real world we have a limited number of possible base pairs that can be joined together in almost any order.
That's great for the real world but a SIM isn't the real world is it
I would love to see emergent behaviour but how is a blob of memory cells in my PC going to learn to move across the screen unless I have already hardwired the physics that allow it to interact with the rest of the computer?
How is it going to learn to metabolize type C food unless Type C food chemistry is well defined and a whole slew of chemical and physical laws are programmed into the software?
The DBs NEED a universe in which to live and laws with which to do so. After that we leave them alone and see what they get up to.
The DNA code of real creatures may well be made up of very simple building blocks but the program (natural laws of the universe) which allow them to interact are more complex than anything we could ever hope to duplicate in DarwinBots.
-
I totally agree. I was just interpreting what Griz though (or what I think he thought :huh: )
Noone expects rules to emerge from complete nothingness (generally) as you need some basic rules for more complex ones to grow from. I think I agree slightly that the rules imposed in the darwinbots universe are too artificial and not general enough.
-
Complex systems have a single rule that is universal to all of them.
They are non-linear. That is, the change in one element has a disproportionate effect in another.
Anyway, that's my aside
For the metabolism, here's what I'm thinking right this moment:
We descend into the madness of metabolic pathways gradualyl, in baby stpes.
Setp 1: Seperate Body into muscle (that makes shots stronger, bots able to move with less effort, etc.), fat/sugar (nrg storage), and maybe cellulose, maybe not, I'm not 100% sure yet.
Step 2: Implement Mitochondria/Chloroplasts. Eukaryotic cells actually handle very little of their own metabolism. Most of the grunt work is handed off to the mitochondria and chloroplasts.
So in DB, chloroplasts would convert light energy and surface area into nrg.
Mitochondria would convert basic substances to/from each other. The details of how the mitochondria do what they do are entirely hidden from the bots.
This isn't all that incredibly different from the current system. Our bots strbody, fdbody, mkpoison, etc. Mitochondria would work in much the same way (I'm expanding the concept of all organelles that construct/destruct materials into the term "mitochondria", even though that's not actually 100% accurate. But I think doesn't lose any generality in persuing this path.)
Step 3: Instead of having mitochondria magically turn nrg into muslce, or whatever, we assign enzymes and such that handle all this, and allow these enzymes to mutate and hopefully evolve.
Note that step 3 is entirely hidden from the view of the bot, since the metabolism is all encapsulated (a programming term) in the mitochondria.
I'm open to criticism, of course, this is hardly set in stone. The idea is that at each step we can try it out and see what happens. Baby steps.
-
Yeah a few are a little on the artificial side. Can't deny that
Poison, Venom, Shell, Slime, Ties, Shots (come to that) are all kind of artificial.
Poison and venom are I think eventually destined to be scrapped in favor of a more complex and flavorfull bunch of chemical interactions. Possibly all shots can be replaced with a kind of fired enzyme from within the loosely planned enzyme metabolism system.
Ties? Donno about them. We have to alow some form of MB interaction so perhaps this is just one of the physical laws of DarwinBot world.
It's very tricky trying to get the balance right without artificially changing behaviours. That is the one thing we need to avoid at all costs, direct behavioural modification from the program. Selection has to be down to survival.
I still think the main problem with the whole of DB is that the entire DB universe is a barren desert, completely devoid of niches or any reason to specialize. Wherever they go, they are always in the same environment.
-
Ties I'm thinking are a special hollow tube mesh constructed from nrg arranged in a crystaline matrix.
This mesh can be stretchy (like a spring), sturdy (like a pice of metal), stretchy to a point (like two bots connected by a peice of string), etc.
This mesh, however, can only be bent in one direction (the axis of the vector between the two bots).
That is:
if ____________ is a tie:
____ is valid
__
\___ is not
However, we just have to say that bots can build this magic meshy substance. Trying to build a ruleset that allows such a mesh to form naturally is beyond the scope of Darwinbots.
There are physical limitations to what can be modelled. At some level, you have to create abstractions.
-
At some level, you have to create abstractions.
For sure. But the more general you go the better, yes?
-
Absolutely and therin lies the problem.
In the eyes of the critic, If you allow one abstraction then why not another, then another. More and more until we are over-run with the bloody things.
The kind of sim in which there are no abstractions and everything operates by a simple set of rules is just not feasible if you want any kind of realism.
You can't hope to simulate nature in all its complexity so what choice do we have other than to simplify branches of it like the ties and present them as a done deal. The sim doesn't need to know the physics. They just work. (the physics we do have in them is quite complex enough thanks)
-
(the physics we do have in them is quite complex enough thanks)
I'll second that.
The amount of stuff that I have learned working on the physics is sickening. Just sickening!
:puke:
-
:puke: :puke: :puke: :puke: :puke: :puke: :puke: :puke: :puke: :puke:
Hehe, physics is fu-- :puke: can't even get that to come out right.
-
I seriously have no idea what you are driving at.
I am fully aware of that ... believe me!
I would just like to know how exactly we can have complex behaviour from simple rules. Give me an example.
well ... there it is ... right there in that very statement ...
you 'need to know' exactly.
that is an approach ... a way of seeing/interacting with the world.
and you carry it over into your work and programming.
so does Nums. and that's fine ... even essential for programming.
but it can also be limiting if not balanced with a willingness to not
always having to be certain about everything.
I'm no differenct. I recognize it.
I program all of the time doing the raytracing thing ...
so I understand the need for precision and logic and linear thinking ...
for the need to know and control ... etc.
but I also find that the greatest discoveries I make ...
are found 'on my way' to something else ...
that while persuing an idea, I make a mistake in code ...
and end up with something that I would never have thought of doing ...
some idea that never would have entered my mind ...
that would never have occured to me.
and if I am too locked into what I am 'trying' to get to ...
I am then not open to, and likely to miss what is now right in front of me.
I also completely understand what you said about 'fun' at programming ...
that it's not much fun to debug. I hear ya.
and that is part of that discovery thing I am speaking of ...
it's easy to get sidetracked by the 'next' great idea! ;)
I know, I know ... I rarely finish a program ...
as I am constantly discovering some new twist to explore.
I see Num doing that for sure ... so I can relate. ;)
but then there is always the dishes that need to be washed, you know?
so it seems to me that programming is a bit of a balancing act ...
that there are times to be tightly/highly focused on the job at hand ...
and other times when we must be willing to pull back and widen that focus ...
to take in a larger picture, to widen our perspective ...
and to take a look at where we are heading ...
see if we're still on course.
anyway ...
here we are ...
discussing all of this ... bringing it to the forefront of our thoughts ...
to the top of the stack, if you will ;) ...
and now we have yourself and hopefully some other folks willing
to pitch in and lend a hand at debugging and getting a stable version ...
while also moving on with the 2.4x stuff.
so ...
we, along with DB ...
continue to evolve.
as it should be.
-
yes shvarz ... you've understand my point and articulate it well.
shvarz:
Griz, I am all for evolution and I absolutely want to see complex things evolving from simple elements. In that sense I absolutely agree with you and I've been always opposed to introduction of arbitrary features for bots.
[...]
... just an arbitrary feature that was introduced to model something that people wanted bots to do.
yes. well said. the extreme case would be ... people want the bots to look and act like us. ;)
... This is what Griz means by "controlling" bots behaviour. His (and my) approach would be to create "substances" or "metabolism" with a bunch of molecules and rules for these molecules and their interaction with bots DNA and stack. Then some of these molecules might turn out to be what we consider "poisonous" - they will mess up bot's behaviour. Then some bots may figure out how to deal with these "poisonous" substances and how to deliver them to other bots, creating what we consider to be "venom".
that's it ... to not introduce 'artificial' behaviors in an attempt to get bots to act how we think
they should act ... but to provide them with the 'material' and allow them to evolve however they do ...
to develope their own stratigies/tactics/defenses.
I also question mutating the current generation .... but do not yet know enough of how you have
it set up to see how it is actually being implimented. the behavior of an individual should not be
altered in any way once that individual is born ... but only the genes once they have been passed
on to the next generation. but perhaps that IS how it works ... I don't know yet.
I'm still trying to get a version to actually work long enough to get some results to look at!. ;)
But I've known PY and Nums for a while now and I have to tell you that you are not correct - they do understand how evolution works and they put in a lot of effort into making DB evo-friendly.
well ... we might quibble on that. again ... until I understand the code and just what is being mutated
and how/when ... I can't say. ;)
The reason they don't understand you is because they are programmers who want to know what feature exactly is wrong and how exactly you propose to fix it. I did not see in your posts these things either, so even I don't understand what exactly pisses you off so much.
I'm not pissed off ... just very disappointed ... esp in the priorities.
Yes, there are tons of things that can be added, but we only have 1.5 programmers working on this very complex project now - give these 1.5 guys a break
understood. I've had my say ... and whether or not they understand what I am saying ...
it seems to me that at least something is now being done to address the concerns of a great many
of us ... so I see that as progress. you know ... if I have to be devil's advocate to bring something to
the attention of others ... I have no problem doing so.
so ... I do tend to stir up the shit now and then ... always have.
but please know my intentions are good ... and I do indeed want to see people succeed ..,
and DarwinBots succeed as well.
so ...
I'm done sniveling and whining. for now.
here's to Num and PY and all who are part of this ...
it's still the coolest thing I've seen ...
and think of how great it will be when it actually works. ;) lol
cheers to you all.
onward!
-
The sim doesn't need to know the physics. They just work. (the physics we do have in them is quite complex enough thanks)
thought I'd go ahead and heartily agree with you on something PY :D
this is a big part of what grates on me ...
we don't need to construct structures that 'look like' the physical world.
nor do the bots need to know physics ...
that is taken care of by the environment we provide ... those laws we impose.
we can control the environment ... and I also agree we need a way to have
some specialization in it ... a diversity of specialization, if that makes any sense. ;) ...
but to let the bots then develope the behaviors that allow them to function ...
or not ... ie ... survive ... 'within' the rules of the 'test tube' we place them in.
so I am not advocating anything goes and not having rules ... not at all ...
only that too many rules actually results in the same problem ...
too many choices. it is about achieving the right balance.
and it seems to me ... that if we start simple enough ...
the program itself will show us what is required in the way of balance.
iow ... the sims/environments that work ... we keep ... and take a look at
why they did. same with a sim/environment that doesn't support or reach
some sort of equilibrium in population.
again ... I think there is more than enough complexity in DB already ...
if not too much ... at least until we ensure the basic workings are in place.
THEN ... we can go more complex.
but perhaps I am repeating myself. ;)
ok.
'nuff.
-
Ties I'm thinking are a special hollow tube mesh constructed from nrg arranged in a crystaline matrix.
I suppose all of the tie physics etc could have been avoided by saying that ties were in fact EM forces holding two bots together. It would also fit with what you were saying about the way ties should be able to deform, [Num].
Although... this would introduce a whole new nightmare of artificial-ness and ambiguity.
-
I suppose all of the tie physics etc could have been avoided by saying that ties were in fact EM forces holding two bots together. It would also fit with what you were saying about the way ties should be able to deform, [Num].
Trouble is, that is exactly how they work.
The tie that we actually see is just drawn on after. It has no relationship to anything and no solidity in the program.
Ties are defined precisely as an interaction between two specified bots, their positions, angles etc. It's actually a really cool idea once you figure it out.
-
we don't need to construct structures that 'look like' the physical world.
nor do the bots need to know physics ...
that is taken care of by the environment we provide ... those laws we impose.
The only thing is that everyone who ever runs the sim does so expecting familiar behaviors. Wether we think so or not alot of how we interpret the simulation is based on what we think is "realistic".
The new physics engine, (which is what I think you're alluding to) is imperitive precicesly because the old one was woefully inadequate. Specifically in the area of ties. Run some bots that tie to each other and drag them around in pre 2.4, then do the same with the newer version.
Night and day difference in how "realistic" it feels. The bots don't care much one way or another, since they do not directly get to see how or what the physics engine is doing. But the people watchinig (the ones that can pull the plug and find somethign else to do) are most particular about things they view as "stupid" or "unrealistic".
Now if bots are doing stuid things on purpose, that's called experimentation.
If the sim is doing stupid things, it's called "lazy programmer" :lol:
we can control the environment ... and I also agree we need a way to have
some specialization in it ... a diversity of specialization, if that makes any sense. ;) ...
but to let the bots then develope the behaviors that allow them to function ...
or not ... ie ... survive ... 'within' the rules of the 'test tube' we place them in.
That is precisely what I feel I've done, and what other programmers before me have done. More or less anyway, there are some abstractions used for the benefit of the coders ;)
But we don't tell bots how or what to do with the abstractions.
again ... I think there is more than enough complexity in DB already ...
if not too much ... at least until we ensure the basic workings are in place.
THEN ... we can go more complex.
You may be a little soured by bugs ;) I most certainly disagree that DB is complex enough already. I can't even imagine a complex system with "too many" choices. Each voice just adds to the harmony if the conductor is any good at all.