Messages

76

Off Topic / How to use my new features.

« on: May 31, 2005, 06:58:47 AM »

shape works like def.  That is, it's a command to the parser instead of the DNA execution.

There are three types of code in the dna files:

1) robot's parameters: these are parameters which can be added to a dna and are automatically saved by the dna save function. Parameters are useful because they carry additional robot's features which cannot be expressed by the dna.

2) parser commands: these commands affect the dna parser. There's only one parser command (def) and it only defines an alias for numbers. Alias label are simply converted to number when dna is tokenized.

3) the executable dna. This is what the parser executes, that is, genes.

Now, the shape type has definitely NOTHING to do with how the dna is parsed or executed. It is instead an additional feature of the robot. So it has to be expressed with the code for that type of feature. There are dedicated routines to parse that kind of code in the dna, as well as routines to add it to the dna when it is saved again from the simulation. So, please, use them, or the program will soon become a total mess.

You were talking about shape effecting how many ties you can have (1 tie per side, right?).  Are you still thinking along those lines?

I hope you're not. In my opinion, there should be a one way arrow going from the simulation to the visual representation, like this:

what happens inside the simulation ----------> what you can see on the screen

(this kind of model is so elegant and so used that modern object oriented programming languages have special constructs to implement it).

I understand that, if you decide that a square robot can have only four ties, then the fact of the robot being square it's just a visualization of the fact it can only have four ties. But let's face it: if you were really interested in this, you'd have added the 1-2-3-4 ties selector in the robot options window, and only after you'd have imagined a way to represent this visually. But here we have the opposite: first you decide that having a triangle robot is funny, and after you say "oh, well, but this should mean something after all". This makes me very very doubtful about the real need of this new feature.

77

Off Topic / How to use my new features.

« on: May 31, 2005, 04:17:03 AM »

To use this, just add a line at the beginning of the robot's DNA using the new "shp" feature. Here is how you do it.


CODE 

shp 4

cond
'your condition
start
'your action
stop

etc.'
 
This will give youa square robot.
shp 3 will give you a triangle and so on.

Hmm. I hope this shall have effects ONLY on the simulation appearance. First, because having three options (triangle, square, pentagon) is not exactly what I'd call "open ended"; second because otherwise you should invent some strange rule to take shape in account. By the way, that shp 4 instruction, if I'm not wrong, just breaks the structure of dna. What is it? Not an executable istruction, it is outside genes, and the correct syntax for this kind of information would be

'#shp: 4

as for color, mutations, generation, etc, in the beginning of the dna. There's a useful routine for dealing with those robots parameter at the beginning of the dna files. So use it!

78

Off Topic / web-page

« on: May 30, 2005, 09:25:46 AM »

I'm working on setting up one on my home computer as well as part of my sister's webspace.  I should have something working by tonight.

Great!

79

Off Topic / web-page

« on: May 30, 2005, 07:40:32 AM »

About the web page. These is a list of things which IMHO need to be changed:

1) the logo isn't the original one, though the original one was itself not very good; but this seems to me definitely worse (looks banal). I'd prefer a different logo or keep the old one.

2) Colours scheme is dark, gloomy, and readability is bad.

3) There are no images, to understand what the site is about you have to read what's written: and still you won't find on the main page the words "artificial life" or anything else explaining what the program is about.  

4) The whole page is included in a vertical band, which is smaller than 800 pixels wide on a 800 px screen. This is surely an error, probably you intended it to be 800 px wide on a 1024 wide screen.

For Numsgil, about the organisms sharing: are you sure you can't set up a (confined) ftp space on the darwinbots server? It would be really cool (shouldn't affect traffic very much, organism files are tiny).

80

Announcements / Darwinbots Webspace

« on: May 29, 2005, 11:48:02 AM »

2. www.darwinbots.com is actually up with some pretty pages! My sister (LemmonLime) went to a moderate amount of trouble to put it together. She actually gave it to me about a month ago (maybe two?), but I've just been so busy lately...

