Le operazioni genetiche in ABiDEvoCOM.dll:

Gli operatori genetici sono due, come si è visto nel capitolo dedicato agli algoritmi evolutivi: crossover e mutazione. Servono a simulare il processo di ereditarietà dei geni per creare nuovi individui ad ogni generazione.

Negli ultimi anni sono stati proposti dai ricercatori molti algoritmi descriventi gli operatori genetici che possono essere raggruppati in tre classi distinte:

1. Operatori convenzionali; 2. Operatori aritmetici; 3. Operatori dinamici.

L’efficacia di tali operatori è più o meno correlata all’ambito per cui sono stati implementati e dunque in ABiDEvoCOM ne vengono studiati diversi alfine di definire quale operatore si adatti meglio al caso studiato.

Il crossover:

Gli operatori di crossover o ricombinazione genica sono definiti a partire dalla classe astratta CrossoverAlgorithm.cs. La classe astratta contiene le proprietà caratterizzanti la probabilità di crossover e il generatore di numeri casuali, i relativi validatori e il metodo virtuale di Crossover (ridefinito in ogni classe ereditante).

Figura 4.17: Visualizzazione grafica della gerarchia delle classi, in alto la classe astratta di Crossover dalla quale ereditano ed estendono le proprietà le classi derivate (in basso)

Tutti gli algoritmi di crossover operano sulla base dello stesso principio: lo scambio (ricombinazione) degli alleli tra i geni del cromosoma. ABiDEvoCOM opera anche in campo vincolato e dunque alcuni algoritmi nascono di esclusivo impiego per il campo non vincolato in quanto operano sulla base di permutazioni, ossia scambiano le posizioni degli alleli (PartiallyMappedCrossover), altri sono definiti per solo tipi interi (MultiPointCrossover e DirectionalCrossover) o per soli tipi reali (DiscreteCrossover e ArithmeticCrossover).

La mutazione:

Come per gli algoritmi di crossover e tutte le altre classi rappresentanti algoritmi espandibili di ABiDEvoCOM.dll, anche la mutazione ha una classe astratta (MutationAlgorithm) definente le caratteristiche di base di tutti gli operatori di questo tipo:

• Probabilità di mutazione; • Generatore di numeri casuali;

• Metodo astratto di applicazione dell’operatore (Mutate).

La figura seguente (Figura 4.18) riporta lo schema relazionale esistente nell’OOP di ABiDEvoCOM tra la stessa classe astratta e le derivate implementate sino ad ora.

Figura 4.18: Visualizzazione grafica della gerarchia delle classi, in alto la classe astratta di mutazione dalla quale ereditano ed estendono le proprietà le classi derivate (in basso)

La mutazione avviene solo quando il numero generato casualmente nell’intervallo chiuso [0,1] è inferiore alla probabilità di mutazione definita ad inizio progetto.

Gli algoritmi di mutazione implementati sono diversamente impiegabili a seconda del tipo dei geni (intero, binario, reale, etc.) e del tipo di cromosoma se omogeneo2 o meno.

Il DOE:

Il Design Of Experiment in un progetto di ricerca dell’ottimo costituisce il punto di partenza dello spazio di ricerca, ossia la prima popolazione. Tale set di cromosomi in ABiDEvoCOM sono generati casualmente all’interno dello spazio di variabilità dei parametri d’ingresso. La generazione del DOE è dunque sempre conforme allo spazio di ricerca.

Così come per gli operatori dell’algoritmo anche il DOE è caratterizzato da una classe astratta (DOEAlgorithm) dalla quale tutti gli algoritmi che gestiscono la generazione “zero” dovranno ereditare le proprietà di base e il metodo principale di Generate attraverso il quale l’ottimizzatore gestisce l’inizializzazione e definizione della popolazione.

Figura 4.19: Rappresentazione grafica della dipendenza tra classe astratta del DOE e la classe ereditante RandomIntDOE

Il metodo RandomIntDOE opera estraendo casualmente un allele dal set di variabilità del gene oggetto di definizione, ovvero operando una scelta casuale su un insieme discreto di valori caratterizzante ogni paramentro della configurazione. All'uscita del metodo verrà fornita una configurazione casuale generata in accordo con i limiti di variabilità imposti.

In ABiDEvoCOM il numero degli esperimenti che possono essere generati, definito dalla variabile numOfExperiments, non è necessariamente coincidente con la dimensione della popolazione (offspringPopSize) e pertanto può esser condotta una prima esplorazione molto ampia dello spazio delle soluzione per poi condurre un’ottimizzazione sulle migliori configurazioni determinate.

La valutazione degli individui:

Al termine della fase computazionale di ogni individuo, ovvero al termine della risoluzione del problema avente come dati d’ingresso i valori attribuiti ai singoli parametri dall’ottimizzatore avviene la fase di valutazione dell’individuo stesso. Tale fase corrisponde nei casi più semplici alla fase computazionale vera e propria, ossia alla determinazione del valore della funzione3. Nella maggior parte dei problemi ingegneristici, come è ben noto, il processo di determinazione della soluzione è il risultato di una moltitudine di operazioni e processi logici che portano all’individuazione di un set di parametri, i quali costituiscono la base per la valutazione complessiva del problema, ossia la determinazione di un costo, piuttosto che di un’efficienza oppure di un peso.

Inoltre, a differenza di molti problemi matematici, i problemi ingegneristici hanno sempre a che fare con il discreto e con i vincoli progettuali. Nasce dunque la necessità di pervenire ad una o più funzioni di valutazione di problemi non immediatamente risolvibili, discreti e vincolati. La strategia che viene adottata in ABiDEvoCOM è costituita dall’introduzione di funzioni di penalizzazione le quali trasformano il problema da vincolato a non vincolato.

Negli ultimi anni sono state proposte molte funzioni di penalizzazione, dalle lineari di semplice impiego alle forme più complesse e mirate al tipo di problema. In ABiDEvoCOM si sono impiegate due distinte funzioni di penalizzazione:

1. Statical Penalty Function (funzione di penalizzazione di tipo statico) segmentata del tipo:

dove:

con numero dei vincoli e la configurazione oggetto di valutazione, mentre rappresenta il valore limite del vincolo e il parametro di penalizzazione associato all’ -esimo vincolo;

2. Dinamical penalty function (funzione di penalizzazione di tipo dinamico) resa qui segmentata dall’equazione definita nello spazio delle soluzioni valide. La funzione è descritta dalla seguente relazione:

dove:

costituisce il valore massimo di violazione del vincolo per la popolazione corrente del considerato vincolo, ossia

;

il numero dei vincoli di progetto;

La funzione di valutazione ( ) fornisce poi la base per la funzione di fitness ( ) che nel presente lavoro è caratterizzata dalla seguente equazione:

dove K è un fattore correttivo costante della funzione di valutazione.

Figura 4.21: Grafico della funzione di penalizzazione dinamica, la freccia indica la direzione della penalizzazione introdotta dal fattore il quale diminuisce con l’andare delle generazioni.

CAPITOLO 5

AutoBiD: