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 ... 9
Suggestions / Sexual Reproduction Focus Group
« on: August 10, 2006, 09:27:50 AM »
By the way, could anybody tell me what's so wrong with .sexrepro?

Suggestions / Sexual Reproduction Focus Group
« on: August 10, 2006, 06:44:08 AM »
Quote from: Numsgil
I would say my primary motive for desiring sexual reproduction is that others desire it.  It is quite common for people to want to run a simulation experimenting with sex.  I've seen several users come and go for this reason.

Well, if you don't know your goal, no surprise you don't have clear ideas on how to reach it.

Allowing the sexual reproduction to be created from more basic commands has a problem with backwards compatibility.  Not impossible to resolve, but still quite noteworthy.  .repro is a perfect reproduction method, as opposed to Avida where the entire genome is concerned with reproduction.  If sexrepro is  orders of magnitude more complex than .repro, we have a problem of a slanted fitness landscape where sex is concerned.

I don't see why sexual and asexual reproduction, or even complex/new style repro and old simple .repro, should cohabit in the same simulation. Sex seems to be per se not competitive with asexual reproduction, at least in the DB world. (This don't necessarily means that there's something wrong with DB: maybe sex just needs huge and complex environments to develop and be advantageous). So I would simply allow to run simulations with sexual repro, without worrying about its complexity or competitivity. Later, but much later, one can think of creating a more AVIDA-like control over genetic material to allow, through the same mechanisms, both asexual and sexual repro.

To resolve it, should we wish, we could generate a sequence of very basic commands to operate on the DNA, and have .repro act as a modifiable macro, perhaps using codules or some such.

As I just said, it would be a completely different project. The problems to address now are (at least) those four points I listed in my previous post.

I am of the strong opinion that we need to move as much of the program away from the gene as a fundamental unit.  DNA should be treated more as a long strip of magnetic tape and less like a collection of pearls on a necklace, if that makes sense.  Especially since modern gene structure can be quite peculiar and convoluted.

That's again another project, which has almost nothing to do with sex.


Suggestions / Sexual Reproduction Focus Group
« on: August 09, 2006, 07:35:50 PM »
Nums, it seems to me that you're taking things from the wrong side. The first thing one should ask himself, before doing anything, is: why do I want sex reproduction? A few good reasons to introduce sex reproduction in DB have been formulated in the (helas) past years (I'll list them later); but we can just say that introducing it would change the rules of the simulation and give rise to some desirable effect. What's important with in this plan is that it takes the new feature as a starting point for some (foreseeable and desired) effect.
Now, you're taking things the other way. You say, well, sex repro exists in nature, and it is obviously advantageous (because so many organisms adopt it), though I don't know why. So if I want to introduce it, I have to copy it as accurately as possible from nature, so that I'm sure not to leave out something important.
There's something not convincing me in this argument. If you don't know what's the advantage of reproducing sexually, then you may want to investigate about it; to do so with an artificial life simulator, you should take as a starting point a very general set of rules - flexible enough to allow many different types of reproduction - and observe the outcome of natural selection. The result may consist in organisms with, say, one, two, n chromosomes; or no chromosome at all, but just exchanging floating dna or single genes. In any case, you're interested in the result, whatever it is. You want to explain sexual reproduction, but you don't actually need it. It is your goal, not your starting point; hence you should not code it directly in the simulation.
At the same time, you say you want to hard code sexual reproduction in the simulation - just as a rule that you need for new complexity. This would make sexual reproduction a starting point, not a goal, and you should be able to list the benefits of introducing it.

Now, it's been a long time since we first thought about introducing sex in DB. There are a few reasons for this:
1) many of the organisms we're most familiar with (expecially those showing complex behaviour) reproduce sexually. It is not to say that then reproducing sexually is good; but, as DB should show a parallelism with the real world, it is good for DB to reproduce some major traits of the world, sometimes even directly coding them;
2) sex should enhance evolution, by letting the result of good mutations which may have taken place in different branches of the evolution tree mix together;
3) sex, requiring compatible DNAs to mix, gives rise to real species and speciation, which always lacked in DB. The very concept of species is blurry without sex;
4) sexual selection becomes possible, though still hard. The criteria generally used in the choice of the partner influence evolution.