Ehm, Nums, I don't wanna hurt your feelings, but it really looks quite horrible :lol:
We have to make something for that page before google starts indexing it!

If you're not going to get angry, I'll expose my criticism in more detail. I understand that building a site is annoying and hard. If you want, I can cooperate (though I'm probably worse at html than your sister). I can provide material and ideas, and, if you want, direct html coding.


The new wiki looks great. And, is there no way to use the domain hosting for ftp organisms sharing?

81

Suggestions / Non-Determinstic Bot DNA flow

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

82

Suggestions / New Mutation Paradigm

« on: May 28, 2005, 03:32:27 AM »

So if our add command mutates into a *.nrg, it doesn't seem to make alot of sense to us but who knows how the bots will use them.

-------
I think there are two points in what you say. The first, is that a point mutation should involve only one of the two values making a dna position, that is "type" or "value".

But this way, add wouldn't mutate into *.nrg, but _always_ in one of the .up or .dn (I don't remember which code represents the add instruction, but is something really near to 0, 1 or 2). You would have mutations unbalanced in favor of the first 10 sysvars or values ranging from 0 to 10 or so.

You cited triplets. Look: you have 4 types of dna pos, and 32000 possible values. 4 means two bits, 32000 means 16 bits. So each pos is represented by:

oo'oooooooooooooooo
^               ^
type        value

which makes eighteen bits. Now, if we like to consider this a triplet, we have to split it this way:

oooooo-oooooo-oooooo

this means that mutating the first part means mutating the type (first two bits of the first part of the triplet) together with the value (six more significant bits of the value part). So, if we split it in equal parts (like a triplet is), we have to mutate types and values together. Same thing if we split it in two equal parts.

Therefore, I think that mutating only type or only value in a dna position makes, in general, no sense.

---------
Your second point is about letting mutations produce junk dna, which means unexistant instructions, sysvars, and so on. This, as I already said, means filling up dnas with tons of junk dna. But junk dna is unlikey to become useful again: as I told you, the instruction coded by the number 500 (possible if you let type change without changing the value) will never become, through subsequent (little) mutations, a valid instruction. It may at most go back to where it came from, that is, to an immediate value or to a pointer, through another mutation. This is very improbable (if a dna position has a chance over 1000 to mutate, it has a chance over 1000000 to mutate two times - not to mention it has to mutate the right way). But if the overall result is to have converted an immediate value to a pointer or vice versa, what was the first mutation for? Let's just say that immediate values can only change to sysvar OR be substituted by a completely different instruction.

I see it this way: we should have

a generator of random meaningful sysvars
a generator of random meaningful values
a generator of random meaningful instructions

and point mutating a pos would mean just calling one of these generators and put the (type, value) they return in the pos we want to mutate.

83

Suggestions / New Mutation Paradigm

« on: May 27, 2005, 07:43:57 PM »

Are you saying that you may have something like

functional code (---mutation--->) junk dna (----mutation--->) functional code again?

Well, this is a possibility. I don't know whether it would improve things or make them worse. But it surely would make dna more unreadable then they are now. And, it would make it much harder to use evolved dnas from previous versions (you'd have to split off all the junk first). Having a mutation routine which don't have to take in account the actual language (in fact, just an integer parameter...) would be of little comfort.

But I think you're right to some degree. Changing, say, values to pointers and vice versa could be a good thing. But changing instructions to values it's not, because the information you keep just changing one part of the (type, value) couple it's simply meaningless. Like in the case of different ranges in sysvars, the value part of, say, an add instruction has simply no *particular* meaning as a pointer or an immediate value. The only way to become useful is to mutate again in the original type, which is very, very improbable.

So, I think we should take in account all these things and design mutation routines which act in a very very arbitrary way, trying to make changes which could make some sense. I think this is necessary due to the way the DB language is designed now. My fault.

OR...

Or we could completely redesign the DB code to be easier to mutate. Less memory locations. Little, defined and universal ranges for variables. Single effects (no more -1 shots, -2 shots, 0> shots, etc.). Simpler structure (sparse conds, etc.). Etc.

