Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Carlo

Pages: 1 2 3 [4] 5 6 ... 9
46
Suggestions / Subfunctions
« on: June 09, 2005, 07:45:15 PM »
Quote
So first you evaluate all the gene's conditions.  Then you pick 1 gene from among all of them that evaulated to true to execute.

That is, there's no use trying to execute a gene that evaluates to false anyway.  In that case you've lost a cycle for nothing.  I wouldn't suggest this except I think it better follows the ND paradigm you're going with.

I asked you because I ALWAYS proposed this model:

Quote
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.

 Probably my english is so bad that... anyway, the important thing is that we understood each other.

47
Suggestions / Subfunctions
« on: June 09, 2005, 07:22:35 PM »
Quote
BTW, did you give any thought to my suggestion of selecting which gene to execute from among the ones that would this cycle?

What do you mean exactly?

48
Suggestions / Subfunctions
« on: June 09, 2005, 01:11:15 PM »
Quote
An external compiler would work just fine, and indeed is an option for non-looping subroutines (just simple macros) and other things we want to add to the language.  But I hate the idea of having access to something the bots don't.
Well, you can always create an interface on the compiler so that the bots can swim in it and play with its commands.   :lol:
Anyway, the bots don't need to play with the compiler because there's nothing the compiler can do that they can't. The compiler is just an useful instrument for you to _see_ dnas in a more comfortable way. But evolution don't need to see anything.

Quote
Why I want junk DNA is the simple fact that real eukaryotic organisms have it.  It may offer increases in fitness, it may not.  No one has really devised a long term experiment to find out, so no one can say one way or another.
These days seems more and more probable that junk dna has some important regulatory functions inside the genome. Someone has even calculated that the apparent complexity of living organisms is more related to the amount of junk dna in their dna than to the quantity of actual genes.
But this is probably because real junk dna is not so junky, and has some active role in the chemical processes that make the cells work. This means that it does something, while junk dna in DB doesn't do anything. You can add as much junk dna as you please in DB, it won't do anything because it is not even interpreted. There isn't as far as I know any hidden function inside DB that will magically use junk dna to boost evolution.

Quote
I'm trying as hard as I can to make diploid multibots that sexually reproduce and swim around supported by the system.
I think that the main problem of sexual reproduction in darwinbots isn't the diploidy (yes, that's one problem, and I clarly feel that's something wrong in the actual sexrepro function; but on the other hand I'd like to know _exactly_ what's wrong with it. Remember that diploidy requires crossing over anyway, this means you have to split the two chromosomes and mix them). Anyway, the main problem of sexual reproduction in DB is the fact that sexual reproduction is a complex thing. Requires a good communication, a good synchronization, time... yes, a comfortable place... How can you find a partner, decide to mate, mate, wait for sons, in an environment in which 10 cycles are an eternity, and you can be hit by anybody and pushed far away? There's something wrong with time in DB. Physics is too fast with respect to internal dna timing.

By the way, this reminds me of the ND debate. You said you were going to add ND routines and a checkbox control to select for ND execution.Can I send you those routines to integrate in the next version?

49
Suggestions / Subfunctions
« on: June 09, 2005, 10:21:56 AM »
I agree with Shvarz. There's no need to add to the language things which you can already obtain with the actual language. A few points to remember you WHY the actual language works the way it works:

1) the activation condition/ body model resembles vaguely that of dna. It is believed that the genome works as a giant network of reciprocally influencing genes; many alife simulations use neural or similar networks as a dna; the DB language is not much different, in that it allows you to design networks of genes activations. The advantage of the DB language over networks is that you can directly program a DNA, and that you can understand (with some effort) how a mutated DNA works.

2) the dna language has been designed to have a syntax reduced to the bone. This is because dnas are going to be randomly mutated, and a random mutation which breaks the code's syntax is just a waste of time. So, the syntax is very very simple, the only requirement is to preserve the cond start stop structure and to put comparison operators and commands in their respective place (that is, in the cond part and in the body part, respectively). There are no other rules.

3) the dna language has been designed to ensure a fair distribution of computational time between robots. The alife simulators allowing a traditional language, Tierra and Avida (I.e., they allow loops and subroutines) solve the problem of the distribution of cpu resources allowing each organism to execute only a precise number of _single instructions_ per cycle. The DB language allows the execution of the entire dna. You can have loops, but you have to split them in different cycles.

4) the resulting language is Turing-complete, in the sense that you can express with it whatever you can express with every other, more complex, language.


So, I perfectly agree with Shvarz. You can already do everything in the current language and whatever you may add to it will make it more difficult to mutate and decrease its evolvability. As for the subroutines (without cycles of any kind): they may be comfortable, but there's nothing you can't do with the actual system. Subroutines would create new problems, because they would break the linearity of the dna execution. They would be substantially macros, separated from the rest of the dna. Why don't you write an external compiler instead? Write a standalone program which receives as input a program in a more "comfortable" version of the DB language and produces a dna as an output. Could be very interesting from the point of view of programming combat bots.

Some other considerations:

I'd agree on making the syntax even looser by allowing to mix cond, start and stop everywhere in the code, as well as allowing the use of comparison operators and instructions everywhere. But this would be, after all, a minor change (and it would make the code much much more difficult to read).

I don't understand why you want so much to have junk dna. JUnk dna is dna which is not used and has no use. Being not used, it will become a total junk and will never by usable again thanks to a mutation. So its size will always increase, never decrease, and will never be useful to evolution. So tell me why you want junk dna so much (leaving apart the fact that there's already junk dna).

