RSS 2.0 Feed

» Welcome Guest Log In :: Register

Pages: (14) < [1] 2 3 4 5 6 ... >   
  Topic: Evolutionary Computation, Stuff that drives AEs nuts< Next Oldest | Next Newest >  
Wesley R. Elsberry



Posts: 4937
Joined: May 2002

(Permalink) Posted: Jan. 23 2014,09:41   

Quote (BillB @ Jan. 23 2014,04:32)
     
Quote (Wesley R. Elsberry @ Jan. 23 2014,09:17)
While I did stress that the genomic content of the initial organism, and thus the Avidian population, could only acquire the new instructions via mutation, once an ancestral organism had one or more of those, they would be passed down to offspring with the usual frequency. And any effects they had on the organism could yield a difference in fitness, driving the usual selective processes. I think saying mutation was the only operative process goes too far. Not including the instructions in any way in the initial organism simply eliminates the possibility that I as experimenter set up a particular outcome by whatever arrangement of movement-relevant instructions might be set in that initial organism.

One question I was asked at SSCI in 2009 was why use Avida and not something like Echo. And while the efficient answer is that when one is at the Devolab, one is usually going to be using Avida, I did survey the available software at the time for applicability to the question I was looking at. The software systems allowing for agent movement all treated movement as a primitive property, often requiring some fixed movement strategy be defined for the agents a priori. I was interested in looking at what evolution could do given just the sort of capabilities underlying movement as seen in organisms like E. coli, but without specifying how those capabilities were used. And that kind of question was not what the other software packages could address.

Excellent stuff, and something I'm really interested in despite having no time to work on any more ...

I'm not intimately familiar with Avida but a few things jumped to mind whilst reading the description:
             
Quote
A facing is always toward another adjacent grid cell, so for an interior grid cell there are eight legal facings, five legal facings on an edge, and three at each corner grid cell.


I would say that there should be no illegal facings, just an inability to move when facing an edge – this would prevent a bias towards movement back to the centre – A bit like breeding E. coli in a jar: They cannot pass through the glass container but they could repeatedly bump against it until they die. By having illegal facings you are, in one sense, providing them with obstacle avoidance behaviour for free.


Avida giveth, and Avida taketh away. Facing is very basic to the software. Illegal facings, when exercised, terminate the program with an ugly "bus error" message.