84

Suggestions / New Mutation Paradigm

« on: May 27, 2005, 08:16:32 AM »

First off, we'd need to come up with a way for the user to create a custom gaussian distribution, where he can decide what values the standard deviation includes (taht is, so he can determine the range for 99% of the generated values).

Ok, this should be the basis of every correct mutation systems.
But I think this should only apply to immediate values and maybe pointers. I can't understand, for example, why an add command, to become a sqrt command, should pass by a sub and a mult command. Hope you're getting the point. Graduality in immediate values is (often) obvious.  
5 .up store should be more likely to change in
6 .up store than in
500 .up store.  

(but often is not: there is no apparent relation between -1 .shoot store and -2 .shoot store or 2 .shoot store  ... and this is a big problem)

Same thing don't applies to instructions and even pointers. Is aimsx more similar to dx or to shoot? Who knows? Does the question even makes sense?

Another problem. Think a the eyeN values. They go from 0 to 100. Now take the refnrg value. It goes from 0 to 32000. Take the shootval value (memory shots): makes sense from 0 to 1000. Take the up, dn etc commands. They make sense (maybe) from -30 to 30.
This is a BIG problem. Mutations should be able to create new functionalities by mixing the code at random. But what can happen if I take a .refnrg value and put it in .dn? Nothing useful. Because the range of values offered by .refnrg is completely different from that accepted by .dn. What happens if the code

"5 . up store"? is mutated in "5 .repro store"? Nothing useful, again. A repro with a 5 value is nearly useless.

I think that these problem are deep in the structure of darwinbots.
A solution for the second problem could be this one: writing in the sysvars file the range of each var. You'd have

1 .up  -20  20
2 .dn  -20  20
....
5  .aimdx  -600 600
...
501 .eye1 0 100

this way you would be able to normalize each value read or written to a var to an universal range... and have much more meaningful mutations.

Mutations aren't limited to reproduction only, nor are they limited to children during reproduction.

This again it's ok for me. Correct from the biological point of view. The only doubt I have about this is that it will likely introduce something like a maximum life span: because if you have, say, one point mutation every 100 dna positions every one thousand cycles on average, this makes it unlikely for a robot to live for arbitrarily long time (death by aging was one of the possibilities I wanted to leave open to evolution).
But on the other hand, robots could evolve multiple copies of the fundamental genes to avoid this problem.

Changes in type always move up or down by 1

This makes no sense, there is no reason for that. There is no reason for instructions to be "nearer" to pointers than immediate values are.

During reproduction, much more massive changes are possible.

I agree on that and on the mutation types you proposed

Mutations which result in a non existant command will show up as number@number (or some other code), with a toggle to turn off display of all Junk in most DNA viewing windows and recording areas.

The beauty of this is that as we add stuff to the program, we don't have to modify the mutations code. It's all set up to handle whatever we throw at it.

No. I perfectly understand what you mean, but keep in mind that those will always be useless mutations until you insert new commands into the dna interpreter. A useless mutation is a mutation that:

- either leave unchanged the functionality of the dna so that is in fact a non-mutation
- makes the code non executable or strongly disfunctional, so that you'll waste cpu cycles just for bringing the new mutated robot to death

Moreover, you have to keep in mind that you cannot add new commands AFTER the mutations are in the dna, because each mutation has to be positively selected by its effects. Introducing new commands after the mutations are in the dna means changing abruptly the way dnas a re interpreted. And that's no good.

So, I think that the best thing to do is allowing the mutations routines to produce only the actual instructions. Simply code them with numbers going from 1 to max and, when you introduce the (n+1)th instruction, change the max to n+1.

85

Suggestions / Bot Recognition

« on: May 27, 2005, 02:50:14 AM »

As for colors, I'm not so sure it is a good idea making color readables. There is a conceputal separation, in DB, between what is real in the simulation and what is seen by users. The video output should just be a representation of what's going on, and there should be no mixes between the two levels, the simulation level and the representation level.
Color means nothing, it's there just to help users to see who's mutant and who's not. I'd also like to have other representation modes: for example  