Now, given these points (2,3,4), it is possible to have an idea of what this kind of sexual reproduction in DB should look like. For 2), sex repro should be able to mix dnas of two (or more) individuals, transferring some genes from one to another, or mixing the genes in a new individual; 3) is the consequence of a reproduction mechanism which requires the source dnas to be similar enough to produce a well-formed destination dna; 4) requires robots to be able to make some kind of choice of the partner(s).

These requirements seem to be not too distant from what the actual .sexrepro command does. The least fulfilled is 4): .sexrepro is very weak in that, partially because it is maybe a too simple mechanism, but also because of intrinsical limitations of DB: things in it simply go too fast and good communication between robots which aren't tied is too difficult. Which should be the elements for a good partner's choice?
Also the algorithm which mixes the two dnas is probably too simple - though working, and not too difficult to improve. Has anybody tried to run extensive simulations making use of (and exclusively of) sexrepro?

Anyway, my point is simply that, before thinking of adding features to DB, one should know exactly what he needs.


Newbie / Delurk
« on: March 11, 2006, 05:29:49 AM »
let's take my two examples and apply a mutation that extracts 3 BPs and moves them to a different point in the genome.

In the original example, you could extract add 2 div and move it somewhere else.

In the modified example with muts, it would be mut 2 mut.

The first has more cohesion to what the original equation was.  Mutations are less likely to destroy equations by moving them around.
Well, you're right. Though this would count as an increase in the mutation rate of the portion of code you considered - and we were talking about methods to increase the mutation rates of code portions.
On the other side, I understand that you may want to increase just the rate for "single base" mutations, without affecting the splicing rates. But, in order to obtain this, you may just have to modify a little the splicing routine, by adding the directive "never splice just before a 'mut' token". Done that, the cohesion of

2 | add | store
2 mut | add mut mut | store

remains exactly the same (I have put in evidence the slicing points). Consider the other advantages of this system: it is easily readable and writable by humans, some of its effects come naturally (increased insertion rate, for example).

Newbie / Delurk
« on: March 10, 2006, 03:15:20 AM »
3 5 mut mut add mut 2 mut div

The computational complexity of the equation hasn't changed one iota, but its elements have become more sparse, leading to less homogenous effects from mutations, and different selective pressures.
What do you mean precisely with "less homogeneous effects from mutations" and "different selective pressures"? Could you make an example?

Newbie / Delurk
« on: March 09, 2006, 05:52:15 PM »
Yup, I hear ya.  Eventually, I'd love to see both atomic instruction level and module 'area' level mutation encoded inside the genome but I fully understand how the latter is more involved.
Just add some new token (instruction) to the dna code (say , for example, 'mut') which has no effect but increasing the mutation rate of the surrounding code. Say that the mutation rate of the surrounding code increases proportionally with the proximity to the mut tokens. And that the influence of the mut tokens is addictive. The token moves with the code, as it is subject to deletions, transpositions, etc. It is subject itself to mutations, and it can be inserted, deleted, etc.
Would it be ok?


Off Topic / Riders of the Purple Wage
« on: September 23, 2005, 11:10:20 AM »
If you have not read it yet, it is time (well, it's been almost 40 years since it was written).  It is one of the best sci-fi works ever written and I put it up on our web-site for a while.  Grab it here, read it and then post your thoughts.  It is fairly short, about long-story or short-novella size.
It is definitely one of my favourites sci-fi novels. I read it for the first time probably 15 years ago, and immediately loved it. It is funny, prophetic, and the premises are very interesting (what would look like a world without the need to work, where everybody is free to develop his own inclinations).  Some of the things I liked most: the tv with thousands of channels where you can watch shit all the time but also gain a degree-level culture, that reminds me of the www. And the phone that rings with the sound of a rare frog grabbed from a tv show, also reminds me of today's world. The motivational analysis used to study the actions of the main characters, is the same used by modern advertising companies to study the promotional campaigns. And the pessimistic, but credible, prediction about the degradation of people just wasting their time playing cards and watching tv - it has much to say about the world we live in, too.
And the style is great, very different from the often flat style of most of the sci-fi novels.

Off Topic / Wikipdia
« on: September 20, 2005, 05:21:19 PM »
changed "no intrinsic fitness function" in "no external fitness function" in the fitness function paragraph. AFAIK, intrinsic fitness function is exactly what DB has, I.e. it has a fitness function that's intrinsic to the simulated system, not imposed from the outside.

Good article, anyway (I appreciated the weaknesses section very much) :)
Ah, and there's a war going on about the main page, I see. :)


