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 ... 9
Darwinbots Program Source Code / Help!
« on: June 29, 2005, 06:44:17 PM »
Public genome() As gene

Here's the problem, I guess. You have declared the data type for genome, but you haven't instantiated it yet. This means, that genome is a pointer to a gene object, but you haven't created the object.

Try instead

Public genome() As new gene

Evolution and Internet Sharing Sims / Shvartz, can you help me out?
« on: June 26, 2005, 03:46:26 AM »
Why don't you just add to the console execution mode also the listing of all memory locations accessed (read and write) by a bot in a certain cycle? It's a 20 minutes work.

You have to understand what it is you're testing.  It's been a while, but I think you're testing if two supposedly events are NOT related.  When you conclude that they are not NOT related, you can't conclude that they ARE related.  Or something like that.

There are some subtle things you cannot conclude, but it's been too long and I just don't remember it all exactly.  I think this is a case of that.  I think sometimes F1 test give a false positive, but they won't give a false negative, or something like that.
A bit of confusion here, it seems.
We're trying to know the probabilities of two _completely related_ events: that is, A wins or B wins. The events are completely related because if A wins, B loses, and vice versa. Ok? We're just tossing a coin, and counting the times we have head, and the times we have cross.

But the sequence of results (A wins, B wins, B wins, A wins, B wins, etc..) is completely unrelated, since there's no information passing from one simulation to the other, so they cannot be related.

Hence, we can apply the same methods we use to calculate whether a coin is even or uneven (fair or unfair, don't know how you say). We toss it a zillion times, and calculate the ratio of head and cross, then we calculate the probabilities, and the error range inside a probability of, say, 90% (this means: that you have 90% chances that the real ratio is inside the error delta).

Darwinbots Program Source Code / Eyes in DB!?
« on: June 22, 2005, 08:15:07 AM »
It works like that: the dna isn't explored at all; instead, each bot has a flag which is called eyeused (or something like that), which is false at birth. When a value is read from any one of the eye locations, that flag is set to true. When the flag is true, the sight routines are calculated. So, each robot sees only from the second time it tries to see in its life; on the other hand, the procedure will still work with viruses or everything else. There's no point in calculating only single eyes, since all eyes are calculated together with a single search on near robots.

Yes, but it's not because it was "better".  It's just that you expect any statistical test between identical copies to produce 50/50 results.  And the way F1 settings works, as the number of trials aproaches infinity, the number of wins you need decreases to about 50%.

So eventually random perturbations will produce a "winner".
I don't see the problem. You can always calculate the significance of the final result. For example, you can calculate that, after 100 rounds, you have 99% probability of getting a ratio of wins of 1/2 +- delta when running two identical copies. I don't actually know how to make the calculation (you're the matematician), anyway it's trivial.

Why instead, as I suggested, don't you try to run a looong simulation with mutrate of mutrates at 1 or so, so to evolve the best mutation rates?

This is an interesting experiment, but I have no idea what it is going to do.  My head hirts when I try to think about all the stuff that is going to be involved in that.  Thing with mutrate of mutrates is that mutrate has no advantage for current generation - it only affects the next generation and even then not directly.  In general, organisms don't want to mutate - chances of getting better after mutations are minute.  So the selection should drive to eliminate mutation rates completely.   I guess..   I may be wrong...
Well, basically the mutation rates determine the probability of having an offspring more or less mutated. This simply means that they affect the probabilty of the offrspring being more or less successful. For each set of mutation rates, say that you have these three values:

a- probability for the offspring to be identical to the parent
b- probability for the offspring to be worse
c- probability to be better

Say that a realistic mutation rates set may have a=90%, b=9.98%, c=0.02%. The interest of the robot is to have a successful offrspring, so it has to maximize c while keeping a good ratio between a and b, which can be done by regulating the mutation rates set. So you can treat it like a mutation as every other: evolution will try to optimize mutation rates to give the better a, b, c ratios.

About the idea that evolution tries to eliminate mutation: it's wrong! As long as an organism has the ability to mutate, it can find some good mutation to be better than its competitors. Let's reason in terms of lions and gazelles. If evolutions succeeds in eliminating mutation in lions, gazelles, which still mutate, can always develop the ability to run faster. No lion will ever catch them again, since lions lost the ability to mutate. A gene which gives gazelles the ability to mutate is successful, because allowing the mutation of the genes for speed in the gazelle gene pool, has more probability to be passed to the faster gazelles, which survive better.
You can do this little experiment, anyway (I tried, and seemd to work - now that there are tools for leagues, should be even easier): just put in the same environment two copies of the same species, identical except for the fact that one has reasonable mutation rates, while the other one has mutations disabled. When I tried it, the species unable to mutate was usually (on average) wiped out by the other one in more or less time.
But would be really great to make the experiment seriously: that is, with tens or hundreds of tries to have precise numbers (and maybe with a good esteem of the average time for a species to take over the other one, and how this time is affected by mutation rates... ). Something may be done automatically with the tools for leagues. And maybe Shvarz knows wheter somebody would be interested in a paper on the subject  :boing:

2.  Comparing two species in a F1 battle to the death doesn't give you any clues as to how well each species adapted to its environment (that is, how strong the Darwinian evolution was).

I understand you point, but that's not completely true. Bots adapt to the environment, which is made of, say, the physics settings AND the other bots; however, you can suppose that, except from particular cases, most of the adaptation is towards the physical environment. Otherwise, you'd not understand why the evolved robot "does better" against the unevolved version and not vice-versa: both are unadapted to the other, since the evolved should be adapted, as you noted, only to two-three generations before.

Imagine if aliens came today, picked the most successful human, and made him (or her) battle to the death with father Adam in the Garden of Eden.  I think you see my point.

No, that's wrong. Humans have a great variability, so you can take very successful humans and suppose that they have something tha makes them so successful. But robots are much simpler, their behaviour is totally determined by the dna (and they have no sexual reproduction, so no dna remixing) so thata  successful robot is successful either by pure chance or because it is, alone, a new species, in the sense that it has some important mutation.

5.  Since you're testing the mutation rates, be sure to set the rate of change of mutation rates to 0.

Why instead, as I suggested, don't you try to run a looong simulation with mutrate of mutrates at 1 or so, so to evolve the best mutation rates?

Suggestions / Eventual improvements to DNA language
« on: June 15, 2005, 03:40:25 AM »
I just voted for eliminating the stop at the end of the gene. It is useless.  Ah, please, Nums, just eliminate the other little stupid thing of the language, that is, the "end" at the end of the dna.

Suggestions / Recombination mechanism
« on: June 10, 2005, 04:16:53 PM »
Nums, I also have to ask you if you can explain again for me the whole _chromosomes_ thing, or post a link. I can't find your original idea about chromosomes, and I'm not sure about how they should work.

Suggestions / Recombination mechanism
« on: June 10, 2005, 03:20:27 PM »
Sometimes you don't want it to be just a label.  Say you want to compare fitness of two closely related organisms that reproduce sexually - then you don't want them to inter-breed.
Yes, this is true. But there should be a standard way to do that, instead of just making things work the wrong way because sometimes it is useful. Another way would be to simply program your creatures to ingoe each other as partners (risky) or mess up their dna - if they have ND execution, for example, you can completely invert the order of their genes without changing their functionality: and they will never be able to interbreed.

They are using the best software available and thier alignments usually take overnight and sometimes go for several days.  Which makes me think that any program that does this in a fraction of a second is a sham.
It may be so. Or it may be that your colleagues work on much bigger data collections that we need to do. I don't think that aligning similar parts should be (nor that it can be) an error free procedure. It should only make things work better than they do now.

Basically, if you can do it - great!  I won't complain.  But I don't see why UID system can't be implemented - it is very powerful and yet it is very easy to add...
I prefer my system, which is not very different from yours except for the fact that
1) it doesn't need explicit and arbitrary marking of the code
2) it works _preferably_ (but not necessarily) on entire genes.
3) it's straightforward to implement