- a species mode, showing all members of an original species with the same color;
- a diversity mode, in which color is someway calculated from genetic diversity (same meaning as now but more "accurate");
- a gene activity pattern mode: the color of a bot changes at each cycle, according to the genes active in the last cycle: this would allow to have an insight of the work of dna just by the color changes in bots. Mutants would have different change patterns;
- an energy mode: the color depend upon the amount of energy of the robot
- and so on...

The problem of identification of bots is easily solved by the unique id, which may be an option.

86

Suggestions / Greven's DNA structure!

« on: May 26, 2005, 05:07:00 PM »

The main bottleneck is still the code that checks what bots a bot can see.

Don't know if it has already been done, but maybe a buckets system would improve things. If thing are still as I programmed them, there is a list of robots which is kept ordered along the x coord, so that checking for collisions and view requires only to check for the nearest robots along the x coordinate. This means that if you have large fields, you may have to check for tons of bots which are way too far along the y coord to see if they are in range for view.
The idea of buckets is simple. Just throw away the ordered list and put in ints place a grid of lists of orbots, each of them linked to the near ones. When a robot moves outside a square of the field, it is removed from a list and put on the neighbour list. When you have to check for view and collisions, you just have to check, for each robot, the robots which are in the same list and in a range of near lists. This means no longer checking for robots which are far away along the Y axis.

87

Suggestions / Greven's DNA structure!

« on: May 26, 2005, 02:47:16 PM »

I know strings are just arrays, but in VB strings have built in commands to modify a string, this will make it easier to build mutation routines, which are faster and more reliable, and less prone to bugs etc.

Well, there are already in DB code a bunch of routines dealing with dnas. They provide all the functionality of the three or four (!) strings handling functions that VB offers, but they also are dedicated for dna handling, which means that they provide specific functionality. Please note that recreating the basic features of the string functions that VB provides, in an absolutely reliable way, requires probably one hour of trivial programming.

More, speed is simply a non issue, as mutation routines are called relatively rarely.

What is a meaningfull mutation?

Well, with meaningful mutation I mean a mutation which produces a meaningful code. For instance, if you have the VB code:

For x=1 to 100
  print "xyz"
next x

then, the mutation

x=1 to 100
  print "xyz"
next x

is NOT a meaningful mutation, because it breaks the syntax of the code.

If you have the DB code

cond *.eye5 > 0 start ... stop

and you mutate in

cond > > 0 start ... stop

this is not a meaningful mutation, because the parser (probably) won't be able to execute it.

So, meaningful mutations are mutations which produce an executable code. Nature works differently, but with at max a few thousands individuals in a microscopic environment, you understand that saving cpu cycles to  execute only well formed dna codes is a good idea.

Said that, I think we could make the language more flexible, allowing for example, operators into conds, etc. The idea is that the more mutations have chances to be meaningful, the better. For instance, we could allow something like

cond *.eye5 3 add 5 > start .... cond *.eye3 5 > start ... stop

where everything can be everywhere, a cond evaluates to true if there is, say, something >0 into the stack top, the execution just starts after a valid cond and stops only when a stop in encountered.

But I do not agree on DB has a some sort of phenotype. Yes it is a optimiztion 'trick' but still in allowes much more of the genome to be unexpressed, now everything is express (or nearly everything).

I meant to say that what is called "phenotype" in real life is something darwinbots already, to some degree, shows. If you have a gene putting 0 in var x, and after that another gene putting 5 in the same var, the effect will be of completley hiding the first gene. But the gene is there. Cut off the second gene, and the effect of the first will appear again. This is phenotype.
What you are proposing is not phenotype: is simply a trick to speed up dna execution: something that has interest for programmers, not from the point of view of evolution.

88

Suggestions / Greven's DNA structure!

« on: May 25, 2005, 03:46:16 PM »

A few comments on this. Maybe it's not all clear to me, and there are parts that I haven't well understood. Anyway, I'll play as usual the role of the actual darwinbots advocate  :D