in fact it may be a whole new project. I've been thinking for a long time to an alife sim working along these lines - but never had the time to start coding. But some of the ideas could maybe work in DB too.
As for the two problems:

1) Yes, veggies are artificially determined, and that's no good. But, it's maybe better to have such a hard and artificial division than introducing complicated rules which can result in adding no more than the complexity of the rule itself.
There is a fact, on the other hand. It don't seems to me that there are in the macroscopic world many examples of a continuum between vegetables (autotrophs) and non vegetables. But maybe in the microscopic world things are much different, I don't know.
So, if we want robots to move gradually between auto and heterotrophy, we should accept the existence of robots which, at the same time, feed through photosynthesis AND hunt for food; otherwise, why should we introduce a model allowing such continuum, and at the same time put in it a number of deterrences to make practical to be only in the extreme positions of the continuum?

2) the energy problem. Here again you're right. There's no methabolism, and the energy parameter is extremely simplistic (by the way, never found irritating that a dying robot with, say, 300 energy,  has all the speed and reaction capability of a fully healthy bot?). Maybe a "multiple container" system would be interesting. You may have a few different parameters, with different characteristics, and let the robot transform one type into the other at slow rates (say, no more than a fixed token per cycle). Anyway, my advice is to try to keep that system the more simple and abstract as possible, purging it from the "organic" nomenclature (fats, carbs, etc) so to make clear what exactly the system is and what it does (otherwise, you'll always be tempted to add features which are "name driven": for example, that fats _should_ make you slow or, being "greasy", _must_ have something to do with slime, etc - hope you get what I mean). Parallelism with real systems may come after, just as a convenient metaphore of the system.

Ok. I'm going away for holidays tomorrow (to Irkutsk!) and I'll be away till the beginning of August. So, goodbye for now, have a nice time. Don't change too much in DB while I'm away !  :lol:


you can write any program with the dna language. Mutations don't allow _syntactically_ uncorrect sequences to appear, but allow any possible correct sequence. If the chemical system should work like that, then it should avoid the specification of reactions like:

abc + xyz -> aaa

(let's say that this reaction is syntactically wrong as there are 3 a on the right and only one on the left side, and the other atoms disappeared - therefore the reaction is simply impossible, the expression has no meaning).

What you are saying, instead, is that we should avoid reactions which are _semantically_ wrong, I.e., work but have no evident meaning. That's exactly the opposite of the DB philosophy.

The first and foremost effect of that would be the blurred line between veggies and non-veggies.  Bots could evolve to become either.  The second effect is that bots can become a lot more diverse: they can be lean and muscular or they can be slow and fat or they can be large and tough  (and any variation in between).

See, that's exactly what I mean. Just read your statement, and count the degrees of freedom that this new system will add to DarwinBots:

1)  veg <-> non-veg
2)  lean <-> fat
3)  weak <-> muscular ?

