Re: [cilib-devel] Mutation and additional parameters in Individuals

[Gary P. <gpa...@gm...>]

This could result in some implementation problems. On the one hand, having the 
entity know what the strategy parameters are is very useful as it ensures that 
the object boundaries are well defined.

On the other hand, it could be an issue when the entities share strategy 
parameters - if you take the belief space within CE as a set of strategy 
parameters then that will break things.

I would, ideally, like to make the implementation as simple as possible. But 
any sort of feedback would be appreciated.

Currently, the EP Iteration startegy is performing the initialization of the 
strategy parameters for the EP. I would like to migrate them to the Individual 
as that is probably the most granular we could go. The only snag with this is 
that the current GA etc will have a slower performance as more onjects will be 
created during the constuctor call of the Individual object. We could always 
make this lazy, but the timing issues that could be introduced could cause 
problems. Alternatively, a new way for creating individuals would be needed - 
I'm contemplating a refactoring exercise on the EC stuff to correct any issues 
that we currently have with anything EC.

Does anyone have anything specific regarding the EC code that is not "good"?

Gary.

On Monday 13 July 2009 13:37:10 Andries Engelbrecht wrote:
> Hi,
>
> > 1. Where should the definition of the initialization for these extra
> > parameters be placed? On the individual? In the EC algorithm? Within the
> > IterationStrategy?
>
> You refer to the Strategy parameters here. What we have to remember
> is that strategy parameters can be "global" or "local". What I mean by
> this is that the same parameter can be used for all individuals, or each
> individual can have its own parameter. The latter can have an even
> smaller granularity in that each dimension of each individual can have
> its own strategy parameter. We should also think about cultural
> algorithms where there is a bielief space, which have some relation
> to strategy parameters. The solution should take the latter into account.
>
> We may argue that not all EAs have strategy parameters, e.g. GA.
> However, in our implementation, parameters such as crossover and
> mutation probability can be seen as strategy parameters with no
> adaptation.
>
> So the question is where does strategy parameters belong? My
> feeling is that these should belong to Algorithms. Not just EC
> algorithms, but all algorithms. Remember that PSO and others
> also have "strategy parameters". performIteration will then have
> a call to some strategy to "adapt" the parameters. And this
> basically should replace ControlParameters.
>
> > 2. How should mutation be handled? Should the strategies know to inspect
> > the individual for strategy parameters? Should the mutation rather be
> > done in a separate class?
>
> Remember that mutation can be applied in PSO and others. Mutation
> is a separate process, that may, or may not make use of the
> strategy parameters. So, mutation should be a separate class.
>
> This then also tells me that the strategy parameters should be on
> a higher level than on entity level.
>
> > Regards,
> > Gary
> >
> > -------------------------------------------------------------------------
> >----- Enter the BlackBerry Developer Challenge
> > This is your chance to win up to $100,000 in prizes! For a limited time,
> > vendors submitting new applications to BlackBerry App World(TM) will have
> > the opportunity to enter the BlackBerry Developer Challenge. See full
> > prize details at: http://p.sf.net/sfu/Challenge
> > _______________________________________________
> > cilib-devel mailing list
> > cil...@li...
> > https://lists.sourceforge.net/lists/listinfo/cilib-devel