Suggestions / Recombination mechanism
« on: June 10, 2005, 11:58:42 AM »
By the way, this is an example of a phylogenetic tree generated with the data from an internet shared simulation (about one year and a half ago, maybe). Each leaf of the tree is a robot (all of the same species), the numbers stand for generation and mutations number. The tree is unrooted (every leaf can be taken as root). The starting data were the pure and simple dnas of the robots.
Code: [Select]
                           +------------8                     +1c-145-95
                           !            !  
                           !            +---------------------1c-119-77
                 !         !                     +-----------1c-154-102
                 !         !   +-----------------4  
                 !         !   !                 +-----------1c-156-103
                 !         +--13  
      +---------20             !             +----------------1c-164-107
      !          !             +-------------7  
      !          !                           +----------------1c-168-120
      !          !  
      !          !               +---------------------------1c-189-118
      !          +--------------11  
      !                          +---------------------------1c-198-139
  !   !                                               +---------1c-225-155
  !   !                +------------------------------2  
  !   !          +----19                              +---------1c-229-156
  !   !          !     !  
  !   !  +------21     +---------------------------------------1c-233-162
  !   !  !       !  
  !   !  !       !                                   +---------1c-235-150
  !   +-23       +-----------------------------------3  
  !      !                                           +---------1c-235-156
  !      !  
  !      !                 +-----------------------------------1c-236-156
  !      +----------------16  
  !                        +-----------------------------------1c-238-165
  !                             +-----------------------------1c-201-138
  !                   +--------12  
  !                   !         +-----------------------------1c-218-154
  !         +--------18  
  !         !         !                          +------------1c-211-142
  !         !         +--------------------------5  
  !         !                                    +------------1c-212-148
  !   +----22  
  !   !     !                 +------------------------------1c-242-172
  !   !     !           +----14  
  !   !     !           !     !                +-------------1c-245-176
  !   !     !           !     +----------------6  
  !   !     +----------17                      +-------------1c-254-185
  +--25                 !  
      !                 !         +--------------------------1c-257-178
      !                 +--------10  
      !                           +--------------------------1c-265-189
      !                            +--------------------------1c-265-192