What else? Probably some more, but now, by contrast, try to count the degrees of freedom the DNA gives to robots: impossible!
See (I'm sorry to be sooo boring), that's the difference between selecting syntax or selecting semantics. If you select syntax, you don't know what to expect. If you select semantics, you already know you'll get what you selected.

Currently bots are made up of body and nrg.  We'd subdivide body into muscle and fat (fat stores nrg, muscle makes the bot stronger).  There'd be animal fat and plant fat (ie: cellulose).  I don't remember how we decided, but plants are allowed to produce animal fat, and animals are allowed to produce cellulose, but there are incentives for bots to produce what is best for their given situation.

That gives 4 basic bot substanes.  Then you add substances that occur in the grid, and that bots can use for either production of stuff or producing energy.  For instance, elemental sulfur can be combined with water to produce hydrogen sulfide and nrg.  Wether its sulfur or we call it glimglam 96 doesn't matter.  For producing stuff, we would have something like silicone -> shell.
So, in the beginning there were DNAs, memory, and energy. Vegs were simply robots which received food for free.
Then you divided energy in Energy and Body; now you want to divide Body in fat and muscle. But not just one type of fat and muscle, two types. The types for vegs, and the types for non vegs (I guess this means erbivores. What about carnivores?). Every robot can produce all four kinds of stuff, but there will be "incentives" to produce only the right stuff. This means that vegs will receive food for free, and also incentives to produce the right stuff. Also non vegs will have their own incentives. Chaotic.

Then you'll add sulfur, or let's call XYZ. XYZ, combined with ABC, will produce HJK and energy. I understand that this can be an interesting way to tie some of the many bots parameters, which are now balanced, if I'm not wrong, by totally arbitrary rules (I mean, there's something preventing bots from having max shell and max slime at the same time, isn't it?).
For example, if you have that

XYZ+ABC -> shell
QWE + ABC -> slime

then you'll have to choose whether to use ABC for shell or for slime. There will be also some competition for the resources.

However, I'd prefer something which leaves some more possibility. For example, say that slime is QWC. Then producing slime would be something like taking off E from QWE, C from ABC, and sticking them together to form QWC. This may cost energy, and would leave out E and AB, which may form ABE or EAB. These things may accumulate in the bot, become dangerous, or be ejected in the environment. All you'd have to do is to define a set of rules telling you how much energy you need to detach letters from a molecule, and to stick them together. Some robots may evolve a transformation sequence which uses the byproducts of another bot's transformation sequence to produce something else. Or a robot may develop alternative, less efficient, transformation sequences to face a lack of some basic molecule.

You'd not have to invent molecules and transformations: all would be in the intial rules. And it would be open ended, too. Wouldn't it be cool?


 if we follow your logic, then limiting bots only to DNA commands that we give them is also not good.  From this point of view bots should be able to create their own DNA commands, because re-arranging DNA commands is "optimization, not evolution".
The system you outlined in your post (with carbs doing this, fats doing that) and only the few reactions needed to obtain just one or the other, well, seemed to me really far from being open ended. DNAs are programs, you can make whatever you want with them: even use them to calculate greatest common divisors, or sorting an array.

A suggestion. Why don't you use, instead of fats, carbs, etc., the dna sequence itself? Say that enzymes act on the dna: for example, that they're able to split the dna sequence in some points. Say that an enzyme which fits  a certain dna portion, is able to delete it from the dna, leaving it splitted in two parts.
For example:

you have the dna:

10 .up store

*.eye5 0 >
-1 .shoot store

and the enzyme:  *.eye5 0 >

what you get is

cond start 10 .up store stop cond


start -1 .shoot store stop end

You can state that the smaller the blocks enzymes can mince, the more energy a robot can take from his prey's dna. Or that the energy is proportional to the length of the remaining ends, and then you can repeat on these the enzymes attack, until you can't split anymore. The rest would be waste? This way you'd have also that longer dnas provide more energy, and that there are many different ways of taking energy from a dna. Vegs would provide little energy, as they have simple dnas.

The advantage is that, this way, you'd tie together enzymes and dna structure, and then evolution of dna, at the same time putting on it the constraint of functionality.
I mean:

predator has an enzyme specialized in a portion of dna; this identifies the prey in a natural way in particular species; prey has an advantage in evolving to change that portion of dna; at the same time, that portion provides a functionality, so it can't change it freely. It may have to choose between becoming undigestable and conserving a particular feature.

What we came up with was either a use it or lose it kind of specialization, where omnivores in a meat free environment, over time, tend to lose tha ability to digest meat as the enzymes, which aren't important anymore, are lost.

-Or- a system where specializing in A causes a despecialization in B.  This is how most games deal with class speciation.
So, what's wrong in the system with an array? You have an array of values, with the first stating the ability to digest element x, the second to digest element y, etc. The total sum of the array (better: of the square of the values) has a fixed cap.
This way, you'd force specialization: every unused ability would be rapidly lost since mutations would favour robots with higher values for the used abilities.

But I still don't understand how do you expect different kinds of bots to have different composition (say, cellulose or proteins or fat), so that they can be methabolized in different way by predators.

Our goal is not to model biochemical reactions and chemistry.  It would be too ambitions and actually a step away from the original goal of looking at evolution.  Instead, we want to allow bots to make choices on how to utilize thier energy in best way to survive.

That's ok. As I said before, our interest should not be in biochemistry in itself: if we feel the need to add some sort of biochemical system is because we noticed that DB fails in simulating some important aspect of evolution, and we correctly identified the problem in the complete absence of something like a biochemistry.
Here there are two things to say.

First, I don't think we want bots to make choices on how to utilize their energy. As you said, the good thing in DB is that DNA provides almost endless possibilities. There are other alife software in which the dna just specifies a few parameters, like probability of doing a certain thing or another. But that's optimization, not evolution. So, we want an open ended system, which instead of providing a few choices, could provied an entire world of different possibilities.
Second, that if we need something like a biochemistry, it must be something related to the DB universe, not a mock up of real world's biochemistry. So we should forget about CO2, O2, sulphur... all things which are totally meaningless inside the DB's universe.

So we'll provide functionality directly, without giving bots access to all possible chemical reactions.  We can give them protein, fat, carbs and some intermediates and a way to convert these molecules into one another.  Each molecule would have different properties and affect bots in different ways: proteins require a lot of energy, but they allow cheaper/more efficient functionality, fats are a good long-term energy storage, carbs are good short-term energy storage and provide turgor. 

But why then we don't simply give to each robot an array of parameters, each specifying the ability to digest something, and state that the total sum of the array must be fixed to, say, 100? It would be an easy and effective way to force robots to specialize. The only problem is that it would be clearly not open ended, and we don't like this. So we need to hide an equally not open ended system behind a complicated set of rules, to make it seem more clever than it is.

Finally, you can decide the ability to digest proteins, fat, or whatever else... and then? You also have to decide which robots are made of what, and in which percentage. You may have food chains with erbivores able to digest cellulose, and then predators able to digest proteins... but who decides that vegetables are made of cellulose and erbivores of proteins? Wouldn't it be easier to put a good control in the simulation options, stating who can eat what, once for all? (obviously, I'm joking).

