Code center > Suggestions

Greven's DNA structure!

<< < (3/3)

Carlo:

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

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.


--- Quote ---What is a meaningfull mutation?
--- End quote ---

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.


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

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.

Numsgil:
As Carlo said, mutations are not the bottleneck of the program.

The main bottleneck is still the code that checks what bots a bot can see.  This probably takes 25% of the execution time at least, especially as the number of bots increases.  I've been working on lowering this from time to time, but that's where the problem is.

If anyone really cares, I can make a list of what functions take how long, in order.

Carlo:

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

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.

Numsgil:
That's not a bad idea.  I'll look at how much work it would be to implement.

I've mostly just been finding ways to streamline the x ordering of the bots and comparisons.  An entirely new structure (a KD tree also comes to mind) might speed up things considerably.

Of course, I've never actually programmed a large and complex system like that yet (that's next semester), so I'd have to dinker around with it for a while.

Navigation

[0] Message Index

[*] Previous page