Suggestions / Recombination mechanism
« on: June 10, 2005, 11:47:16 AM »
Does not look like Nums is too excited about doing double-work, though dry.gif It is a valid substitute for now and it will fix sexrepro to some degree.
I can assure you is a rapid work. By contrast, all other proposals seems much more difficult to realize, still are rather undefined, and involve much rework of the code in the rest of the program.

As Nums pointed out, it has its weaknesses too - it is still gene oriented.
You can even split the coupled genes inside them, if you want, instead of chosing one or  another.

Also, it is not fool-proof for genomes that got significantly diverged during parallel evolution.
This is correct, because individuals which have diverged too much should not interbreed. That's speciation.

On the other hand, your system
5. It automatically prevents cross-breeding between different species (even if they have exactly the same DNA). Yet it still allows occasional breeding between organisms that evolved from common ancestor.
Which is a blatant violation of one of the principles of DB, that is, that species name is just a comfortable label and has no meaning inside the simulation.

As for the pluses of your system, probably there is something that you should know: that is, that there are standard and well known routines to calculate the common parts and similarities between to texts. And they are relatively fast. So, UID in principle is useless. Programmers commonly use text editors which are able to highlight the differences between two source codes. There are many bioinformatic tools that calculate the differences between two or many textfiles or genefiles.

For example:
gendistance: this is free:
calculates the distance matrices between a number of textfiles. Then you can build a phylogenetic tree. I used it once for DarwinBots (in conjunction with phylip I think). (oops.. now that I remember... I even made a tool to automatically build archives to pass to gendistance... )
And here you can find a wide list of free tools for comparing text files:

Suggestions / Recombination mechanism
« on: June 10, 2005, 11:13:28 AM »
We should build up from A to B. The code is already fairly strung out and inconsistant. Coding something that just needs to be coded over later is wasteful.
First, it's not said that we're really going to change the dna language. I don't really see any need for that, except maybe going in the direction of less programmability and understandability of the language itself.

And remember what's wrong with the current sexual reproduction system: It's gene centric. If all you're after is mixing up the genes between bots, it does just fine.
It seems to me that nobody said that. Shvarz's point, that is correct, is that the mixing of genes how it is made now don't work when genes are duplicated (because sometimes  the zig-zag procedure cuts off a valid gene). But this method solves the problem perfectly, and it's also biologically sound.

Suggestions / Recombination mechanism
« on: June 10, 2005, 10:50:10 AM »
I'd prefer to leave apart the discussion about possible new structures for the dna language, and implement rapidly this kind of sexual reproduction. If we (you) are ever going to change the dna structure, you'll change also this, among many other things. But let's have immediately what we can have now.

Suggestions / Recombination mechanism
« on: June 10, 2005, 09:38:04 AM »
Shvarz, your UID system gave me an idea. I think UID would be a good thing, being basically a shortcut to actually comparing dna portions to look for similar parts. On the other hand, it would require changes in the way dnas are stored. What do you think of this: without the need to modify anything anywhere else, we just change the sexual reproduction routines. We insert a new routine which calculates a number (let's call it idcode) from each gene (say, just by calculating the sum of the type-value sequence in the gene, or something like that). Then, we take each gene from one of the parents, and we couple it with the gene with the closest idcode number. When genes have been coupled, we take one of them from each parent and build a new dna. We should decide what to do with genes that remain uncoupled.

Now, to be clear, an example. Say we have a gene

  *.eye5 0 >
  10 .up store

If we assign a value to each instruction, variable and number, we can easily make a sum of these values and obtain a code which is not unique for that gene, but has very good chances to be unique in that dna. An important feature of this code is that, unlike a hash code, it is only slightly changed by little variations.
Now, say that the calculated idcode for this gene is 100.

A mutated copy of this gene, say

  *.eye7 0 >
  10 .up store

may have idcode=102

Now, if we have two dnas, with genes: (where 1, 2, ... are different genes, 1a, 1b,.. are slightly mutated copies of the gene 1, and there's an idcode associated to each gene)


You understand that it is relatively simple to mix these two dnas. You should couple each gene of dna1 with one of those with more similar idcode on dna2. You may decide randomly which gene to couple if there are two or more with similar idcode. For example, you may decide to couple either gene2 or gene2a from dna1 to gene2 in dna2.

If you wish to have a more fine crossing, you may even decide to go further and split the coupled genes somewhere inside them and mix the two ends.

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