There are (at least) two possible approaches to model biochemistry in DBs:
1. Take real biochemistry as an example, copy reactions and allow bots to do only those reactions that we introduce.  This is a fairly easy approach and I think we managed to come up with a system, which would be open-ended - we can start with a small subset of reactions and slowly introduce new steps/pathways in a way that is backwards compatible.
2. The second approach is not to rely on real chemistry at all, but instead invent our own set of molecules and rules through which these molecules can interact.  Then allow bots figure out the biochemistry on their own.

Right now we are almsot set on the first approach, although I do like the second one too ( I am sure Carlo would go with the second approach as well, if that matters to anyone).

That's not what "open ended" means. Open ended means that you expect robot to figure out their own way to use molecules and even build new molecules that you never thought of. The approach of defining each single molecule in the world, and then describing all the possible reactions between them, with all the energetic balances, and so on, is used in simulations of biological processes. There it makes sense. In darwinbots it makes no sense at all. Why should we define sugars, water, carbon dioxide, and so on, when our organisms have a DNA written in reverse polish notation, their genes don't produce proteins or enzymes but values in a memory array? What's the meaning of "sugar" with respect to a computer program like db's DNA? Simply, no meaning at all.
I think that DB should be a good metaphor of nature, not bad copy. I mean, we should not copy from the real world things like sugar, carbon dioxide, etc. If we want to have something that recalls a chemistry in DB, then

a) it must be because we understand that some of the complexity lacking in DB comes in the real world from the existence of a chemistry - and not because we want to mock up nature
b) we should create something that makes sense in the universe of db, and can give the complexity we're looking for. It has not necessarily to have to do with sugar and oxygen and ATP; it must only give the desiderd complexity, in the context of the db general rules and principles
c) if - I say if- there will be a parallelism between the system created for DB and real chemistry, it has to come from DB, and not from nature. I mean, you should not put sugar in DB because in nature you have sugar; but you may _discover_ an element of the DB system that seems a good metaphor of sugar, and nickname it "sugar".

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