>allow junk DNA.

Junk dna is _already_ allowed, as anybody can see just by looking at the code of some evolved bot. Gene duplications and condition mutations can easily create tons of junk genes.

The genome for a bot now is stored in an array. In my DNAS the genome is made up by a single string!

Which is exactly the same thing. Strings _are_ arrays of characters. Coding the double value (type, value) of the db array to a single value (byte) string would not change things very much. In fact, each actual dna position can be converted in a three characters sequence. Surely two chars for the value (as 16 bits are needed, and a char is 8 bits) plus a few bits for the type.

Now, I have to explain one thing. There is nothing easier than just mutate randomly the dna array (or string), putting conditions and instructions at random. You can just randomly insert, delete, duplicate and mutate values wherever you like to.
The problem is just that, as we're working on a pc which has limited power, we have to try to favour meaningful, effective mutations. This is (among other things) why  I have chosen the genes structure. Because it seemed more easy to mutate without destroying completely the functionality of dnas. And this is also why there are various mutation routines, some acting on whole genes, some _trying_ to deal with complete statements (that is, an instruction with its parameters), some acting just on conditions, and so on. I repeat, you can easily throw away these mutation routines in favour of a single routine which simply creates random mutations without trying to preserve a working dna structure. It is more simple, and more fair: but probably much less effective from the point of view of evolution.

The trick of having a phenotype (which, by the way, has nothing to do with the true concept of phenotype, which darwinbots _already_ has - just think at genes that are unexpressed because their effect is covered by the effect of another gene) is elegant from the point of view of programming - saves calculation time- but it is just an optimization trick, as Shvarz already noted. For example, actual dnas aren't executed as one may expect, that is by scanning the dna for conds, but instead a list of conds is built up at robot's birth, and is checked at each cycle. Optimization, it doesn't really changes the way the things are.

Finally, I don't really get the point of the last part - but maybe I haven't understood what you're saying. Seems you're proposing a token language for the dnas, with instructions expressed with a single letter (that is, a single array position) and numbers expressed in a positional way. Well, in the actual DB instructions already are tokenized (that is, cond isn't really the "cond" string, but is represented by a single position in the dna array). And, well, using a positional notation for numbers would allow breaking a number into its digits by inserting among them, for instance, a new instruction. But this is nothing you can't already do with the appropriate mutation routine: just create a routine which searches for numbers, calculates their decimal digitas, and breaks them the way you want. Nothing easier.

89

Tips and Tricks / Do you know what is venom?

« on: May 24, 2005, 08:31:19 AM »

Ideally, yes, but there are quite a few things in the game that keep track of a robot's lineage, some subtle, some not. Mutation rates, for one.  A few other things.

No, there aren't (well, there weren't in the code I released). Mutation rates, for instance: are not in any way species-dependant, but are individual for each robot. The only thing which is indeed linked to the species is the autotroph status.

The program is a large amalgamate of 'hey, at least it works'.  I'm not saying if that's good or bad, but, hey, at least it works.

Well... :rolleyes:

90

Suggestions / Make position a Single, not a Long

« on: May 23, 2005, 04:34:03 AM »

What do you mean by 'too big for a single to cope with'? Larger than 3.402823E38?? :blink:

 :lol:

But don't you think that singles (that means single precision floating point) could slow down calculations? Maybe I'm wrong... I have simply no idea of the power of actual computers.

One more thing: I don't see the connection between the robots' memory and their position. They don't know their (x,y) coordinates nor should they

I think they know them - PY or Numsgil added this feature. Initially I thought it was very stupid: everything was designed to give organisms only relative views on the environment. Well, I'm a bit less fundamentalist about that now. Most animals are able to orientate in the environment, and this is an important feature. Obviously, they do not have a GPS in their head, but, to some extent, it is like they do. But developing such a feature is probably impossible in the DarwinBots universe, not only because organisms are very simple, but also because of the nature of the DarwinBots environment, so poor of landmarks and allowing so limited senses.
So, maybe, it is not so bad that robots know their approximate position.