Different ubound and lbound for different variables and feasibility

[Pedro Nariyoshi]

Hello all,
I've just started using ECF and so far I'm very happy (the documentation is specially pleasant to read). One question that I haven't been able to find an answer to is: can I set different ubounds and lbound for each element in the "realValue" array? If not, what would be the best approach for it? Normalize all values so they are in the same range?

In addition to this, is there a way of implement feasibility and penalties for infeasibility outside the evaluation function? Or must I embed it into the evaluation function?

Thank you

[Domagoj Jakobovic]

Hello Pedro,

there are two ways of doing it; the simpler is

a) use multiple FloatingPoint genotypes and define bounds for each; this works with GA and ES variants, but won't work with algorithms that require a single FP genotype. If that is the case, then

b) scaling the variables in the fitness function, e.g. if the genotype is defined in [0,100]:

scaled[i] = lower[i] + gen->realValue[i] / 100 * (upper[i] - lower[i])

Of course, the same scaling should be applied to the algorithm output after the evolution.

<digression> In a more general case, you can use a transformation of the unbounded variables to bounded values, e.g.</digression>

bounded[i] = lower[i] + (upper[i] - lower[i]) * 0.5 * (1 + fp->realValue[i] / sqrt(1 + pow(fp->realValue[i], 2)));

This works nice on some example problems; another function that maps to [0, 1] can also be used such as sigmoid:

bounded[i] = lower[i] + (upper[i] - lower[i]) / (1 + exp(-fp->realValue[i]));

this converges even better, but can be problematic with large input values; or

bounded[i] = lower[i] + (upper[i] - lower[i]) * pow(sin(fp->realValue[i]), 2);

but this converges worse.

Now, the downside is that this must be defined in the code (not in parameters) and slightly complicates the fitness function. Please let me know if you found an acceptable solution...

Currently infeasibility is meant to be checked in evaluation only, since it varies with every problem. Alternatively, you can define an Operator class that is envoked once each generation and loops over every individual to check feasibility.

[Pedro Nariyoshi]

Yes, that makes sense.

Actually, it also makes sense to have hard constraints (as defined in the configuration) and "soft" constraints, defined in the evaluation function. This makes possible for dynamic constraints and other interesting things.

In any way, thanks for the prompt reply.