On the other hand, the world geometry options are (or I should say "were", I haven't checked the latest code) grid, torus, and clique. I have no idea what clique does. Torus, though, wraps the edges of the world grid. Using torus would solve the illegal facing issue, since every cell would then be an interior cell. However, I also thought of torus as giving Avidians something for free, since on a relatively prime grid size I think movement on the diagonal will give the organism access to a lot of the grid, if not all of it.

   
Quote (BillB @ Jan. 23 2014,04:32)

             
Quote
The "sense-diff-facing" instruction puts the difference in the amount of a specified resource between the current grid cell and the faced grid cell into one of the Avida registers.


What if this was expanded to be a “sense X,Y diff” instruction where X and Y can be any of the surrounding cells, or your own cell? The values for X and Y would be heritable. (And I don't know what you do about sensing the cell in front of you when facing the edge of the world)


As I recall it, access to adjoining cells is entirely defined by facing. It would be nice to have X,Y addressable during the run, but as I recall, it doesn't work that way.

I think this issue, among others, led a colleague of mine to give up on modifying the Avida grid system entirely, and instead implemented a separate arena-style system that was instantiated on a per-organism basis, what she referred to in the planning stages as "dream-a-grid". Many of the things that I am describing as constraints would not be in her codebase. (Her Avidians evolved such things as perfect maze-running, but she had a complex system of markers that when correctly sensed and acted upon would lead to that.) The tradeoff, though, is that her movement experiments were all about individual performances, and no interaction between members of the population would be possible. I'm thinking in terms of future experiments possibly having a larger role for competition.

   
Quote (BillB @ Jan. 23 2014,04:32)

Perhaps if you wanted to add an interesting twist you could turn that into something like "Z=F(X,Y)" where X and Y are as described above but the function F is a heritable operand (Add, Subtract Multiply Divide or Modulo) - you might even include bit shifting as a possible operand? Z=X<<Y or Z=X>>Y

The point would be to provide multiple pathways for this sensory apparatus to work - and for it to fail to work.

Expanding on this a bit more (if it is worth doing) you could allow for more distal sensing - maybe a Z=F((A,B)(X,Y)) instruction where A and B, and X and Y, are relative cell co-ordinates, perhaps capped to a maximum range of +/- 5. If you did this then I would be tempted to add a cost for longer range sensing (You need more energy to grow those longer whiskers!)


There was already code in Avida for distinguishing resources. This was based on a label system, where several bases in the genome get interpreted as a label, so what the organism gets when it processes a sensory instruction is heritable. All the sensory instruction does is put a value into an Avidian CPU register. What happens to it after that has to evolve, too.

Like I said above, I don't know that distant sensing has an obvious implementation pathway.

   
Quote (BillB @ Jan. 23 2014,04:32)

             
Quote
The environment is defined with a positively rewarding resource, with a peak in the resource set off-center in the world grid.


Can you make this more complex and dynamic? Perhaps try something more akin to a simple hydrothermal vent model:

A source (of the resource) pops up at a random location and begins churning out the ‘resource’, creating a gradient. Eventually the source is exhausted and the gradient disappears. You can have a maximum of x sources in the world at any time and when the number of sources is less than x a new source has some probability of appearing at a new random location.


The current way I define a resource gradient is quite cumbersome. I have a Perl script that set up CELL declarations in the environment config for every cell in the grid. I do have code for a method to establish a resource gradient at runtime, but that's not yet tested. Yes, I'd like to have a moving resource at some point. I don't think it will be the first thing out the gate.

   
Quote (BillB @ Jan. 23 2014,04:32)

It would also be nice to have a negative resource – something that causes harm but which is not simply a lack of positive resource – using the same hydrothermal vent model you could have a second resource whose intensity costs or harms an agent. This should result in a much more interesting and dynamic resource landscape for the agents to navigate.

I'm not sure if this should be a sense-able resource (something the agent can sense) of if it just causes harm without the agent realising -- Something I'm not clear on with Avida: can the agent sense its own 'energy' and as a result tell if it is being rewarded or harmed?


The "detrimental resource" is likely the first thing out the gate. There's some issues on how this gets implemented, but I think I see a way forward on that that won't impact what I've already done too much.

As far as the Avidians sensing whether they are doing well or not, I think the answer is "no". The system scheduler assigns cycles based on merit, so poorly performing Avidians are also slowly performing Avidians. As far as I know, permitting an Avidian to have access to some transformation of its own merit would require setting up an instruction to do just that. Plus, an absolute value for merit wouldn't be terribly useful. In the first hundred updates, a merit of 0.29 would be excellent, but then pretty miserable not so much further into the run. What would be useful to the Avidian is some relative number related to their ranking in the population. I don't know of any biological correlate to that, though.

   
Quote (BillB @ Jan. 23 2014,04:32)

I am tempted to suggest actually defining a spectrum of resources (some good, some bad) but this would require many more methods for the agent to sense them (and makes for a much more complex research project). What I am thinking of here (and it is a vague thought without any of the important details) is to include potential routes by which an agent can gain an advantage by combining certain resources in certain ratios – it can create a more potent energy source than the ones it absorbs passively – This would, of course, be balanced by the potential for agents to combine resources into fatal concoctions.


Actually, the sensing system is already label-based, so multiplying the resources could be done without any particular hassle for the programmer. What it would do to the Avidians... that's an experiment.

The first experiment was pretty much a stab in the dark. We set up something that hadn't been tried, and we didn't know whether we were posing a challenge outside the scope of what could be evolved in Avida. Now that we know that Avidians can evolve movement strategies, including ones in an optimal class of strategies, we can raise the bar some.

--------------
"You can't teach an old dogma new tricks." - Dorothy Parker

    
  399 replies since Mar. 17 2009,11:00 < Next Oldest | Next Newest >  

Pages: (14) < [1] 2 3 4 5 6 ... >   


Track this topic Email this topic Print this topic

[ Read the Board Rules ] | [Useful Links] | [Evolving Designs]