50
Evolution and Internet Sharing Sims / Project: New Ancestor
« on: June 07, 2005, 03:49:06 PM »
Quote
So if you have 10 genes making up 100 variables both with 1 in 10,000 chance of mutating, you get a 1 in 1,000 for whole gene alterations and 1 in 100 for variable changes?

Yes, it's like that. So, to have an appropriate number of gene duplications/ deletions, you have to set an appropriate value for gene mutations, that is, a value that takes in account the fact that genes are much less then variables.

Quote
Might be fun to try and get it up to date purely through mutations. Are you interested in joining in Carlo, the more the merrier :)

Oh, thank you. But, you know, I run only ND simulations.  :lol:
Obviously, I'm joking. Tell me which version of DB to use and server name.

51
Evolution and Internet Sharing Sims / Project: New Ancestor
« on: June 07, 2005, 01:54:15 PM »
Quote
Also the mutation rates as slow as you can stand, the higher numbers the better chance of bad mutations being killed off leaving decent ones, I use around 25,000 to 50,000.

Just an idea for mutations. I'd suggest to put much lower values for things such as gene duplication and gene deletion, etc. This because there are much more variables in a dna than genes, so gene mutations should be more frequent. If you have on average a gene every 10 variables, you should give 10 times more chances to gene mutation to happen, so you should put a mutation number ten times smaller.

Another idea, is to set the mutation rate of mutation rates to some very little value, say less than 10 (or even 1). A mutation of the mutation rates won't change the functionality of the dna (and, if I'm not wrong, won't be counted as a mutation). It will just mutate (sligthly) one of the mutation rates. This should eventually automatically balance the various mutation rates (and the mutrate of mutrates itself) to an optimal value for survival. This is because robots DO have interest in mutating: if they don't, other mutated robots will eventually become stronger and kill them or their progeny. So the point is to find the correct mutation rates, and this can be made through random mutations.

52
Suggestions / Eventual improvements to DNA language
« on: June 06, 2005, 01:44:05 PM »
Quote
I'd love to get Carlo's take on this. Although I'm afraid I have a feeling what his feelings might be

I'd just like to know what is the rational for all this proposals. You say:

Quote
This is the idea I have for expanding the language to make it easier for complex behaviors to be developed and hopefully evolved.

and

Quote
These changes hopefully will encourage more complex DNA to develop from both writers and mutations. Most bots today are still very, very simple.

That's ok. But you should be more specific about which things exactly would be better, and why. For example: how each of these changes would positively affect mutations? And how programming? What would be possible that isn't possible now, from one point of view or the other? How should mutations handle these new flow control instructions? Etc.

53
Suggestions / Non-Determinstic Bot DNA flow
« on: June 06, 2005, 06:24:17 AM »
Quote
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...

Quote
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.

Quote
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.

Quote
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).

54
Suggestions / Renaming sexrepro?
« on: June 06, 2005, 05:52:55 AM »
Quote
On another note can you all stop err...debating so much? It seems kind of silly for relative strangers to be argueing about the direction a peice of freeware should take. Just stick ND as an option so DB doesn't split too much and let everyone decide on their own. Or option B, just make another Alife program. Lord knows there aren't enough good or even really decent ones around. I personally would like the competition, as a species we do well with it, especially when accomplishing the goal would represent a sucess to everyone.

I like especially your option B. I don't think a good combat bots program can also be a good alife simulator, nor that you can keep adding options to make everybody happy. Forking development would then be a good idea. Unfortunately, seems that I would be alone on my side of the fork: which is not bad in itself, but becomes bad when you have no time do dedicate to programming. So, until I find the time to put up my own "concept version" of DB, I'm afraid I'll keep getting on your nerves, here and there  :lol:

55
Suggestions / Non-Determinstic Bot DNA flow
« on: June 05, 2005, 01:19:59 PM »
Quote
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?

Quote
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.

Quote
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.

Quote
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.

Quote
Yes, this is my goal.  Complexity.  I've said it before and I'll say it again.  When I'm done, it'll be impossible for any one person to understand everything in DB!  Why?  What possible masochistic reason would I have for such a thing?

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.

Quote
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.

Quote
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.

Quote
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.

56
Suggestions / Non-Determinstic Bot DNA flow
« on: June 05, 2005, 05:39:38 AM »
Quote
I would definately like to explore an ND DNA execution model, just not for the main course of the program.  It's main interest is in evolution sims.

But evolution sims ARE the main interest of the program. Any other use is secondary.

Quote
A simple slider between the two can allow us to tweak and decide which is best.

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".

57
Suggestions / Non-Determinstic Bot DNA flow
« on: June 05, 2005, 04:20:46 AM »
Quote
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.

Quote
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...

58
Suggestions / Non-Determinstic Bot DNA flow
« on: June 04, 2005, 06:21:06 PM »
Quote
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.

Quote
2.  You've created race conditions

Can you be more specific about this point?

Quote
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.

Quote
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.

Quote
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.

Quote
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.

Quote
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.

Quote
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.

Quote
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.

Quote
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.

Quote
For instance, your two gene example would work just as well with a sleep command (which I proposed in another thread).

Horrible. :lol:

Quote
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?

59
Suggestions / Non-Determinstic Bot DNA flow
« on: June 04, 2005, 10:55:43 AM »
Quote
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


Quote
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:

Code: [Select]
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.


Quote
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.

60
Suggestions / Non-Determinstic Bot DNA flow
« on: June 03, 2005, 10:12:02 AM »
Quote
Well, since The One is a single gene and does just fine, no, I can't.

Perfect.

Quote
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.

Quote
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.

Pages: 1 2 3 [4] 5 6 ... 9