Metode rješavanja kvadratičnog problema pridruživanja

Transcription

1 SVEUČILIŠTE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA MAGISTARSKI RAD Metode rješavanja kvadratičnog problema pridruživanja Dipl. ing. Zvonimir Vanjak Mentor: Prof.dr. Damir Kalpić

2 . Sadržaj. SADRŽAJ UVOD OPĆENITO O PROBLEMU PRIDRUŽIVANJA LINEARNI PROBLEM PRIDRUŽIVANJA Linearni bottleneck problem pridruživanja TIME-SLOT PROBLEM PRIDRUŽIVANJA KVADRATIČNI PROBLEM PRIDRUŽIVANJA MOTIVACIJA MATEMATIČKA FORMULACIJA PRIMJENE Primjena na problem ožičenja Primjena na dizajn tipkovnice RAZLIČITE FORMULACIJE LINEARIZACIJA QAP-A Linearizacija po Kaufmanu i Broeckxu Linearizacija po Friezeu i Yadegaru SLOŽENOST Složenost optimalnog rješavanja QAP-a Složenost lokalnog pretraživanja NAČINI RJEŠAVANJA EGZAKTNI ALGORITMI ZA RJEŠAVANJE Metoda grananja i ograđivanja Izračunavanje donje granice HEURISTIČKI ALGORITMI ZA RJEŠAVANJE Metode izgradnje Metode ograničenog prebrojavanja Metode poboljšavanja Tabu search Simulirano kaljenje Genetički algoritam Greedy randomized adaptive search GRASP PROGRAMSKA IZVEDBA I USPOREDBA METODA UVOD GENERIČKI RAZREDI ZA ITERATIVNU OPTIMIZACIJU Razredi za predstavljanje rezultata Razredi za opis algoritma i njegovih parametara Razredi za enkapsulaciju iterativnog algoritma

3 6.2.4 Razredi za ugradnju višezadaćnosti RAZREDI ZA RJEŠAVANJE QAP-A Implementacija funkcija za lokalno pretraživanje Razredi za rješavanje QAP-a tabu-search algoritmom Razredi za rješavanje QAP-a simuliranim kaljenjem Razredi za rješavanje QAP-a genetičkim algoritmom OPIS APLIKACIJE Struktura aplikacije REZULTATI I USPOREDBE Ispitivanje efikasnosti izvođenja algoritma u ovisnosti o parametrima Rezultati optimizacije pomoću TabuSearch-a Rezultati optimizacije pomoću simuliranog kaljenja Rezultati optimizacije pomoću genetičkog algoritma Međusobna usporedba različitih algoritama rješavanja PRIMJENA NA PROBLEM RASPOREDA ISPITNIH ROKOVA OPIS PROBLEMA OPIS STRUKTURA PODATAKA Strukture podataka Funkcija cilja OPIS KORIŠTENOG ALGORITMA OPIS APLIKACIJE Izbornik File Izbornik View Izbornik Opcije Izbornik Optimizacija Izbornik Rezultati REZULTATI ZAKLJUČAK SUMMARY ŽIVOTOPIS REFERENCE

4 2. Uvod Kvadratični problem pridruživanja (u literaturi poznat po skraćenici QAP koja dolazi od eng. Quadratic Assignment Problem, koja će često biti korištena i u ovom radu) formulirali su Koopmans i Beckman 957. godine prilikom rješavanja problema određivanja lokacija za skup tvornica uz minimizaciju ukupnih troškova toka materijala među tvornicama. Za razliku od linearnog problema pridruživanja, koji je rješiv u polinomijalnom vremenu, kod QAP-a je funkcija cilja kvadratična u svojim varijablama (odakle mu potječe i ime), te je nalaženje optimalnih rješenja puno teže. Jedan od glavnih razloga velikog interesa za kvadratični problem pridruživanja je činjenica da se mnogobrojni konkretni problemi iz područja diskretne optimizacije mogu svesti upravo na QAP. Na popisu tih problema se nalaze problemi iz područja raspoređivanja, proizvodnje, dizajna VLSI krugova, statističke analize i drugih. Pored toga se i neki poznati problemi iz kombinatorijalne optimizacije mogu formulirati kao kvadratični problem pridruživanja: npr. problem trgovačkog putnika i problem particioniranja grafa. Početna istraživanja koja su provodili istraživači s ciljem efikasnog rješavanja kvadratičnog problema pridruživanja su se svodila na reformuliranje QAP-a kao linearnog programa, čime su se dobijali veliki mješovito-cjelobrojni linearni problemi linearnog programiranja koji su bili neprikladni za rješavanje; odnosno, s obzirom na veliki broj cjelobrojnih varijabli pronalaženje optimalnih rješenja pomoću njih je bilo nemoguće. Međutim, takve formulacije QAP-a su se pokazale korisnima u teorijskim analizama, poglavito kod istraživanjima strukture kvadratičnog problema pridruživanja te kod implementacije algoritama grananja i ograđivanja pomoću kojih su se optimalno uspjele riješiti male instance problema (do veličine 20-25). Naime, kvadratični problem pridruživanja spada u klasu NP-teških problema, što njegovo optimalno rješavanje čini nemogućim za veće probleme. Osim te činjenice, značajno je još uočiti da je čak i pronalaženje približnih rješenja za QAP jako težak problem, što ga svrstava među najteže kombinatorijalne optimizacijske probleme. Međutim, QAP pokazuje zanimljivo asimptotsko ponašanje kad veličina problema teži u beskonačnost. Tada omjer između najbolje i najgore vrijednosti funkcije cilja teži prema jedan, što praktički znači da su sva pridruživanja jednako vrijedna s obzirom na funkciju cilja, što rješavanje problema čini trivijalnim. S druge strane, to svojstvo je više od teorijskog značaja budući da su realni problemi daleko od praga kada se manifestira ta pojava, te se kod njih mogu uočiti značajne razlike među rješenjima. S obzirom da su se egzaktne metode pokazale neprikladnima, primjenjene su heurističke metode rješavanja pomoću kojih se ipak uspjelo pronaći način za rješavanje većih problema. Istraživači su za rješavanje QAP-a primjenili gotovo sve poznate heurističke metode rješavanja kombinatorijalnih problema: algoritme lokalnog pretraživanja, genetičke algoritme, algoritme simuliranog kaljenja, tabu-search algoritme, pohlepne algoritme, 4

5 algoritme simuliranog skakanja (eng. simulated jumping) i algoritme bazirane na analogiji sa traženjem hrane kod mrava (eng. ant systems). Od navedenih vrsta algoritama, algoritmi lokalnog pretraživanja su se pokazali kao nedovoljno efikasni s obzirom na njihovu tendenciju da nađu rješenja koja predstavljaju lokalne minimume. Njihovo definiranje ipak nije bilo uzaludno budući da se mogu iskoristiti unutar ostalih heurističkih algoritama kao jedan njihov dio koji lokalno optimizira nađena rješenja. Upravo takvi, hibridni, algoritmi su se pokazalo kao najefikasniji način rješavanja kvadratičnog problema pridruživanja. Genetički algoritmi, koji oponašaju proces prirodne selekcije definirajući populaciju jedinki koja se primjenom križanja i mutacije pokušava poboljšati, su najčešći "korisnici" metoda lokalnih pretraživanja, te su se pokazali kao vrlo efikasan način rješavanja QAP-a. Tabu-search algoritmi, s druge strane, sami po sebi predstavljaju algoritam lokalnog pretraživanja s tom razlikom što imaju ugrađenu listu zabranjenih (eng. tabu) poteza čime se spriječava zaglavljivanje algoritma u lokalnom optimumu. Algoritmi simuliranog kaljenja se zasnivaju na analogiji između procesa preraspodjele molekula u materijalima prilikom njihovog hlađenja i procesa diskretne optimizacije, gdje se u oba slučaja može uočiti funkcija koja se tijekom procesa smanjuje (kod procesa kaljenja materijala to je temperatura, odnosno energija pojedinih molekula, a kod procesa optimiranja to je vrijednost funkcije cilja). Kao što je već rečeno, kvadratični problem pridruživanja se često pojavljuje u primjenama, a u ovom radu je prikazano rješavanje sličnog problema, problema rasporeda ispitnih rokova na Fakultetu elektrotehnike i računarstva. Naime, kod definiranja termina ispitnih rokova potrebno je uzeti u obzir činjenicu da na jednom ispitnom roku studenti uglavnom izlaze na više ispita, te je potrebno tako rasporediti termine održavanja kako bi se studentima što više olakšalo polaganje ispita. Kao glavni kriterij optimizacije se postavlja što manji presjek studenata na ispitima sa bliskim terminima održavanja, odnosno potrebno je tako rasporediti termine održavanja ispita da termini održavanja dva ispita za koje postoji veliki broj studenata koji mogu izaći na oba ispita, budu što udaljenija. Takvim definiranjem funkcije cilja problem postaje kvadratičan u svojim varijablama, te se mora riješavati heurističkim metodama. Za razliku od standardnog QAP-a, kod problema rasporeda ispita se ne radi o bijektivnom pridruživanju, tako da se i algoritmi za rješavanje moraju prilagoditi toj činjenici. 5

6 3. Općenito o problemu pridruživanja Problemi pridruživanja se bave pitanjem kako pridružiti n jedinki (poslovi, tvornice, radnici) na n drugih jedinki (strojevi, lokacije, zadaci). Kombinatorna struktura na kojoj se ti problemi zasnivaju je pridruživanje, koje je u stvari bijektivno preslikavanje φ između dva konačna skupa elemenata. Kod problema optimizacije tražimo najbolje pridruživanje; znači, ono koje optimizira neku zadanu funkciju cilja. Neka su V i W dva konačna skupa elemenata, V = { v, v 2,..., v n } i W = {w, w 2,..., w n }. Tada pridruživanje φ : V W koje svakom elementu iz skupa V pridružuje element iz skupa W možemo prikazati permutacijom φ skupa N = {, 2,..., n} gdje je elementu v i iz skupa V pridružen element w φ (i) iz skupa W. Drugi način na koji možemo prikazati pridruživanje je pomoću permutacijske matrice X φ = (x ij ) gdje je x ij = za j = φ(i) i x ij = 0 za j φ (i). Oba načina su prikazana, za isto pridruživanje, na slici, na kojoj je pridruživanje prikazano i kao bipartitni graf. φ = X φ 0 0 = Slika 3. : Različiti prikazi pridruživanja Lako je uočiti da postoji jedan-naprema-jedan ekvivalencija između skupa svih permutacija S n i skupa permutacijskih matrica, koja je definirana na sljedeći način: neka je X=(x ij ) matrica dimenzija n n. Ukoliko elementi matrice x ij zadovoljavaju sljedeće uvjete : x n i= n j= ij x x ij ij =, j n =, i n { 0,}, i, j n (3.) tada X nazivamo permutacijskom matricom. Skup svih permutacijskih matrica dimenzija n n označavamo sa Π n. Jedan-naprema-jedan korespodencija se realizira tako da se svakoj permutacijskoj matrici X=(x ij ) Π n pridruži permutacija π X S n, gdje je π X (i) = j ako i samo ako vrijedi x ij =. 6

7 Problem pridruživanja (ili slaganja) entiteta iz jednog skupa na entitete drugog skupa se pojavljuje u mnogim praktičnim problemima dizajna ili alokacije resursa. Ukoliko su pridruženi troškovi konstante za svako moguće sparivanje, tada se radi o klasičnom problemu pridruživanja, za koji su algoritmi rješavanja poznati već dugo vremena. S druge strane, ukoliko je struktura troškova složenija, tako da trošak određenog pridruživanja ovisi i o drugim sparivanjima, dolazimo do teških kombinatorijalnih problema, od kojih je kvadratični problem pridruživanja jedan od primjera. U daljnjem nastavku poglavlja će ukratko biti opisani neki problemi pridruživanja, poput linearnog problema pridruživanja i time-slot problema pridruživanja, a nakon toga će detaljnja pažnja biti posvećena kvadratičnom problemu pridruživanja. 3. Linearni problem pridruživanja Promotrimo sljedeći problem. Dano je n strojeva koje je potrebno rasporediti na n poslova, tako da ukupni trošak raspoređivanja bude minimalan, s time da je poznat trošak raspoređivanja svakog stroja na svaki pojedinačni posao. Tada problem možemo matematički formulirati kao: min x n i= j= n i= n j= ij x x n ij ij c uz ograničenja ij x = = ij j n i n { 0,} i, j n (3.2) gjde je C = (c ij ) matrica troška raspoređivanja i-tog elementa j-tu lokaciju. Uz korištenje simboličke notacije gdje φ označava permutaciju a c ij su koeficijenti troška, problem se može definirati i kao: min φ ( c c + + ) φ () + K (3.3) 2φ (2) c n φ ( n) Za rješavanje ovakvog problema pridruživanja je razvijen veliki broj algoritama, npr. primalno-dualni algoritmi, simpleks metode ili algoritmi sa relaksacijskim pristupom. Pregled metoda i raspoloživi računalni programi se mogu naći u Burkard i Çela []. Ovako definiran problem pridruživanja je moguće rješiti u polinomijalnom vremenu O(n 3 ), ali su razvijeni algoritmi sa očekivanim trajanjem O(n 2 log n) u slučaju nezavisnih i uniformno distribuiranih koeficijenata troška c ij unutar intervala [0,]. 7

8 Linearan problem pridruživanja se u praksi najčešće pojavljuje kao potproblem u složenijim problemima, primjerice u problemu trgovačkog putnika, problemu pridruživanja osoblja i slično. 3.. Linearni bottleneck problem pridruživanja Varijanta linearnog problema pridruživanja je takozvani linearni bottleneck problemi pridruživanja gdje ne minimiziramo ukupnu sumu (npr. ukupan trošak) već želimo minimizirati najveći trošak (minimax princip) neke odluke. Matematički se problem formulirao kao: min max φ i n ci φ ( i) (3.4) Uveli su ih Fulkerson, Glicksberg i Gross [2] kod rješavanja problema pridruživanja poslova paralelnim strojevima s ciljem minimizacije najdružeg vremena trajanja. Druga mogućnost primjene linearnog bottleneck problema pridruživanja se pojavljuje kod lociranja objekata u prostoru. Neka imamo n objekata koji se detektiraju pomoću dva senzora na različitim geografskim lokacijama. Svaki senzor mjeri kut pod kojim se vidi objekt, odnosno, svaki senzor definira n linija na kojima leže objekti. Tada je moguće naći lokaciju svakog objekta kao presjecište dviju linija iz senzora. Zbog mogućih grešaka u mjerenju, moguće je da se linije neće sjeći, te je potrebno naći najbolju aproksimaciju njihivog presjecišta. Ukoliko definiramo c ij kao najmanju udaljenost od i-te linije senzora do j-te linije senzora 2, tada rješavanjem linearnog bottleneck problema pridruživanja sa takvom matricom koeficijenata troška možemo dobiti vrlo dobre rezultate. 3.2 Time-slot problem pridruživanja Ovaj problem se javlja u području telekomunikacija kod korištenja tehnike TDMA (eng. time division multiple access) za reemitiranje podataka od zemaljske stanice preko satelita do druge zemaljske stanice. Kod primjene ovakve tehnike podaci za emitiranje se najprije spremaju u spremnik a nakon toga se šalju u vrlo kratkim impulsima k satelitu. Na satelitu podatke primaju transponderi koji ih dalje emitiraju prema prijemnoj zemaljskoj stanici. Transponderi povezuju stanicu koja šalje i stanicu koja prima podatke. Za zadani vremenski interval duljine λ k n stanica koje šalju podatke je povezano sa stanicama koje primaju podatke preko n transpondera na satelitu, odnosno, na snazi je određeni mod prespajanja (eng. switch mode). Matematički, mod prespajanja P k odgovara permutacijskoj matrici gdje vrijednosti u matrici određuju koja stanica je vezana na koji transponder. Nakon kratkog vremenskog intervala veze na satelitu se simultano mijenjaju i u sljedećem vremenskom intervalu novi 8

9 parovi prijemnih i odašiljnih stanica se povezuju preko transpondera, odnosno primjenjuje se novi mod povezivanja. Rješenje ovog problema podrazumijeva određivanje koji modovi povezivanja bi se trebali primjeniti i koliko dugo bi svaki trebao trajati kako bi se zadana količina podataka mogla reemitirati u najkraćem vremenskom roku. Ukoliko je zadana n n matrica prometa među prijemnim i odašiljnim stanicama T = (t ij ), gdje je t ij količina informacija koja se treba poslati od i-te prijemne stanice do j-te odašiljne, moramo odrediti modove prespajanja P k, k=, 2,... i nenegativne dužine trajanja λ k pripadnih vremenskih intervala kada se primjenjuju modovi prespajanja P k, tako da se svi podaci reemitiraju u najkraćem vremenskom roku. Problem se može formulirati kao sljedeći matematički model: min k λ uz ograničenja k λ p k k ij t ij, i, j n, (3.5) λ 0, k za svaki k Problem se može optimalno riješiti pomoću algoritma složenosti O(n 4 ) (vidjeti Burkard [0]) koji se zasniva na dekompoziciji matrice. Poznato je da se matrica T dekomponira u najviše n 2-2n+2 različita moda prespajanja. Međutim, kako se na satelitu nalazi otprilike 40 transpondera, to vodi na otprilike 600 prespajanja u vremenskom intervalu od 2 ms (koliko otprilike traje pojedini time-slot), a to je tehnički nemoguće izvesti. Zbog toga se, da bi rješenje bilo primjenjivo, broj prespajanja mora ograničiti. Međutim, tada time-slot problem pridruživanja uz dodatno ograničenje postaje NP-težak problem i mora se rješavati heurističkim metodama. 9

10 4. Kvadratični problem pridruživanja U ovom poglavlju je najprije definiran kvadratični problem pridruživanja te su navedni neki primjeri gdje se on javlja u primjenama. Nakon toga su navedene dvije različite formulacije problema, a navedna su i dva načina linearizacija QAP koji vode na mješovitocjelobrojne linearne programe. Na kraju je jedno podpoglavlje posvećeno pitanju složenosti kvadratičnog problema pridruživanja. 4. Motivacija Problem je sljedeći. Kao ulazni podaci su dane tri matrice: matrica toka između tvornica A = (a ij ), gdje je a ij tok materijala između tvornica i i j, matrica udaljenosti B = (b kl ), gdje je b kl udaljenost između lokacija k i l, te matrica C = (c ik ) koja predstavlja trošak postavljanja i-te tvornice na k-tu lokaciju. Potrebno je naći takav raspored tvornica po lokacijama kako bi ukupan trošak bio minimalan. Pridruživanje svih tvornica na određene lokacije se može prikazati permutacijom π S n, gdje je S n skup svih mogućih permutacija od N elemenata. Trošak istovremenog postavljanja tvornice π(i) na lokaciju i i tvornice π(j) na lokaciju j je dan sa a π(i)π(j) b ij. Ukupan trošak pridruživanja π svih tvornica je jednak min π S n n a b + c π ( i) π ( j) ij n i= j= i= n π ( i) i a cilj optimizacije je minimizirati ukupni trošak postavljanja i rada tvornica., (4.) Ovako definiran problem smještaja je motivirao Koopmansa i Beckmanna da 957. [3] uvedu kvadratični problem pridruživanja. Ostale primjene QAP-a u rješavanju problema smještaja su izveli Dickey i Hopkins [53], gdje se radilo o planiranju kampusa, te Elshafei [55], gdje se radilo o rasporedu bolničkih odjela. 4.2 Matematička formulacija Da bi matematički formulirali kvadratični problem pridruživanja definirajmo skup {, 2,..., n} i dvije matrice dimenzija n n, A = (a ij ) i B = (b ij ). Kvadratični problem pridruživanja sa matricama koeficijenata A i B, koji ćemo označavati sa QAP(A,B), se tada formulira kao : min n n π Sn i= j= a π ( i) π ( j) b ij, (4.2) 0

11 gdje je S n skup permutacija od {, 2,..., n}. Budući da vrijednost sume očito ovisi o matricama A i B, te permutaciji π, možemo formalizirati tu ovisnost označavanjem : Z n n ( A, B, ) = min aπ( i) π ( j) π S n i= j= π b. (4.3) Z(A,B,π) se naziva funkcija cilja (eng. objective function), a permutaciju π 0 koja minimizira danu funkciju nad skupom permutacija S n ćemo zvati optimalno rješenje. Dimenzija matrica A i B se naziva veličina problema. Ova formulacija QAP-a se još zove i Koopmans- Beckmannov QAP, prema istraživačima koji su ga prvi formulirali [3]. Ukoliko su matrice A i B simetrične, tada QAP(A,B) zovemo simetrični QAP; inače se radi o asimetričnom QAP-u. Općenitija definicija kvadratičnog problema pridruživanja koju je postavio Lawler[4] je dana sa min n n π Sn i= j= d π ( i) iπ ( j) j ij (4.4) gdje je D = d kilj 4-dimenzionalno polje realnih brojeva, i, j, k, l =,2,..., n. Ukoliko za elemente polja vrijedi d kilj = a kl b ij, za i, j, k, l n, očito je tada Lawlerov problem ekvivalentan formulaciji QAP-a (4.). Donekle drugačiji problem, koji se također naziva kvadratičnim problemom pridruživanja je sljedeći. Pored matrica A i B, definira se još jedna dodatna matrica C, čiji su članovi linearni koeficijenti u funkciji cilja : min π S min π S n n a b + c π ( i) π ( j) ij n i= j= i= n n d n + c π ( i) i π ( j) j n i= j= i= n π ( i) π ( i) i i, ili (4.5). (4.6) Navedene formulacije ćemo nazivati općeniti Koopmans-Beckmann QAP i općeniti Lawlerov QAP, respektivno. Ukoliko zamjenimo sume u funkciji cilja sa operacijom maksimuma, dobivamo takozvani kvadratični bottleneck problem pridruživanja (eng. quadratic bottleneck assignment problem BQAP), koji se (u Koopmans-Beckmannovom obliku) može formulirati kao min max a π i, j n ij b π ( i) π ( j), (4.7) Praktički svaki QAP model koji se pojavljuje u primjenama može se modelirati kao BQAP, i primjenjuje se kada umjesto ukupnog troška želimo minimizirati maksimalni trošak neke odluke.

12 U primjenama se javlja i takozvani bikvadratični problem pridruživanja (eng. skraćenica BiQAP) koji su uveli Burkard, Çela i Klinz u [5], a čije uvođenje je bilo motiviranom rješavanje optimizacije povezane sa dizajnom sinhronih sekvencijalnih VLSI krugova. BiQAP se matematički može formulirati na sljedeći način: min n π Sn i= j= k = l= n n n a π ( i) π ( j) π ( k ) π ( l) b ijkl (4.8) gdje S n predstavlja skup svih permutacija od {, 2,... n }, a A i B su četverodimenzionalna polja. Više o BiQAP-u, sa detaljnim referencama se može naći u sedmom poglavlju u []. Međutim, kvadratična ovisnost funkcije cilja i varijablama problema se javlja i kod niza drugim problema optimizacije, koji se međutim po svojoj podatkovnoj strukturi razlikuju od klasičnog QAP-a. Osnovni problem koji se pojavljuje predstavlja činjenica da se više ne mora raditi o bijektivnom pridruživanju, već skupovi V i W mogu imati različiti broj elemenata, u kojem slučaju se mijenja oblik rješenja i donekle sama funkcija cilja. Ovoj problematici će više prostora biti posvećeno u 7. poglavlju, gdje će QAP biti primjenjen na rješavanje problema rasporeda ispitnih rokova na fakultetu. 4.3 Primjene Kvadratični problem pridruživanja su uveli Koopmans i Beckmann 957. godine kao matematički model za rješavanje problema smještanja nedjeljivih ekonomskih aktivnosti (eng. facility location problem). Problem koji su rješavali se sastojao u smještanju n tvornica na n lokacija, gdje je trošak smještanja proporcionalan toku između dviju tvornica uz dodatni trošak postavljanja tvornice na određenu lokaciju, uz cilj optimizacije da se minimizira ukupan trošak. Od tada, kvadratični problem pridruživanja se primjenjuje kao model kod problema raspoređivanja, problema ožičenja u elektronici, paralelnog i distribuiranog računanja, dizajniranja tipkovnica, sportu, kemiji, proizvodnji računala. BQAP je prvi primjenio Steinberg [53] kod problema ožičenja pločice gdje je cilj bio minimizirati maksimalnu duljinu žica na pločici Primjena na problem ožičenja Kod problema ožičenja potrebno je postaviti određen broj modula na ploču. Moduli su u parovima povezani određenim brojem žica, i cilj je naći takav raspored modula na ploči da je ukupna duljina žica minimalna. Na potpuno ekvivalentan način, pridruživanje n modula na Engleska riječ facility (eng. a place built or set aside to provide a special service, World Book Dictionary) nema odgovarajući jednostavni prijevod u hrvatskom jeziku, te će se u daljnjem tekstu kao ekvivalent koristiti riječ uslužitelj. 2

13 n mjesta na ploči se može reprezentirati permutacijom π skupa {, 2,..., n}. Neka je broj žica koji povezuje module i i j dan sa a ij, a udaljenost među mjestima na ploči k i l neka je dana sa d ij, i, j, k, l n. Tada je duljina žica potrebna za povezivanje modula π(i) i π(j) koji su smješteni na mjesta i i j je dana sa a π(i) π(j) b ij, a ukupna duljina potrebnih žica je Z(A,B,π). Da bi se našao raspored koji minimizira ukupnu duljinu iskorištenih žica, potrebno je riješiti QAP(A,B), gdje je A = (a ij ) i B = (b ij ) Primjena na dizajn tipkovnice Burkard i Offerman [56] su pokazali da se QAP može primjeniti i na problem dizajniranja tipkovnice. Problem se definira na sljedeći način. Potrebno je rasporediti tipke na tipkovnici tako da se minimizira vrijeme potrebno za pisanje nekog teksta. Označimo sa N = {, 2,..., n} skup simbola koje je potrebno rasporediti. Neka a ij označava broj pojavljivanja parova simbola i i j. Koeficijenti u matrici udaljenosti b kl predstavljaju vrijeme koje je potrebno da se pritisne tipka na poziciji l nakon što je prije toga pritisnuta tipka na poziciji k. Permutacija φ S n predstavlja raspored simbola na tipke i optimalno rješenje se dobije kao rješenje QAP(A,B), gdje je A = (a ij ) i B = (b ij ). 4.4 Različite formulacije Pored formulacije kvadratičnog problema kako je ona definirana u (4.), koja se najčešće koristi zbog toga što najbolje izražava kombinatorijalnu strukturu QAP, moguće su i drugačije formulacije, čije prednosti dolaze do izražaja kod primjene tehnika poput cjelobrojnog ili mješovito-cjelobrojnog programiranja, te semidefinitnog programiranja. Dvije različite formulacije QAP-a koje će biti navedene su Koopmans-Beckmannova formulacija i trag-formulacija (eng. trace formulation). Koopmans-Beckmannova formulacija. Lako vidimo da je QAP(A,B) ekvivalentan sljedećem minimizacijskom problemu nad skupom permutacijskih matrica : min x n i= j= k = l= n i= n j= ij x x n ij ij n n uz ograničenja a ij b kl x ik =, j n =, i n x kj { 0,}, i, j n (4.9) 3

14 Ekvivalencija između definicija problema (4.) i (4.5) se najbolje može vidjeti u kontekstu primjene na problem smještaja. Naime, ukoliko je x ij = tada je tvornica i smještena na lokaciji j, inače je x ij = 0. Ograničenja u (4.5) formaliziraju činjenicu da se svaka tvornica smješta na samo jednu lokaciju, odnosno da se na svakoj lokaciji može nalaziti samo jedna tvornica. Član a ij b kl x ik x jl doprinosi funkciji cilja sa iznosom a ij b kl samo ukoliko je x ik = x jl =, odnosno, ukoliko je tvornica i smještena na lokaciji k a tvornica j smještena na lokaciji l. Trag formulacija. Druga ekvivalenta formulacija QAP se može izvesti koristeći notaciju permutacijskih matrica. Za instancu problema kvadratičnog pridruživanja QAP(A,B) veličine n, možemo definirati funkciju f A,B na skupu Π n permutacijskih matrica sa vrijednostima u R: t f Π R uz f ( X ) = tr( AXBX ) (4.0) A, B: n A, B gdje t označava transponiranu matricu, a tr(a) je trag 2 matrice A. Uz korištenje ove notacije, QAP(A,B) je ekvivalentan sljedećem minimizacijskom problemu na skupu permutacijskih matrica. min f, t ( X ) = min tr( AXBX ) (4.) A B X Π n X Π n Ovu formulaciju je uveo Edwards [27][28], a svoju primjenu nalazi kod izvođenja donjih granica pomoću svojstvenih vrijednosti. 4.5 Linearizacija QAP-a Budući da je funkcija cilja kod QAP-a kvadratična u svojim varijablama, teško je očekivati da će biti moguće naći efikasne metode za njegovo rješavanje. Jedan od prvih pristupa rješavanju QAP-a je bio linearizacija problema prilikom čega se kvadratični oblik funkcije cilja prevodi u linearni. Različiti autori su predlagali mnogobrojne linearizacije koje su se uglavnom svodile na mješovito-cjelobrojne linearne programe (eng. mixed-integer linear program MILP). Međutim, rješavanje QAPa pomoću tih lineariziranih problema je nemoguće unutar razumnih vremenskih granica, budući da sve linearizacije stvaraju MILP problem sa velikim brojem varijabli. Obimni popis referenci na različite linearizacije QAP se može naći u [22], a neke linearizacije su detaljno opisane u [24]. Ovdje ćemo opisati dvije linearizacije: linearizaciju po Kaufmanu i Broecxu [25], koja je jedna od "najmanjih" linearizacija ikad predloženih za QAP, te linearizacija po Friezeu i 2 Trag matrice A dimenzija n n se definira kao tr(a) = n a ii i=. 4

15 Yadegaru [26], koja predstavlja kamen temeljac za mnoge druge linearizacije koje vode ka najboljim donjim granicama za QAP Linearizacija po Kaufmanu i Broeckxu Kaufmann i Broeckx [25] su izveli formulaciju QAP-a kao MILP sa O(n 2 ) binarnih varijabli, O(n 2 ) realnih varijabli i O(n 2 ) ograničenja. Ova linearizacija je vjerojatno najmanja u smislu broja varijabli i broja ograničenja, međutim, čak i ona ima, za veliki n, veliki broj varijabli i ograničenja što je za rješavanje praktičnih problema čini neprikladnom. Da bi prikazali ovu linearizaciju, najprije je potrebno definirati realne varijable y ik pomoću y ik = x n n ik j= l= a ij b kl x jl (4.2) Uz pomoć ovako definiranih varijabli, funkciju cilja za QAP(A,B) opisan sa (4.7) možemo linearizirati : n n n n a b ij kl ik jl i= j= k = l= i= k = x x = n n y ik (4.3) Pored toga, uvesti ćemo još i konstante d ik, i, k n, sa d ik = n n j= l= a ij b kl (4.4) Tada se može pokazati da je QAP(A,B) koji je dan u (4.) ekvivalentan sa sljedećim mješovito-cjelobrojnim linearnim programom : min d x n i= k = n i= n k = ik ik x x n x ik ik ik y uz ograničenja ik = = + n j= l= a b x y d k n i n i, k n { 0, }, y 0, i, k n ik n ij kl jl ik ik (4.5) Dokaz se može naći u [24]. 5

16 Linearizacija po Friezeu i Yadegaru Frieze i Yadegar [26] su linearizirali QAP(A,B) tako što su uveli n 4 novih binarnih varijabli y ijkl pomoću : n l k j i za x x y jl ik ijkl =,,, (4.6) Uz pomoć ovih varijabli, Frieze i Yadegar su pokazali da je sljedeći mješovito-cjelobrojni linearni program ekvivalentan sa QAP(A,B) definiranim u (4.7). { } n l k j i y n k i x n k i x y n k j i x y n l j i x y n l k i x y n l k j x y n i x n k x y b a ijkl ik ik iikk ik n l ijkl jl n k ijkl ik n j ijkl jl n i ijkl n k ik n i ik n i n j n k n l ijkl kl ij = = = = = = = = = = = = = = = = =,,, 0, 0,,,,,,,,,, min ograničenja uz (4.7)

17 4.6 Složenost Sa stanovišta izračunavanja, QAP spada među najteže optimizacijske probleme. U ovome odjeljku će se raspraviti neki detalji vezani za složenost kvadratičnog problema pridruživanja. Pokazati će se da kvadratični problem pridruživanja spada u NP klasu problema. Također će se pokazati da QAP spada među najteže optimizacijske probleme budući da se čak i nalaženje približnog rješenja smatra teškim problemom Složenost optimalnog rješavanja QAP-a Ovdje su od ključnog značaja dva teorema koja su dokazali Sahni i Gonzalez [6] 976. godine. Teorem 4. Kvadratični problem pridruživanja je strogo NP-težak 3. Dokaz: Dokaz se sastoji u pokazivanju da bi postojanje algoritma koji se izvršava u polinomijalnom vremenu za rješavanje QAP-a kod kojega su elementi matrica iz skupa {0,, 2} povlačilo postojanje polinomijalnog algoritma za Hamiltonov problem, koji spada u skupinu NP-kompletnih problema. Po definiciji, to povlači da je QAP strogo NP-težak. Hamiltonov problem je definiran na sljedeći način: neka je zadan graf G=(V,E) gdje je V skup svih čvorova a E skup svih grana koje povezuju čvorove. Da li G sadrži Hamiltonov ciklus 4? Pretpostavimo da postoji algoritam koji bi se izvršavao u polinomijalnom vremenu za rješavanje QAP-a sa koeficijentima iz skupa {0,,2}. Uzmimo sada proizvoljnu instancu Hamiltonovog problema, odnosno tražimo Hamiltonov ciklus u prozvoljnom grafu G=(V,E). Neka je V = n, V={v, v 2,..., v n }. Definirajmo dvije matrice dimenzija n n, A=(a ij ) i B=(b ij ) na sljedeći način: a ij = ako ( vi, v j ) E 2 inače b ij = ako j = i +, i n ili i = n, j = 0 inače i promotrimo QAP(A,B). Lako se provjeri da je optimalna vrijednost od QAP(A,B) jednaka n ako i samo ako G sadrži Hamiltonov ciklus. Stoga možemo prevesti danu instancu Hamiltonovog problema u instancu QAP-a i primjeniti polinomijalni algoritam čije je postojanje pretpostavljeno. Nakon toga provjeravamo da li je nađeno rješenje jednako n. 3 NP-težak problem se definira kao problem koji se polinomijalnom transformacijom može svesti na problem iz NP-kompletne klase problema. Za detaljniju definiciju, vidjeti [2]. 4 Hamiltonov ciklus se za zadani graf G=(V,E) definira kao niz (v, v 2,..., v n ) različitih čvorova iz V takav da je {v i, v i+ } E za i < n i {v n, v } E. 7

18 Budući da se sve to može obaviti u polinomijalnom vremenu imali bi algoritam za rješavanje Hamiltonovog problema u polinomijalnom vremenu. Budući da je poznato da Hamiltonov problem spada u NP - klasu problema, dolazimo do kontradikcije i teorem je dokazan. Dodatno su Sahni i Gonzalez dokazali da je čak i nalaženje ε-aproksimativnog rješenja za kvadratični problem pridruživanja težak problem, u smislu da postojanje polinomijalnog ε- aproksimativnog algoritma povlači P = NP. Definicija. Za realni broj ε > 0, algoritam Υ za kvadratični problem pridruživanja nazivamo ε-aproksimativnim algoritmom ako i samo ako za svaku instancu QAP(A,B) vrijedi sljedeće: Z( A, B, π ) Z( A, B, π Υ Z( A, B, π opt ) opt ) ε (4.6) gdje je π Υ rješenje QAP(A,B) izračunato pomoću algoritma Υ a π opt je optimalno rješenje od QAP(A,B). Teorem 4.2 (Sahni i Gonzalez [6], 976) Za proizvoljni ε > 0, postojanje polinomijalnog ε-aproksimativnog algoritma za QAP povlači P = NP. Dokaz: Teorem se dokazuje tako da se pokaže da postojanje polinomijalnog ε- aproksimativnog algoritma za QAP povlači postojanje ε-aproksimativnog algoritma za problem nalaženja Hamiltonovog cikulsa, koji je NP-kompletan problem. Pretpostavimo da je Υ polinomijalni ε-aproksimativni algoritam za rješavanje QAP-a, za neki određeni ε. Koristeći algoritam Υ, možemo definirati polinomijalni algoritam za problem nalaženja Hamiltonovog ciklusa. Uzmimo instancu Hamiltonovog problema u proizvoljnom grafu G=(V,E) sa skupom čvorova V = {v, v 2,..., v n }. Konstruirajmo (u polinomijalnom vremenu) instancu QAP-a QAP(A,B) tako što ćemo definirati dvije matrice dimenzija n n A=(a ij ) i B=(b ij ) koje su definirane na sljedeći način: a ij = ω ako ( v, v ) E i j inače b ij = ako j = i +, i n ili i = n, j = 0 inače gdje je ϖ > + nε. Primjenimo algoritam Υ na QAP(A,B) i sa π Υ označimo rješenje dobiveno pomoću algoritma Υ a sa π OPT označimo optimalno rješenje od QAP(A,B). Nejednakost (4.6) sada povlači Z( A, B, π OPT ) Z( A, B, π Υ ) + ε Ova nejednakost pokazuje da ako je Z(A,B,π Y ) > n (+ε) tada Z(A,B,π OPT ) > n, i stoga G sadrži Hamiltonov ciklus. Suprotno, ako G ne sadrži Hamiltonov siklus, tada Z(A,B,π) n- 8

19 +ω > n (+ε), za svaki π S n. Stoga je Z(A,B,π Y ) > n (+ε). Dalje, problem Hamiltonovog ciklusa ima odgovor "da" ako i samo ako je Z(A,B,π OPT ) > n (+ε). Sada možemo formulirati naš polinomijalni algoritam za rješavanje Hamiltonovog problema u tri koraka. ) prevođenje instance Hamiltonovog problema u pripadni QAP problem 2) primjenjivanje algoritma Υ na instancu QAP-a 3) provjeravanje funkcije cilja Z(A,B,π Y ) za rješenje π Y koje je dao algoritam Υ Kako se sva tri koraka mogu obaviti u polinomijalnom vremenu, imamo kontradikciju sa činjenicom da se Hamiltonov problem ne može riješiti u polinomijalnom vremenu i teorem je dokazan. Budući da je uvriježeno mišljenje (iako nije dokazano) da je P NP, vrlo je malo vjerojatno da će se pronaći polinomijalni ε-aproksimativni algoritam za rješavanje kvadratičnog problema pridruživanja. Stoga se rješavanje QAP-a do optimalnosti ili nalaženje ε-aproksimativnog rješenja smatra vrlo teškim problemom. U usporedbi sa drugim teškim kombinatorijalnim problemima, QAP se pokazuje kao jedan od najtežih. Naime, poznato je da se problem putujućeg putnika (TSP od eng. traveling salesman problem) može formulirati kao kvadratični problem pridruživanja tako da je matrica A matrica udaljenosti među gradovima, dok je matrica B matrica susjednosti 5 za Hamiltonov ciklus na n čvorova. Za slučaj kada je matrica udaljenosti simetrična i zadovoljava nejednakost trokuta, TSP je rješiv u polinomijalnom vremenu [7]. Queyranne [8] je pokazao da, osim ako je P=NP, QAP(A,B) nije moguće aproksimirati u polinomijalnom vremenu unutar nekog konačnog aproksimativnog omjera, čak i ako je A matrica udaljenosti nekog skupa točaka na Euklidovoj liniji a B je blok dijagonalna simetrična matrica. Osim problem trgovačkog putnika, neki od poznatih problema koji se mogu svesti na QAP su: - problem particioniranja grafa - problem maksimalne klike u grafu Postoji nekoliko specijalnih slučajeva kada je QAP rješiv u polinomijalnom vremenu koje su istraživali Christofides i Gerrard [9]. Pokazali su da ako obe matrice A i B predstavljaju matrice susjednosti stabla, problem se može riješiti pomoću dinamičkog programiranja, u polinomijalnom vremenu. Ali, ukoliko je samo jedna od njih takva, problem je i dalje NPkompletan budući da se problem trgovačkog putnika može dovesti u takav oblik. 5 Matrica susjednosti (eng. adjacency matrix) za graf G=(V,E) sa skupom čvorova V = {v, v 2,..., v n } je takva matrica A dimenzija n n čiji su elementi definirani kao a ij = ako postoji direktna veza između čvorova i i j, odnosno a ij = 0 ukoliko takva veza ne postoji. 9

20 4.6.2 Složenost lokalnog pretraživanja Prilikom rješavanja problema iz područja kombinatorijalne optimizacije, a koji spadaju u grupu NP-kompletnih problema, pokazuje se da je nalaženje optimalnog rješenja moguće samo za probleme male veličine. Stoga se moramo zadovoljiti s rješenjem koje je "dobro" u određenom smislu, iako vjerojatno nije optimalno. Ovakav pristup vodi na metode takozvanog lokalnog pretraživanja gdje se ne traži globalno optimalno rješenje već se traži najbolje rješenje unutar nekog podskupa rješenja. Kod implementacije ovakvog pristupa, kreće se od slučajno odabranog mogućeg rješenja te se ono poboljšava tražeći bolja rješenja iz okoline trenutnog rješenja. Traženje se nastavlja sve dok se bolje rješenje više ne može naći. Evidentno je da će ovakav pristup uvijek rezultirati nalaženjem rješenja koje predstavlja lokalni optimum, s mogućnošću da nađeni lokalni optimum predstavlja i globalni optimum. Algoritmi lokalnog pretraživanja se mogu formalno opisati na sljedeći način. Promotrimo instancu optimizacijskog problema P definiranu osnovnim skupom ε, skupom mogućih rješenja F 2 ε i funkcijom troška c : ε. Funkcija troška c podrazumijeva funkciju cilja f : F definiranu kao f ( S) = c( x), za sve S F. Cilj je naći moguće rješenje koje minimizira ili maksimizira funkciju cilja. Pretpostavimo radi konkretnosti da je P minimizacijski problem i neka je S F moguće rješenje. Definirajmo skup N(S) F koji se sastoji od mogućih rješenja koju se "blizu" S. Takav skup N (S) se naziva okolina od S. Definiranjem okolina N (S) za sve S F dobivamo tzv. strukturu okoline {N (S) : S F }. Sada, umjesto da tražimo optimalno rješenje problema P, odnosno S * F takav da je x S f ( S * ) = min f ( S), tražimo lokalno optimalno rješenje (odnosno u našem slučaju lokalni minimum) od P, takvo da je _ f ( S) = S F min _ S N ( S ) f ( S) S _ F Očigledno je da je optimalnost nađenog rješenja u uskoj vezi sa odabirom okoline rješenja. Stoga, ukoliko se okoline N (S) zamijene sa novim okolinama N '(S), očekivano je da će se promijeniti rješenje. Sve što je rečeno za općeniti optimizacijski problem P se može primijeniti i na QAP. Da bi se moglo istražiti složenost metoda lokalnog pretraživanja, potrebno je najprije definirati strukturu okoline. Murthy, Pardalos i Li [20] su uveli jednu takvu strukturu okoline, a budući da je ta struktura okoline vrlo slična strukturi okoline koju su definirali Kerninghan i Lin za problem particije grafa, u literaturi se naziva K-L tip strukture okoline za QAP. K-L tip strukture okoline za QAP. Promotrimo QAP(A,B) i proizvoljnu permutaciju π 0 S n. Zamjena od π 0 je permutacija π S n dobivena iz π 0 primjenom transpozicije (i,j), π = π 0 (i,j). Transpozicija se definira kao permutacija koja preslikava i u j, j u i i k u k za sve k 20

21 {i,j}. Pohlepna zamjena permutacije π 0 je zamjena π koja minimizira razliku Z(A,B,π) Z(A,B, π 0 ) preko svih zamjena π od π 0 (znači pohlepna zamjena je ona zamjena nakon obavljanja koje ćemo dobiti minimalnu moguću funkciju cilja). Neka je sada π 0, π,..., π l skup permutacija iz S n, gdje je svaka od njih pohlepna zamjena prethodne. Takav niz se naziva monotonim ukoliko za svaki par permutacija π k, π t u nizu vrijedi {i k, j k } {i t, j t } =, gdje je π k (π t ) dobivena primjenom transpozicije (i k, j k ) (odnosno (i t, j t ) ) na prethodnu premutaciju u nizu. Okolina od π 0 se sastoji od svih permutacija koje se pojavljuju u (jedinstvenom) maksimalno monotonom nizu pohlepnih zamjena koje počinju sa permutacijom π 0. Označimo ovu strukturu okoline za QAP sa N K-L. Nije teško vidjeti da, za zadani QAP(A,B) veličine n i permutaciju π S n, kardinalnost skupa N K-L (π) ne prelazi n 2 +. Dodatna jednostavna i često korištena definicija strukture okoline u S n je takozvana okolina zamjena parova (eng. pair-exchange ili 2-opt) N 2. Okolina zamjena parova za dan permutaciju π 0 S n se sastoji od svih permutacija π S n dobivenih iz π 0 kada se primjeni neka transpozicija (i,j). Stoga, N 2 (π) = {(i,j) π : i j, i, j n} PLS-kompletnost i QAP Da bi se opisala složenost rješavanja kombinatornih optimizacijskih problema pomoću lokalnog pretraživanja, Johnson, Papadimitiou i Yannakakis [2] su definirali klasu PLSproblema (eng. polynomial-time local search problems) koja opisuje strukturu NP-problema na nivou mogućih rješenja i okolina. Problem P se nalazi u PLS ukoliko za svaku instancu x I (skup svih instanci), imamo skup mogućih rješenja F(x) takav da je lako odlučiti da li je s F(x) za neko rješenje s. Tada, uz dani x I, možemo producirati moguće rješenje s F(x) u polinomijalnom vremenu te nakon toga za dani x I i s F(x) možemo izračunati trošak C(s,x) od s u polinomijalnom vremenu. Dodatno, svako rješenje s F(x) ima skup okolnih rješenja N(s,x). I na kraju, za dani x I i s F(x), možemo provjeriti u polinomijalnom vremenu da li je s lokalno optimalno rješenje, i ako nije, proizvesti rješenje koje pripada u N(s,x) sa boljom vrijednošću troška (rješenje je lokalno optimalno ukoliko ne postoji strogo bolje susjedno rješenje). Formalno, lokalni problem pretraživanja P u PLS se definira kako sljedi: Za dani ulaz x, nađi lokalno optimalno rješenje s F(x). Za problem P, sljedeća tri algoritma sa polinomijalnim vremenom izvršavanja moraju postojati: i) Algoritam A, koji za ulaz x I, izračunava početno moguće rješenje s 0 F(x) ii) iii) Algoritam B, za ulaz x I i s F(x) izračunava C(s,x) Algoritam C, za ulaz x I i s F(x), ustanovljava da li je s lokalno optimalno rješenje ili ako nije, nalazi bolje rješenje iz N(s,x). 2

22 Problem P PLS je PLS-reducibilan na drugi probleme Q PLS ukoliko postoje funkcije f i g sa polinomijalnim vremenom izračunavanja, takve da f preslikava instancu x od P u instancu f(x) od Q i za svako lokalno optimalno rješenje s od f(x), g(s,x) producira lokalno optimalno rješenje od x. Problem P iz PLS je PLS-kompletan ukoliko je svaki drugi problem u PLS PLS-reducibilan na P. Sada imamo sljedeći teorem. Teorem 4.3 (Pardalos, Rendl i Wolkowicz [22], 994) Lokalni problem pretraživanja (QAP, N K-L ), gdje je N K-L Kerninghan-Lin tip strukture okoline za QAP, je PLS-kompletan. Teorem se dokazuje redukcijom sa problema particioniranja grafa, sa Kerninghan-Lin sturkturom okoline. Najprije se dokazuje da je QAP u PLS, što je lako provjeriti budući da se generiranje mogućeg rješenja QAP i izračunavanje pripadne vrijednosti funkcije cilja može obaviti u polinomijalnom vremenu. Također, možemo u polinomijalnom vremenu ustanoviti da li je dana permutacija π lokalni minimum, i ukoliko nije, generirati bolju permutaciju među n njezinih 2 + susjeda. Da bi se dokazala PLS-kompletnost, još se mora pokazati da je problem particioniranja grafa PLS-reducibilan na QAP. Za taj dokaz, vidjeti [22] Asimptotsko ponašanje Zanimljivo svojstvo kvadratičnog problema pridruživanja je da sa povećanjem veličine problema, razlika između najgoreg i optimalnog rješenja postaje mala, odnosno, omjer najgoreg i najboljeg rješenja teži u kad veličina problema teži u beksonačnost. S obzirom da se QAP smatra vrlo teškim problemom, ovakvo ponašanje je donekle iznenađujuće. To znači da relativna greška bilo koje heurističke metode iščezava s povećanjem veličine problema, odnosno, svaka metoda će gotovo sigurno naći optimalno rješenje kada se primjeni na instance QAP-a dovoljne veličine. Stoga, za takve probleme rješavanje QAP-a postaje trivijalno. Za detaljniju analizu ovog aspekta kvadratičnog problema pridruživanja vidjeti Burkard i Fincke [23]. 22

23 5. Načini rješavanja U ovom poglavlju će biti dani opisi različitih načina rješavanja kvadratičnog problema pridruživanja. Prvo potpoglavlje je posvećeno opisu egzaktnih algoritama rješavanja, pomoću kojih se mogu izračunati optimalna rješanja QAP-a, i među koje spadaju dinamičko programiranje, metode presječne ravnine (eng. cutting-plane) i metode grananja i ograđivanja. Međutim, optimalno rješavanje kvadratičnog problema pridruživanja je nemoguće za veličine problema veće od 20, te se mora pribjeći različitim heurističkim metodama koje su obrađene u drugom dijelu poglavlja. 5. Egzaktni algoritmi za rješavanje Egzaktne metode rješavanja QAP-a uključuju dinamičko programiranje, metode presječne ravnine i metode grananja i ograđivanja. Od ove tri metode, metoda grananja i ograđivanja se pokazuje kao najkvalitetnija. Međutim, čak i korištenjem te metode problemi veličine veće od 20 se teško rješavaju zbog nedostatka algoritama za izračunavanje dobrih donjih granica za probleme srednje i velike veličine. Metode presječne ravnine su uveli Bazaraa i Sherali [29] (gdje se može vidjeti i detaljni opis algoritma). Iako se prilikom izračunavanja nisu pokazale kao zadovoljavajuće, pokazalo se da se takve metode mogu iskoristiti za nalaženje dobrih suboptimalnih rješenja. Christofides i Benavent [30] su iskoristili pristup pomoću dinamičkog programiranja za posebnu klasu QAP-a kod kojih matrica toka predstavlja matricu susjednosti stabla, te su uspješno riješili probleme do veličine Metoda grananja i ograđivanja Metoda grananja i ograđivanja je općenita metoda za rješavanje kombinatornih problema optimizacije. Za rješavanje kvadratičnog problema pridruživanja postojeći algoritmi se mogu podijeliti u tri skupine: - metode jednostrukog pridruživanja (eng. single assignment algorithms) - metode pridruživanja u paru (eng. pair assignment algorithms) - metode relativnog pozicioniranja (eng. relative positioning algorithm) Sve tri metode kreću od prazne permutacije te je tijekom izvršavanja algoritma proširuju do potpune permutacije. Metodu jednostrukog pridruživanja je razvio Gilmore [3]. Algoritmi koji spadaju u ovu grupu pridružuju jednog uslužitelja (koji još nije pridružen), označimo ga sa i, na neku još 23

24 nezauzetu lokaciju, označimo je sa j, u svakom koraku grananja. Izbor indeksa (i,j) se definira na osnovu izbornog pravila i uglavnom ovisi o odabranoj tehnici ograđivanja. Budući da gotovo sve tehnike ograđivanja na kraju završe rješavanjem linearnog problema pridruživanja, izbog para (i,j) se često bazira na tzv. alternativnim troškovima p ij koji su dani sa p ij { c : k j, k n } + min{ c : k i, k n} = min (5.) ik gdje koeficijenti c ij predstavljaju reduciran trošak zadnjeg linearnog problema pridruživanja koji je riješen prilikom izračunavanja trenutne donje granice. Alternativni trošak p ij predstavlja donju granicu za povećanje trenutne donje granice, u slučaju da se trenutna permutacija proširi pridruživanjem uslužitelja i na lokaciju j. Metodu pridruživanja u paru su razvili Gavett i Plyter [32] kod koje se u svakom koraku grananja se par uslužitelja pridružuje na par lokacija. Međutim, numerička izračunavanja su pokazala da ovaj pristup ne daje dobre rezultate. Zadnji algoritam, metedu relativnog pozicioniranja su razvili Mirchandani i Obata [33] i kod tog pristupa, nivoi stabla grananja i pretraživanja ne odgovaraju pridruživanjima uslužitelja na lokacije, već se parcijalne permutacije na svakom nivou određuju u odnosu na udaljenosti među uslužiteljima, odnosno njihovim relativnim pozicijama. Numerički eksperimenti pokazuju da među navedena tri tipa algoritma grananja i pretraživanja, metoda jednostrukog pridruživanja daje najbolje rezultate, dok se metoda relativnog pozicioniranja eventualno može koristiti kod problema sa rijetko popunjenim matricama. kj 5..2 Izračunavanje donje granice Dobar algoritam za izračunavanje donje granice predstavlja ključnu stvar za uspjeh metode grananja i ograđivanja kod primjene na probleme kombinatorijalne optimizacije. Idealne donje granice bi trebale biti oštre i brze za izračunavanje. Za kvadratični problem pridruživanja metode za izračunavanje donje granice možemo podijeliti u tri skupine. U prvoj su klasična Gilmore-Lawlerova granica (GLB). U drugu skupinu spadaju metode zasnovane na izračunavanju svojstvenih vrijednosti, dok su zadnju skupinu spadaju metode koje se zasnivaju na reformulacijama QAP-a i općenito podrazumijevaju rješavanje određenog broja linearnih problema pridruživanja Gilmore-Lawlerova donja granica Gilmore-Lawlerova granica se izračunava korištenjem minimalnog i maksimalnog vektorskog produkta, koje označavamo sa x, y i x, y, a koji se definira kako slijedi + x, y = min x, Py, x, y max x, Py (5.2) = P Π + P Π 24

25 gdje skup Π označava skup svih permutacija od N i x,y R n. U stvari, x, y se može izračunati kao skalarni produkt od x + i y, gdje je x + dobiven uređivanjem komponenata od x u uzlaznom poretku, a y je dobiven uređivanjem komponenata od y u silaznom poretku. x, y se može izračunati na sličan način. + Neka su a i, b i, i=,..., n vektori redaka matrica A i B, respektivno. Neka je â i vektor koji se sastoji od (n-) komponenti vektora a i, isključujući a ii i neka je b i vektor koji se sastoji od (n-) komponenti vektora b i isključujući b ii. Sada definirajmo matricu L = (l ij ) kao lij = aii b jj + a i, b j, i, j =,..., n Tada se GLB(A,B), čime označavamo Gilmore-Lawlerovu donju granicu za QAP(A,B), definira kao rješenje linearnog problema pridruživanja sa matricom troška jednakom L, odnosno n P Π i= (5.3) GLB( A, B) = min l. (5.4) Složenost izračunavanja GL granice je O(n 3 ), budući da je to složenost rješavanja linearnog problema pridruživanja, a složenost izračunavaja matrice troška L je također O(n 3 ). Za detaljniju diskusiju Gilmore-Lawlerove granice, vidjeti []. ip( i) Donja granica izračunata pomoću svojstvenih vrijednosti Granice zasnovane na svojstvenim vrijednostima za kvadratični problem pridruživanja su zasnovane na vezi između vrijednosti funkcije cilja u trag formulaciji i svojstvenih vrijednosti matrica koeficijenata. Ove metode izračunavanja granica se mogu primjeniti samo na Koopmans-Beckmannon QAP, a ne i na Lawlerov QAP. U odnosu na Gilmore-Lawlerovu granicu, ova metoda daje dobre granice. Međutim, izračunavanje je vremenski dosta zahtjevno te stoga nisu prikladne kao osnovne metode izračunavanja granica u algoritmima grananja i pretraživanja. Od primarne važnosti je sljedeći teorem. Teorem 5. Neka su A i B simetrične matrice, i neka su λ, λ 2,..., λ n svojstvene vrijednosti od A, a µ, µ 2,..., µ n svojstvene vrijednosti od B. Tada vrijedi da za bilo koji p Π n i= i n n n n i+ aijb p( i) p( j) λi µ i i= j= i= λ µ. (5.5) Linearni dio QAP je moguće točno ograničiti rješavanjem linearnog problema pridruživanja, kojeg ćemo označiti sa LAP(C). Tada dobivamo sljedeću granicu za QAP EVB n { A, B} µ LAP( ) = λ i n i+ + C. (5.6) i= 25

26 Ostale metode izračunavanja donje granice Pored dvije navedene metode za izračunavanje donjih granica, postoje još i metode zasnovane na reformulacijama QAP, zatim metode bazirane na relaksiranim linearnim programima te metode zasnovane na semidefinitnim relaksacijama. Autori Godina Veličina Gilmore Lawler Gavett i Plyter Burkard Bazaraa i Sherali Burkard i Derigs Bazaraa i Kirca Roucairol Pardalos i Crouse Mautor i Roucairol Clause i Perregaard Bruenegger i drugi Tablica 5. Tablica problema rješenih do optimalnosti pomoću metode grananja i ograđivanja (preuzeto iz []) 26

27 5.2 Heuristički algoritmi za rješavanje Budući da su egzaktni algoritmi za rješavanje kvadratičnog problema pridruživanja neprikladni za instance sa n > 20, jedina mogućnost je da se problem pokuša riješiti heurističkim algoritmima. Međutim, kod primjene heurističkih metoda, nemoguće je dokazati optimalnost rješenja, te se kvaliteta rješenja mora procijeniti iskustveno, ili u usporedbi sa rješenjima koja su dobivena nekim drugim metodama. Princip rada heurističkih algoritama je sljedeći. Naajprije je potrebno definirati prostor rješenja (koji se često naziva i konfiguracijski prostor) za dani problem. Zatim se odabire početno rješenje te se nakon toga prostor rješenja pretražuje u potrazi da sve boljim i boljim rješenjima. Razlika među heurističkim algoritmima je u tome na koji način obavljaju to pretraživanje. Najelementarniji pristup je metoda najbržeg spusta (eng. steepest descent method) koja iz zadane početne točke u prostoru rješenja (početno rješenje od kojeg kreće pretraživanje) kreće u smjeru najbržeg smanjivanja funkcije cilja (ukoliko se radi o problemu minimizacije) dok ne dođe do minimuma funkcije. Međutim, ta metoda je izrazito neprikladna ukoliko imamo višedimenzionalni konfiguracijski prostor (što je gotovo uvijek slučaj kod složenijih kombinatorijalnih optimizacijskih problema), budući da ona nalazi rješenje koje predstavlja lokalni minimum. U analogiji sa dinamičkim sustavima, lokalni minimumi u konfiguracijskom prostoru predstavljaju atraktore sistema za metodu najbržeg spusta, odnosno fiksne točke. Stoga je kod efikasne metode pretraživanja konfiguracijskog prostora potrebno naći način kojim bi algoritam izašao iz lokalnog minimuma i nastavio pretraživanje konfiguracijskog prostora u potrazi za boljim rješenjima, odnosno globalnim minimumom. Najpoznatiji algoritmi koji imaju ugrađen u sebi taj mehanizam su: - tabu-search algoritmi, koji korištenjem liste zabranjenih poteza spriječavaju zaglavljivanje u lokalnom minimumu - simulirano kaljenje, kod kojeg se s određenom vjerojatnošću prihvaćaju i pomaci u prostoru stanja koji će rezultirati povećanjem funkcije cilja - genetički algoritmi koji primjenom operatora križanja i mutacije nad reprezentacijama rješenja pretražuju prostor stanja Međutim, čak i ukoliko se spriječi zaglavljivanje algoritma u nekoj od fiksnih točaka sutava, i dalje postoji mogućnost da će se pojaviti granično kolo (eng. limit cycle) koje predstavlja zatvorenu putanju u konfiguracijskom prostoru stanja kroz koje algoritam stalno prolazi. Tabu-search metode su eksplicitno definirane kako bi se spriječilo pojavljivanje takvih zatvorenih putanja, jer će lista zabranjenih poteza spriječiti ponavljanje određene sekvence pomaka u prostoru stanja. 27

28 Nažalost, postoji i treća mogućnost, a to je pojava kaotičnog atraktora (eng. chaotic attractor) gdje je pretraživanje ograničeno na određeni dio konfiguracijskog prostora, bez pojavljivanja fiksnih točaka ili graničnih kola. Stoga, iako algoritam ne zaglavljuje u određenoj točki (kao kod pojavljivanja fiksne točke) niti stalno prolazi kroz određeni skup stanja (kao kod graničnog kola), ipak je pretraživanje ograničeno na određeni dio skupa rješenja, te se globalni optimum neće naći, osim ukoliko se ne nalazi unutar tog skupa. Prepoznavanje pojavljivanja kaotičnog atraktora, i nalaženje načina za izbjegavanje, je stoga od velike važnosti kod implementacije heurističkih algoritama. U ovom potpoglavlju će biti definirane osnovne metode za rješavanje kvadratičnog problema pridruživanja pomoću heurističkih algoritama. Na početku su prikazane elementarne metode u koje spadaju metode izgradnje, metode ograničenog prebrojavanja i metode poboljšavanja. Nakon toga su opisani pametniji algoritmi: tabu-search (koji bi se također moglo klasificirati kao pametniju metodu poboljšavanja), simulirano kaljenje, genetički algoritam i GRASP-algoritam Metode izgradnje Metode izgradnje pripadaju među najjednostavnije metode rješavanja QAP-a, ali je sukladno tome i kvaliteta rješenja vrlo loša. Sve metode izgradnje se baziraju na jednostavnom principu koji se može ukratko opisati na sljedeći način. Uvijek se kreće od praznog rješenja (permutacije), znači rješenja gdje nijednoj jedinki nije dodijeljena pripadna lokacija, i zatim se lokacije rekurzivno dodjeljuju jedinkama po nekom definiranom kriteriju. Ove metode spadaju među najstarije, a primjenio ih je već u 60-tima Gilmore [3]. Nešto poboljšanu verziju je predložio Burkard [34], a metodu koja u usporedbi sa drugim metodama izgradnje daje bolja rješenja predložio je Muller-Merbach [35]. Ta metoda se naziva metoda povećavanja stupnja slobode. Kod implementacije ovog postupka, kreće se od prazne permutacije koja se preko parcijalnih permutacija točno određenim redoslijedom koraka popunjava do pune permutacije. Parcijalna permutacija od {,2,..., n} je injektivno preslikavanje podskupa X {,2,...,n} na {,2,...,n}, π:x {,2,...,n}, gdje je X {,2,...,n}. Prilikom pokretanja postupka, definira se točno određeni redoslijed indeksa r, r 2,..., r n gdje je n veličina problema. Neka je π : M π {,2,...,n} trenutna parcijalna permutacija, gdje je M π = {r, r 2,..., r k- }. Novu permutacija π': M π' {,2,...,n} se konstruira sa M π' = M π {r k }, gdje je r k prvi nepridruženi indeks iz skupa {r, r 2,..., r n }. Permutacija π' se konsturira na sljedeći način. Najprije se r k pridruži nekom j π(m π ) te se izračuna pripadno povećanje iznosa funkcije cilja Z j. Nakon toga se promotre pridruživanja gdje se indeks r k pridružuje na neku od lokacija koje su već zauzete, dok se onaj uslužitelj koji je bio pridružen toj lokaciji stavlja na neku od nepopunjenih lokacija. Formalno, r k se pridružuje u j π(m π ). Definirajmo r i {r, r 2,..., r n } takav da je π(r i ) = j i označimo sa Z jl promjenu funkcije cilja kada se r k pridruži j te r i pridruži u l, gdje l π(m π ). Između ovih k(n-k+) mogućnosti za konstruiranje π' se 28

29 odabire ona koja postiže najmanji porast funkcije cilja. Postupak se ponavlja sve dok se svi uslužitelji ne pridruže na neke lokacije. Usprkos poboljšanju algoritma, metode izgradnje daju vrlo loša rješenja. Međutim, implementacija pripadnih algoritama je vrlo jednostavna a i zahtjevi na računarske resurse su mali. Stoga se metode izgradnje mogu upotrijebiti kao dio nekog boljeg algoritma za rješavanje QAP-a Metode ograničenog prebrojavanja Metode ograničenog prebrojavanja su povezane sa egzaktnim metodama poput metode grananja i ograđivanja, ili metode presječne ravnine. Ove metodu se baziraju na činjenici da se dobro rješenja pripadnog problema, znači rješenje koje je optimalno ili vrlo blizu optimalnome često nađe vrlo rano u postupku traženja dok se ostatak vremena troši ili na vrlo malo poboljšanje vrijednosti funkcije cilja ili na dokazivanje da je nađeno rješenje stvarno optimalno. Kod metoda ograničenog prebrojavanja primjenjuju se dva pristupa. Prvi pristup je da se nametnu vremenske granice. Znači, nakon što postupak traje određeno vrijeme ili nakon što prođe određeni interval da se rješenje nije poboljšalo, optimizacija se zaustavlja. Drugi pristup je da se povećavaju donje granice u čvorovima koji još nisu razgranati, nakon što je zadovoljen određeni kriterij. Na primjer, ako nakon nekog određenog vremena nije nađeno poboljšanje rješenja, donje granice se povećavaju za određeni postotak Metode poboljšavanja Metode poboljšavanja rješenja imaju široku primjenu u raznim problemima kombinatorne optimizacije, i one spadaju u širu klasu algoritama poznatih pod nazivom algoritmi lokalnog pretraživanja ( local search ). Algoritmi lokalnog pretraživanja počinju svoj rad sa početnim mogućim rješenjem i u nastavku optimizacije ga pokušavaju poboljšati sa nekim rješenjem iz okoline trenutnog rješenja. Taj postupak se iterativno ponavlja sve dok se više rješenje ne može poboljšati. Da bi se postupak mogao provoditi, nužno je definirati pojam okoline rješenja. Kod kvadratičnog problema pridruživanja, najčešće se koristi okolina definirana sa svim izmjenama parova (eng. pair-exchange neighborhood ) ili okolina definirana sa svim cikličkim trostrukim izmjenama (eng. cyclic triple-exchange neighborhood ). Kod okoline definirane zamjenom parova, okolina je definirana kao skup svih permutacija koje se iz trenutne mogu dobiti primjenom transpozicije, odnosno zamjenom dva n člana u permutaciji. Očito je da je kardinalnost skupa svih mogućih zamjena dana sa. 2 Pretraživanje cijele okoline je u tom slučaju složenosti O(n 3 ) budući da je veličina okoline 29

30 O(n 2 ) a izračunavanje funkcije cilja Z(A,B,π') za element π' iz okoline od π može se obaviti u O(n) vremenu, kada je poznata vrijednost Z(A,B,π). Kod korištenja okoline definirane cikličkim trostrukim izmjenama, okolina rješenja π se sastoji od svih permutacija dobivenih iz π pomoću ciklične zamjene tri indeksa. Primjerice, ukoliko su tri indeksa koje treba zamjeniti dana sa (i,j,k), nove dvije permutacije π' i π'' dobijamo iz stare permutacije π kako slijedi : { i, j, k} π ( x) x { i, j, k} π ( x) x π ( k) x = i π ( j) x = i π '( x) = π ''( x) = (5.7) π ( i) x = j π ( k) x = j π ( j) x = k π ( i) x = k Veličina okoline je 2 n. S obzirom na povećanje veličine okoline, jasno je da dolazi i do 3 usporenja postupka. Međutim, iskustva pokazuju da korištenje ove definicije okoline ne dovodi do boljih rezultata u odnosu na okolinu definiranu sa izmjenom u paru. Pored definicije okoline, za korištenje metode poboljšanja potrebno je definirati i redoslijed pretraživanja okoline, a nakon toga je potrebno odrediti način na koji će se poboljšavati trenutno moguće rješenje. U slučaju korištenja okoline definirane zamjenom parova, sljedeće tri metode se najčešće koriste : metoda prvog poboljšanja metoda najboljeg poboljšanja Heiderova metoda [36] Kod metode prvog poboljšanja uzima se kao novo rješenja prvo rješenje iz okoline koje predstavlja poboljšanje trenutnog rješenja. Kod korištenja metode najboljeg poboljšanja pretražuje se cijela okolina i uzima se najbolje nađeno rješenje. Kod Heiderove metode okolina se pretražuje u zadanom cikličkom redoslijedu. Čim se nađe element u okolini koji poboljšava rješenje uzima ga se kao novo rješenje, ali za razliku od metode prvog poboljšanja, ne kreće se iznova sa pretraživanjem okoline, već se ciklički nastavlja pretraživanje okoline redoslijedom transpozicija koji je bio zadan, znači slijedeća transpozicija koja će se primjeniti je sljedbenik one koja je pronašla poboljšanje rješenja. Da bi se pronašla bolja rješenja potrebno je algoritme za lokalno pretraživanje pokretati više puta sa različitim početnim rješenjima. Često se metode poboljšavanja koriste u sprezi sa metodama za izgradnju tako da se najprije pomoću metode za izgradnju rješenja generira početno moguće rješenje a zatim ga se pokuša popraviti sa algoritmom za lokalno pretraživanje. Međutim, kako su pokazali numerički eksperimenti koje je proveo Bruijs [37], pokretanje postupka lokalnog pretraživanja iz dobrog početno rješenja ne utječe značajno na poboljšanje nađenih rješenja pomoću postupka lokalnog pretraživanja. 30

31 5.2.4 Tabu search Tabu search je heuristička metoda koja spada u grupu metoda lokalnog pretraživanjaa i koja je primjenjiva kod rješavanja mnogih problema kombinatorijalne optimizacije. Tabu search metodu je predložio Glover [38] [39], kao način da se riješi problem zaglavljivanja postupaka optimizacije u lokalnom optimumu kod algoritama koji rade na principu lokalnog pretraživanja. Detaljan opis tabu searcha i njegove primjene na razne probleme optimizacije može se naći u [40]. Kod implementacije tabu search algoritma posebnu je pažnju potrebno posvetiti definiranju strukture okoline rješenja i sa tim usko povezanim problemom definiranja poteza (moves). Također je potrebno definiranje liste zabranjenih poteza (eng. taboo list) i definiranje aspiracijskog kriterija. Općenito, tabu search algoritam radi kako slijedi: u svakoj iteraciji algoritma se izračunavaju promjene vrijednosti funkcije cilja za sve moguće poteze iz okoline trenutnog rješenja, i odabire se najbolji potez (moguće je da čak i najbolji potez ne poboljšava funkciju cilja; npr. ukoliko se trenutno nalazimo u lokalnom optimumu, svi potezi pogoršavaju funkciju cilja). Očito je da se kod ovakve optimizacijske procedure mogu pojaviti ciklička kruženja poteza, odnosno, dolazi do situacije da se određeni slijed poteza stalno ponavlja (npr. ukoliko smo iteraciju ranije bili u lokalnom minimumu i nakon što je algoritam odabrao potez koji ga je najmanje udaljio od lokalnog minimuma, sljedeći najbolji potez evidentno nas opet vraća u taj isti lokalni minimum). Kako se to ne bi dogodilo, uvodi se lista zabranjenih poteza koja definira poteze koji nisu dopušteni. Ta lista je najčešće realizirana na principu FIFO (skraćenica od eng. first in first out). Kako se koji potez prihvati, stavlja ga se u tabu listu te taj potez kroz određeni broj iteracija nije dopušteno izvoditi, čime će se spriječiti cikličko ponavljanje poteza. Naravno, potrebno je da tabu lista bude odgovarajuće veličine. Međutim, budući da se u listu spremaju samo potezi, a ne i cjelokupni kontekst u kojem je taj potez zabranjen, moguće je da zabranjivanje tog poteza, nakon što se algoritam nađe u nekom drugom rješenju, spriječi istraživanje moguće zanimljivih rješenja kojima bi taj potez vodio. Stoga se uvodi i aspiracijska funkcija pomoću koje se poništava tabu status nekog poteza i omogućava da se on prihvati iako se nalazi u listi zabranjenih poteza. Primjerice, aspiracijska funkcija može vraćati vrijednost istina (potez zadovoljava aspiracijsku funkciju) ukoliko taj potez vodi ka rješenju koje je bolje od dosada pronađenog. Pseudo kod za implementaciju tabu-search algoritma izgleda ovako: Function TabooSearch InitializeTabooList(); GenerateRandomSolution(); do selected_move = empty; do move = FindBestMove(); if ( IsTabooMove(move) == true && Aspiration(move) == false ) continue; 3

32 else selected_move = move; while (selected_move == empty); while (EndCriterion!= true); EndFunction; Potezi Tabu search-a Prirodan tip poteza kod kvadratičnog problema pridruživanja je već prije definirani potez (odjeljak metoda zamjene parova) koji zamjenjuje lokacije dviju jedinki. Ukoliko krećemo iz permutacije π, permutacija π' iz okoline tog rješenja se dobija zamjenom jedinica i i j na sljedeći način: π '( k) = π ( k) π '( i) = π ( j) π '( j) = π ( i) k r, s (5.8) Ukoliko su matrice simetrične, promjena funkcije cilja za potez se može izračunati kao: φ (5.9) (, i, j) = ( a jj aii )( bφ ( i) φ ( i) bφ ( j) φ ( j) ) + 2 ( a jk aik ) ( bφ ( i) φ ( k ) bφ ( j) φ ( k ) ) k i, j Ukoliko matrice nisu simetrične, tada se može primjeniti općenit izraz za izračunavanje promjene funkcije cilja ( φ, i, j) = ( a + jj k N \ a ii (( a { i, j} )( b jk φ ( i) φ ( i) a ik b )( b φ ( j) φ ( j) φ ( i) φ ( k ) ) + b ( a ji φ ( j) φ ( k ) a ) + ij )( b ( a kj φ ( i) φ ( j) a ki b )( b φ ( j) φ ( i) φ ( k ) φ ( i) ) + b φ ( k ) φ ( j) )) (5.0) Lista zabranjenih poteza Kod definiranja liste zabranjenih poteza, raniji istraživači su primjenjivali dva pristupa. Prvi, koji je predložila Skorin-Kapov [4], sastoji se u tome da se zabranjuju potezi zamjene dvije jedinke koje su bile zamijenjene tijekom zadnjih s iteracija (s je kontrolni parametar koji definira veličinu tabu liste). Formalno se tabu lista sastoji od parova (i,j) jedinki koje ne mogu biti zamijenjene, a vrlo se jednostavno implementira pomoću simetrične matrice gdje element A[i][j] sadrži u sebi broj iteracije u kojoj će ponovno biti dopuštena zamjena ta dva elementa. Takav pristup je efikasan i vrlo brz jer se za ustanovljavanje statusa poteza troši samo jedna usporedba sa elementom dvodimenzionalnog polja. S druge strane, Taillard [42] je u svojoj implementaciji primjenio drugačiju tehniku gdje se za svaku jedinku i svaku lokaciju zapisuje zadnja iteracija kada je ta jedinka bila na toj lokaciji. Potez se proglašava tabu potezom ukoliko se njime obe jedinke dodjeljuje na lokacije koje su zauzimale unutar zadnjih s iteracija. Ovakav tip tabu poteza je vrlo sličan onom primjenjenom kod Skorin-Kapov, ali je zgodniji kod tabu liste koja je promjenjive veličine, što je i bila odlika Taillardove implementacije. 32

33 Veličina liste Kod tabu search algoritma, veličina liste zabranjenih poteza je od velike važnosti. Naime, ukoliko je lista premala, može doći do cikličkog ponavljanja poteza, dok u slučaju da je ona prevelika, zanimljivi potezi mogu biti odbačeni, što povećava broj iteracija potreban da se nađu kvalitetna rješenja. Prema dosadašnjim istraživanjima, veličina tabu liste ovisi o veličini problema koji se rješava i s njom stoji u proporcionalnom odnosu (što je veći problem, potrebna je i veća tabu lista). Međutim, pojavljivanje cikličkih ponavljanja poteza nije nužno u direktnoj vezi sa veličinom tabu liste. Naime, Taillard je u [42] objavio pojavljivanje cikličkih ponavljanja kod rješavanja s veličinom tabu liste jednakom 30, ali se ciklička ponavljanja nisu događala kada je veličina tabu liste bila unutar intervala [26,29]. Stoga je Taillard u tom radu predložio da veličina tabu liste ne bude konstantna već da se slučajno mijenja unutar nekog intervala sa određenom frekvencijom. Predloženi interval je bio [s min, s min + ], a frekvencija mijenjanja veličine je postavljena na svakih 2 s max (= s min + ) iteracija, kako bi postojala određena vjerojatnost da se obave iteracije sa s = s max Aspiracijska funkcija Namjena aspiracijske funkcije je da dopusti zanimljive poteze koji se nalaze u tabu listi, odnosno poteze koji su zabranjeni. Klasična implementacija aspiracijske funkcije poništava potezu tabu status ukoliko taj potez vodi do rješenja koje je bolje od dosada najboljeg pronađenog rješenja, i takva implementacija aspiracijske funkcije je korištena u [4] i [43]. Međutim, kako je primjećeno u [42] najbolja rješenja se često nisu mogla dobiti uz ovako jednostavnu aspiracijsku funkciju, te je predloženo da aspiracijska funkcija ne poklanja uopće pažnju vrijednosti funkcije cilja već da vrši ulogu diversifikacije rješenja na taj način da potez zadovoljavan aspiracijsku funkciju ukoliko dodjeljuje obe jedinke na lokacije koje one nisu okupirale unutar zadnjih t iteracija (gdje je t kontrolni parametar algoritma). Vrijednost t-a u toj implementaciji se kretala od 400 pa sve do 0000 za veće probleme Reaktivni tabu-search algoritam Kod opisa tabu search algoritam odmah upada u oči njegova ovisnost o određenom broju vanjskih parametara: veličina tabu liste, odabir aspiracijske funkcije. Da se izbjegnu takve ovisnosti, Battiti i Tecchiolli [43] su predložili modifikaciju tabu search algoritma, nazvanu reactive tabu search, kod koje se automatski obavljaju modifikacije parametara u potrazi za što boljim rješenjem. Kod implementacije ovog algoritma, pored standardnih elemenata tabu-search procedure, znači korištenje liste zabranjenih poteza, definira se automatizirani način prilagođavanja veličine liste zabranjenih problema u skladu sa trenutnim stanjem pretraživanja. Pored toga se definira i način diversifikacije pretraživanja kada standardni 33

34 mehanizam taub-search procedure zakaže. Reaktivni tabu-search algoritma se u praksi pokazao superiornijim, iako su zahtjevi na memorijske resurese puno veći budući da u sebi ima ugrađen mehanizam dugotrajne memorije koja se iskorištava za praćenje napredovanja algoritma, te uočavanje graničnih kola i kaotičnih atraktora Simulirano kaljenje Postupak simuliranog kaljenja se zasniva na interesantnoj analogiji između problema kombinatorijalne optimizacije i statističke mehanike koju su prvi uočili Kirkpatrick, Gelatti i Vecchi [44]. Termin kaljenje se koristi za opis procesa gdje se sistem najprije zagrije do visoke temperature, što uzorkuje taljenje, te se zatim hladi kroz korake određene rasporedom kaljenja (eng. annealing schedule). Proces se nastavlja sve dok sistem ne dođe u blizinu temperature ukrućivanja kada se dozvoljava sistemu da dođe u osnovno stanje (stanje najniže energije sistema). Simulirano kaljenje predstavlja varijantu Monte Carlo pristupa da bi se simuliralo ponašanje sistema kako bi se postigla termalna ravnoteža na danoj temepratura uz korištenje određenog rasporeda kaljenja. Iterativno poboljšavanje, koje se često primjenjuje na probleme kombinatorijalne optimizacije, je vrlo slično mikroskopskom preuređenju koje se modelira statističkom mehanikom, s funkcijom cilja u ulozi energije sustava. Međutim, prihvaćajući samo preuređenja koja vode na smanjenje funkcije cilja, sistem će vrlo brzo doći u lokalni minimum, što bi predstavljalo ekvivalent brzog ohlađivanja. Kako bi se to spriječilo, dozvoljena su i preuređenja koja pogoršavaju funkciju cilja, čime se omogućava algoritmu efikasnije pretraživanje prostora rješenja. Pseudo-kod za implementaciju simuliranog kaljenja se može napisati ovako: generiraj početnu konfiguraciju definiraj početnu temepraturu čini čini izračunaj promjenu energije sistema za malu promjenu konfiguracije ako je promjena energije < 0 prihvati novu konfiguraciju inače prihvati novu konfiguraciju s vjerojatnošću P(dE) = e -de/kt dok se sistem nije smirio na danoj temepraturi smanji temperaturu sistema dok nije zadovoljen uvjet završetka k je Boltzmannova konstanta, a T temperatura sistema koja u stvari predstavlja kontrolni parametar procedure optimizacije i njom se kontrolira koliko će se prihvatiti promjena konfiguracije koje vode na lošije konfiguracije. 34

35 Simulirano kaljenje su na kvadratični problem pridruživanja primjenili Burkard i Rendl [45], Wilhelm i Ward [46], te Connoly [48]. Za implementaciju algoritma simuliranog kaljenja, potrebno je definirati raspored kaljenja, odnosno skup S = {t, t 2,..., t r } gdje je (t > t 2 >... > t r ) i t i predstavlja temperaturu u i-toj iteraciji kaljenja. Sam algoritam u pseudo-kodu se može definirati na sljedeći način: Function SimAnnealing() Config = GenerateRandomConfiguration(); E = CalcEnergy(Config); T = InitialTemperature(); i = 0; r = Card(S); // r = broj različitih temperature u rasporedu kaljenja do { do { RandomlySelectTwoFacilities(r,s); de = CalcEnergyChange(Config, r, s); if ( de 0 ) AcceptNewConfig(); else { X = rand(0,); // slučajna vrijednost iz intervala [0,) P = exp(-de / T ); if ( X < P ) AcceptNewConfig(); } while (EquilibirumReached( T )!= true); T = NextTemperature(); } while ( i < r ); EndFunction; Prilikom implementacije algoritma za optimizaciju pomoću simuliranog kaljenja, od najveće je važnosti odabir rasporeda kaljenja, odnosno odabir sekvence temperatura kroz koje će prolaziti sistem, a povezano s time je od velike je važnosti i odabir trenutka promjene temperature. Različiti autori su predlagali različite varijante rasporeda kaljenja Burkard-Rendl raspored kaljenja Burkard i Rendl su u svome radu radu implementirali elementarni raspored kaljenja koji se sastojao u smanjivanju temperature za određeni multiplikativni faktor, s time da se temepratura mijenjala nakon određenog, preddefiniranog broja obavljenih zamjena. 35

36 Wilhelm-Ward raspored kaljenja U radu Wilhelma i Warda je korišten raspored kaljenja koji se prvi put pojavljuje kod Kirkpatricka i Gelatta [44], gdje se predlaže da se raspored kaljenja definira sljedećim nizom temperatura: i t = (0) (0.9), za i =, 2,..., r. (5.) i Za dinamiku mijenjanja temperatura primjenili su nešto složeniju procedure koja se može opisati na sljedeći način. Uvodi se pojam epohe koja se definira kao a priori određeni broj prihvaćenih izmjena konfiguracije te se na kraju svake epohe ispituje da li je na toj temperaturi sistem došao do točke ravnoteže. Ispitivanje se provodi tako da se izračuna srednji ukupni trošak, koji ćemo označiti sa f e, svih pridruživanja koja su prihvaćena tijekom epohe te se usporedi sa ukupnim srednjim troškom, označenim sa f e ', svih pridruživanja u svim prethodnim epohama. Ukoliko je ukupni srednji trošak pridruživanja u zadnjoj epohi dovoljno blizu (unutar nekog intervala ε) ukupnom srednjem trošku svih pridruživanja, pretpostavlja se da je sistem u ravnoteži te se prelazi na sljedeću temperaturu Lundy-Mees raspored kaljenja Lundy i Mees su u svome radu [47] predložili sljedeći raspored kaljenja: T T i i+ =, gdje je β T 0. (5.2) + βti Kako bi se procedura hlađenja obavila u određenom broju koraka M (da bi se moglo uspoređivati rezultate sa drugim rasporedima), β se definira kao: T0 T f β =. (5.3) M T T 0 f Connoly-ev poboljšani raspored kaljenja Connoly je u svom radu [48] pristupio problemu definiranja rasporeda kaljenja na sljedeći način. Naime, uočio je da potpuno slučajno odabiranje sljedeće konfiguracije za ispitivanje može biti neefikasno iz dva razloga: jedan je što se na nižim temperaturama mogu propustiti ispitati neki zanimljivi potezi, a drugi što se napori za micanje iz lokalnog optimuma mogu oslabiti zbog preranog odbacivanja uzlaznog poteza (poteza koji pogoršava funkciju cilja). Stoga je u svome radu definirao dvije procedure koje su imale različiti raspored. Prva, nazvana L&M (L&M zbog toga što je primjenio Lundy-Mees formulu za određivanje slijeda temperatura), je bila standardna u smislu da je slučajno odabirala sljedeću konfiguraciju za ispitivanje, dok je druga, L&M2, konfiguracije ispitivala u točno određenom redoslijedu, krećući od (,2), (,3),..., (,n), (2,3)..., gdje brojevi u zagradama predstavljaju indekse uslužitelja čije se lokacije zamjenjuju. Eksprimentalnim ispitivanjem je ustanovio da procedura L&M2 pokazuje bolje rezultate. 36

37 Pored toga, u tom radu je značajna pažnja posvećena i kontroli temprature, odnosno definiranju brzine s kojom će se smanjivati temperatura. Naime, ukoliko se sistem drži na prevelikoj temepraturi, značajan broj uzlaznih poteza će biti prihvaćen te se algoritam degenerira na slučajno pretraživanje prostora stanja. S druge strane, ukoliko se sistem prebrzo ohladi, završiti će u nekom od bliskih lokalnih minimuma. Stoga negdje između ta dva ekstrema postoji optimalna temepratura na kojoj bi performanse algoritma bile najbolje. Predloženi algoritam je sljedeći. Na početku se definira parametar M koji predstavlja broj zamjena koji će se ispitati, i to u redoslijedu kao kod L&M2 procedure. Predodređena vrijednost za M je 50K, gdje je K = 0.5 n (n-) broj susjeda za svaku točku konfiguracijskog prostora. Ukoliko korisnik ne specificira raspon temperatura, izvodi se 0.0M slučajnih zamjena iz kojih se određuju δ min i δ max (minimalni i maksimalni trošak zamjene dva uslužitelja), te se raspon temperatura definira kao T 0 min ( max min ) T f = δ = δ min + 0 δ δ (5.4) Za definiranje slijeda temperatura se koristi Lundy-Meesova formula, s time da se uvodi dodatni parametar MXFAIL pomoću kojeg se modificira kontrola temperature na takav način da se u slučaju odbacivanja MXFAIL uzastopnih uzlaznih poteza obavlja sljedeće: ) sljedeći uzlazni potez se prihvaća 2) T se vraća na vrijednost TFOUND koja predstavlja temepraturu na kojoj je nađeno dosad najbolje rješenje 3) hlađenje se zaustavlja postavljanjem parametra β na 0 Cilj koji se ovime pokušava postići je da TFOUND predstavlja pouzdani indikator optimalne temeprature. Za vrijednost parametra MXFAIL se uglavnom koristila vrijednost 0.5 n (n-). Pored navedenih koraka, u algoritam je ugrađen i postupak lokalnog pretraživanja kako bi se dobivena rješenja još više poboljšala. Rezultati koje je Connoly dobio primjenom na poznate probleme pokazali su boljima od ostalih implementacija simuliranog kaljenja za rješavanje QAP-a, a gotovo u svim slučajevima je algoritam našao rješenje unutar % najboljeg poznatog rješenja Genetički algoritam Genetički algoritmi predstavlju još jednu vrstu stohastičke metode pretraživanja. Ideja je potekla od Hollanda 975.g. [9] koji je primjenio ideju prirodnog procesa selekcije, gdje se pomoću jednostavnih evolucijskih mehanizama razvijaju vrlo složene vrste, na rješavanje kombinatorijalnih optimizacijskih problema. Osnovni pristup rješavanja pomoću genetičkkog algoritma je sljedeći. Algoritam starta sa skupom početnih mogućih rješenja (koja se generiraju slučajno ili korištenjem neke heuristike) koji se naziva početna populacija. Elementi populacije se često nazivaju "jedinke" 37

38 ili "članovi". Algoritam odabire određeni broj parova jedinki iz trenutne populacije (proces selekcije) i koristeći pravila križanja (eng. crossover rules) generira novo rješenje iz svakog para jedinki. Za svaki odabrani par jedinke se nazivaju roditeljima dok se novo generirano rješenje naziva djetetom. Također se određeni broj "loših" rješenja izbacuje iz populacije (eng. culling). Postupak se ponavlja dok se ne ispuni nekakav kriterij zaustavljanja Kao kriterij zaustavljanja može se koristiti obavljanje određenog broja iteracija, dostizanje određene vrijednosti funkcije cilje, ili se provjerava da li je populacija konvergirala u neku jedinku, kada više nema smisla nastaviti izvršavanje algoritma. Tijekom izvršavanja algoritma, na članove populacije se primjenjuje mutacija ili imigracija, kako bi se slučajnim promjenama jedinki algoritam usmjerio na pretraživanje dotad neistraženih područja prostora rješenja. Nakon završetka algoritma, najbolja jedinka se uzima kao rješenje. Često se unutar samog genetičkog algoritma ugrađuju funkcije koje obavljaju lokalno pretraživanje kako bi se ubrzalo izvođenje algoritma i poboljšali rezultati. Naravno, ukoliko se pri tome pretjera, algoritam će završiti u lokalnom minimumu, što znači da je potrebno pogoditi pravi balans između obavljanja operacija genetičkog algoritma (križanje, mutacija,...) i poboljšavanja rješenja pomoću lokalnog pretraživanja. Za postizavanje raznolikosti rješenja, često se primjenjuje tournaments sistem kod kojega se paralelno pokreće više instanci genetičkog algoritma, koje kreću iz različitih početnih rješenja, te se nakon optimizacije kreira nova populacija dobivena unijom boljih jedinki iz različitih instanci algoritma. Nakon toga se nastavlja optimizacija sa tako generiranom populacijom. Općenito se genetički algoritam u pseudo-kodu može definirati na sljedeći način: generiraj početnu populaciju ponavljaj odaberi dvije jedinke I i I 2 iz populacije primjeni operator križanja na I i I 2 da se stvori dijete I 3 zamjeni jednu od jedinki (I ili I 2 ) sa djetetom I 3 povremeno primjeni mutaciju/imigraciju dok populacija ne konvergira; kraj Kodiranje Kod implementacije genetičkog algoritma, najprije je potrebno pronaći način kodiranja jedinki, odnosno način reprezentacije rješenja u jedinkama populacije. Inicijalno se koristilo binarno kodiranje, odnosno, rješenja su se reprezentirala binarno kako bi se direktnom primjenom operatora genetičkog algoritma na bitove mogla proizvesti nova rješenja. Međutim, nema potrebe za takvim kodiranjem budući da se operatori genetičkog algoritma ne moraju bitovno definirati već se mogu koristiti standradne programske strukture podataka. 38

39 Budući da kod kvadratičnog problema pridruživanja rješenje predstavlja permutaciju ono se može kodirati pomoću pomoću običnog niza cijelih brojeva P[i], i=,... N, gdje P[i] predstavlja lokaciju na koju će se pridružiti i-ti uslužitelj Stvaranje početne populacije Kvaliteta rada genetičkog algoritma je vrlo osjetljiva na kvalitetu početne populacije jedinki. Valjanost početne populacije ovisi i o prosječnoj vrijednosti funkcije cilja jedinki (eng. fitness) i o raznolikosti populacije. Što su jedinke u početnoj populaciji bolje, to će biti bolje i krajnje jedinke nakon obavljenje optimizacije. Pored toga, velika raznolikost među jedinkama spriječava preranu konvergenciju algoritma u lokalno optimalno rješenje. Što se tiče veličine populacije, općenito je prihvaćeno da veličina populacije ne bi trebala prelaziti 00, budući da se povećanjem broja jedinki produžava izvođenje optimizacije, a dobivena poboljšanja nisu proporcionalan uloženom vremenu optimizacije Križanje i selekcija Da bi se obavilo križanje među jedinkama, čija je namjena stvaranje jedinki koje će naslijediti dio svojih svojstava od oba roditelja, najprije je potrebno obaviti proces selekcije, odnosno odabir jedinki za križanje. Kod obavljanja procesa selekcije, moguća su dva pristupa. Kod prvoga se veću vjerojatnost odabira za križanje daju jedinkama sa boljom funkcijom cilja dok se kod drugoga vrijednost funkcije cilja uopće ne uzima u obzir pa se svim jedinkama daje ista šansa da budu odabrani za proces križanja. Kod primjene genetičkih algoritama na QAP, neki istraživači su primjenjivali prvi pristup, primjerice Fleurent i Ferland [50] te Lim, Yuan i Omatu [52], dok su Ahuja, Orlin i Tiwari [5] te Tate i Smith [49] koristili drugi. Za obavljanje samog procesa križanja, u literaturi se spominju četiri implementacije operatora križanja: jednostavno križanje (korišteno u [49] i [50]), križanje zamjenom staze (eng. swap path crossover) [5], križanje ubacivanjem staze (eng. insert path crossover) [5] i optimizirano križanje (eng. optimized crossover) [5]. U opisu razlčitih operatora križenja, dva roditelja će se označavati sa I i I 2, dok će se rezultirajuće dijete označavati sa I 3. Jednostavan operator križanja se izvodi u sljedeća tri koraka: ) ukoliko se u oba roditelja uslužitelj pridružuje istoj lokaciji, tada se i u jedinki djeteta taj uslužitelj pridružuje na istu lokaciju. 2) nepridruženi uslužitelji se pregledavaju s lijeva na desno te se pridružuju na lokaciju na kojoj su pridruženi u nekom od roditelja. 3) nepridruženi uslužitelji se nakon prva dva koraka stavljaju na lokacije koje već nisu zauzete Na slici 5. se može vidjeti obavljanje tri koraka za jednostavan operator križanja. 39

40 I I korak 5 korak korak Slika 5. Primjer djelovanja operatora križanja Kod primjene križanja zamjenom staze počinje se od slučajno određene pozicije, te se jedinke ispituju ciklički od te pozicije. Ukoliko je uslužitelj u oba roditelja pridružen istoj lokaciji, ide se na ispitivanje sljedećeg uslužitelja. Ukoliko to nije slučaj, obavlja se zamjena pridruženih lokacija u oba roditelja, čime se stvaraju dva djeteta, te se u daljnje razmatranje uzima djete koje ima bolju vrijednost funkcije cilja. Postupak se ponavlja sve dok svi uslužitelji nisu uzeti u obzir. Sva djeca nastala tijekom postupka se uspoređuju te se dijete sa najboljom vrijednošću funkcije cilja uzima kao rezultat križanja. Ilustracija postupka je dana na slici 5.2, gdje su podebljano označene lokacije uslužitelja koji su u oba roditelja pridruženi na iste lokacije. Ukoliko pretpostavimo da se kreće od prve pozicije u permutaciji, vidimo da postoje dva načina na koja možemo obaviti zamjenu Roditelj : Zamjena u roditelju : Roditelj 2 : Zamjena u roditelju 2 : Slika 5.2 Ilustracija križanja zamjenom staze Operator križanja ubacivanjem staze je sličan, s tom razlikom što se ne obavlja zamjena pozicija unutar jedinke roditelja, već se na poziciji gdje se križanje obavlja ubacuje lokacija iz drugog roditelja s time da se ostatak permutacije u roditelju nad kojim se obavlja križanje pomiče udesno. Ilustracija je dana na slici 5.3, gdje u prvom slučaju vidimo da se na prvu poziciju u I ubacio uslužitelj 2, a uslužitelj 5 se pomakao na drugu poziciju, dok je u drugom slučaju došlo do značajnijih promjenaa: najprije se faacility 5 ubacio na prvu poziciju, a zatim su se uslužitelji 2, i 6 pomakli za jedno mjesto udesno. Naravno, prilikom ovih pomicaanja faacility koji su u oba roditelja pridruženi na iste lokacije se ne pomiču. Roditelj : Zamjena u roditelju : Roditelj 2 : Zamjena u roditelju 2 : Slika 5.3 Ilustracija križanja ubacivaanjem staaze U [5] je numeričkim ispitivanjem ustanovljena prednost korištenja operatora križanja ubacivanjem staze. 40

41 Mutacija i imigracija Pojam mutacije se odnosi na povećanje raznolikosti u populaciji pomoću uvođenja slučajnih varijacija u članovima populacije, dok se pojam imigracije odnosi na zamjenjivanje lošijih članova populacije sa novim jedinkama. Kod primjene na QAP, u literaturi se uglavnom koristila mutacija, koja se najčešće izvodi tako da se u jedinkama odabranim za mutaciju slučajno odaberu dva uslužitelja te se zamjene lokacije na koje su oni pridruženi. Kod korištenja imigracije od najveće je važnosti da se sa uvođenjem novih jedinki u populaciju unosi i novi genetički matrijal, odnosno rješenja koja se značajno razlikuju od onih već prisutnih u populaciji, kako bi se povećala raznolikost populacije i time algoritmu omogućilo bolje pretraživanje prostora rješenja. Ahuja, Orlin i Tiwari su primjenili sljedeći algoritma za deifniranje novih jedinki. Definirajmo matricu α = (α ij ) dimenzija n n u kojoj se na poziciji (i,j) nalazi broj koji govori koliko je jedinki tijekom cijelog izvršavanja optimizacije na i-toj lokaciji imalo j-ti uslužitelj. Nove jedinke se tada selektiraju tako da se najprije generira slučajna permutacija n brojeva koja definira redoslijed kojim će se razmatrati lokacije, jedna po jedna. Kod razmatranja svake lokacije, označimo je sa k, njoj se pridružuje nepridruženi uslužitelj l za koji je α kl najmanji. Time se postiže promoviranje jedinki iz dijela prostora rješenja koje nije toliko istraženo, čime se dobiva na raznolikosti populacije Elitizam Budući da se kod genetičkog algoritma operatori križanja i mutacije primjenjuju na sve jedinke, može se desiti, čak i kod algoritama gdje je vjerojatnost selekcije jedinke za križanje ili mutaciju proporcionalna vrijednosti funkcije cilja, da se najbolja jedinka u populaciji primjenom genetičkih operatora promijeni. Kako bi se to izbjeglo može se primijeniti princip elitizma, kod kojeg se genetički algoritam implementira na takav način da se najbolja jedinka (ili čak određen skup najboljih jedinki) uvijek zadržava u populaciji. Loša posljedica takvog pristupa je da se smanjuje raznolikost populacije time što se ne dopušta algoritmu da izmjenom najboljih jedinki krene u istraživanje nekog drugog dijela prostora rješenja Princip tournamenting-a U principu se genetički algoritam može primijeniti više puta sa različitim početnim populacijama, te se na kraju odabiru najbolja rješenja. Međutim, kao alternativa se može iskoristiti pristup gdje se iz konačnih populacija nastalih iz dva različita pokretanja genetičkog algoritma, uzima po 50 % jedinki, te se na tako dobivenu populaciju ponovno primjenjuje genetički algoritam. Na taj način se može očekivati da će algoritam pretražiti područja koja se nalaze "između" područja gdje su ta dva rješenja konvergirala. 4

42 Ovakav pristup se može poopćiti i tada dobivamo tournamenting. Princip je vidljiv iz slike 5.4. Kod korištenja ovakvog algoritma mora se definirati način na koji će se iz dviju populacija odabrati po 50% jedinki za stvaranje nove populacije. Dvije opcije su dominantne: i) odabiranje najboljih 50% jedinki iz unije dvije populacije ii) unija najboljih 50% jedinki iz svake populacije Početna populacija P Početna populacija P2 Početna populacija P3 Početna populacija P4 Primjeni GA Primjeni GA Primjeni GA Primjeni GA Poboljšana populacija P Poboljšana populacija P2 Poboljšana populacija P3 Poboljšana populacija P4 Eliminiraj 50 % Eliminiraj 50 % Početna populacija P 2 Početna populacija P 34 Primjeni GA Primjeni GA Poboljšana populacija P 2 Poboljšana populacija P 34 Eliminiraj 50 % Početna populacija P 234 Primjeni GA Poboljšana populacija P 234 Slika 5.4 Princip rada tournamenting algoritma Hibridni algoritam Početne implementacije genetičkog algoritma za rješavanje QAP su se pokazale neefikasnim u odnosu na algoritme simuliranog kaljenja ili tabu-searcha, što je navelo istraživače da pokušaju iznaći modifikacije tih algoritama koje bi ih učinile kompetitivnijim. Rješenje se pronašlo u tzv. hibridnim genetičkim algoritmima čija je karakteristika da je unutar genetičkog algoritma ugrađena komponenta lokalnog pretraživanja, koja nakon primjene operatora križanja i mutacije obavlja lokalno pretraživanje s ciljem poboljšavanja jedinki u populaciji. Takav pristup se pokazao ispravnim tako da se genetički algoritmi implementirani na takav način mogu po efikasnosti i kvaliteti rješenja uspoređivati sa drugim načinima rješavanja QAP-a. Prvi su takav pristu primjenili Fleurent i Ferland [50], a nakon njih su poboljšane verzije definirali Lim,Yuan i Omato [52] te Ahuja,Orlin i Tiwari [5]. 42

43 5.2.7 Greedy randomized adaptive search GRASP GRASP metoda predstavlja iterativan proces gdje se svaka iteracija sastoji od dvije faze, faze izgradnje rješenja i faze lokalnog pretraživanja, te se najbolje nađeno rješenje zadržava kao rezultat. U prvoj fazi se rješenje iterativno konsturira, element po element. U svakoj iteraciji izgradnje, izbor sljedećeg elementa se određuje tako da se poslože svi elementi u listi kandidata s obzirom na pohlepnu funkciju koja mjeri dobit izboraa svakog elementa. Heuristika je adaptivna jer se dobici povezane sa izborom svakog elementa ponovno izračunavaju prilikom svake iteracije u fazi izgradnje kako bi se uzele u obzir promjene nastale izborom prethodnog elementa. Slučajnost je uvedena tako što se među najboljim kandidatima slučajno bira element, koji najčešće nije i najbolji. Rješenja generirana u fazi izgradnje uglavnom nisu lokalno optimalna s obzirom na definciju okoline. Stoga se gotovo uvijek pokazuje korisnim primjeniti lokalno pretraživanje kako bi se poboljšalo izgrađeno rješenje. Iako takvo pretraživanje može zahtjevati eksponencijalno vrijeme ukoliko se kreće iz proizvoljne početne točke, empirički se efikasnost pretraživanja značajno poboljšava kako se početno rješenje poboljšava. Korištenjem prilagođenih struktura podataka i pažljivom implementacijom, može se stvoriti efikasna faza izgradnje koja producira dobra početna rješenja za lokalno pretraživanje. Formalno se GRASP algoritam može opisati ovako. Faza izgradnje GRASP algoritma počinje sa pridruživanjem dva uslužitelja i 0, j 0 na dvije lokacije k 0, l 0. Odabiranje ovog para za pridruživanje se obavlja na sljedeći način. Za QAP(A,B) veličine n, pohlepna komponenta odabire i 0, j 0, k 0, l 0, takve da je { a b : i, j, k, l {,2,..., n}, i j k l} ai j bk l = min ij kl, (5.4) Slučajna komponenta daje određenu slobodu izbora proceduri pretraživanja i modificira odabir s nadom da će se izbjeći zarobljavalje algoritma u lokalno optimalna rješenja loše kvalitete. Ovdje je potrebno uvesti parametar 0 < β <. Nedijagonalni elementi matrice A=(a ij ) se sortiraju u neopadajući redoslijed i r najmanjih elemenata se označavaju sa a i j, ai j,..., a 2 2 i r j r gdje je r = (β (n 2 -n)). Analogno, nedijagonalni elemetni matrice B=(b ij ) se soritiraju u nerastućem redoslijedu i označavaju sa b k l, bk l,..., bk r l. Tada imamo : 2 2 r a b i j k l a b i j 2 2 k l a... b ir jr krlr (5.5) Troškovi mogućih pridruživanja parova a b a b, a b i j k l, i j k l,... ir jr krl (5.6) r se tada soritiraju u neopadajućem poretku i najmanjih r' = (αβ (n 2 -n)) se uzima u daljnje razmatranje. 0 < α < je drugi kontrolni parametar algoritma. Nakon toga se lokacije i 0, j 0 i uslužitelji k 0, l 0, odabiru slučajno među (i t, j t ) i (k t, l t ) gdje je t r' te se obavlja početno 43

44 pridruživanje i 0 k 0 i j 0 l 0. U sljedećim koracima faze izgradnje se preostali uslužitelji pridružuju na preostale lokacije, jedan po jedan. Ukoliko obavljamo (t+)-vu iteraciju faze izgradnje i ako sa Γ = {(i, k ), (i 2, k 2 ),..., (i t, k t )) označimo skup obavljenih pridruživanja, tada je trošak pridruživanja nekog uslužitelja j, j {i, i 2,..., i t }, na neku lokaciju l, l {k, k 2,..., k t }, s obzirom na već napravljena pridruživanja dan sa c = ( a b + a b ) (5.7) jl ( i, k ) Γ ij gdje se c jl naziva međutroškom. Ukoliko još postoji m parova (j,l) nepridruženih uslužitelja i lokacija, odabiremo slučajno jedan par među parovima koji daju (α m) najmanjih međutroškova c jl. Dodajemo odabrani par u Γ i ponavljamo sve dok se ne izgradi cijela permutacija. Nakon toga završava faza izgradnje GRASP-a. Nakon konstruiranja početnog rješenja, potrebno je primjeniti lokalno pretraživanje, nakon čega se dobija konačno rješenje. Cijela procedura se ponavlja određeni broj puta, kako bi se pretražio što veći prostor rješenja, te se najbolje nađeno rješenje uzima kao konačni rezultat optimizacije. Na slici 2 je prikazan pseudo-kod općenite GRAPS procedure : function GRASP(ListSize, MaxIter, RandomSeed) InputInstance(); InitializeDataStructures(); BestFoundSolution = ; do k= ConstructGreedyRandomizedSolution(ListSize, RandomSeed); LocalSearch(BestFoundSolution); UpdateSolution(BestFoundSolution); while k<maxiter; end grasp; Proceduri se kao parametar moraju definirati veličina liste kandidata, maksimalni broj iteracija, te parametri α i β. Posebno poželjna karakteristika GRASP metode je jednostavnost implementacije budući da su pohlepne funkcije poznate za mnoge probleme a isto tako i definicije okoline i lokalnih metoda pretraživanja. Također, potrebno je definirati i podesiti malo parametara, što omogućava veću koncentraciju na efikasnu implementaciju. I na kraju, GRASP metoda se vrlo lako može implementirati za višeprocesorska računala budući se iteracije mogu obavljati nezavisno jedna od drugu uz dijeljenje jedino varijable koja predstavlja najbolje nađeno globalno rješenje. kl ji lk 44

45 6. Programska izvedba i usporedba metoda U ovom poglavlju je opisana implementacija algoritama za rješavanje kvadratičnog problema pridruživanja i njihove međusobne usporedbe. Najprije je definirana hijerarhija razreda koja obuhvaća i na odgovarajući način implementira apstrakcije zajedničke svim algoritmima za iterativnu optimizaciju, poslije čega je razvijena hijerarhija razred za rješavanje kvadratičnog problema pridurživanja, unutar koje su definirani objekti sa implementacijama samih algoritama. Korištenjem implementiranih algoritama, napisana je aplikacija za rješavanje kvadratičnog problema pridruživanja, čiji je opis dan u nastavku poglavlja. Na kraju poglavlja su dani rezultati usporedbe različitih algoritama za rješavanje QAP-a. 6. Uvod Prilikom implementacije opisanih algoritama, korišten je programski jezik C++. Razlog odabira baš tog progamskog jezika leži u činjenici da se radi o modernom objektnoorijentiranom programskom jeziku koji pored standardnih svojstava svih OO-jezika (podržavanje apstrakcije i enkapsulacije podataka, te nasljeđivanja i polimorfizma) podržava i koncept generičkog programiranja preko uzoraka (eng. templates). Budući da je C++ nastao kao nasljednik programskog jezika C, prilikom njegovog definiranja je velika pažnja posvećena efikasnosti izvođenja programskog koda, što ga čini idealnim jezikom za pisanje numerički intezivnih aplikacija, za razliku od nekih drugih objektno-orijentiranih programskih jezika, npr. Jave. Nakon početne faze razvoja u kojoj je najveća pažnja bila posvećena izvedbi raznih algoritama za optimizaciju, pokazalo se da postoje mnogobrojne apstrakcije zajedničke svim tim implementacijama, što je omogućilo da se razviju hijerarhije razreda koji direktno oslikavaju te apstrakcije. Takav pristup je omogućilo postizavanje maksimalne jednostavnosti implementacije preko ponovnog korištenja koda (eng. code reusability) korištenjem nasljeđivanja iz razreda definiranih unutar hijerarhije. Pored korištenje samog nasljeđivanja, iskorištena je mogućnost generičkog programiranja u C++ kako bi se određeni algoritmi, odnosno razredi koji ih implementiraju, mogli napisati neovisno o tipu parametara nad kojima djeluju, čime se na još jednom nivou dobiva na ponovnoj iskoristivosti programskog koda. 45

46 6.2 Generički razredi za iterativnu optimizaciju Kod definiranja hijerarhije generičkih razreda za optimizaciju potrebno je najprije uočiti zajedničke apstrakcije kako bi se moglo krenuti od najopćenitije apstrakcije, prema onima koje su više specijalizirane (tzv. generalizacija/specijalizacija odnos u OO-dizajnu informacijskih sustava [3]). Kod razvijanja bilo kakvog programskog sustava čija je namjena rješavanje optimizacijskih problema, mogu se uočiti sljedeći problemi: - prikazivanje rezultata - praćenje napretka algoritma i osvježavanje sa trenutnim rezultatima - definiranje kriterija za zaustavljanje izvođenja optimizacije - čuvanje međurezultata Prvi problem se lako rješava. Korištenjem modernih objektno-roijentiranih jezika, jednostavno je definirati strukture podataka koje će čuvati rezultate izračunavanja u prikladnoj formi. Ovaj pristup se može dalje poboljšati budući da je jednostavno definirati strukture koje će čuvati ne samo završno rješenje već i informacije o međurezultatima koje je algoritam pronašao. Korištenjem tih međurezultata može se na jednostavan način analizirati napredak algoritma prema završnom rješenjeu. Drugi problem se javlja kada su izračunavanja koja je potrebno izvesti vremenski zahtjevna te je vrlo neprikladno ostaviti prazan ekran ispred korisnika sve dok se izračunavanje ne obavi do kraja. Zbog toga je nužno naći način da se ekran periodički osvježava sa trenutnim rješenjem. Treći problem je povezan sa činjenicom da se mogu definirati različiti kriteriji zaustavljanja algoritama. Programski je najlakše izvesti zaustavljanje nakon izvršavanja određenog broj iteracija, ali se ponekad pokazuje kao prikladno da se kao kriterij zaustavljanja uzme vrijeme izvršavanja algoritma. Čuvanje međurezultata je povezano sa predstavljanjem rezultata i praćenjem napredtka algoritm i njegova implementacija ovisi o rješavanju ta dva problema. Osim definiranja struktura podataka koje će čuvati međurezultate, što je već spomenuto u prethodnom paragrafu, potrebno je definirati i kada će se ti međurezultati spremati, gdje se za određivanje trenutka snimanja rezultata mogu definirati različiti kriteriji. Da bismo mogli definirati zajedničke koncepte iterativnih optimizacijskih algoritama, najprije je potrebno definirati iteracijski optimizacijski algoritam. U ovom radu se pod iterativnim optimizacijskim algoritmom smatra bilo kakav algoritam koji se može predstaviti sljedećim pseudo-kodom: generiraj početno rješenje čini poboljšaj rješenje koristeći korak iteracije dok uvjet nije zadovoljen kraj; 46

47 Jedna iteracija algoritma može biti korak proizvoljne složenosti, sve dok izračunavanje u t-toj iteraciji ovisi samo o rezultatu iz (i-)-te iteracije. Uvjet završetka izračunavanja može se proizvoljno definirati Razredi za predstavljanje rezultata Kad god smo suočeni sa problemom optimizacije, bez obzira da li se radi o problemu trgovačkog putnika, kvadratičnom problemu pridruživanja ili jednostavnom problemu nalaženja maksimuma neke funkcije, uvijek imamo funkciju cilja koju optimiramo, vrijednost funkcije cilja i vrijednost varijabli problema koje predstavljaju rješenje. Korištenjem simboličke notacije, možemo obuhvatiti ova tri aspekta optimizacijskog probleme na sljedeći način: _TypeValue OptFunc ( _TypeSol x ); Matematički, možemo definirati funkciju cilja kao OptFunc: X Y, gdje je X skup varijabli tipa _TypeValue a Y skup varijabli tipa _TypeSol. Koristeći uzorke, koji predstavljaju način za generičko programiranje u C++ [4][7], možemo deklarirati našu funkciju kao: template<class _TypeValue, class _TypeSol> _TypeValue OptFunc( _TypeSol & ); U vezi sa deklaracijom optimizacijske funkcije, odmah je očito da će razredi koje ćemo koristiti za predstavljanje rješenja našeg problema također morati biti parametrizirani te da će ovisiti o dva parametra: jedan koji će definirati tip vrijednosti funkcije (koji će obično biti običan realni broj, odnosno tip float ili double u jeziku C++), dok će drugi definirati tip rješenja. Da bismo predstavili rezultat optimizacije, možemo definirati općeniti razred OptimizationResult čiji bi osnovni elementi bili sljedeći: template<class _TypeValue, class _TypeSol> class OptimizationResult { protected: _TypeValue FuncValue; // postignuta vrijednost funkcije cilja _TypeSol Solution; // nađeno rješenje long IterNum; // broj obavljenih iteracija float OptimDuration; // trajane optimizacije u ms public: OptimizationResult(); OptimizationResult(_TypeValue infuncval, _TypeSol insol, long induration); OptimizationResult( const OptimizationResult<_TypeValue,_TypeSol> &copy); OptimizationResult& operator=(const OptimizationResult<_TypeValue,_TypeSol> &b ); float getoptimduration() const; _TypeValue getfuncvalue() const; _TypeSol getsolution( void ) const; void getsolution( _TypeSol *outsol ) const; 47

48 }; void setoptimduration( float inoptimduration ); void setfuncvalue( _TypeValue infuncval ); void setsolution( _TypeSol insol ); Osim definiranih članskih varijabli, koje će sadržavati rezultat optimizacije, dodano je i nekoliko članova kako bi se zadovoljila kanonska forma [6] koja omogućava korištenje definiranog razreda al pari sa bilo kojim predefiniranim tipom u programskom jeziku C++. Budući da će razred predstavljati rezultat iterativnog algoritma, dodana su još dva člana: jedan koji će predstavljati ukupni broj iteracija, i jedan za predstavljanje vremena izvršavanja. Kod optimiranja neke funkcije pomoću iterativnog algoritma, često se nameće potreba da se sačuvaju i rješenja koja je algoritam pronašao tijekom optimizacije, a ne samo završno rješenje. Razlog tome bi bio potreba da se analizira napredak algoritma tijekom optimizacije, da se može pratiti kako promjene parametara tijekom optimizacije utječu na ponašanje algoritma i slično. Razred koji bi imao sposobnost čuvanja takvih rezultata očigledno bi u sebi morao sadržavati nekakav spremnik (eng. container) u koji bi se pohranjivali ti rezultati. Također bi morala postojati i mogućnost da se brzo pronađe rezultat iz određene iteracije. U tu svrhu idealno može poslužiti skupina razreda definiranih u Standard Template Library (skraćenica STL), koja je dio programskog jezika C++ [7]. Budući da je bitan dohvat podatka po određenom ključu (koji će u ovom slučaju biti broj iteracije za koji je sačuvano rješenje), kao prirodno rješenje se nameće parametrizirani razred map<class Key, class T>, gdje Key predstavlja tip ključa po kojem će se dohvaćati podaci, a T je sam tip podataka koji će se nalaziti spremljen 6. Korištenjem tako definiranog spremnika, definirana su još dva razreda, OptContResult i OptContResultWithSolutions, s namjerom da ti razredi u sebi sadrže rješenja koja je algoritam pronašao tijekom izvođenja optimizacije. Razlog zbog kojeg su definirana dva razreda je taj što nas često zanima samo mijenjanje iznosa funkcije cilja tijekom izvršavanja algoritma, a ne i samo rješenje koje odgovara toj funkciji cilja. Stoga razred OptimizationResult -FuncValue : _TypeValue -Solution : _TypeSol -IterNum : long -OptDuration : float +//... for canonical form() OptContResult _TypeValue, _TypeSol -mapitertofuncvalue : map<_typevalue, _TypeSol> +AddValue(in IterNum : long, in FuncValue : _TypeValue) OptContResultWithSolutions -mapitertosolution : map<_typevalue, _TypeSol> +AddSolution(in IterNum : long, in Sol : _TypeSol) _TypeValue, _TypeSol _TypeValue, _TypeSol Sl. 6.: Hijeraarhija razreda za predstavljanje rješenja. 6 Ovaj razred predstavlja u stvari asocijativno polje (eng. associative array) koje sadrži parove vrijednosti od kojih jedna predstavlja ključ po kojem se polje indeksira, a druga samu vrijednost koja se sprema. U STL-u je definirana i generalizacija pojma asocijativnog polja. To su asocijativni spremnici (eng. associative containers) među koje spadaju multimap, set i multiset parametrizirani razredi. 48

49 OptContResult čuva samo iznose funkcije cilja, dok razred OptContResultWithSolutions čuva cjelokupno rješenje, znači i iznos funkcije cilja i pripadno rješenje. Razlog razdvajanju je taj što razred OptContResultWithSolutions ima puno veće memorijske zahtjeve, te ga stoga nema smisla koristiti osim kada nas baš zanimaju sama rješenja. Kako bi se iskoristila funkcionalnost već definirana u razredu OptimizationResults, primjenjeno je nasljeđivanje budući da u razred OptContResult predstavlja podvrstu (odnosno specijalizaciju) razreda OptimizationResult, a isto tako razred OptContResultWithSolutions predstavlja specijalizaciju razred OptContResult. Hijerarhija razreda je prikazana na slici 6. koristeći UML notaciju [8]. Detaljan kod se može naći u prilogu Razredi za opis algoritma i njegovih parametara Namjena ovih razreda je da služe za potpuni opis primjenjenog algoritma i njegovih parametara kod rješavanja nekog problema. Razred AlgParam služi za opis pojedinačnog parametra, gdje Name predstavlja ime parametra, Value njegovu vrijednost (koja se upisuje kao string), a Type govori o kakvom tipu parametra se radi (I-cjelobrojni, F-realni tip,...). U principu, korisnik ovih razreda može ta značenja proizvoljno definirati. class AlgParam { private: string Name; string Value; char Type; public: // pripadne pristupne članske funkcije... }; Razred AlgDescription predstavlja kolekciju parametara algoritma uz dodatne članove koji opisuju tip i podtip algortima. Za opis primijenjenog algoritma, ovaj skup podataka je dovoljan. Međutim, prvenstveni razlog uvođenja ovog razreda je bio to što je prilikom rješavanja određnog problema pomoću različitih algoritama bilo potrebno razlikovati o kakvom se algoritmu radilo prilikom prikaza rješenja. Kako se isti problem može rješavati istim algoritmom, pa čak i uz iste parametre, potreban je još jedan dodatni kvalifikator pomoću kojih bi se razlikovale tako izvedene optimizacije. Taj kvalifikator predstavlja članska varijabla OptID u koju se može upisati proizvoljna vrijednost opisa te optimizacije. Kako bi se korisnika razreda oslobodilo potrebe da prilikom svake provedene optimizacije definira i taj parametar, uvedena je članska funkcija setautomaticoptid koja popunjava tu člansku varijablu sa trenutnim datumom i vremenom početka optimizacije. class AlgDescription { private: string Type; string Subtype; string OptID; 49

50 std::vector<algparam> vecparam; public: // konstruktori i pristupne funkcije... void setautomaticoptid();... // «bitne» članske funkcije void addparam( string inname, string invalue, char inparamtype ) void addparam( string inname, long invalue, char *format, char inparamtype ) void addparam( string inname, float invalue, char *format, char inparamtype ) bool getparam( int ParamNum, string &outname, string &outvalue, char &outparamtype ) bool changeparam( string ParamName, string innewvalue, char innewtype ) }; Razredi za enkapsulaciju iterativnog algoritma Nakon što smo dali definiciju iterativnog algoritma, odmah se može napisati sučelje koje takav algoritam mora zadovoljavati: template<class _TypeValue, class _TypeSol> class IIterativeOptimization { public: }; virtual void Initialize() = 0; virtual void PerformIteration() = 0; virtual _TypeValue Optimize( ); virtual _TypeValue OptFunc( _TypeSol & ) = 0; Međutim, ovakav način enkapsulacije je bez značenja, ukoliko se iz njega ne mogu izvući neke dodatne koristi. Te koristi dolaze u vidu jednostavnijeg implementiranja i rješavanja problema navedenih ranije: određivanja kriterija prekidanja optimizacije, snimanja međurezultata te osvježavanja ekrana sa trenutnim rezultatima Prekidanje optimizacije Duljina trajanja iterativnog izračunavanja je uglavnom definirana pomoću broj aiteracija koji se treba izvršiti. Međutim, ponekad se pokazuje kao zgodna mogućnost deifniranja vremenskog trajanja optimizacije, ili se može zahtjevati da se optimizacija izvršava sve dok se ne dostigne određeni iznos funkcije cilja. Standardnim pristupom taj bi se problem riješito tako što bi se napisalo više funkcija za implementaciju danog algoritma od kojih bi svaka imala definirani svoj kriterij, ili bi unutar jedne funkcije imali više mogućnosti izbora. Međutim objektno-orijentirana paradigma nudi drugo rješenje. Mogu se definirati objekti koji će implementirati različite kriterije prekidanja optimizacije, a budući da će se definirati posebno sučelje koje će svi oni zadoovljavati, korištenjem polimorfizma će se sa svima njima moći postupati na isti način, korištenjem metoda koje su definirane u sučelju. Sučelje za objekte koji će se brinuti o prekidanju optimizacije se može definirati na sljedeći način: 50

51 class IOptTerminator { public: virtual void Start() = 0; // za provođenje inicijalizacije virtual void NextStep( void *pdata ) = 0; virtual bool IsOptimizationFinished() = 0; }; Svi objekti koji će definirati svoje kriterije za završetak optimizacije moraju zadovoljavati, odnosno implementirati, ovo sučelje. Na početku optimizacije, objekti primaju poruku Start() kako bi se obavile potrebne inicijalizacije. Poruka NextStep() se šalje objektu nakon svake iteracije kako bi objekt mogao prilagoditi svoje stanje izvršenom izračunavanju; npr. povećati brojač obavljenih iteracija, osvježiti vrijeme trajanja optimizacije ili zapamtiti trenutni iznos funkcije cilja (argument void *pdata koji se predaje ovoj funkciji je potreban kako bi joj se mogao predati pokazivač na neke podatke koji su potrebni za obavljanje ažuriranja stanja). Funkcija IsOptimizationFisnished() definira sam kriterij zaustavljanja i vraća logičku vrijednost istina kada je taj kriterij zadovoljen. Primjeri objekata koji bi se mogli definirati za različite kriterije završetka optimizacije su IterativeOptTerminator, koji završava postupak optimizacije kada je obavljen određeni broj Slika.6.2: Hijerarhija razreda koji implementiraju IOptTerminator sučelje IOptTerminator _TypeValue +Start() +NextStep() +IsOptimizationFinished() IterativeOptTerminator -IterationNum : long -CurrIterNum : long _TypeValue TimeOptTerminator -OptDuration : float -TimeStarted : float _TypeValue ConvergedOptTerminator _TypeValue -TargetObjValue : _TypeValue -ReachedObjValue : _TypeValue ConvergedFromUpOptTerminator _TypeValue _TypeValue ConvergedFromDownOptTerminator iteracija, ili TimeOptTerminator koji radi to isto nakon određenog vrmeneskog intervala. Također se može definirati i objekt ConvergedOptTerminator koji završava optimizaciju kada se dostigne određena vrijednost funkcije cilja (potrebna su dva različita objekta kako bi se imali elegantnije rješenje za rad s problemima minimizacije i maksimizacije). Na slici 6.2 je pirkazana hijerarhija tako definiranih razreda. 5

52 Praćenje napredovanja algoritma Kao što je ranije navedno, kada se obavljaju dugotrajna izračunavanja, potrebno je periodički osvježavati ekran sa trenutnim rješenjem, kako bi korisnik imao određeni uvid u napredovanje izračunavanja. Također je zgodno imati mogućnost uvida u napredovanje algoritma u traženju rješenja. Prirodno je definirati nekoliko različitih načina određivanja perioda osvježavanja: - osvježavanje nakon određenog broja obavljenih iteracija - osvježavanje nakon određenog vremenskog intervala - osvježavanje kada se funkcija cilja poboljša za određeni iznos Jednostavno rješenje, kojim bi se direktno implementirale sve ove mogućnosti u programskom kodu uz definiranje IterativeOptRefresher -IterNum : long -CurrIterNum : long IOptRefresher +Start() +NextStep() +IsTimeToRefresh() +PerformRefreshing() _TypeValue, _TypeSol _TypeValue, _TypeSol TimeOptRefresher -TimeStarted : float -RefreshInterval : float _TypeValue, _TypeSol Slika 6.3: Hijerarhija razreda za IOptRefresher sučelje odabira preko argumenta funcije bi rezultirale u ponavljanju istog koda. Stoga je primjenjen drugi pristup koji koristi polimorfizam, a koji je vrlo sličan onome primjenjenom kod definiranja kriterija za prekidanje optimizacije. Kao i kod definiranja različitih objekata za implementaciju različitih kriterija završetka optimizacije, tako ćemo i ovdje definirati jedno jedinstveno sučelje koje će implementirati različiti objekti za rukovanje osvježavanjem. Sučelje, u vidu UML dijagrama, je prikazano na slici 6.3, zajedno sa dva jednostavna objekta koji ga implementiraju. Objekt IterativeOptRefresher implementira funkciju IsTimeToRefresh() na način da vraća logičku vrijednost istina svaki put kada je algoritam izveo određeni broj iteracija, dok objekt tipa TimeOptRefresher implementira tu funkciju tako da vraća istinu kada prođe određeni vremenski interval. Pored definiranja perioda osvježavanja (odnosno određivanja kada će se podaci na ekranu osvježiti), u sučelje je ubačena i funkcija PerformRefreshing() čija je namjena obavljanje samog osvježavanja. Budući da je logično da se osvježavanje ekrana sa novim rezultatima obavlja u funkciji, unutar razreda IOptRefresher je definirana članska varijabla koja predstavlja pokazivač na callback funkciju, deklarirana kao: void (*pfrefresh)( OptContResultsWithSolutions<_TypeValue, _TypeSol> &Sol ); i koja će se u funkciji PerformRefreshing() pozvati kada se ustanovi da je ispunjen kriterij za određivanje trenutka osvježavanja ekrana. U nastavku poglavlja, gdje će biti prezentirana hijerarhija razreda za višenitno izvođenje, ovaj objekt će biti dograđen jer u višenitnom načinu rada neće više biti prikladan. 52

53 Čuvanje međurezultata Kod ovog odjeljka je potrebno napomenuti da se ovdje rješava samo problem definiranja trenutka kada će se obaviti snimanje međurezultata. Da bi se problem čuvanja međurezultata potpuno riješio, potrebno je imati spregu između nekog spremnika gdje će se rezultati spremati, i nekog objekta koji će definirati kada će se rezultasti spremati. Ta veza će biti opisana u odjeljku posvećenom opisu izvedbi algoritama za rad u višenitnom načinu izvršavanja Za rješavanje problema trenutka snimanja rezultata, pristup sličan kao i kod prethodna dva navedena gore. Definira se sučelje koje objekti moraju zadovoljavati, i zatim se implementiraju objekti koji će imati ugrađene različite kriterije. Ponovno se kao prirodni nameću razredi koji će definirati kriterij za snimanje rezultata u ovisnosti o izvedenom broju iteracija, za što je definiran razred IterOptSaver, ili o proteklom vremenu, kada se koristi razred TimeOptSaver. Nakon definiranja ovih sučelja, možemo sve skupa sklopiti u jednu cjelinu i navesti kompletnu definiciju razreda IIterativeOptimization. U razred se dodaju tri članske varijable, pokazivači na objekte koji implementiraju sučelja IOptTerminator, IOptRefresher and IOptSaver, IOptTerminator _TypeValue IterativeOptSaver -IterNum : long -CurrItterNum : long IOptSaver +Start() +NextStep()() +IsTimeToSave() _TypeValue, _TyepSol _TypeValue, _TypeSol TimeOptSaver -TimeStarted : float -SaveInterval : float _TypeValue, _TypeSol Slika 6.4: Hijerarhija razreda za određivanje trenutka snimanja rezultata +Start() +NextStep() +IsOptimizationFinished() -pterminator _TypeValue, _TypeSol IOptRefresher +Start() +NextStep() +IsTimeToRefresh() +PerformRefreshing() IOptSaver _TypeValue, _TypeSol -prefresher _TypeValue, _TypeSol IIterativeOptimization -CurrFuncValue : _TypeValue -BestFuncValue : _TypeValue -CurrSolution : _TypeSol -BestSolution : _TypeSol +Initialize() +PerformIteration() +OptFunc() +Optimize() +SetOptTerminatorObject() +SetOptRefresherObject() +SetOptSaverObject() +Start() +NextStep()() +IsTimeToSave() -psaver Slika 6.5: Hijerarhija za razred IIterativeOptimization 53

54 preko kojih će se određivati kriteriji za završetak optimizacije, trenutak osvježavanja ekrana i snimanja međurezultata. Pored te tri članske varijable, u sučelju se definiraju dvije čiste virtualne funkcije, Initialize() i PerformIteration(), koje će izvedeni razredi implementirati na takav način da se u funkciji Initialize() obavlja početna inicijalizacija algoritma, dok se u funkciji PerformIteration() obavlja iteracija algoritma. Kao što je vidljivo iz slike 6.5, gdje je prikazan hijerarhijski odnos razreda IIterativeOptimization sa definiranim razredima sučelja, dodane su i članske varijable BestFuncValue i BestSolution koje predstavljaju najbolje rješenje nađeno tijekom optimizacije te varijable CurrFuncValue, CurrSolution koje predstavljaju trenutno rješenje. Pored toga su definirane i pristupne funkcije SetOptTerminatorObject, SetOptRefresherObject, SetOptSaverObject. Sada se može napisati funkciju Optimize() koja će, koristeći implementacije funkcija Initialize() i PerformIteration() u izvedenim objektim, provesti cijeli postupak optimizacije. _TypeValue IIterativeOptimization::Optimize() { OptContResultWithSolutions<_TypeValue, _TypeSol> IntermedSol; Initialize(); do { PerformIteration(); if( prefresher->istimetorefresh() == true ) prefresher->performrefreshing(currsolution); if( psaver->istimetosave() == true ) IntermedSol.AddSolution(CurrSolution); } pterminator->nextstep(); prefresher->nextstep(); psaver->nextstep(); } while( pterminator->isoptimizationfinished()!= true ); 54

55 6.2.4 Razredi za ugradnju višezadaćnosti S obzirom na napredak računalne znanosti na svim poljima, pa tako i na polju operativnih sustava, u današnje se vrijeme od aplikacija očekuje da budu napisane tako da iskoriste mogućnosti za višenitno izvršavanje, kako bi se korisniku omogućilo da nastavi rad s programom dok se u pozadini obavljaju neke vremenski zahtjevne operacije. Stoga se i prilikom implementacije algoritama za rješavanje kvadratičnog problema pridruživanja nametnuo zahtjev da se izračunavanja obavljaju u posebnoj niti kako bi korisnik za to vrijeme mogao pregledavati već dobivene rezultate, vršiti usporedbe i slično. Za rješavanje tog problema primjenjen je ponovno generički pristup, uz korištenje objektno-orijentirane paradigme. Budući da se svi iterativni algoritmi mogu napisati tako da zadovoljavaju sučelje definirano u razredu IIterativeOptimization, gdje je korištenjem takvog pristupa kao što je opisano u prethodno odjeljku postignuto jednostavnije i elegantnije rješavanje problema zajedničkih svim takvim algoritmima, postavilo se pitanje da li bi se takav pristup mogao primjeniti i na ugradnju višezadaćnosti, jer se pretpostavljalo da će rješenje tog problema za različite iterativne algoritme imati mnogo zajedničkih svojstava. Najprije je potrebno definirati zahtjeve koje bi svaki objekt koji implementira neki iterativni algoritam morao zadovoljavati da bi se mogao izvršavati u višezadaćnom načinu. Kao primarni zahtjev se postavila nužnost postojanja metoda Start() i Terminate() pomoću kojih bi se pokretala i zaustavljala optimizacija. Međutim, odmah se nametnula i potreba za privremenim zaustavljanjem optimizacije, kako bi se mogli npr. promijeniti parametri algoritma, ustanoviti kako napreduje algoritam i slično, pa su pridodane metode Stop(), koja privremeno zaustavlja izvršavanje niti u kojoj se obavlja izračunavanje, i Continue() koja ponovno pokreće nit izračunavanja od točke gdje je ona zaustavljena. Uzimajući u obzir navedene zahtjeve, cilj je definirati razred ThreadableOptObject kojega će nasljeđivati objekti koji će implementirati različite algoritme i koji će interno riješavati sve detalje vezane uz implementaciju višezadaćnosti, dok će prema vanjskim korisnicima razreda davati sučelje koje će se sastojati od funkcija Start(), Stop(), Continue() i Terminate() Implementacija Kod svake implementacije višezadaćnosti u bilo kakvom informacijskom sustavu, najveću je pažnju potrebno posvetiti problemu zajedničkih resursa, odnosno problemu komunikacije među nitima koje se paralelno izvršavaju. Naime, budući da sva interakcija korisnika s niti za izračunavanje ide preko glavnog programa, potrebno je imati vezu preko koje će glavni program i nit izračunavanja komunicirati. Budući da je većina modernih operacijskih sustava napravljena tako da interakcija operacijskog sustava s aplikacijama ide preko reda poruka (eng. message queue), kao prirodno se rješenje nameće upravo takav način komunikacije između niti glavnog programa i niti za izračunavanje. 55

56 Kreiranje niti Prilikom implementiraanja bilo kakvog programskog sustaava koji će u sebi imati ugrađenu višezadaćnost, potrebno se, nažalost, opredijeliti za određeni operacijski sustav budući da razni operacijski sustavi imaju različite funkcije i strukture za rad s redom poruka. Budući da se u ovom radu koristilo Visual C++ razvojno okruženje na PC platformi, kao prirodan odabir se nametnuo izbor operacijskog sustava Windows. Osnovna funkcija operacijskog sustava za kreiranje niti je funkcija int CreateThread( void *pfunc, void *pdata); Kao prvi parametar se predaje pokazivač na funkciju koja će se izvršavati u posebnoj niti i koja mora imati sljedeću deklaraciju unsigned int Func( void *pdata ); Drugi parametar koji se predaje funkciji CreateThread je pokazivač koji će se predati funkciji Func prilikom početka izvršavanja, odnosno na taj način možemo iz glavnog programa predati podatke funkciji koja će se izvršavati u toj niti. Ovdje se odmah može uočiti problem ukoliko se u posebnoj niti želi izvršavati članska funkcija nekog razreda. Naime, članske funkcije razreda imaju drukčiji način pozivanja od običnih (statičkih) funkcija u C++-u, te nije moguće predati pokazivač na člansku funkciju funkciji CreateThread. Razlog tome je što se prilikom svakog poziva članske funkcije razreda implicitno, sakriveno od programera, funkciji prenosi i pokazivač na objekt za koji je funkcija pozvana (pokazivač this). Stoga je potrebno pronaći način kako u posebnoj niti izvršavati člansku funkciju razreda. Kao što je to često slučaj u programskom jeziku C++, problem se može riještiti uvođenjem dodatnog nivoa indirekcije. U razred ThreadableOptObject, koji će implementirati sve potrebne operacije za obavljanje višezadaćnosti, ćemo dodati jednu statičku člansku funkciju, koju ćemo nazvati ThreadFunc, koja će točno zadovoljavati deklaraciju koju očekuje funkcija CreateThread, što znači da će se njena adresa moći predati kao parametar toj funkciji te će se kod koji će se nalaziti unutar te funkcije izvršavati u posebnoj niti. Budući da se radi o statičkoj funkcijji razreda, njoj se ne prenosi pokazivač this [4]. Međutim, to za sobom povlači nezgodnu posljedicu jer statička funkcija ne može pristupati članskim varijablama razreda, osim onima koje su deklarirane kao statičke (statičke varijable razreda su varijable koje su zajedničke svim instancama tog razreda, odnosno svi objekti instancirani iz tog razreda koriste iste varijable). Problem koji sada imamo je sljedeći. Možemo u posebnoj niti izvršavati kod iz funkcije ThreadFunc, ali kako je ta funkcija statička, ne možemo unutar nje koristiti članske varijable objekta unutar kojeg je ona definirana. Budući da mi želimo imati objekte koji će svoje algoritme tako implementirati da koriste članske varijable definirane unutar razreda (jer time postižemo enkapsulaciju podataka), problem još uvijek nije riješen. Ali, problem se može riješiti tako da se funkciji ThreadFunc prilikom poziva funkcije CreateThread preko pokazivača pdata preda upravo pokazivač na objekt za čiju člansku 56

57 funkciju želimo da se pokrene izvršavanje u posebnoj niti, odnosno, ono što prevodila obavlja implicitno za sv ečlanske funkcije, mi ćemo za funkciju ThreadFunc napraviti eksplicitno. Međutim, postavlja se pitanje pokazivač na kakav tip objekta se treba prenijeti funkciji ThreadFunc, i koju člansku funkciju tog objekta pozvati, nakon što smo dobili pokazivač na objekt. Budući da se u ovom radu implementira hijerarhija razreda namijenjena rješavanju optimizacijskih problema, odlučeno je da se uvijek u danom objektu izvodi funkcija Optimize(). Međutim, s obzirom da je C++ strogo tipiziran jezik (znači da se slaganje imena i tipova izvodi prilikom samog prevođenja) prevodiocu se mora dati mogućnost da provjeri da li se u objektu čiju adresu prenosimo funkciji ThreadFunc uopće nalazi definirana funkcija Optimize(). Kako bi se korisnika ove hijerarhije razreda natjeralo da takva funkcija postoji u objektu za koji se poziva ThreadFunc, definiran je poseban apstraktni razred ICalculateObject, sa sljedećom deklaracijom: template<class _TValue, class _TSol> class ICalculateObject { public: virtual void GetAlgDescription( AlgDescription &alg ) = 0; virtual long Optimize( OptContResWithSolutions<_TValue, _TSol> &outres) = 0; }; Funkcija ThreadFunc će se implementirati na takav način da očekuje pokazivač na objekt koji implementira ovo sučelje. Što to konkretno znači? Znači da ukoliko imamo razred za koji želimo da se neko izračunavanje obavlja u posebnoj niti, potrebno je da razred implementira sučelje ICalculateObject te da se kod koji se treba izvršiti u posebnoj niti stavi u funkciju Optimize(), koju taj razred mora imati ugrađenu. Budući da će se svi objekti koji će imati potrebu za korištenjem višezadaćnosti morati izvesti iz razreda ThreadableOptObject, jednostavan način «prisiljavanja» tih objekata na implementaciju sučelja ICalculateObject je da se i razred ThreadableOptObject izvede iz tog apstraktnog razreda, čime automatski i svi razredi izvedeni iz ThreadableOptObject nasljeđuju to sučelje. Funkcija Optimize je parametrizirana kako bi se omogućilo da se implementiraju algoritmi definirani nad različitim strukturama podataka. U definiranom sučelju se može uočiti i funkcija GetAlgDescription koja je dodana kako bi se svaki objekt koji će implementirati određeni algoritam prisililo da ugradi tu funkciju pomoću koje će se moći saznati kratki opis tog algoritma (opis se vraća preko strukture AlgDescription koja je opisana u odjeljku 6.2.2) Vraćanje podataka iz niti u glavni program Sljedeći problem na koji se nailazi je problem vraćanja razultata iz niti izračunavanja u glavni program. Jednostavno rješenje problema bi bilo da se niti izračunavanja preda pokazivač na neku memorijsku lokaciju, čija adresa će biti poznata i glavnom programu, te da se po završetku izračunavanja tamo spremi rezultat. Međutim, kako je općenitost primjene jedan od zahtjeva koji se postavlja na razvijenu hijerarhiju razreda, a u cilju izbjegavaanja rada sa void pokazivačima (što je jedini način ukoliko se želi imati različite tipove rezultata 57

58 izračunavanja), ponovno je primjenjen princip definiranja sučelja (koje će biti parametrizirano u skladu sa tipovima rezultata algoritma): template<class _TValue, class _TSol> class ISaveResultObject { public: virtual bool AddOptResult( OptContResultWithSolutions<_TValue,_TSol> &outresult, AlgDescription &algdesc ) = 0; }; Namjena ovako definiranog sučelja je da predstavlja most između razreda ThreadableOptObject i objekta gdje će se spremati rezultati optimizacije, a koji će implementirati to sučelje. Unutar razreda ThreadableOptObject će postojati pokazivač na objekt koji implementira ovo sučelje, te će unutar funkcije Optimize(), koja obavlja samo izračunavanje, biti jednostavno pristupiti objektu i zapisati konačni rezultat izračunaavanja. Kao rezultat izračunavanja je uzet najopćenitiji razred OptContResultWithSolutions koji u sebi imati i konačni rezultat u vidu vrijednosti funkcije cilja i samog rješenja, a isto tako se, ukoliko sep okaže potreba, mogu tijekom obavljanja funkcije ubacivati i rješenja do kojih je tijekom izvršavanja došao algoritam. Naravno, nužno je da se i ovaj pokazivač preda funkciji ThreadFunc kao parametar. Budući da sada imamo dva parametra koja se treba predati funkciji ThreadFunc, definirati ćemo maksimalno jednostavnu strukturu unutar koje ćemo zapakirati ta dva pokazivača i funkciji ThreadFunc predati pokazivač na tu strukturu, iz koje će ona saznati oba podatka. Struktura je nazvana ThreadParameters i definirana je na sljedeći način: template<class _TValue, class _TSol> class ThreadParameters { public: ThreadParameters( ICalculateObject<_TValue, _TSol> ISaveResultObject<_TValue, _TSol> ) : objcalc(calc), objsave(save) { } &inobjcalc, *inobjsave }; ICalculateObject<_TValue, _TSol> ISaveResultObject<_TValue, _TSol> &objcalc; *objsave; Sada možemo i navesti kod funkcije ThreadFunc, budući da su svi elementi potrebni za njeno definiranje na mjestu: static unsigned int ThreadFunc( void *ppar ) { OptContResultWithSolutions<_TValue, _TSol> outresult; ThreadParameters<_TValue, _TSol> *pthrpar; pthrpar = static_cast<threadparameters<_tvalue, _TSol> *>( ppar ); pthrpar->objcalc.optimize(outresult); } delete pthrpar; return ; 58

59 Nakon definiranja načina izmjene podataka između niti i glavnog programa te načina kreiranja same niti, potrebno je riješiti problem upravljanja tako nastalom niti Upravljanje Kao što je na početku ovog potpoglavlja rečeno, komunikacija između niti i glavnog prograama će se odvijati korištenjem reda poruka, odnosno, korištenjem mehanizma događaja. Funkcije iz Win32 API-ja koje će nam biti od interesa su sljedeće: SuspendThread ResumeThread PostMessage Funkcije iz sučelje koje razred ThreadableOptObject definira a koje su posvećene upravljanju niti su Start, Terminate, Stop i Continue. Prije navođenja samog koda koji implementira funkciju Start, potrebno je reći par riječi o tome na koji način će se izvesti komunikacija preko reda poruka. Implementacija funkcija Start, Stop i Continue je vrlo jednostavna. U funkciji Start je potrebno pomoću funkcije CreateThread kreirati nit, dok će funkcije Stop i Continue tu nit zaustavljati pomoću funkcije SuspendThread, odnosno ponovno pokrenuti pomoću funkcije ResumeThread. Najveći izazov je implementacija funkcije Terminate. Početna ideja je vrlo jednostavna. U razred ThreadableOptObject se stavi logička varijabla bterminate koja će govoriti da li se nit treba završiti (vrijednost true) ili ne (vrijednost false) a u funkciji Terminate se ta varijabla jednostavno postavlja na true. Međutim, ostavljajući po strani mogućnost istovremenog pristupa toj varijabli od strane glavnog programa i niti, postavlja se pitanje što će se dogoditi ukoliko se iz glavnog programa pozove funkcija Terminate koja će postaviti bterminate na true i odmah vratiti kontrolu glavnom programu, a u niti se pravovremeno ne ispita vrijednost te varijable. Budući da je logično vrijednost te varijable provjeravati na početku iteraacije, a kod opisa iterativnog algoritma je rečeno da korak iteracije može biti proizvoljne složenosti, može se desiti da se funkcija unutar niti izvršava dosta dugo prije nego što se, napočetku sljedeće iteracije, ponovno provjeri vrijednost varijable bterminate. Problem je što u međuvremenu glavni program očekuje da je nit završena te se objekt koji je namijenjen za pospremanje rezultata izračunavanja niti može izbrisati iz memorije. Kada nit konačno provjeri vrijednost varijable bterminate i ustanovi da je postavljena na true, nit završava izračunavanje i pokušava spremiti svoj rezultat u objekt koji više ne postoji. Da bi se riješio ovaj problem, potrebno je na neki način zaustaviti izvođenje funkcije Terminate sve dok se ne ustanovi da je nit doista završila. U tu svrhu se može iskoristiti mehanizam događaja (eng. events) koji je dio Win32 API-a. Događaji predstavljaju objekte operacijskog sustava koji mogu biti u postavljenom i nepostavljenom stanju. Funkcije koje su za nas bitne, a dio su Win32 API-ja su sljedeće: CreateEvent SetEvent 59

60 WaitForSingleObject Korištenjem funkcije CreateEvent se događaj kreira, te se od funkcije dobija rukovatelj (eng. handle) pomoću kojeg se taj događaj može identificirati. Funkcija SetEvent postavlja događaj, a funkcija WaitForSingleObject čeka sve dok određeni događaj ne dođe u postavljeno stanje. Način korištenja ovog mehanizma je sada evidentan. Funkcija Terminate će nakon postavljanja vrijednosti varijable bterminate na true, pozvati funkciju WaitForSingleObject koja će čekati na događaj koji će u postavljeno stanje postaviti funkcija Optimize nakon što završi optimizaciju. Sada možemo dati cijelu deklaraciju raazreda ThreadableOptObject, sa svim funkcijama i članskim varijablaama: template<class _TValue, class _TSol> class ThreadableOptObject : public ICalculateObject<_TValue, _TSol>, public IIterativeOptimization<_TValue, _TSol> { public: ThreadableOptObject(); ThreadableOptObject( IOptTerminator *inpterm, ISaveResultObject<_TValue, _TSol> *inpsave) : psave(inpsave), IIterativeOptimization<_TValue, _TSol>(inpTerm) void void void void Start(); Stop(); Continue(); Terminate(); static unsigned int ThreadFunc( void *ppar ); virtual long Optimize( IterOptContResWithSolutions<_TValue, _TSol> &res ); bool SaveFinalResults(IterOptContResWithSolutions<_TValue, _TSol> &Res) { void setsaveobject( ISaveResultObject<_TValue, _TSol> *inpsave ) { bool IsCalcInProgress() { return bcalcinprogress; } bool IsCalcStopped() { return bcaclstopped; } // ove funkcije će morati definirati algoritmi za optimizaciju virtual bool Initialize() = 0; virtual bool PerformIteration() = 0; // funkcija koja se optimira virtual _TValue OptFunc( _TSol &a ) = 0; private: ISaveResultObject<_TValue, _TSol> *psave; HANDLE hthread; HANDLE hterminateevent; }; bool bterminate; // istina kada je potrebno završiti optimizaciju bool bcalcstopped; // istina ukoliko je optimizacija privremeno zaustavljena bool bcalcinprogress; // istina ukoliko je optimizacijaa u tijeku 60

61 Kao što je već navedeno, psave je pokazivač na objekt koji će se pobrinuti za snimanje konačnog rezultata, hthread je rukovatelj nit, a hterminateevent rukovatelj događaja koji signalizira završetak optimizacije. Također se može navesti i implementacija svih funkcija za upravljanje niti: void Start() { ThreadParameters<_TValue, _TSol> *pthrpar; pthrpar = new ThreadParameters<_TValue, _TSol>(*this, psave); hterminateevent = CreateEvent ( NULL, FALSE, FALSE, NULL); if ( hterminateevent == NULL ) return; DWORD IDThread; hthread = CreateThread ( NULL, 0, ThreadFunc, pthrpar, 0, &IDThread ); } if ( hthread == NULL ) return; bcalcinprogress = true; // greška kod stvaranja niti void Stop() { if ( bcalcstopped == false && hthread!= NULL ) { SuspendThread ( hthread ); bcalcstopped = true; } } void Continue() { if ( bcalcstopped == true && hthread!= NULL ) { ResumeThread ( hthread ); bcalcstopped = false; } } void Terminate() { if ( bcalcinprogress == true ) { // ukoliko je nit zaustavljena, treba je ponovno pokrenuti if ( bcalcstopped == true ) Continue(); } } bterminate = true; // sada moramo čekati da dobijemo potvrdu od niti izračunavanja da je završila WaitForSingleObject ( hterminateevent, INFINITE ); bcalcinprogress = false; 6

62 Konačno, možemo napisati i kompletnu funkciju Optimize(): virtual long Optimize( OptContResultWithSolutions<_TValue, _TSol> &res ) { Watch.Start(); Initialize(); ptermobj->start(); CurrIterNum = 0; while( ptermobj->isoptimizationfinished() == false ) { // neka izvedeni algoritam obavi svoj korak iteracije PerformIteration(); if( prefreshobj!= NULL && prefreshobj->istimetorefresh(currfuncvalue) ) { OptimizationResult<_TValue, _TSol> opt( CurrFuncValue, CurrSolution, Watch.GetRunningTime(), CurrIterNum ); prefreshobj->performrefreshing(opt, BestFuncValue, &BestSolution); } if( psaveobj!= NULL && psaveobj->istimetosave( CurrFuncValue ) ) { res.addsolution( CurrIterNum, CurrFuncValue ); } ptermobj->nextstep(&bestfuncvalue); prefreshobj->nextstep(null); psaveobj->nextstep(null); CurrIterNum++; } if( bterminate == true ) { if( hterminateevent!= NULL ) { SaveFinalResults(res); SetEvent(hTerminateEvent); } break; } // snimamo konačni rezultat // obaviještavamo glavni program da smo završili // ovdje snimamo rezultat samo ukoliko je optimizacija došla do svog prirodnog kraja if( bterminate == false ) SaveFinalResults(res); bcalcinprogress = false; return 0; } 62

63 Obavljanje osvježavanja Kod rješavanja problema osvježavanja potrebno je riješiti problem komunikacije između niti glavnog programa i niti izračunavanja. Dva problema su prisutna. Jedan se odnosni na način prijenosa podataka između dvije niti, a drugi na definiranje mehanizma kojim će niti međusobno komunicirati. Prvi problem je riješen definiranjem novog objekta, nazvanog ExchangeDataObject, dok se za rješavanje drugog iskoristio red poruka u Windows operacijskom sustavu. Da bismo prenijeli podatke iz jedne niti u drugu potrebno je da obe niti dijele neki zajednički resurs preko kojega će se obaviti prijenos. U najjednostavnijem slučaju to može biti običan dio memorije, čiju će adresu imati obje niti, ali zbog primjene principa enkapsulacije definiran je poseban objekt : template<class _TValue, class _TSol> class ExchangeDataObject { public: ExchangeDataObject( HWND inhwnd ); ExchangeDataObject( HWND inhwnd, _TValue &val, _TSol &sol ); virtual void SetResult( IterativeOptRes<_TValue, _TSol> _TSol &inbestsolution ) { m_bestvalue = inbestvalue; m_bestsolution = inbestsolution; m_currresult = CurrSol; CurrSol, _TValue &inbestvalue, PostMessage(m_hWnd, WM_REFRESH_MESSAGE, 0, 0); } virtual void GetResult( IterativeOptRes<_TValue, _TSol> *CurrSol, _TValue *val, _TSol *sol ); public: HWND m_hwnd; }; _TValue m_bestvalue; _TSol m_bestsolution; OptimizationResults<_TValue, _TSol> m_currresult; Objekt je vrlo jednostavan, i osim konstruktora i dvije pristupne funkcije za stavljanje i uzimanje podataka, ima članske varijable koje čine podatke koji se prenose između dvije niti. Varijabla m_hwnd je potrebna za implementiranje mehanizma komunikacije. Kao što je u uvodu rečeno, iskoristiti će se mehanizam reda poruka, što znači da će nit izračunavanja nakon što dođe do podataka s kojima treba osvježiti ekrana, jednostavno pozvati funkciju SetResult nad definiranim objektom, a on će dalje pomoću funkcije PostMessage poslati poruku WM_REFRESH_MESSAGE (ovo predstavlja identifikator poruke i u stvari je najobičniji cijeli broj) koju će uhvatiti objekt za ispis, što će mu biti znak da su na raspolaganju novi rezultati. Varijabla m_hwnd predstavlja rukovatelj prozora kojemu će se poslati poruka. 63

64 IOptRefresher _TypeValue, _TypeSol +Start() +NextStep() +IstTimeToRefresh() +PerformRefreshing() _TypeValue, _TypeSol _TypeValue, _TypeSol OptRefreshSingleThread -*prefresh OptRefreshMultiThread -*pexch : ExchangeDataObject IterativeRefreshST -IterNum : long -CurrIterNum : long _TypeValue, _TypeSol TimeRefresherST -TimeStarted : float -RefreshInterval : float _TypeValue, _TypeSol IterativeRefreshMT -IterNum : long -CurrIterNum : long _TypeValue, _TypeSol TimeRefreshMT -TimeStarted : float -RefreshInterval : float _TypeValue, _TypeSol Slika 6.6 Hijerarhija razreda za obavljanje osvježavanja Međutim, sada je potrebno prilagoditi hijerarhiju razreda definiranu u odjeljku koji su bili namijenjeni za osvježavanje ekrana. Budući da sada imamo višenitno izračunavanje, jednostavan mehanizam gdje se funkcija PerfomRefreshing obavljala tako da se preko call-back funkcije pozove funkcija za ispis na ekrana, više neće biti dobar. Nova hijerarhija je prikazana na slici 6.6, i u njoj se mogu uočiti sljedeće modifikacije. Razred IOptRefresher je ostao isti jer u biti on samo definira sučelje, ali su uvedena dva nova razreda OptRefreshSingleThread i OptRefreshMultiThread, čija je namjena, kao što im i samo ime govori, da implementiraju osvježavanje u slučaju običnog jednonitnog, odnosno višenitnog izvršavanja. Razlika se očituje u funkciji PerformRefreshing. Razred OptRefreshSingleThread ima u sebi kao člansku varijablu pokazivač na callback funkciju koja će se jednostavno pozvati unutar funkcije PerformRefreshing, dok razred OptRefreshMultiThread ima pokazivač na ExchangeDataObject nad kojim će se pozvati metoda SetResult, koja će se dalje pobrinuti za sve ostalo. Deklaracija bitnih dijelova razreda je sljedeća: template<class _TValue, class _TSol> class OptRefreshSingleThread : public IOptRefresher<_TValue, _TSol> { private: void (*prefreshfunc)( IterativeOptRes<_TValue, _TSol> &CurrSol, _TValue Best, const _TSol *BestSol ); public: OptRefreshSingleThread( long IterNum ); virtual void PerformRefreshing( IterativeOptRes<_TValue, _TSol> &CurrSol, _TValue Best, const _TSol *BestSol ) { if( prefreshfunc!= NULL ) (*prefreshfunc)(currsol,best,bestsol); } }; 64

65 template<class _TValue, class _TSol> class OptRefreshMultiThread : public IOptRefresher<_TValue, _TSol> { private: ExchangeDataObject<_TValue, _TSol> *pexdata; public: OptRefreshMultiThread(); void AssignPointerToExchangeData( ExchangeDataObject<_TValue, _TSol> *inpexdata ){ pexdata = inpexdata; } }; virtual void PerformRefreshing( IterativeOptRes<_TValue, _TSol> &CurrSol, _TValue Best, _TSol *BestSol ) { if( pexdata!= NULL ) { pexdata->setresult( CurrSol, Best, *BestSol); } } Problem koji se sada javlja, a koji je vidljiv iz prikazane hijerarhije na slici 6.6 je da je unutar svake od dviju grana hijerarhije potrebno definirati praktički iste objekte, IterativeOptRefresher i TimeOptRefresher. Nažalost, to je cijena koja se mora platiti za definiranje zajedničke hijerarhije za osvježavanje u jednonitnom i višenitnom slučaju. Sada se postavlja pitanje na koji način se može iskoristiti ovako definirana hijerarhija. Pretpostavimo da imamo objekt OptObject koji je izveden iz razreda ThreadableOptObject i koji implementira neki algoritam za izračunavanje. Također pretpostavimo da postoji dijalog ControlDlg, sa upravljačkim dugmetima Start i Stop namijenjenim pokretanju i zaustavljanju izračunavanja. Da bi iskoristili definirane razrede potrebno je u kod funkcije koja će se izvršiti pritiskom na dugme Start staviti sljedeći kod: OptRefreshMultiThread<float, SolType> *prefobj; // u razredu controldlg je potrebno definirati funkciju GetRefObject koja će na osnovu // odabranog kriterija osvježavanja (nakon određenog broja iteracija, vreman,.. ) // kreirati odgovarajući objekt i vratiti ga prefobj = GetRefreshObj(); pexch = new ExchangeDataObject<float, SolType>(this->m_hWnd); prefobj->assignpointertoexchangedata(pexch); poptobj = new OptObject (... ); poptobject->setoptrefresherobject(prefobj); poptobj->start(); dok se u kod funkcije koja se poziva nakon pritiska na dugme Stop treba samo pozvati funkcija Terminate poptobj->terminate(); 65

66 Pored toga, u razredu dijaloga je potrebno definirati funkciju koja će hvatati poruku WM_REFERSH_MESSAGE, i koja će obavljati ispis novoprispjelih podataka na ekran. Da bi se lakše uočito vremenski slijed događaja, na slici 6.7 je prikazan interakcijski dijagram u UML notaciji za jedan jednostavan scenario. U prikazanom interakcijskom dijagramu se mogu uočiti dvije niti izvršavanja, koje su prikazane pomoću uskih pravokutnika koji se spuštaju od vrha prema dolje (po toj osi je definiran tijek vremena). Pomoću strelica su prikazane poruke koje se izmjenjuju među objektima, koji su prikazan ina vrhu pomoću pravokutnika. Linija života (eng. lifeline) pojedinog objekta je prikazana pomoću isprekidane crtice, a kada je objekt aktivan, odnosno kada se unutar neke njegove članske funkcije izvršava neka nit, isprekidana linija se pretvara u pravokutnik određene teksture i boje. Ovako definirana hijerarhija razreda ima višestruke prednosti. Ukoliko nema potrebe za obavljanjem izračunavanja u višenitnom načinu, jednostavno se prilikom implementacije algoritma koristi nasljeđivanje iz razreda IIterativeOptimization koji pruža svu potrebnu infrastrukturu za implementaciju algoritma, te je potrebno napisati samo programski kod za inicijalizaciju algoritma u funkciji Initialize te kod za obaavljanje iteraciju funkciji PerformIteration. S druge strane, ukoliko je višenitno izračunavanje bitno za algoritam, jednostavno se objekt koji će obavljati izračunavanje izvede iz razreda ThreadableOptObject i sva potrebna infrastruktura je na mjestu, s time da je osim funkcija Initialize i PerformIteration, potrebno još i definirati objekte preko kojih će se obavljati razmjena podataka između niti i glavnog programa. 66

67 ControlDlg SaveResultObject Start() new() poptobj new() IOpt objects set IOpt objects() new() ExchangeDataObject *pexch Start() () StartThread() ThreadFunc new() res Optimize() PerformRefresh() SetResult() PostMessage() () Refresh Msg() GetData() Refresh() Stop() Terminate() Wait() delete() SetEvent() delete() () AddOptimizationResult() delete() Slika 6.7 Interakcijski dijagram. 67

68 6.3 Razredi za rješavanje QAP-a Kod implementacije algoritama za rješavanja kvadratičnog problema pridruživanja mogu se uočiti njihove sljedeće zajedničke karakteristike: - problem je opisan pomoću dviju matrica A i B, koje predstavljaju ulaz za algoritam, te cijelog broja N koji predstavlja veličinu problema - svi algoritmi će primjenjivati isti postupak za izračunavanje promjene funkcije cilja prilikom zamjene lokacija dvaju uslužitelja Kod implementacije svih algoritama prijemenjen je objektni pristup koji uvjetuje stavljanje podataka i algoritama koji djeluju nad tim podacima unutar razreda, kako bi se cjelokupna implementacija zatvorila u jednu zatvorenu cjelinu. Principi enkapsulacije nalažu da se pristup podacima definiranim unutar razred omogući preko pristupnih funkcija te da se tako od korisnika razreda sakriju detalji unutrašnje implementacije. Međutim, takav način implementacije bi vodio k tome da bi svaki razred koji implementira neki algoritam za rješavanje QAP-a u sebi imao definirane iste podatke i iste funkcije. Da bi se izbjeglo takvo dupliciranje programskog koda, definiran je osnovni razred QAPSolver, unutar kojega su definirani podaci i funkcije zajedničke svim algoritmima za rješavanje QAP-a. Time je razred QAPSolver postao bazni (ili osnovni) razred hijerarhije iz kojeg će se primjenom nasljeđivanja izvoditi svi ostali razredi s implementacijom algoritma za rješavanje QAP-a. Međutim, nakon definiranja takvog razreda uočena je mogućnost različitih struktura matrica koje sadrže podatke koji definiraju QAP. Naime, matrice A i B mogu biti simetrične ili asimetrične, gdje se razlika ta dva slučaja očituje u načinu izračunavanja promjene iznosa funkcije cilja kod obavljanja zamjene lokacija dva uslužitelja. Za rješavanje ovog problema moguća su dva pristupa. Prvi predstavlja korištenje generičkog programiranja pomoću uzoraka kod kojeg bi se vrsta matrice za QAP definirala kao parametar, dok se kod drugog pristupa koristi polimorfizam na način da se definira apstraktni bazni razred koji definira samo sučelje za objekte koji će riješavati QAP, te se iz njega izvode konkretni razredi koji implementiraju postupke za određeni tip matrica. Budući da su se u ovom radu isključivo kao ulazni podatak algoritma koristile simetrične matrice, hijerarhija razreda je tako modelirana te ovoj problematici nije posvećeno više pažnje, tako da je primjenjen drugi pristup, što se vidi i iz definirane hijerarhije razreda. Sučelje koje mora zadovoljavati svaki objekt koji će implementirai algoritam za rješavanje QAP se sada može definirati kao: class IQAPSolver { public: virtual float CalcOptFunc( QAPSolution &Sol ) = 0; virtual float CalcExchangeValue( int i, int j, const QAPSolution &Sol ) = 0; virtual void GetAlgDescription( AlgDescription &alg ) = 0; 68

69 protected: int nfacilitynum; }; Iz tako definiranog sučelja se sada mogu izvesti tri čvorna razreda [3], od kojih će svaki definirati sučelje za algoritam rješavanja nad određenim tipom matrice. IQAPSolver -nfacilitynum +CalcExchangeValue() +OptFunc() +GetAlgDescription() QAPSolver -A : SymmetricMatrix -B : SymmetricMatrix QAPSolverAsymmetric -A : Matrix -B : Matrix QAPSolverSparse -A : SparseMatrix -B : SparseMatrix Slika 6.8 Vrh hijerarhije razreda za rješavanje QAP-a. S obzirom na već navedenu napomenu o strukturi problema koji su se istraživali u ovom radu, dalje će biti razvijana hijerarhija razreda samo za QAPSolver koji pretpostavlja da su matrice problema simetrične. Implementacija svih algoritama za rješavanje QAP-a će biti izvedena na sljedeći način. Biti će definiran poseban razred za svaku metodu rješavanja, koji će biti izveden iz razreda QAPSolver kako bi se iskoristile stvari koje su definirane u tom razredu, a isto tako i da bi svi razredi za rješavanje zadovoljavali isto sučelje. Dodatno, kako bi se omogućilo da se izvedeni razredi mogu koristiti u višenitnom režimu rada, a s obzirom da programski jezik C++ podržava višestruko nasljeđivanje, razredi koji će implementirati različite algoritme će biti izvedeni i iz razred ThreadableOptObject, što će im omogućiti da koriste cijeli skup mogućnosti koje pruža taj razred. Naravno, izvedni razredi će morati zadovoljavati sučelje razreda ThreadableOptObject, odnosno, morati će implementirati funckije Initialize i PreformIteration, ali budući da su svi korišteni algoritmi iterativni, takav pristup implementaciji će biti prirodan Implementacija funkcija za lokalno pretraživanje Kao što je u petom poglavlju već navedno, postoje tri različita načina pretraživanja okoline kod implementacije lokalnog pretraživanja: metoda prvog poboljšanja, metoda najboljeg poboljšanja te Heiderova metoda. U razvijenoj hijerarhiji razreda za rješavanje QAP-a, implementirane su sve tri metode, s time da je za definiciju okoline korištena metoda zamjene parova. 69

70 Za razliku od implementacija ostalih algoritama, koji su svi implementirani kao posebni razredi, navedeni algoritmi lokalnog pretraživanja su implementirani na dva načina: na standardni način (opisan u prethodnom odjeljku) kao razredi koji su izvedeni iz razreda QAPSolver i ThreadableOptObject, te dodatno kao funkcije unutar samog razreda QAPSolver. Na prvi pogled, time se duplicira programski kod jer će definirani razredi unutar sebe imati isti kod dva puta: jedan put u funkcijama koje će naslijediti iz razreda QAPSolver, a drugi put prilikom implementacije funkcija Initialize i PerformIteration što je nužno zbog izvođenja iz razreda ThreadableOptObject. Korist od takvog dupliciranja koda će se manifestirati kod implementacije razreda za rješavanje pomoću genetičkog algoritma i simuliranog kaljenja. Naime, hibridni genetički algoritmi (definirani u odjeljku ), a i neke od implementacije algoritama simuliranog kaljenja, u svakoj iteraciji obavljaju lokalno pretraživanje nad rješenjima do kojih su došli kako bi se ta rješenja maksimalno poboljšala. S obzirom da se svi implementirani razredi za rješavanje QAP-a izvode iz razreda QAPSolver, stavljanjem funkcija koje obavljaju to lokalno pretraživanje u razred QAPSolver je u stvari postignuto smanjenje dupliciranja koda, jer bi inače trebalo taj isti kod trebalo pisati unutar svakog razreda koji će primjenjivati postupak lokalnog pretraživanja. Sama implementacija metoda je vrlo jednostavna. Kod definiranja razreda za rješavanje QAP-a ovom metodom u funkciju Initialize je stavljen kod za kreiranje slučajnih početnih rješenja: bool Initialize() { CurrSolution.Resize(getFacilityNum()); BestSolution.Resize(getFacilityNum()); CurrSolution.GenerateRandom(); BestSolution = CurrSolution; CurrFuncValue = BestFuncValue = OptFunc(CurrSolution); } return true; dok se u funkciji PerformIteration pretraživala cijela okolina (navedena je implementacija funkcije PerformIteration za razred QAPSolverLSFirstImprovement): bool PerformIteration() { int i, j; float delta; for( i=; i<getfacilitynum(); i++ ) for( j=i+; j<=getfacilitynum(); j++ ) { delta = CalcExchangeValue(i, j, CurrSolution); if( delta < 0 ) { CurrSolution.Exchange(i,j); BestSolution = CurrSolution; 70

71 CurrFuncValue = BestFuncValue = OptFunc(CurrSolution); // čim smo našli prvo poboljšanje, iteracija je gotova return true; } } // ako nismo našli poboljšanje, treba završiti optimizaciju jer smo u lokalnom minimumu TerminateOptimization(); } return true; Naravno, unutar tri definirana razreda, nazvana QAPSolverBestImprovement, QAPSolverFirstImprovement, QAPSolverHeiderMethod, implementacija funkcije PerformIteration se donekle razlikovala, budući da se npr. u slučaju korištenje metode prvog poboljšanja se u danoj iteraciji odmah prekida daljnje traženje čim se nađe bolje rješenje od trenutnoga, kod metode najboljeg poboljšanja se pretraži cijela okolina kako bi se našlo najbolje rješenje, dok je Heiderova metoda negdje između: svako bolje rješenje se odmah prihvaća, ali se pretraživanje okoline nastavlja od točke gdje je nađeno bolje rješenje, za razliku od metode prvog poboljšanja gdje pretraživanje kreće ispočetka (u implementacijama metoda je korišten sljedeći redoslijed pretraživanja okoline, što se vidi i iz gore napisanih petlji (,2), (,3), (,4),... (,n), (2,),..., (n-,n)). Osim implementacija funkcija Initialize i PerformIteration, u definiranim razredima je bilo još potrebno implementirati funkciju GetAlgDescription pozivom koje se nad instanciranim objektom za rješavanje QAP-a može dobiti opis algoritma Razredi za rješavanje QAP-a tabu-search algoritmom U ovome radu su implementirana četiri različita algoritma za rješavanje kvadratičnog problema pridruživanja pomoću tabu-search metode. Kao što je u petom poglavlju već rečeno, osnovni sastojci tabu-search algoritma su način definiranja liste zabranjenih poteza i aspiracijske funkcija. Budući da se svaki od ova dva sastavna elementa algoritma može definirati na dva načina, različitim kombinacijama se dobivaju četiri različita algoritma. Kod implementacije razreda za rješavanje kvadratičnog problema pridruživanja pomoću tabu-search metode uočeno je da se navedena četiri algoritma razlikuju samo po tome na koji način se definira odgovor na pitanje da li je potez zabranjen ili ne, i po odgovoru na aspiracijski kriterij, odnosno da li navedeni potez zadovoljava aspiracijski kriterij ili ne. Stoga je definiran jedan općeniti razred QAPSolverTabuSearchGeneral unutar kojeg je implementiran sam algoritam, sa definiranim funkcijama Initialize i PerformIteration, dok su različiti kriteriji određivanja statusa poteza prebačeni na pomoćne razrede. To je izvedeno na sljedeći način. Najprije su definirana dva razreda sučelja IIsTaboMove i IIsSatisfiedAspiration sa sljedećom deklaracijom: 7

72 class IIsTabuMoveQAP { public: virtual bool IsTabuMove( int i, int j, const QAPSolution &CurrSol, int CurrIterNum, int TabuListSize ) = 0; }; virtual void SetInitialAssignment( const QAPSolution &Sol ) = 0; // moraju znati kada se u algoritmu napravi neki potez virtual void MovePerformed( int i, int j, const QAPSolution &CurrSol, int CurrIterNum, int TabuListSize ) = 0; class IIsSatisfiedAspiration { public: virtual bool IsSatisfiedAspiration( int r, int s, const QAPSolution &CurrSol, int CurrIterNum, float MoveValue) = 0; }; virtual void SetInitialAssignment( const QAPSolution &Sol, float ininitialfuncvalue ) = 0; // moraju znati kada se u algoritmu napravi neki potez virtual void MovePerformed( int i, int j, const QAPSolution &CurrSol, int CurrIterNum, float MoveValue ) = 0; Iz tako definiranih sučelja su izvedena po dva konkretna razreda unutar kojih su implementirani odgovarajući kriteriji za određivanje da li je potez zabranjen, odnosno da li potez zadovoljava aspiracijski kriterij: // Skorin-Kapov pristup // matrica NextVisitAllowed[i][j] sadrži redni broj iteracije kada će ponovno biti dozvoljena potez // koji zamjenjuje jedinke na lokacijama i i j class IsTabuMoveSK : public IIsTabuMoveQAP { public: IsTabuMoveSK( int N ) : NextVisitAllowed(N,N) { NextVisitAllowed.Clear(); } bool IsTabuMove( int i, int j, const QAPSolution &CurrSol, int CurrIterNum, int TabuListSize ) { return( NextVisitAllowed[i][j] > CurrIterNum && NextVisitAllowed[j][i] > CurrIterNum ); } void MovePerformed( int i, int j, const QAPSolution &CurrSol, int CurrIterNum, int TabuListSize ) { NextVisitAllowed[i][j] = CurrIterNum + TabuListSize; NextVisitAllowed[j][i] = CurrIterNum + TabuListSize; } private: Math::Matrix<int> NextVisitAllowed; }; // Taillardov pristup // Matrica LastTimeAssigned[i][j] sadrži redni broj iteracije kada je zadnji put obavljen potez koji // mijenja sadržaj na lokacijama i i j 72

73 class IsTabuMoveT : public IIsTabuMoveQAP { public: IsTabuMoveT( int N ) : LastTimeAssigned(N,N) { for( int i=; i<=n; i++ ) for( int j=; j<=n; j++ ) LastTimeAssigned[i][j] = ; } void SetInitialAssignment( const QAPSolution &Sol ) { // moramo zapamtiti kako su u početku ( iteracije 0 ) bile raspodijeljene jedinke for( int i=; i<=sol.getsize(); i++ ) LastTimeAssigned[i][Sol(i)] = 0; } bool IsTabuMove( int i, int j, const QAPSolution &CurrSol, int CurrIterNum, int TabuListSize ) { return( LastTimeAssigned[i][CurrSol(j)] >= CurrIterNum-TabuListSize && LastTimeAssigned[j][CurrSol(i)] >= CurrIterNum-TabuListSize ); } void MovePerformed( int i, int j, const QAPSolution &CurrSol, int CurrIterNum, int TabuListSize ) { LastTimeAssigned[i][CurrSol(j)] = CurrIterNum; LastTimeAssigned[j][CurrSol(i)] = CurrIterNum; } private: Math::Matrix<int> LastTimeAssigned; }; // pristup primjenjen kod jednostavne aspiracijske funkcije gdje se uzima da je aspiracijski // kriterij zadovoljen ukoliko se dobija rješenje koje je bolje od najboljeg dosada pronađenoga class IsSatisfiedAspirationFirst : public IIsSatisfiedAspiration { public: bool IsSatisfiedAspiration( int r, int s, const QAPSolution &CurrSol, int CurrIterNum, float MoveValue ) { return ( CurrFuncValue + MoveValue < BestFuncValue ); } void SetInitialAssignment( const QAPSolution &Sol, float ininitialfuncvalue ) { CurrFuncValue = BestFuncValue = ininitialfuncvalue; } void MovePerformed( int i, int j, const QAPSolution &CurrSol, int CurrIterNum, float MoveValue) { CurrFuncValue += MoveValue; if( CurrFuncValue < BestFuncValue ) BestFuncValue = CurrFuncValue; } private: float CurrFuncValue; float BestFuncValue; }; 73

74 // implementacija pristupa kod kojega aspiracijska funkcija vrši diversifikaciju rješenja, odnosno // uzima se da je aspiracijski kriterij zadovoljen ukoliko se uslužitelj dodjeljuju na lokacije na kojima // nisu bili unutar zadnjih AspFuncParamT iteracija class IsSatisfiedAspirationSecond : public IIsSatisfiedAspiration { public: IsSatisfiedAspirationSecond( int infacnum, long inaspfuncparamt ) { plastassignediteration = new Math::Matrix<int>(inFacNum,inFacNum); for( int i=; i<=infacnum; i++ ) for( int j=; j<=infacnum; j++ ) (*plastassignediteration)[i][j] = ; } AspFuncParamT = inaspfuncparamt; bool IsSatisfiedAspiration( int r, int s, const QAPSolution &CurrSol, int CurrIterNum, float MoveValue ) { if ( (*plastassignediteration) [r] [CurrSol(s)] <= CurrIterNum-AspFuncParamT && (*plastassignediteration) [s] [CurrSol(r)] <= CurrIterNum-AspFuncParamT ) return true; else return false; } void SetInitialAssignment( const QAPSolution &Sol, float ininitialfuncvalue ) { for( int i=; i<=sol.getsize(); i++ ) (*plastassignediteration) [i] [Sol(i)] = 0; } void MovePerformed( int i, int j, const QAPSolution &CurrSol, int CurrIterNum, float MoveValue ) { (*plastassignediteration) [i] [CurrSol(j)] = CurrIterNum; (*plastassignediteration) [j] [CurrSol(i)] = CurrIterNum; } private: long AspFuncParamT; Math::Matrix<int> *plastassignediteration; }; Kako bi razred QAPSolverTabuSearchGeneral mogao iskoristiti tako definirane razrede, unutar njega su stavljene dvije članske varijable, pokazivači na navedena sučelja, što se može vidjeti i iz deklaracije razreda: enum AspirationFunctionType { FIRST, SECOND }; enum IsTabuMoveType { SKORIN_KAPOV, TAILLARD }; class QAPSolverTabuSearchGeneral : public QAPSolver, public ThreadableOptObject<float, QAPSolution> { public: 74

75 QAPSolverTabuSearchGeneral( int infacnum, IOptTerminator *inpterm, int intabulistsize = 30, int indeltatabulistsize = 5, long inaspfuncparamt = 000, IsTabuMoveType intabumovetype = SKORIN_KAPOV, AspirationFunctionType inaspfunctype = FIRST ); bool FindBestMove( int *best_s, int *best_r, float *BestMoveValue, float FuncValue, float BestSoFar, const QAPSolution &Sol ); float OptFunc( QAPSolution &a ) { return CalcOptFunc(a); } bool Initialize(); bool PerformIteration(); protected: int TabuListSize, InitialTabuListSize; int DeltaTabuListSize, TabuListSizeChangePeriod ; long AspFuncParamT; }; IIsTabuMoveQAP IIsSatisfiedAspiration *ptabumove; *paspiration; Kako bi se do kraja razjasnio način na koji se koriste ti pokazivači, navodimo kod funkcije PerformIteration: bool QAPSolverTabuSearchGeneral::PerformIteration() { // provjeri da li je došlo vrijeme za promejnu veličine tabu-liste if( TabuListSizeChangePeriod!= 0 && CurrIterNum % TabuListSizeChangePeriod == 0 ) { // određujemo novu veličinu tabu-liste u rasponu [TS-Delta, TS+Delta] TabuListSize = InitialTabuListSize + (((float)rand()) / RAND_MAX) * 2 * DeltaTabuListSize - DeltaTabuListSize; } if( FindBestMove( &best_s, &best_r, &BestMoveValue, CurrFuncValue, BestFuncValue, CurrSolution) == false ) { // ukoliko ne možemo naći nikakav najbolji potez, znači da nijedan nije dopušten return false; } // napravi potez ptabumove->moveperformed( best_s, best_r, CurrSolution, CurrIterNum, TabuListSize ); paspiration->moveperformed( best_s, best_r, CurrSolution, CurrIterNum, BestMoveValue ); int t = CurrSolution[best_s]; CurrSolution[best_s] = CurrSolution[best_r]; CurrSolution[best_r] = t; 75

76 // ažuriraj funkciju cilja CurrFuncValue += BestMoveValue; } if( CurrFuncValue < BestFuncValue ) { BestFuncValue = CurrFuncValue; BestSolution = CurrSolution; } return true; Iz navedenog programskog koda se vidi da je, što se razreda QAPSolverTabuSearchGeneral tiče, sasvim svejedno na kakav konkretno tip objekta pokazuju spomenuta dva pokazivača, dok god se radi o objektima koji implementiraju navedena sučelja. Ovim pristupom se omogućilo jednostavno implementiranje četiri razreda za rješavanje QAP pomoću četiri različita tabu-search algoritma. Sve što je bilo potrebno napraviti je da se ta četiri razreda izvedu iz razreda QAPSolverTabuSearchGeneral, te da se u konstruktoru instanciraju konkretni objekti i njihove adrese pridruže članskim varijablama, na sljedeći način: class SimpleTabuSearchQAPSolver : public QAPSolverTabuSearchGeneral{ public: SimpleTabuSearchQAPSolver( int infacnum, IOptTerminator *inpterm, int intabulistsize = 30 ) : QAPSolverTabuSearchGeneral( infacnum, inpterm, intabulistsize, 0, 0, SKORIN_KAPOV, FIRST ) { } }; void GetAlgDescription( AlgDescription &alg ) { alg.settype("tabu search "); alg.setsubtype("simple " ); alg.setautomaticoptid(); alg.addparam("t.list size ", (long)gettabulistsize(), "%ld", 'I' ); } Također se vidi na koji način se implementira funkcija GetAlgDescription, koju moraju definirati svi razredi izvedeni iz ThreadableOptObject, čijim pozivom se može saznati opis algoritma s kojim je izvršena optimizacija, te popis parametara. Pored gore navedenog razreda SimpleTabuSearchQAPSolver, koji koristi Skorin-Kapov pristup za određivanje liste zabranjenih poteza i jednostavnu aspiracijsku funkciju, definirani su još i sljedeći razredi: - SimpleDiversifyTabuSearchQAPSolver također se koristi Skorin-Kapov lista zabranjenih poteza, ali uz diversifikacijsku apsiracijsku funkciju - RobustTabuSearchQAPSolver Taillardova implementacija robusnog tabu search algoritma kod koje se veličina liste zabranjenih poteza mijenja, uz običnu aspiracijsku funkciju - RobustDiversifyTabuSearchQAPSolver Taillardova implementacija uz diversifikacijsku aspiracijsku funkciju 76

77 6.3.3 Razredi za rješavanje QAP-a simuliranim kaljenjem Pristup razvijanju razreda za rješavanje QAP-a pomoću simuliranog kaljenja je bio nešto drugačiji. Naime, nije definiran jedan općeniti razred unutar kojega su implementirane sve različite metode obavljanja optimizacije, kao što je to napravljeno kod razreda QAPSolverTabuSearchGeneral, već je definirano parametrizirano sučelje ISimAnnealing, unutar kojega su navedne čiste virtualne funkcije koje čine sučelje koje mora zadovoljavati svaki algoritam simuliranog kaljenja. Deklaracija sučelja je sljedeća: template<class _SAConfig> class ISimAnnealing : public ThreadableOptObject<float, _SAConfig> { public: ISimAnnealing( IOptTerminator *inpterm, ISaveResultObject<float, _SAConfig> *inpsave ) : ThreadableOptObject<float, _SAConfig>(inpTerm, inpsave) {} virtual float InitialTemperature() = 0; // početna temperatura virtual float NextTemperature( float CurrTemp ) = 0; // izračunava sljedeću temperaturu virtual bool IsEquilibriumReached() = 0; // da li je za danu temperaturu dostignuta termalna ravnoteža // mijenja trenutnu konfiguraciju Old i vraća novu konfiguraciju New, te promjenu energije virtual float ChangeConfig( _SAConfig &Old, _SAConfig *New ) = 0; virtual bool Initialize() = 0; virtual bool PerformIteration() = 0; }; virtual float OptFunc( _SAConfig &Conf ) = 0; Nakon ovoga je potrebno je iz navedenog razreda ISimAnnealing izvesti konkretne razrede koji će definirati implementaciju za čiste virtualne funkcije definirane u sučelju. Međutim, budući da se algoritmi simuliranog kaljenja opisani u poglavlju mogu iskoristiti i za rješavanje drugačijih problema optimizacije od QAP-a, najprije su iz sučelja ISimAnnealing izvedeni konkretni parametrizirani razredi koji implementiraju algoritme opisane u Implementirana su četiri algoritma: Burkard-Rendl algoritam Jednostavan algoritam kojemu se zadaje početna i konačna temperatura, gdje se na svakoj temepraturi obavlja određeni broj zamjena, a temperatura se mijenja za određenu multiplikativnu konstantu. Razred implementacije je nazvan SimpleSimAnnealing. Navodimo samo ugradnju dvije funkcije iz kojih se vidi kako se mijenja temperatura i kada se postiže ravnoteža: float NextTemperature( float CurrTemp ) { return CurrTemp * TempChangeFactor; } bool IsEquilibriumReached() { if( CurrIterOnTemp!= 0 && CurrIterOnTemp % IterNumOnTemp == 0 ) return true; else return false; } 77

78 Koristeći ovako definiran općeniti razred, možemo sada iz njega izvesti razred koji će implementirati navedeni algoritam simuliranog kaljenja za rješavanje kvadratičnog problema pridruživanja. Sve što je potrebno deifnirati unutar tog razreda su funkcije CalcRandomConfigChange, koja se koristi za generiranje nove konfiguracije (odnosno rješenja) i funkcija GetAlgDescription, koja, kako je već opisano, vraća opis algoritma u strukturi AlgDescription. Razred je nazvan QAPSolverSimpleSimAnnealing Jednostavan automatizirani raspored kaljenja Jedna od nezgodnih strana jednostavnog algoritma simuliranog kaljenja je nužnost definiranja početne temperature sistema. Međutim, za razliku od nekih drugih parametara algoritama za rješavanje QAP-a (primjerice vjerojatnost mutacije kod genetičkog algoritma, ili veličina liste zabranjenih poteza kod tabu-search algoritma) ovom se parametaru ne može iz prve dati smislena vrijednost, zato jer uvelike ovisi o točki u kojoj se sistem nađe na početku optimizacije. Stoga je implementiran ovaj jednostavni algoritam koji je uglavnom potpuno jednak Burkard-Renldovom algoritmu, s tom razlikom što se početna tempeatura automatski određuje na osnovu jednog dodatnog parametra, nazvanog AcceptHigherProb. Ovaj parametar, kao što i samo ime govori, definira kolika će biti vjerojatnost prihvaćanja uzlaznog poteza na početku optimizacije. Formula kojom se tada definira početna temperatura je: T = AvgEnergyIncrease(), log AcceptHigher Pr ob gdje je AvgEnergyIncrease funkcija koja računa prosječno povećanje temeprature iz početne točke optimizacije za 00 različitih novih konfiguracija. U ostalim implementacijskim detaljima je ovaj algoritam isti kao prethodni. Na određenoj temepraturi se izvodi optimizacija kroz određeni broj iteracija, zadan parametrom IterNumOnTemp, a nakon toga se temperatura smanjuje množenjem sa multiplikativnom konstantom TempChangeFactor. Razred za rješavanje QAP-a ovom metodom je nazvan QAPSolverAutomatedSimAnnealing Wilhelm-Ward algoritam Wilhelm-Ward algoritam je implementiran na način kako je to detaljno opisano u odjeljku Ulazni parametri algoritma su broj iteracija po epohi, EpochIterNum, te parametar Eps, koji definira koliko blizu mora biti prosječna vrijednost troška prihvaćenih pridruživanja tijekom trenutne epohe prosječnoj vrijednosti svih obavljenih pridruživanja. Imajući u vidu formulu 5. kojom je definiran raspored kaljenja (odnosno sekvenca temperatura), postavlja se pitanje da li je početna temperatura 0 uvijek dobra. Razred za rješavanje je nazvan QAPSolverWWSimAnnealing. 78

79 Connoly algoritam Kod implementacije Connolyevog algoritma, primjenjeni su principi navedeni u odjeljku Znači, korišten je sekvenca temepratura, nove konfiguracije nisu generirane slučajno već su ispitivane u preddefiniranom redoslijedu, i izvođenje optimizacije je zaustavljeno na temepraturi TFOUND kada bi MXFAIL uzastopnih uzlaznih poteza bilo odbijeno. Implementirana su dva algoritma. Prvi, ugrađen u razred QAPSolverConnSimAnnealing, ima tri ulazna parametra, početnu i završnu temperaturu, te parametar MXFAIL (parametar M koji je spominjan u odjeljku gdje je opisan Connolyev algoritam predstavlja u stvari broj iteracija algoritma, te se stoga ne radi o "pravom" parametru algoritma). Međutim, kao što je to napravio i Connoly u svom radu, parametar MXFAIL se uglavnom nikad nije mijenjao već je uvijek bio jednak 0.5n(n-), gdje je n bila veličina problema. Drugi algoritma, implementiran u razredu QAPSolverConnAutomatedSimAnnealing, se razlikovao po tome što se početna i završna temperatura izračunavala automatski, po formuli 5.4, čime je broj parametara algoritma pao na (MXFAIL), ali kako je i on uglavnom bio preddefiniran, u principu se ovdje radi o algoritmu koji nema ulaznih parametara Razredi za rješavanje QAP-a genetičkim algoritmom Za rješavanje QAP-a pomoću genetičkog algoritma implementirane su tri metode. Prva metoda predstavlja implementaciju genetičkog algoritma po sistemu turnirske selekcije (tournament selection), dok druge dvije predstavljaju hibridne algoritme koji u sebi imaju ugrađene i procedure lokalnog pretraživanja. Kako bi se olakšala i pojednostavnila implementacija genetičkih algoritama, njihova zajednička svojstva i metode su definirane u parametriziranom razredu sučelja IGeneticAlg. Definirane varijable i metode se najbolje mogu vidjeti iz deklaracije: template<class _TCrom> class IGeneticAlg : public ThreadableOptObject<float,_TCrom> { public: IGeneticAlg( int inpopulationsize, IOptTerminator *inpterm, ISaveResultObject<float, _TCrom> *inpsave ) : ThreadableOptObject<float, _TCrom>(inpTerm, inpsave) {... } virtual void GenerateInitialPopulation() = 0; virtual void SetCromosomParameters( _TCrom & ) = 0; virtual bool Initialize() = 0; virtual bool PerformIteration() = 0; virtual float OptFunc( _TCrom & ) = 0; int findmincromindex( float *outminvalue ) {... } int findmaxcromindex( float *outmaxvalue) {... } 79

80 protected: int _TCrom }; PopulationSize; *CromList; Odmah je pretpostavljeno da će se razredi koji će implementirati rješavanje pomoću genetičkog algoritma koristiti u višenitnom okruženju te je razred IGeneticAlg izveden iz razreda ThreadableOptObject tournament-selection algoritam Genetički algoritmi turnirske selekcije su vrlo jednostavni budući da nad populacijom primjenuju samo genetičke operatore križanja i mutacije. U principu se govori o k- tournament-selection algoritmima, gdje parametar k predstavlja vrijednost koja govori među koliko će se jedinki odabirati jedinke za križanje. Kod 3-turnirskog algoritma, odabiru se tri jedinke. Najlošija jedinka među tri odabrane se zamjenjuje sa djetetom dobivenim križanjem preostale dvije. Kod implementacije ovog algoritma je korišteno jednostavno križanje, opisano u U svakoj iteraciji se poslije obavljanja križanja obavlja i mutacija, za obavljanje koje je potrebno definirati drugi ulazni parametar algoritma (prvi je, naravno, veličina populacije jedinki) MutationProb, koji je realiziran kao realna vrijednost koja određuje vjerojatnost mutacije na sljedeći način. Parametar MutationProb mora biti unutar intervala [0,], te se do odluke da li će se u toj iteraiciji nad određenom jedinkom obaviti mutacija ili ne dolazi na sljedeći način: for( i=0; i<populationsize; i++ ) { // računa se vjerojatnost za svaku jedinku prob = rand() / ((float) RAND_MAX); // najprije odredi vjerojatnost mutacije if( prob>=0 && prob<=mutationprob ) {... // obavljanje mutacije } } Znači, ukoliko slučajno generirani broj (normaliziran na interval [0,]) bude manji od parametra MutationProb, nad danom jedinkom će se obaviti mutacija. Sada se cjelokupni korak ovog algoritma može napisati kao: virtual bool PerformIteration() { int ToReplace, ToSurvive[2]; } PerformSelection(&ToReplace, ToSurvive, 2); // selekcija tri jedinke PerformCrossover(ToSurvive[0],ToSurvive[],ToReplace); // primjenjujemo operator križanja PerformMutation(); // mutacija BestInd = findmincromindex(&currfuncvalue); CurrSolution = CromList[BestInd]; if( CurrFuncValue < BestFuncValue ) { BestFuncValue = CurrFuncValue; BestSolution = CromList[BestInd]; } Razred za rješavanje QAP-a ovom metodom je nazvan QAPGenAlgTournamentSelection. 80

81 FFGA algoritam Ovaj algoritam (nazvan FFGA po njegovim autorima, Fleurent i Ferland), u stvari predstavlja hibridni genetički algoritam budući da u sebi ima ugrađenu proceduru lokalnog pretraživanja. Sam algoritam se sastoji iz dvije faze: faze izgradnje početnih rješenja i faze poboljšanja primjenom genetičkih operatora. Zanimljiva karakteristika algoritma je da nema ugrađen operator mutacije, odnosno, koristi se samo operator križanja. U fazi izgradnje rješenja, skup jedinki u populaciji se generira slučajno, nakon čega se nad njima obavlja lokalno pretraživanje, s ciljem poboljšanja jedinki. Za lokalno pretraživanje se koristila metoda prvog poboljšanja. Nakon obavljanja lokalnog pretraživanja se populacija sortira po postignutoj vrijednosti funkcije cilja. Nakon izgradnje rješenja, kreće se sa izvođenjem samog genetičkog algoritma. U svakoj iteraciji algoritma se generira PerGeneration (prvi parametar algoritma) novih jedinki, primjenom operatora križanja nad odabranim jedinkama. Jedinke za križanje se odabiru sljedećom procedurom. Generira se slučajni broj u iz intervala [0, PopulationSize / R ], gdje je R drugi parametar algoritma čija vrijednost mora biti unutar intervala [,2), te se za selekciju odabire jedinka koja se nalazi na u R poziciji unutar populacije (podsjetimo da su jedinke unutar populacije sortirane po vrijednosti funkcije cilja). Povećavajući parametar R se povećava vjerojatnost selekcije boljih roditelja za proces križanja, dok vrijednost parametrta R= daje jednaku vjerojatnost selekcije svim jedinkama u populaciji. Na svako dijete dobiveno križanjem se primjenjuje lokalno pretraživanje, te se na kraju iteracije ponovno sortira populacija. Razred koji implementira ovaj algoritam za rješavanje QAP-a je nazvan QAPGenAlgFFGA Pohlepni (greedy) genetički algoritam Zadnji genetički algoritam koji je implementiran je takozvani pohlepni genetički algoritam, kojem su njegovi autori (Ahuja, Orlin i Tiwari) dali takvo ime zbog komponente lokalnog pretraživanja koja "pohlepno" želi što više poboljšati rješenja. Algoritam koristi operator križanja, proces imigracije (umjesto operatora mutacije), te lokalno pretraživanje, čime algoritam dobija pohlepnu komponentu. U svakoj iteraciji se obavlja križanje dvije slučajno selektirane jedinke, te se lošija jedinka roditelja zamjenjuje sa dobivenom jedinkom djeteta. Za operator križanja je iskorišteno križanje ubacivanjem staze. Proces imigracija se obavlja svakim ImmigrationRate iteracija (gdje je ImmigrationRate ulazni parametar algoritma), i to postupkom opisanim u odljeku čime se nastoji ubaciti novi genetski materijal u populaciju koji će u sebi sadržavati rješenja iz neistraženog dijela konfiguracijskog prostora. Lokalnim pretraživanjem se svakih LocalSearchRate iteracija poboljšava 0% populacije. Razred implementacije je nazvan QAPGenAlgGreedy. 8

82 6.4 Opis aplikacije Kod izgradnje aplikacije, korišten je programski paket Microsoft Visual Studio 6.0, a kao osnovni element je korišteno razvojno okruženje Visual C++. Iako Visual C++ ne spada u ponajbolje RAD (Rapid Application Development) alate (čime se misli na to da postoje i okruženja koja omogućavaju brže razvijanje grafičkog sučelja), ipak se kombinacija moćnog jezika kao što je C++ uz korištenje mogućnosti za brzi razvoj vizualnog grafičkog sučelja pokazala kao dobitna. Kao osnovna arhitektura aplikacije korišten je MFC okvir aplikacija (Microsoft Foundation Classes framework) koji u sebi već ima definirane razrede za rad sa dokumentima i prikazom sadržaja dokumenata u prozoru, a isto tako sadrži i razrede za rad sa izbornicima, dijalozima i svim ostalim elementima grafičkog sučelja Struktura aplikacije Aplikacija je strukturirana u skladu sa Document/View arhitekturom koju definira MFC [5]. Osnovna ideja je da se definiraju posebni razredi za rukovanje podacima (koje uključuje i njihovo čuvanje) i prikazivanje tih podataka na ekran. Razredi koji rukuju podacima su izvedeni iz razreda CDocument čime je automatski omogućena standardna serijalizacija dokumenata na i sa diska (operacije Open, Save, Save As), a vrlo jednostavna je ugradnja ispisa na pisač. Stoga je na odmah na početku razvijanja aplikacije definiran razred QAPSolverDoc, sa sljedećim bitnim dijelovima: class CQAPSolverDoc : public CDocument, public ISaveResultObject<float, QAPSolution> { public: int nproblemsize; Math::Matrix<float> *A; Math::Matrix<float> *B; std::vector< IterOptContResWithSolutions<float, QAPSolution> > std::vector< AlgDescription > vecalgdesc; vecsol; }; bool AddOptResult( IterOptContResWithSolutions<float, QAPSolution> &res, AlgDescription &alg ); bool DeleteOptimizationResult( int Index ); Može se uočiti da je definirani razred izveden iz razreda CDocument, ali i iz razreda ISaveResultObject, budući da će se rezultati optimizacije spremati upravo u razred definirani dokumenta pomoću funkcije AddOptResult, koja je definirana u sučelju razreda ISaveResultObject. Unutar funkcije Serialize, koja je nasljeđena iz razreda CDocument, je ugrađen kod za snimanje i učitavanje tako definiranog dokumenta na disk. Međutim, vrlo brzo se pokazalo 82

83 nužnim definirati još jedan razred dokumenta. Naime, budući da se željelo implementirane algoritme međusobno uspoređivati ispitujući njihovo ponašanje i postignuta rješenja nad određenim skupom instanci kvadratičnog problema pridruživanja, pokazalo se kao vrlo nezgrapno dodavati unutar definiranog razreda skup članskih varijabli koji bi opisivao te različite instance QAP-a budući da je primarna namjena razreda QAPSolverDoc rješavanje jedne instance QAP-a. Stoga je definiran još jedan razred dokumenta, QAPSolverCompareDoc, unutar kojega su definirane sljedeće članske varijable: int strsize[0]; // veličina pojedinih učitanih instanci problema CString strfilename[0]; // nazivi datoteka iz kojih su podaci učitani std::vector< Math::Matrix<float> > veca; std::vector< Math::Matrix<float> > vecb; // vektor u kojem se nalaze definirane matrica A // vektor matrica B std::vector< QAPSolution > vecbestknownsol; // najbolja poznata rješenja za učitane probleme std::vector< IterOptContResWithSolutions<float, QAPSolution> > std::vector< AlgDescription > vecalgdesc; vecsol; Time se postiglo razdvajanje dvije različite mogućnosti provođenja optimizacije. Podrška aplikacijama koje rade sa više dokumenata unutar MFC-a je izvrsna, tako da se ovisno o tipu dokumenta s kojim se radi, na ekranu prikazuje i prikladni izbornik (budući da je jasna stvar da se izbornici za definiranje opcija nad ova dva različita razreda dokumenta moraju razlikovati). Pored toga se za svaki razred dokumenta mogu ugraditi funkcije Serialize() što omogućava spremanje svakog od dokumenata na disk. Razredi koji omogućuju prikaz sadržaja dokumenta na ekran se izvode iz CView razreda (ili iz njegovih podrazreda koji obuhvaćaju CScrollView, CFormView,...) i time se automatski dobiva ispravno osvježavanje ekrana prilikom pomicanja prozora, promjene veličine, ili promjene podataka u dokumentu koji se prikazuje u prozoru. Međutim, budući da se sva interakcija sa korisnikom odvijala preko dijaloga, uključujući i prikaz rješenja, nije bilo potrebno modificirati razred CView budući da se u dijelu prozora aplikacije namijenjenog iscrtavanju (tzv. client area) nije ništa ispisivalo. 83

84 6.4.. Opcije programa za rad sa dokumentom QAPSolverDoc Izbornik File U ovome izborniku se pored standardnih opcija koje imaju svi Widnows programi pisani pomoću MFC-a (opcije Open, Save, Save As koje su implementirane u samom MFC-u) nalaze dvije opcije: Load problem data Load best known solution opcija se koristi za učitavanje podataka o problemu iz tekstualne datoteke u kojoj su definirani elementi matrica A i B koristi se za učitavanje najboljeg poznatog rješenja iz tekstualne datoteke (učitava se i iznos funkcije cilja i raspored po lokacijama) Izbornik Optimization Ovaj izbornik čini srž aplikacije jer se u njemu nalaze opcije za pokretanje optimizacije različitim metodama. U osnovnoj razini izbornika se nalaze popisane osnovne vrste implementiranih algoritama, a odabiranjem bilo koje od opcija se prikazuje dodatni popup izbornik u kojem je dan popis metoda rješavanja, za svaki od navedenih tipova algoritama. Local search First improvement Best improvement Heider method Tabu search Simple Simple diversify Robust Robust diversify Simulated annealing Simple Burkard-Rendl Automated algorithm Wilhelm-Ward algorithm Connoly algorithm Automated Connoly algorithm Genetic algorithm 3-tournament selection FFGA Greedy genetic algorithm Odabirom bilo koje od navedenih opcija na ekranu se pojavljuje dijalog za pokretanje optimizacije. Izvedba tog dijaloga u sebi nosi određene specifičnosti, te će biti detaljnije opisana. 84

85 Dijalog za optimizaciju Početna ideja kod razvijanja dijaloga za optimizaciju je bila da se za svaki algoritam napravi poseban dijalog za unos parametara algoritma, budući da različiti algoritmi imaju različite parametre. Međutim, kako se broj algoritama povećavao, ustanovljeno je da su svi dijalozi manje više isti, jer je najveći dio kontrola na dijalogu bio posvećen definiranju kriterija za završetak optimizacije, kriterija za osvježavanje te kriterija za određivanje trenutka snimanja međurezultata, uz određene kontrole posvećene ispisu rezultata. Stoga je definiran jedan generički dijalog, koji je prikazan na slici 6.9, unutar kojega je definiran sav potreban programski kod za rukovanje sa gore navednim kriterijima, ispisom rezultata i osvježavanje ekrana. Slika 6.9. Generički dijalog za optimizaciju Na dijalogu se na desnoj strani može uočiti više dijelova. Tri dijela su posvećena, navodeći redom: određivanju kriterija završetka optimizacije (mogućnost odabira broja iteracija, vremena izvršavanja ili dostignute vrijednosti funkcije cilja), određivanju kriterija za osvježavanje ekrana (mogućnost definiranja intervala osvježavanja preko broja izvedenih iteracija ili proteklog vremena) te određivanju kriterija za snimanje međurezultata (također postoji mogućnost definiranja intervala preko broja iteracija i proteklog vremena). 85

86 Na vrhu dijaloga s desne strane je upravljačka dugmad za pokretanje i zaustavljanje optimizacije, dok je u dnu ekrana prostor predviđen za ispis najboljeg nađenog rješenja i trenutnog rješenja koje algoritam istražuje. Najveći dio dijaloga zauzima ActiveX kontrola koja prikazuje raspored pridruživanja uslužitelja na određene lokacije. ActiveX kontrola je razvijena budući da ona predstavlja dobro deifniranu komponentu, a mogućnošću primjene i u drugim projektima. Kontrola je vrlo elementarna, sa par definiranih metoda za postavljanje uslužitelja na određenu lokaciju, a zbog korištenja u rješavanju problema rasporeda ispita, postoji mogućnost i višestrukog prisdruživanja (što kod rješavanja standardnog QAP-a nema smisla, ali ima kod rješavanja probleam ispita, budući da se za jedan ispit mora odrediti više ispitnih termina - vidi poglavlje 7.). Na slici 6.0 je prikazano kako dijalog izgleda za vrijeme izvođenja optimizacije. Slika 6.0. Izgled dijaloga za optimizaciju za vrijeme izvođenja optimizacije. U gornjem lijepom kutu dijaloga se može uočiti prostor namijenjen definiranju parametara algoritma, gdje se kod korištenja različitih algoritama mogu definirati kontrole za unos tih parametara. Način na koji je programski izveden generički dijalog je sljedeći. Najprije je iz razreda CDialog (osnovni razred u MFC-u iz kojega se izvode svi razredi za prikaz dijaloga) izveden 86

87 razred dijaloga CDlgGeneric unutar kojega su definirane sve ulazno izlazne kontrole prikazane na slici 6.9 koje su u stvari zajedničke svim dijalozima. class CDlgGeneric : public CDialog { public: CDlgGeneric(CQAPSolverDoc *p, CWnd* pparent = NULL); // standard constructor void Refresh( IterativeOptRes<float, QAPSolution> *res, float Best, const QAPSolution *BestSol ); IOptTerminator *GetTermObj(); IOptSaver<float, QAPSolution> *GetSaveObj(); OptRefreshMultiThread<float, QAPSolution> *GetRefreshObj(); } // ovdje se mora kreirati sam objekt koji će provesti optimizaciju virtual void OnStart() = 0; virtual void OnStop() = 0; virtual void OnContinue() = 0; virtual void OnUseNewParameters() = 0; virtual void OnGenericOK() = 0; virtual void OnGenericCancel() = 0;... Pored toga je definirano i sučelje koje će morati zadovoljavati svi izvedeni dijalozi, koji će se koristiti za određene algoritme. Međutim, razredi dijaloga za izvođenje optimizacije pomoću određenog algoritma nisu izvedeni direktno iz ovoga razreda, već iz parametriziranog razreda CDlgGenericTemplate. template<class _SolverType> class CDlgGenericTemplate : public CDlgGeneric { public: CDlgGenericTemplate<_SolverType>(CQAPSolverDoc *p, CWnd* pparent = NULL) : CDlgGeneric(p, pparent) {... } protected: _SolverType *pqap; Razlog zbog čega je potrebno da taj razred bude parametriziran je činjenica da različiti algoritmi koriste različite razrede namijenjene rješavanju QAP-a i stoga dijalog mora biti parametriziran s obzirom na tip razreda koji će se koristiti za izvođenje optimizacije. Tome je namijenjena članska varijabla (odnosno pokazivač) pqap. Međutim, pored toga, unutar ovog razreda dijaloga su implementirane mnoge funkcije koje su definirane u sučelju razreda CDlgGeneric. To je bilo moguće napraviti budući da, primjerice, implementacija funkcije OnTerminate (koja se poziva kada se na dijalgu pritisne upravljačko dugme Terminate) jednostavno treba razredu za rješavanje QAP-a proslijediti poruku Terminate, a budući da su svi razredi za rješavanje izvedeni iz razreda ThreadableOptObjec koji ima tu funkciju definiranu u svome sučelju, svi razredi QAP je također imaju implementiranu. U principu, jedina funkcija čija se implementacija morala ostaviti konkretnim razredima dijaloga je funkcija OnStart koja se poziva prilikom pokretanja optimizacije, budući da se u njoj razredu 87

88 za rješavanje QAP-a moraju predati parametri optimizacije, koji su za različite razrede različiti. Međutim, uprkos tome, na ovakav način se postigla izvanredna ekonomičnost prilikom dodavanja novih dijaloga (preko kojih će se pokretati algoritmi za rješavanje QAP-a), budući da je prilikom definiranja novog dijalga potrebno samo u konstruktoru dijaloga kreirati ulazne kontrole (koje su najčešće standardne Windows Textbox kontrole), u funkciji OnDataExchange obaviti izmjenu podataka između kontorla i članskih varijabli u razredu dijaloga, te implementirati funkciju OnStart. Budući da je na slici 6.0 prikazan dijalog koji se koristi za optimizaciju pomoću pohlepnog genetičkog algoritma, može se navesti cijeli kod koji je potrebno napisati da bi se proizveo takav dijalog: #define GEN_ALG_GREEDY_EDIT_POP_SIZE #define GEN_ALG_GREEDY_EDIT_PER_GEN 5820 #define GEN_ALG_GREEDY_EDIT_SEL_PAR_R class CDlgGenAlgGreedy : public CDlgGenericTemplate<QAPGenAlgGreedy> { public: CDlgGenAlgGreedy(CQAPSolverDoc *p, CWnd* pparent = NULL) : CDlgGenericTemplate<QAPGenAlgGreedy>(p, pparent) { int x, y, dx; RECT rect; GetClientRect(&rect); x = rect.right * 0.77; dx = rect.right * 0.; y = rect.bottom * 0.2; m_label.create("pop.size", WS_VISIBLE, CRect(x,y,x+dx,y+20), this ); m_label.showwindow(true); m_label2.create("immigration ", WS_VISIBLE, CRect(x,y+30,x+dx,y+50), this ); m_label2.showwindow(true); m_label3.create("l.search rate ", WS_VISIBLE, CRect(x,y+60,x+dx,y+80), this ); m_label3.showwindow(true); m_ctrlpopsize.create(bs_pushbutton WS_VISIBLE WS_BORDER WS_THICKFRAME, CRect(x+dx,y-5,x+2*dx,y+5), this, GEN_ALG_GREEDY_EDIT_POP_SIZE ); m_ctrlpopsize.showwindow(true); m_ctrlimmigration.create(bs_pushbutton WS_VISIBLE WS_BORDER WS_THICKFRAME, CRect(x+dx,y+25,x+2*dx,y+45), this, GEN_ALG_GREEDY_EDIT_PER_GEN ); m_ctrlimmigration.showwindow(true); m_ctrllsrate.create( BS_PUSHBUTTON WS_VISIBLE WS_BORDER WS_THICKFRAME, CRect(x+dx,y+55,x+2*dx,y+75), this, GEN_ALG_GREEDY_EDIT_SEL_PAR_R ); m_ctrllsrate.showwindow(true); m_npopsize = 50; m_ctrlpopsize.setwindowtext("50"); 88

89 } m_nimmigrationrate = 20; m_ctrlimmigration.setwindowtext("20"); m_nlocalsearchrate = 00; m_ctrllsrate.setwindowtext("00"); void DoDataExchange(CDataExchange* pdx) { // DDX/DDV support DDX_Text(pDX, GEN_ALG_GREEDY_EDIT_POP_SIZE, m_npopsize); DDX_Text(pDX, GEN_ALG_GREEDY_EDIT_PER_GEN, m_nimmigrationrate); DDX_Text(pDX, GEN_ALG_GREEDY_EDIT_SEL_PAR_R, m_nlocalsearchrate); } CDlgGeneric::DoDataExchange(pDX); void OnStart() { // najprije kreiramo objekt IOptTerminator IOptSaver<float, QAPSolution> OptRefreshMultiThread<float, QAPSolution> *ptermobj; *psaveobj; *prefobj; if( pqap == NULL ){ // ukoliko objekt zza rješavanje još nije kreiran UpdateData(); ptermobj prefobj psaveobj = GetTermObj(); = GetRefreshObj(); = GetSaveObj(); pqap = new QAPGenAlgGreedy( pdoc->getproblemsize(), ptermobj, NULL, m_npopsize, m_nimmigrationrate, m_nlocalsearchrate ); pqap->setoptrefresherobject(prefobj); pqap->setoptsaverobject(psaveobj); // međurezultati će se snimati u Document razred pqap->setsaveobject(pdoc); pqap->seta(*pdoc->geta()); pqap->setb(*pdoc->getb()); } else { // ako je objekt za rješavanje već kreiran, onda osvježi kriterije (jer su s emožda promijenili) ptermobj = GetTermObj(); prefobj = GetRefreshObj(); psaveobj = GetSaveObj(); pqap->setoptterminatorobject(ptermobj); pqap->setoptrefresherobject(prefobj); pqap->setoptsaverobject(psaveobj); } if( pexch!= NULL ) delete pexch; 89

90 pexch = new ExchangeDataObject<float, QAPSolution>(this->m_hWnd); prefobj->assignpointertoexchangedata(pexch); } // i konačno pokreni optimizaciju pqap->start(); private: int float m_npopsize, m_nimmigrationrate; m_nlocalsearchrate; }; CStatic CEdit m_label, m_label2, m_label3; m_ctrlpopsize, m_ctrlimmigration, m_ctrllsrate; Izbornik View U ovom izborniku se nalaze sljedeće opcije: View data View results View best known solution prikazuje na ekranu dijalog sa ispisanim elementima matrica A i B prikazuje na ekranu dijalog sa rezultatima dosadašnjih optimizacija prikazuje dijalog sa najboljim poznatim rješenjem (ono koje je učitano pomoću funkcije Load best know solution) Od navedenih opcija, jedino opcija View results zaslužuje detaljniji opis, budući da su ostale dvije elementarne Prikaz rezultata Odabirom opcije View result, na ekranu se prikazuje dijalog prikazan na slici 6.. Dijalog se sastoji od popisa svih obavljenih optimizacija nad učitanom instancom problema, gdje se u tom popisu vidi vrsta i podvrsta primjenjenog algoritma, popis parametara algoritma, trajanje optimizacije, obavljeni broj iteracija, te postignuta vrijednost funkcije cilja. 90

91 Slika 6. Dijalog za pregled rezultata optimizacije. Selektiranjem pojedinog retka se može dobiti grafički prikaz tijeka optimizacije na ekranu, prikazan na slici 6.2, gdje je prikazan tijek optimizacije prilikom korištenja metode simuliranog kaljenja (Wilhelm-Ward algoritam) za rješavanje problema veličine 4. Slika 6. Dijalog za grafički prikaz tijeka optimizacije. Kako bi se moglo uspoređivati tijek optimizacije kod korištenja različitih algoritama (ili različitih parametara istog algoritma), na istom dijalogu se može prikazati više grafova, 9

92 primjer čega je prikazan na slici 6., za postizanje čega je potrebno selektirati radio-dugme (eng. radio-button) Show graphs in same window. Također se prilikom iscrtavanja grafova može odabrati korištenje boja (opcija Use colors) i/ili korištenje različitih stilova linije (opcija Use line styles). Slika 6.2 Dijalog za grafički prikaz sa iscrtanih više grafova. Ovdje valja napomenuti da je za prikaz grafova na ekranu također razvijena ActiveX kontrola, nazvan SimpleGraf, za mogućnostima definiranja legende, određivanja i labeliranja x i y osi, te prikaza više grafova rad usporedbe. Opcija Draw to metafile se može iskoristiti za zapisivanje tako definiranog grafa (ili grafova) u Windows metafile, čime se omogućava učitavanje u programe za obradu teksta i postiže jednostavnost prilikom uključivanja tako dobivenih grafova u neki tekst. 92

93 Opcije progama za rad s dokumentom QAPSolverCompareDoc Razred QAPSolverCompareDoc, kako je u uvodu već rečeno, je namijenjen ispitivanju ovisnosti algoritama o njihovim parametrima. Da bi se realizirala ideja uspoređivanja algoritama nad različitim instancama problema kvadratičnog pridruživanja, potrebno je najprije te instance i definirati. To se postiže odabirom opcije Set problem instances, u izborniku File, čime se na ekranu dobija sljedeći dijalog: Slika 6.3. Dijalog za određivanje skupa instanci problema U ovome dijalogu se definira skup instanci, koji će se kasnije rješavati pomoću različitih algoritama. Nakon odabira datoteke sa ulaznim podacima, program te podatke učitava u varijable veca i vecb, koje predstavljaju niz koji sadrži matrice A i B za definiciju problema. Također se mogu učitati i podaci o najboljem poznatom rješenju, koji se onda spremaju u niz vecbestknownsolution. Inicijalna zamisao je bila da se u razvijenoj aplikaciji za rješavanje kvadratičnog problema pridruživanja, implementira i mogućnost analize dobivenih rješenja, ispisivanje rezultata u tablicama i usporedbe pomoću grafova. Međutim, zaključilo se da bi to jako zakompliciralo aplikaciju, a budući da postoje već gotovi alati i programi za anlizu takvih podataka, prešlo se na pristup gdje se rezultati optimizacije dobiveni rješavanjem QAP-a spremaju u tekstualne datoteke, iz kojih se ti podaci jednostavno mogu učitati u programe za analizu, crtanje grafova i slično. Sama optimizacije se pokreće iz posebnog dijaloga koji je opisan u sljedećem odjeljku. 93

94 Dijalog za automatsku optimizaciju Pomoću ovog dijaloga se može pokrenuti izvođenje algoritma za rješavanje QAP-a nad različitim instancama problema sa ralzičitim postavkama parametara. Dijalog je prikazan na slici 6.4. Najprije je u listi izbora (kontrola Listbox) potrebno odabrati koji algoritam će se koristiti, a zatim se definira niz parametara s kojim će se rješavati učitane instance QAP-a. Kako bi se izbjegao utjecaj početnog rješenja na kvalitetu nađenog rješenja, moće se definirati koliko puta će se izvršiti optimizacija za svaku postavku parametara (opcija Number of repetitions). Isto tako, za svaku definiranu veličinu problema se postavlja kriterij završetka optimizacije u vidu određivanja vremena koliko će se izvoditi optimizacija. Kao što se vidi na prikazanoj slici, za probleme manje veličine se stavlja manje vrijednosti nego kod složenijih problema (vrijeme se zadaje u milisekundama). Slika 6.4. Dijalog za pokretanje optimizacije Pritiskom na dugme Start optimization, pokreće se optimizacija, čiji rezultati se, kao što je već navedeno, upisuju u tekstualne datoteke koje se dalje obrađuju pomoću drugih programa. Potrebno je još napomenuti da se prilikom izvođenja optimizacije, za svaku kombinaciju parametara u te datoteke zapisuje najbolje nađeno rješenje, najgore nađeno rješenje, prosječno rješenje, te devijacija rješenja od najboljeg poznatog rješenja. 94

95 6.5 Rezultati i usporedbe Nakon opisa svih algoritama, načina njihove implementacije i opisa razvijene aplikacije, potrebno se posvetiti analizi tih istih algoritama kako bi se ustanovile njihove međusobne sličnosti i razlike, te odredilo koji se među njima pokazuju kao najefikasniji za rješavanje kvadratičnog problema pridruživanja. Istraživanje je provedeno na sljedeći način. Budući da svi algoritmi ovise o jednom ili više parametara, najprije je provedeno ispitivanje performansi algoritama u ovisnosti o različitim parametrima, odnosno, željelo se ustanoviti za koje vrijednosti parametara algoritam najefikasnije radi. Nakon tog ispitivanja, pokušalo se pomoću svih algoritama, koristeći najbolje postavke parametara, dobiti najbolja moguća rješenja za određeni skup problema kvadratičnog pridruživanja, kako bi se mogli usporediti različiti algoritmi Ispitivanje efikasnosti izvođenja algoritma u ovisnosti o parametrima Kako bi se ustanovila ovisnost algoritma o parametrima, najprije je potrebno definirati skup problema nad kojima će se algoritmi testirati. Za potrebe ovog istraživanja, iz velike kolekcija problema [57], odabrani su sljedeći: had2 nug20 nug30 tai40b Matrica A predstavlja Manhattan udaljenost povezanog celularnog kompleksa u ravnini, dok su elementi matrice toka unifromno generirani unutar intervala [,n]. Najbolje rješenje 652 (dokazano optimalno). Problemi koje je definirao C.E.Nugent. Matrica udaljenosti sadrži Manhattan udaljenosti pravokutne mreže, dok su ulazi matrice B generirani. Najbolje rješenje 2570 (dokazano optimalno). Najbolje rješenje 624 (dokazano optimalno). Instance taixxx je predložio Taillard, i predstavljaju probleme koji su slučajno generirani. Najbolje poznato rješenje tai50b Najbolje poznato rješenje tai60a Najbolje poznato rješenje tai80a Najbolje poznato rješenje wil00 Problem koji su definirali Wilhelm i Ward. Najbolje poznato rješenje

96 Definirani skup instanci QAP-a je riješen pomoću svakog od implementiranih algoritma, i to tako da je za određeni skup parametara svaki problem riješen 0 puta, kako bi se smanjio utjecaj početnog rješenja (koje se u svim algoritmima slučajno generira). Za svaku instancu problema je definirano vrijeme izvođenja, s time da se otprilike radilo o sljedećim vrijednostima: veličina vrijeme (µs) veličina vrijeme (µs) Naravno, budući da složenost problema raste eksponencijalno sa porastom veličine problema, otprilike linearni porast vremena izvršavanja za veće probleme neće biti prikladan. Međutim, budući da je za većinu algoritama postojalo 0 20 različitih kombinacija parametara, te se za svaku kombinaciju problem riješavao 0 puta, moralo se napraviti kompromis kako bi vremena izvršavanja bila unutar nekih razumnih vremenskih granica. Stoga se za veće probleme nisu očekivali jako dobri rezultati, ali to i nije bilo toliko bitno budući je namjera ovog početnog istraživanja bila da se ustanovi ovisnost algoritama o parametrima. Ipak, kasnije se po kazalo da ovisnost algoritama o parametrima određena za kratko vrijeme izvršavanja algoritma, nije garancija da će te vrijednosti parametara biti dobre i kod izvođenja dugotrajnih optimizacije, s ciljem nalaženja optimalnih rješenja Rezultati optimizacije pomoću TabuSearch-a U ovom odjeljku su ispitane ovisnosti implementiranih tabu-search algoritama o njihovim parametrima. Četiri ugrađena algoritma imaju sljedeće parametre: ) SimpleTabuSearch a) TabuListSize - veličina tabu liste 2) SimpleDiversifyTabuSearch a) TabuListSize - veličina tabu liste b) AspPar - aspiracijski parametar 3) RobustTabuSearch a) TabuListSize - veličina tabu liste b) - parametar koji definira širinu intervala unutar kojeg će se mijenjati veličina liste 4) RobustDiversifyTabuSearch a) TabuListSize - veličina tabu liste b) AspPar - aspiracijski parametar c) - isto kao i kod RobustTabuSearch 96

97 Rješavanje pomoću SimpleTabuSearch algoritma U ovome odjeljku su prikazani rezultati izvođenja optimizacija nad definiranim skupom instanci problema kvadratičnog pridruživanja. Za svaku instancu problema su prikazana dva grafa. Na prvome su prikazana najbolja, najgora i srednja rješenja u ovisnosti o veličini liste zabranjenih poteza, a drugi prikazuje ovisnost devijacije o veličine tabu liste. Veličina problema 2 min max sred. std.dev Najbolje poznato rješenje ,4 0, ,4 0, , ,4 0, ,2 0, ,4 0,05 Ovisnost nađenog rješenja o veličini tabu liste Devijacija nađenog rješenja od najboljeg rješenja 670 0,55 nađeno rješenje min max sred. devijacija 0,45 0,35 0,25 0, veličina tabu liste 0,05-0, veličina tabu liste Veličina problema 20 min max sred. std.dev Najbolje poznato rješenje ,8, ,2 0, ,8 0, ,8 0, ,8 0, , ,2 0, ,4 0, ,6 0, ,6 0,42 Ovisnost nađenog rješenja o veličini tabu liste Devijacija nađenog rješenja od najboljeg rješenja nađeno rješenje min max sred. devijacija,5 0, veličina tabu liste veličina tabu liste 97

98 Veličina problema 30 min max sred. std.dev Najbolje poznato rješenje ,6 2, ,6 0, ,8 0, ,4 0, , ,2 0, ,2 0, ,8 0, ,6 0, ,79 Ovisnost nađenog rješenja o veličini tabu liste Devijacija nađenog rješenja od najboljeg rješenja nađeno rješenje min max sred. devijacija 2,5 2,5 0, veličina tabu liste veličina tabu liste Veličina problema 40 min max sred. std.dev Najbolje poznato rješenje ,4 2, ,4 9, , ,8 0, , ,8 7, ,2, ,2 0, ,4 9,6 Ovisnost nađenog rješenja o veličini tabu liste Devijacija nađenog rješenja od najboljeg rješenja 8,00E nađeno rješenje 7,00E+08 min max sred. devijacija ,00E veličina tabu liste veličina tabu liste 98

99 Veličina problema 60 min max sred. std.dev Najbolje poznato rješenje ,4 2, ,4, ,6, ,4, , , ,6, ,4, ,4, ,8,8 Ovisnost nađenog rješenja o veličini tabu liste Devijacija nađenog rješenja od najboljeg rješenja 2,5 nađeno rješenje min max sred. devijacija 2,5 0, veličina tabu liste veličina tabu liste Veličina problema 00 min max sred. std.dev Najbolje poznato rješenje , ,2 0, ,4 0, ,4 0, , , ,8 0, ,2 0, , ,8 0, Ovisnost nađenog rješenja o veličini tabu liste Devijacija nađenog rješenja od najboljeg rješenja nađeno rješenje min max sred. devijacija 0,75 0,5 0, veličina tabu liste veličina tabu liste Analizom prikazanih grafova se može primjetiti da se za svaku instancu problema može definirati veličina liste zabranjenih poteza koja najbolje "leži" tom problemu, te se može reći da ta veličina lagano raste za veće probleme. Što se tiče postignutih rješenja, vidi se da je ta male instance (2 i 20) algoritam bez problema našao optimalna rješenja, dok za veće instance to nije bio slučaj. S obzirom na vrijeme koje je posvećemo riješavanju svakog problema, to i ne iznenađuje. Ono što iznenađuje su jako loša rješenja koja je algoritam postigao za problem veličine 40. Kasnija 99

100 istraživanja su pokazala da se tu radi o dosta teškom problemu koji je i ostalim algoritmima predstavljao najveći izazov Rješavanje pomoću SimpleDiversifyTabuSearch algoritma Budući da ovaj algoritam ovisi o dva parametra, tablice u kojima su prikazana nađena rješenja i devijacija su malo drugačijeg oblika. Veličina tabu liste je definirana skupom {0,20,30,40,50} dok se parametar AspPar uzimao iz ksupa vrijednosti {500, 000, 2000, 4000, 8000}. Na grafu je prikazana ovisnost devijacije o veličini tabu liste za različite vrijednosti aspiracijskog parametra , , , , , , , , , , , , , , , , , ,2 Tablica : Minimalno i maksimalno rješenje, te izračunata srednja vrijednost nađenih rješenja Veličina problema 2 0 0,34 0,27 0,34 0,34 0,27 Najbolje rješenje ,22 0,5 0,22 0, ,05 0,04 0, , 0,29 0,6 0,27 0, ,58 0,3 0,5 0,63 0,5 Tablica: Standardna devijacija nađenih rješenja od najboljeg rješenja Devijacija nađenog rješenja u ovisnosti o veličini tabu liste i aspiracijskom parametru 0,7 devijacija 0,5 0,3 0, , veličina tabu liste 00

101 , , , , , , , , , , , , , , , , , , , , ,2 Tablica : Minimalno i maksimalno rješenje, te izračunata srednja vrijednost nađenih rješenja Veličina problema ,49,28 0,58 0,6 0,84 Najbolje rješenje ,46 0,3 0,42 0,35 0, ,64 0,43 0,5 0,42 0, ,56 0,7 0,69 0,77 0,8 50 0,9 0,9 0,92 0,97 Tablica: Standardna devijacija nađenih rješenja od najboljeg rješenja Devijacija nađenog rješenja u ovisnosti o veličini tabu liste i aspiracijskom parametru,4,2 devijacija 0,8 0,6 0, , veličina tabu liste , , , , , , , , , , , Tablica : Minimalno i maksimalno rješenje, te izračunata srednja vrijednost nađenih rješenja ,46,39,47,42,39 20,57,6,69,57,54 30,78,83,7,77,82 40,92,77,7,74,85 50,89,8,87,84,88 Tablica: Standardna devijacija nađenih rješenja od najboljeg rješenja Veličina problema 60 Najbolje rješenje devijacija 2,8,6,4 Devijacija nađenog rješenja u ovisnosti o veličini tabu liste i aspiracijskom parametru , veličina tabu liste 0

102 , , , , , , Tablica : Minimalno i maksimalno rješenje, te izračunata srednja vrijednost nađenih rješenja ,69 0,9 0,85 0,66 0, ,58 0,55 0,54 0,6 0,5 30 0,44 0,5 0,49 0,44 0, ,42 0,46 0,47 0,38 0,4 50 0,39 0,43 0,4 0,39 0,47 Tablica: Standardna devijacija nađenih rješenja od najboljeg rješenja Veličina problema 00 Najbolje rješenje devijacija 0,8 0,6 0,4 Devijacija nađenog rješenja u ovisnosti o veličini tabu liste i aspiracijskom parametru , veličina tabu liste Iz grafova dobivenih rješavanjem pomoću SimpleDivesifyTabuSearch algoritma se još bolje može uočiti ovisnost efikasnosti algoritma o veličini tabu liste. S druge strane, ovisnost o vrijednosti aspiracijskog parametra nije lako uočljiva te se može reći da ne utječe značajno na rezultate algoritma (barem ne u početnim stadijima optimizacije) Rješavanje pomoću RobustTabuSearch algoritma Kod ovog algoritma ispitivana je ovisnost o veličini tabu liste (vrijednosti 0,20,30,40,50) i o parametru {5,0,5}. Za svaki problem su prikazane dvije tablice. U prvoj su navedena najbolje i najgore nađeno rješenje, te prosječno rješenje, dok su u drugoj navedene devijacije nađenih rješenja od najboljeg poznatog rješenja , , , , , , , , , , 0,3 0, ,38 0,34 0, ,27 0,27 0, ,5 0, Veličina problema 2 Najbolje poznato rješenje 652 devijacija,2 0,8 0,6 0,4 0,2 Devijacija nađenog rješenja u ovisnosti o veličini tabu liste i veličina tabu liste 02

103 , , ,2 0 3,49 2,97 2, , ,52 0,66, , , ,8 30 0,47,33 0, , , ,6 40 0,45 0,33 0, , , ,4 50 0,28 0,32 0,42 Veličina problema 30 Najbolje poznato rješenje 624 devijacija 4 3,5 3 2,5 2,5 0,5 0 Devijacija nađenog rješenja u ovisnosti o veličini tabu liste i veličina tabu liste , , , , , , , , , , ,09 3,6 20 2,06,88 2, ,35,49 2,34 40,47,58,46 50,45,36,46 4,5 4 3,5 3 Devijacija nađenog rješenja u ovisnosti o veličini tabu liste i Veličina problema 60 Najbolje poznato rješenje devijacija 2,5 2, , veličina tabu liste 03

104 , , , , , , , , , , ,02 0,95 0, ,88 0,96, ,86 0,7 0, ,87 0,73 0, ,74 0,85 0,84 Veličina problema 00 Najbolje poznato rješenje devijacija,2 0,8 0,6 0,4 0,2 Devijacija nađenog rješenja u ovisnosti o veličini tabu liste i veličina tabu liste I kod ovoga algoritma se uočava prednost izvođenja optimizacije sa većom listom zabranjenih poteza. Iako se za utjecaj parametra može reći da nije značajan, iz prikazanih grafova je vidljivo da algoritam efikasnije radi za vrijednosti =0 i = Rješavanje pomoću RobustDiversifyTabuSearch algoritma Budući da ovaj algoritam ovisi o tri parametra, prikaz rezultata provedenih optimizacija će biti malo drugačiji. Za svaku veličinu problem će biti prikazano više tablica. U prve tri tablice su prikazani rezultati optimizacije za različite vrijednosti parametra AspPar {500, 2000, 8000}, i to najbolje i najgore nađeno rješenje, prosječno nađeno rješenje te devijacija nađenih rješenja od najboljeg poznatog rješenja. U četvrtoj tablici su radi preglednosti prikazani samo podaci o devijacijama, koji su prikazani i u trodimenzionalnom grafu. 04

105 Veličina problema = 2. Asp = 500 min max sred dev min max sred dev min max sred dev vel , ,6 0, ,6 0, ,4 0, ,8 0, ,6 0, ,4 0, ,8 0, Asp = 2000 min max sred dev min max sred dev min max sred dev vel ,6 0, ,4 0, ,8 0, ,2 0, ,6 0, ,4 0, ,6 0, Asp = 8000 min max sred dev min max sred dev min max sred dev vel , , ,6 0, , ,4 0, ,6 0, ,6 0, ,8 0, Asp vel ,34 0,32 0,98 0,73 0,73 0,38 0,8 0,84 0, ,27 0,38 0,32 0,3 0,22 0,27 0,34 0,27 0,4 30 0,27 0, ,22 0 0, , Devijacija nađenog rješenja u ovisnosti o veličini tabu liste, aspiracijskom parametru i parametru 0,9 0,8 0, Asp=8000 0,6 0,5 0,4 0,3 0,2 0, 0 devijacija 5 0 Asp= Asp= Asp= Asp= Asp=500 veličina tabu liste 5 parametar 05

106 Veličina problema = 30. Asp = 500 min max sred dev min max sred dev min max sred dev vel ,2 2, ,6 3, ,8 2, ,2 0, ,6, ,6 0, ,8 0, ,2, ,6 0, , ,2 0, ,4 0, ,2 0, ,8 0, ,8 0,24 Asp = 2000 min max sred dev min max sred dev min max sred dev vel , ,4 2, ,4 2, ,2 0, ,8, ,2, ,6 0, ,2 0, , ,8 0, ,2 0, ,4 0, ,4 0, ,2 0, ,6 0,26 Asp = 8000 min max sred dev min max sred dev min max sred dev vel ,2 2, , ,4, , ,4 0, , ,2 0, ,6, ,4 0, ,6 0, ,8 0, , ,2 0, , ,23 Asp vel ,68 3,25 2,39 3, 2,46 2,6 2,28 3,36, ,54,5 0,5 0,3,67,42 2,04 0,63 0, ,28, 0,69 0,78 0,47,4 0,56,83 0, ,25 0,28 0,32 0,22 0,22 0,27 0,27 0,26 0, ,8 0,3 0,24 0,23 0,23 0,26 0,3 0,33 0,23 Devijacija nađenog rješenja u ovisnosti o veličini tabu liste, aspiracijskom parametru i parametru 3,5 3 2, Asp= Asp= devijacija,5 0, Asp= Asp= Asp= Asp=500 veličina tabu liste 50 5 parametar 06

107 5 Veličina problema = 60. Asp = 500 min max sred dev min max sred dev min max sred dev vel ,2 2, , ,6 3, , ,8 3, ,8, ,4 2, ,6 2, ,8, ,2, , ,2, ,4, ,2, ,4,2 Asp = 2000 min max sred dev min max sred dev min max sred dev vel ,6 3, ,2 3, ,6 4, ,8 2, ,6 3, , ,8, ,2 2, , ,6, ,8, ,2, ,8, ,8, ,6,4 Asp = 8000 min max sred dev min max sred dev min max sred dev vel ,8 3, ,4 4, , , ,2 2, ,4, , ,8, ,8 2, ,6, ,6, , ,4, ,8, ,27 Asp vel ,22 3,49 3,2 3,93 3,64 4,06 3,7 4,02 3, ,26 3,46,52 2,69 3,48 2 2,73 2,4, ,2 2,44,4,52 2,6,63 2,07,44 2,34 40,39,36,69,38,39,36,55,45,35 50,7,2,2,33,9,4,26,24,27 Devijacija nađenog rješenja u ovisnosti o veličini tabu liste, aspiracijskom parametru i parametru 4,5 4 3,5 0 Asp= devijacija 2,5 2,5 5 0 Asp= Asp= Asp= Asp= Asp=500 veličina tabu liste 50 5 parametar 07

108 Iz dobivenih rezultata se vidi da je presudan parametar optimizacije veličina liste zabranjenih poteza. Ovisnost o parametrima i AspPar je previše mala da bi se moglo uočiti neke posebne zakonitosti Rezultati optimizacije pomoću simuliranog kaljenja U ovom odjeljku su ispitivane ovisnosti sljedećih algoritama simuliranog kaljenja o njihovim parametrima: ) SimpleSimAnnealing a. T 0 početna temperatura b. TempChangeFactor multiplikativni faktor s kojim se mijenja temepratura c. IterNumOnTemp broj iteracija koji se obavlja na svakoj temperaturi 2) AutomatedSimAnneling a. AcceptHigherProb vjerojatnost prihvaćanja uzlaznog poteza na početku izvođenja algoritma b. TempChangeFactor multiplikativni faktor s kojim se mijenja temepratura c. IterNumOnTemp broj iteracija koji se obavlja na danoj temperaturi 3) WWSimAnnealing a. EpochIterNum broj iteracija u epohi b. Eps definira kriterij za završetak epohe (za temeljitiji opis vidjeti odjeljak ) Rješavanje pomoću Burkard-Rendl algoritma Budući da ovaj algoritam također ovisi o tri parametra, rezultati su prikazani na isti način kao i kod prethodno ispitivanog algoritma. Najprije su u tri tablice prikazani dobiveni rezultati za tri različite vrijednosti parametra IterNumOnTemp, a u četvrtoj tablici su prikazani samo podaci o devijacijama nađenih rješenja. Parametar IterNumOnTemp se uzimao iz skupa vrijednosti {00,200,500}, parametar T 0 iz skupa {0, 50, 00, 250}, a parametar TempChgFactor iz skupa {0.9999, 0.999, 0.99, 0.98}. 08

109 Veličina problema = 2. IterOnTemp = 00 min max sred dev min max sred dev min max sred dev min max sred dev TempChg T0 0,9999 0,999 0,99 0, ,2 0, ,6, ,8, ,8, ,4 0, , ,4 0, ,4 0, ,6 0, ,6 0, ,6 0, , ,8 0,22 IterOnTemp = 200 min max sred dev min max sred dev min max sred dev min max sred dev TempChg T0 0,9999 0,999 0,99 0, , ,4, ,8, , , ,2 0, ,4 0, ,4 0, ,6 0, ,6 0, , ,2 0,3 IterOnTemp = 500 min max sred dev min max sred dev min max sred dev min max sred dev TempChg T0 0,9999 0,999 0,99 0, ,6, ,8, ,8, ,2, , , ,6, ,8, ,8 0, ,2 0, ,8 0, ,4 0, ,6 0, ,8 0, ,4 0,05 IterOnTemp TempChg T0 0,9999 0,999 0,99 0,98 0,9999 0,999 0,99 0,98 0,9999 0,999 0,99 0,98 0 0,82,06,24,2,4,02,8,2,8,28,22, , ,,0,, ,34 0,27 0,27 0,35 0,23 0,04 0,27 0,3 0,5 0,04 0 0, ,27 0,27 0,29 0,22 0,22 0,3 0,6 0,3 0,9 0,22 0,22 0,05 Devijacija nađenog rješenja o parametrima T 0, IterNumOnTemp i TempChgFactor devijacija,4,2 0,8 0,6 0,9999 Iter=00 0,999 0,99 0,98 0,9999 Iter=200 0,999 0,99 0,98 0,9999 Iter=500 0,999 0,99 0,98 0,4 0,2 0 0,99 0,9999 Iter=500 0,99 0,9999 Iter=200 0 T ,99 0,9999 Iter=00 TempChgFactor Iz prikazanog grafa se odmah uočava da se za malu početnu temepraturu dobijaju jako loša rješenja. Razlog tome je što se sistem ne stigne istražiti veći dio konfiguracijskog prostora, te se optimizacija svodi na lokalno pretraživanje malog dijela prostora rješenja. S druge strane, na većim temperatura se sistem za ograničeno vrijeme koje je bilo pridjeljeno svakoj optimizaciji za izvršavanje ne stigne ohladiti te se stoga opet dobijaju lošija rješenja. Odavde se već može uočiti jako velika ovisnost algoritma simuliranog kaljenja o početnoj temperaturi s koje kreće optimizacija. 09

110 Veličina problem = 30. IterOnTemp = 00 min max sred dev min max sred dev min max sred dev min max sred dev TempChg T0 0,9999 0,999 0,99 0, ,8 5, ,8 6, , ,8 5, ,2 0, , ,4 0, ,6 0, ,2, ,6, ,6, , ,4, ,2, ,8, ,35 IterOnTemp = 200 min max sred dev min max sred dev min max sred dev min max sred dev TempChg T0 0,9999 0,999 0,99 0, ,8 5, , ,6 6, ,2 5, ,4 0, ,8 0, ,8 0, ,4 0, ,2 0, ,2, ,6, ,6, ,4, , ,2, ,9 IterOnTemp = 500 min max sred dev min max sred dev min max sred dev min max sred dev TempChg T0 0,9999 0,999 0,99 0, ,2 5, ,6 6, ,4 5, ,4 5, ,2, ,4, ,6, , ,2 0, ,2 0, ,4 0, ,4 0, ,4, , , ,4, IterOnTemp TempChg T0 0,9999 0,999 0,99 0,98 0,999 0,99 0,98 0,99 0,98 0 5,73 6,9 6,28 5,69 5,92 6,7 6,7 5,6 6 6,3 5,97 5, ,84 0,67 0,62 0,6 0,42 0,4 0,44 0,5,7,8,87,86 00,37,45,3,45 0,93,,08,23 0,97 0,83 0,99 0,7 250,9,8,85 2,35,7,33,48,9,5 0,85 0,82, Devijacija nađenog rješenja o parametrima T 0, IterNumOnTemp i TempChgFactor devijacija 3 2,5 2,5 0,9999 Iter=00 0,999 0,99 0,98 0,9999 Iter=200 0,999 0,99 0,98 0,9999 Iter=500 0,999 0,99 0,98 0,5 0 0,99 0,9999 Iter=200 0,99 0,9999 Iter= ,99 T ,9999 Iter=00 TempChgFactor 0

111 Veličina problema = 60. IterOnTemp = 00 min max sred dev min max sred dev min max sred dev min max sred dev TempChg T0 0,9999 0,999 0,99 0, ,8 2, ,2 2, ,8 2, ,4 2, ,8 2, ,6 2, ,8 2, ,4 2, , ,4 3, ,2 3, ,2 3, ,4 4, ,6 3, , ,6 3,9 IterOnTemp = 200 min max sred dev min max sred dev min max sred dev min max sred dev TempChg T0 0,9999 0,999 0,99 0, ,8 2, , ,2 2, ,8 2, ,2 2, ,6 2, ,8 2, ,8 2, ,2 3, ,8 3, ,4 3, ,8 3, ,4 3, ,6 3, ,8 3, ,2 3,64 IterOnTemp = 500 min max sred dev min max sred dev min max sred dev min max sred dev TempChg T0 0,9999 0,999 0,99 0, , , , , ,4 2, ,8 2, , , ,2 3, ,6 3, ,2 3, ,6 3, ,2 3, ,4 3, ,2 3, ,2 3,43 IterOnTemp TempChg T0 0,9999 0,999 0,99 0,98 0,9999 0,999 0,99 0,98 0,9999 0,999 0,99 0,98 0 2,62 2,54 2,6 2,59 2,49 2,4 2,33 2,29 2,47 2,39 2,3 2,2 50 2,87 2,8 2,9 2,72 2,84 2,73 2,76 2,52 2,45 2,34 2,57 2,4 00 3,84 3,65 3,68 3,7 3,55 3,44 3,6 3,74 3,2 3, 3,2 3, ,9 3,82 3,97 3,9 3,78 3,84 3,86 3,64 3,34 3,4 3,49 3,43 Devijacija nađenog rješenja o parametrima T 0, IterNumOnTemp i TempChgFactor 4,5 4 3,5 3 devijacija 0,9999 Iter=00 0,999 0,99 0,98 0,9999 Iter=200 0,999 0,99 0,98 0,9999 Iter=500 0,999 0,99 0,98 TempChgFactor 0,98 0,99 0,999 0,9999 Iter=50 0,98 0,99 0,999 0,9999 Iter=20 0,98 0,99 0,999 0,9999 Iter= ,5 2 T 0 Na ovome grafu vidimo suprotan slučaj u odnosu na dva prethodna grafa. Ovdje je optimizacija bila uspješnija za male početne temperature. Pored toga se može uočiti prednost kod optimizacije s parametrom TempChgFactor 0.98 i 0.99, u odnosu na vrijednosti i Razlog tome je što se sa manjom vrijednošću parametra TempChgFactor sistem brže ohladi te se može bolje istražiti lokalne optimume u području kojem je algoritam konvergirao.

112 Također se može uočiti i utjecaj parametra IterNumOnTemp, čije veće vrijednosti također usporavaju hlađenje sustava, utječući time na performanse algoritma. Veličina problema = 00. IterOnTemp = 00 min max sred dev min max sred dev min max sred dev min max sred dev TempChg T0 0,9999 0,999 0,99 0, ,4 0, ,4 0, ,8 0, ,6 0, ,2 0, ,4 0, ,4 0, ,8 0, , ,6 0, ,2 0, ,6 0, ,8 0, ,8 0, ,8 0, ,2 0,66 IterOnTemp = 200 min max sred dev min max sred dev min max sred dev min max sred dev TempChg T0 0,9999 0,999 0,99 0, ,6 0, ,6 0, , ,6 0, ,4 0, ,8 0, ,4 0, ,6 0, ,8 0, ,6 0, , ,4 0, ,8 0, , , ,2 0,54 IterOnTemp = 500 min max sred dev min max sred dev min max sred dev min max sred dev TempChg T0 0,9999 0,999 0,99 0, ,8 7, ,6 7, ,4 7, ,4 7, ,8 0, , ,2 0, ,2 0, ,8 0, ,6 0, , ,8 0, IterOnTemp TempChg T0 0,9999 0,999 0,99 0,98 0,9999 0,999 0,99 0,98 0,9999 0,999 0,99 0,98 0 0, 0,3 0,08 0, 0,6 0,9 0,4 0,4 7,05 7,8 7,3 7,2 50 0,26 0,24 0,24 0,2 0,8 0,2 0,8 0,4 0,6 0,3 0,6 0,5 00 0,59 0,62 0,54 0,54 0,4 0,4 0,48 0,45 0,34 0,29 0,34 0, ,68 0,72 0,56 0,66 0,5 0,55 0,56 0, Devijacija nađenog rješenja o parametrima T 0, IterNumOnTemp i TempChgFactor devijacija 3 2,5 2,5 0,9999 Iter=00 0,999 0,99 0,98 0,9999 Iter=200 0,999 0,99 0,98 0,9999 Iter=500 0,999 0,99 0,98 0,99 TempChgFactor 0,9999 Iter=500 0,99 0,9999 Iter=200 0,99 0,9999 Iter= ,5 0 T 0 Ovdje je efekt opisan u prethodnom paragrafu još više izražen. Vidimo da je za vrijednost IterNumOnTemp=500 algoritam našao jako loša rješenja, a najbolja rješenja su nađena s vrijednošću 200, iz čega se može zaključiti da je provođenje 00 iteracija algoritma na svakoj temperaturi premalo za ovaj problem. 2

113 Rješavanje pomoću automatiziranog algoritma Kod ispitivanja ovog algoritma parametri su uzimani iz sljedećih skupova vrijednosti: IterNumOnTemp {00,200,500}, AcceptHigherProb {0.999, 0.99, 0.98} i TempChgFactor {0.9999, 0.999, 0.99}. Veličina problema = 2. IterOnTemp = 00 min max sred dev min max sred dev min max sred dev TempChg T0 0,9999 0,999 0,99 0, ,8, ,4, ,8,6 0, ,8, , ,6,39 0, ,4 0, ,8 0, ,34 IterOnTemp = 200 min max sred dev min max sred dev min max sred dev TempChg AcceptHigher 0,9999 0,999 0,99 0, ,2, ,6, ,23 0, , ,2, ,2,9 0, ,4 0, ,4 0, ,29 IterOnTemp = 500 min max sred dev min max sred dev min max sred dev TempChg AcceptHigher 0,9999 0,999 0,99 0, ,4, ,6, ,2,5 0, ,6, ,2, ,4,2 0, , ,2 0, IterOnTemp TempChg AcceptHigher 0,9999 0,999 0,99 0,9999 0,999 0,99 0,9999 0,999 0,99 0,999,23,2,6,43,6,23,28,38,5 0,99,35,25,39,38,47,9,28,37,2 0,98 0,8 0,5 0,34 0,27 0,3 0,29 0,6 0,04 0 Devijacija nađenog rješenja o parametrima AcceptHigherProb, PermNum i TempChgFactor devijacija,8,6,4,2 0,8 0,6 0,4 0,9999 Iter=00 0,999 0,99 0,9999 Iter=200 0,999 0,99 0,9999 Iter=500 0,999 0,99 0,2 0 0,99 0,999 0,9999 Iter=500 0,99 0,999 AcceptHigherPr ob 0,999 0,99 0,98 0,999 0,99 0,9999 Iter=00 0,9999 Iter=200 TempChgFactor 3

114 Veličina problema = 30. IterOnTemp = 00 min max sred dev min max sred dev min max sred dev TempChg T0 0,9999 0,999 0,99 0, ,2 6, ,6 6, ,4 6,34 0, ,2 0, , ,4 0,52 0, , ,6, ,4,43 IterOnTemp = 200 min max sred dev min max sred dev min max sred dev TempChg AcceptHigher 0,9999 0,999 0,99 0, ,8 6, ,4 6, ,2 6,59 0, ,4 6, ,8 6, ,72 0, ,8 0, ,6, ,8 0,76 IterOnTemp = 500 min max sred dev min max sred dev min max sred dev TempChg AcceptHigher 0,9999 0,999 0,99 0, , ,4 6, ,2 6,37 0, ,4 6, , ,2 6, 0, ,2 0, ,2 0, ,2 0,89 IterOnTemp TempChg AcceptHigher 0,9999 0,999 0,99 0,999 0,99 0,9999 0,99 0,999 6,88 6,6 6,34 6,39 6,37 6,59 6,2 6,7 6,4 0,99 0,59 0,5 0,52 6,36 6,4 6,72 6,5 6,9 6, 0,98,33,09,43 0,98,43 0,76 0,9 0,84 0,89 Devijacija nađenog rješenja o parametrima AcceptHigherProb, PermNum i TempChgFactor devijacija ,9999 Iter=00 0,999 0,99 0,9999 Iter=200 0,999 0,99 0,9999 Iter=500 0,999 0, ,999 0,99 AcceptHigherPr ob 0,98 0,999 0,9999 Iter=00 0,99 0,999 0,9999 Iter=500 0,99 0,999 0,9999 Iter=200 0,99 TempChgFactor 4 Vidimo da veće vrijednosti parametra AcceptHigherProb ne odgovaraju algoritmu, jer one povlače kretanje sa više početne temeprature, što vodi k nemogućnosti pravilnog ohlađivanja zbog čega su i pronađena rješenja lošija za takve vrijednosti parametra. Ipak, za manju vrijednost parametra IterNumOnTemp (=00) se sistem uspije dovoljno ohladiti i pronaći bolje rješenje. Razlog tome je što se obavljanjem manje iteracija na svakoj temepraturi, temepratura brže spušta, odnosno sistem se brže hladi. 4

115 Veličina problema = 60. IterOnTemp = 00 min max sred dev min max sred dev min max sred dev TempChg T0 0,9999 0,999 0,99 0, ,8 3, , ,6 3,34 0, ,8 2, ,2 3, ,4 2,8 0, ,8 3, , ,8 3,92 IterOnTemp = 200 min max sred dev min max sred dev min max sred dev TempChg AcceptHigher 0,9999 0,999 0,99 0, ,8 3, ,8 3, ,6 3,33 0, ,4 2, ,8 2, ,6 2,57 0, ,6 3, ,2 3, ,8 3,39 IterOnTemp = 500 min max sred dev min max sred dev min max sred dev TempChg AcceptHigher 0,9999 0,999 0,99 0, , ,4 3, ,26 0, ,2 3, ,6 3, ,6 3,4 0, , ,4 3, ,2 3,4 IterOnTemp TempChg AcceptHigher 0,9999 0,999 0,99 0,999 0,99 0,9999 0,999 0,99 0,999 3,3 3,27 3,34 3,7 3,3 3,33 3,2 3,4 3,26 0,99 2,89 3,4 2,8 2,86 2,67 2,57 3,2 3,25 3,4 0,98 3,7 3,54 3,92 3,75 3,42 3,39 2,97 3,2 3,4 Devijacija nađenog rješenja o parametrima AcceptHigherProb, PermNum i TempChgFactor devijacija ,9999 Iter=00 0,999 0,99 0,9999 Iter=200 0,999 0,99 0,9999 Iter=500 0,999 0, ,999 0,99 0,999 0,9999 Iter=500 0,99 0 0,9999 Iter=200 0,99 0,999 0,99 0,98 0,999 0,9999 Iter=00 TempChgFactor AcceptHigherProb 5

116 Veličina problema = 00. IterOnTemp = 00 min max sred dev min max sred dev min max sred dev TempChg T0 0,9999 0,999 0,99 0, , ,8 7, ,27 0, , , ,2 0, ,8 0, ,2 0, ,4 0,63 IterOnTemp = 200 min max sred dev min max sred dev min max sred dev TempChg AcceptHig 0,9999 0,999 0,99 0, ,6 7, , ,6 7,35 0, ,6 0, ,2 0, ,8 0,2 0, ,6 0, ,8 0, ,6 0,44 IterOnTemp = 500 min max sred dev min max sred dev min max sred dev TempChg AcceptHig 0,9999 0,999 0,99 0, , ,2 7, ,6 7,3 0, ,6 7, , ,6 7,28 0, ,2 0, ,6 0, ,8 0,29 IterOnTemp TempChg AcceptHig 0,9999 0,999 0,99 0,999 0,99 0,9999 0,99 0,999 7,24 7,33 7,27 7,32 7,29 7,35 7,3 7,34 7,3 0,99 0,24 0,27 0,2 0,8 0,8 0,2 7,3 7,34 7,28 0,98 0,56 0,54 0,63 0,39 0,5 0,44 0,28 0,29 0,29 Devijacija nađenog rješenja o parametrima AcceptHigherProb, PermNum i TempChgFactor devijacija ,9999 Iter=00 0,999 0,99 0,9999 Iter=200 0,999 0,99 0,9999 Iter=500 0,999 0,99 0 0,99 0,999 0,9999 Iter=500 0,99 0,999 0,9999 Iter=200 AcceptHigherPr ob 0,999 0,99 0,98 0,999 0,99 0,9999 Iter=00 TempChgFactor Komentirajući rezultate ovoga algoritma simuliranog kaljenja, može se reći da je najvažniji parametar AcceptHigherProb, koji definira početnu temepraturu sistema. Za izvođenje uspješne optimizacije, potrebno je dobro podesiti i vrijednosti parametar IterNumOnTemp i TempChgFactor, odnosno za uspješno provođenje optimizacije, sva tri parametra se moraju dobro usaglasiti kako bi proizvela jednoliko i polagano hlađenje sistema, koje rezultira i dobrim rješenjima. 6

117 Rješavanje pomoću Wilhelm-Ward algoritma U ovom odjeljku su prikazane ovisnosti Wilhelm-Wardovog algoritma o njegovim parametrima za instance veličine 2, 30, 60 i 00. Ispitivala se ovisnost o parametrima EpochIterNum (skup vrijednosti {5,5,25,50}) i Eps (skup vrijednosti {0.25, 0., 0.0}). Veličina problema 2 Najbolje poznato rješenje 652 0,25 0, 0, ,8 0, ,4 0, ,6 0, , ,4 0, ,4 0, ,2 0, ,2 0, ,4 0, ,2 0, ,4 0, ,6 0,3 Devijacija nađenog rješenja u ovisnosti o parametrima EpochIterNum i Eps devijacija 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0, parametar EpochIterNum 0,25 0, 0,0 Veličina problema 30 Najbolje poznato rješenje 624 0,25 0,25 0,25 0,25 0, 0, 0, 0, 0,0 0,0 0,0 0, , ,6 3, ,2 3, ,2, ,6 2, ,6 2, ,4, ,4, ,8, , ,8, ,6,53 Devijacija nađenog rješenja u ovisnosti o parametrima EpochIterNum i Eps devijacija 4 3,5 3 2,5 2,5 0, parametar EpochIterNum 0,25 0, 0,0 7

118 Veličina problema 60 Najbolje poznato rješenje ,25 0,25 0,25 0,25 0, 0, 0, 0, 0,0 0,0 0,0 0, ,6 4, , , ,6 3, ,4 3, ,6 3, ,4 2, ,6 2, ,8 2, , , ,4 2,26 Devijacija nađenog rješenja u ovisnosti o parametrima EpochIterNum i Eps devijacija 5 4,5 4 3,5 3 2,5 2,5 0, parametar EpochIterNum 0,25 0, 0,0 Veličina problema 00 Najbolje poznato rješenje ,25 0,25 0,25 0,25 0, 0, 0, 0, 0,0 0,0 0,0 0, ,6, ,6 0, ,6 0, ,8 0, , ,8 0, ,2 0, ,8 0, ,8 0, ,6 0, ,2 0, ,63,2 Devijacija nađenog rješenja u ovisnosti o parametrima EpochIterNum i Eps devijacija 0,8 0,6 0,4 0,2 0,25 0, 0, parametar EpochIterNum Analizirajući dobivene grafove može se uočiti da je optimizacija bolja za veće vrijednosti parametra EpochIterNum, dok parametar Eps nema tolikog utjecaja, iako se može uočiti lagana tendencija boljeg rada algoritma za manje vrijednosti parametra, što su primjetili i Wilhelm i Ward u svome originalnom radu. 8

119 6.5.4 Rezultati optimizacije pomoću genetičkog algoritma U ovom odjeljku su prikazani rezultati ispitivanja ovisnosti sljedećih genetičkih algoritama o njihovim parametrima: ) 3-tournament-selection algoritam a. PopulationSize veličina populacije jedinki b. MutationProb vjerojatnost mutacije jedinke iz populacije u jednoj iteraciji 2) FFGA algoritam a. PerGeneration koliko novih jedinki se generira u svakoj iteraciji b. R definira u kolikoj mjeri se prilikom odabira jedinki za selekciju uzima u obzir vrijednost njihove funkcije cilja 3) Pohlepni genetički algoritam a. ImmigrationRate svakih koliko iteracija se primjenjuje proces imigracije b. LocalSearchRate svakih koliko iteracija se lokalno optimizira dio jedinki tournament-selection algoritam Kod ispitivanja ovog algoritma proučavala se efikasnost optimizacije u ovisnosti o dva parametra, veličini populacije te vjerojatnosti mutacije. Veliečina populacije je pročavana za vrijednosti {25, 50, 75, 00} a vjerojatnost mutacije za vrijednosti {0.00, 0.005, 0.0, 0.02, 0.05}. 0,00 0,00 0,00 0,005 0,005 0,005 0,0 0,0 0,0 0,02 0,02 0,02 0,05 0,05 0, , , , , , ,2 Tablica: Minimalno i maksimalno rješenje, t eizračunate srednje vrijednosti nađenih rješenja 0,00 0,005 0,0 0,02 0,05 25,57,3,23,55,2 50 0,94,03 0,8,09,7 75 0,99 0,86,3 0,94,0 00 0,79,05 0,89 0,88 0,88,7 Devijacija nađenog rješenja o veličini populacije i vjerojatnosti mutacije Tablica: Devijacija nađenih rješenja od najboljeg rješenja,5 Veličina problema 2 Najbolje poznato rješenje 652 devijacija,3, 0, ,7 0,5 0,00 0,005 0,0 0,02 0,05 vjerojatnost mutacije 9

120 0,00 0,00 0,00 0,005 0,005 0,005 0,0 0,0 0,0 0,02 0,02 0,02 0,05 0,05 0, , , , , , , , , , , , , , , , ,6 Tablica: Minimalno i maksimalno rješenje, te izračunate srednje vrijednosti nađenih rješenja 0,00 0,005 0,0 0,02 0,05 Veličina problema ,76 4,94 4,74 5,35 4,64 Najbolje poznato rješenje ,7 3,7 3,4 3,8 3, ,3 3,6 3,23 3,35 3, ,35 6,6 7,6 7,07 7,23 Tablica: Devijacija nađenih rješenja od najboljeg rješenja Devijacija nađenog rješenja o veličini populacije i vjerojatnosti mutacije 8,5 7,5 6,5 devijacija 5,5 4,5 3,5 2,5, ,5 0,00 0,005 0,0 0,02 0,05 vjerojatnost mutacije 0,00 0,00 0,00 0,005 0,005 0,005 0,0 0,0 0,0 0,02 0,02 0,02 0,05 0,05 0, , , , , , , , ,6 Tablica: Minimalno i maksimalno rješenje, t eizračunate srednje vrijednosti nađenih rješenja 0,00 0,005 0,0 0,02 0, ,0 5,0 5,05 4,98 5,2 50 4,32 4,36 4,59 4,44 4, ,28 4,29 4,56 4,72 4, ,63 5,55 5,35 5,54 5,53 Tablica: Devijacija nađenih rješenja od najboljeg rješenja 6 5,5 Devijacija nađenog rješenja o veličini populacije i vjerojatnosti mutacije Veličina problema 60 Najbolje poznato rješenje devijacija 5 4, ,5 3 0,00 0,005 0,0 0,02 0,05 vjerojatnost mutacije 20

121 0,00 0,00 0,00 0,005 0,005 0,005 0,0 0,0 0,0 0,02 0,02 0,02 0,05 0,05 0, , , , , , , , , , , , , ,6 Tablica: Minimalno i maksimalno rješenje, te izračunate srednje vrijednosti nađenih rješenja 0,00 0,005 0,0 0,02 0,05 Veličina problema 00 25,68,75,7,66,6 Najbolje poznato rješenje ,2,,9,4 75,7,,08,04, ,3 3,22 3,2 3,2 3,2 Tablica: Devijacija nađenih rješenja od najboljeg rješenja 3,5 Devijacija nađenog rješenja o veličini populacije i vjerojatnosti mutacije devijacija 3 2,5 2, ,5 0,00 0,005 0,0 0,02 0,05 vjerojatnost mutacije Nakon analize grafova, neke činjenice odmah postaju uočljive. Prvo, veličina populacije doista ne bi trebala prelaziti 00 jer, kako se na grafovima vidi, rezultati dobiveni s tako velikom populacijom zaostajo po kvaliteti za onima s manjim populacijama. S druge strane, vidimo da populacija ne bi trebala biti ni premala jer se ni rješenja sa veličinom populacije 25 nisu pokazala kao dobra. Naravno, obavljanjem optimizacije sa većim populacijama bi se sigurno moglo doći do jednako kvalitetnih rješenja, ali bi vrijeme potrebno za to bilo značajno duže nego sa manjim populacijama. Što se tiče drugog parametra, vjerojatnosti mutacije, može se reći da se lagana prednost može dati manjim vrijednostima, iako bi za konkretnije zaključivanje bilo potrebno provoditi opsežniju analizu, sa dužim izvršavanjima algoritma. 2

122 FFGA Kod istraživanja ovisnosti algoritma FFGA o njegovim parametrima, zanemarena je ovisnost o veličini populacije, koja je postavljena na 50 (s obzirom na rezultate iz prethodnog odjeljka), a pročavana jeovisnost o parametrima PerGeneration i R. Parametar PerGeneration je imao vrijednosti iz skupa {2,5,0}, a R iz skupa {,.3,.6,.9 }.,3,6, , , Tablica: Minimalno i maksimalno rješenje, te izračunate srednje vrijednosti nađenih rješenja,3,6,9 Veličina problema ,3 Najbolje poznato rješenje , Tablica: Devijacija nađenih rješenja od najboljeg rješenja 0,5 Devijacija nađenog rješenja u ovisnosti o parametrima PerGeneration i R 0, devijacija 0, ,3,6,9-0,05 parametar R,3,6, , , , , , , , , , , ,2 Tablica: Minimalno i maksimalno rješenje, te izračunate srednje vrijednosti nađenih rješenja,3,6,9 2 0,58 0,57 0,44 0,46 5 0,54 0,26 0,4 0,33 0 0,45 0,44 0,27 0,34 Tablica: Devijacija nađenih rješenja od najboljeg rješenja 0,8 0,6 Devijacija nađenog rješenja u ovisnosti o parametrima PerGeneration i R Veličina problema 30 Najbolje poznato rješenje 624 devijacija 0, ,2 0,3,6,9 parametar R 22

123 ,3,6, , , , , , , , ,8 Tablica: Minimalno i maksimalno rješenje, te izračunate srednje vrijednosti nađenih rješenja,3,6,9 2 0,6 0,62 0,59 0,59 5 0,72 0,69 0,53 0,85 0 0,7 0,48 0,59 0,35 Tablica: Devijacija nađenih rješenja od najboljeg rješenja Devijacija nađenog rješenja u ovisnosti o parametrima PerGeneration i R Veličina problema 50 Najbolje poznato rješenje devijacija 0,8 0,6 0, ,2,3,6,9 parametar R Iz dobivenih grafova se može uočiti da se bolji rezultati dobivaju za veće vrijednosti parametra PerGeneration, dok parametar R, čija veća vrijednost povlači i veću vjerojatnost selekcije boljih jedinki za križanje ne utječe toliko na rezultat optimizacije Pohlepni (greedy) genetički algoritam Kod rješavanje skupa problema pomoću ovoga algoritma, testirana je ovisnost o parametirma ImmigrationRate i LocalSearchRate, dok je veličina populaicje bila postavljena na fiksnu vrijednost Tablica: Minimalno i maksimalno rješenje, te izračunate srednje vrijednosti nađenih rješenja Tablica: Devijacija nađenih rješenja od najboljeg rješenja Veličina problema 2 Najbolje poznato rješenje 652 Ovdje se može uočiti izvrsne rezultate koje je algoritam producirao iz kojih se vidi stopostotna učinkovitost. Međutim, s obzirom da se radi o vrlo jednostavnom problemu, to nije ni iznenađujuće, jer za tako mali problem lokalno pretraživanje koje se pokreće iz različitih točaka vrlo efikasno nalazi optimalno rješenje. 23

124 , , , , , , ,6 Tablica: Minimalno i maksimalno rješenje, te izračunate srednje vrijednosti nađenih rješenja ,8 0,96 0,83 0 0,74 0,6 0, ,8 0,97 0,95 Tablica: Devijacija nađenih rješenja od najboljeg rješenja,2 Devijacija nađenog rješenja u ovisnosti o parametrima ImmigrationRate i LocalSearchRate Veličina problema 30 Najbolje poznato rješenje 624 devijacija 0,8 0,6 0,4 0, parametar LocalSearchRate , , , , , , , ,8 Tablica: Minimalno i maksimalno rješenje, te izračunate srednje vrijednosti nađenih rješenja ,93 2,29,5 0 2,6 2,07 2, ,48,7 3, Tablica: Devijacija nađenih rješenja od najboljeg rješenja 3,5 Devijacija nađenog rješenja u ovisnosti o parametrima ImmigrationRate i LocalSearchRate Veličina problema 40 Najbolje poznato rješenje devijacija 3 2,5 2, parametar LocalSearchRate , , , , , , , ,2 Tablica: Minimalno i maksimalno rješenje, te izračunate srednje vrijednosti nađenih rješenja ,29,25,3 0,2,55,27 20,48,45,28 Devijacija nađenog rješenja u ovisnosti o parametrima ImmigrationRate i LocalSearchRate Tablica: Devijacija nađenih rješenja od najboljeg rješenja,6 Veličina problema 50 Najbolje poznato rješenje devijacija, , parametar LocalSearchRate 24

125 Ovaj algoritam se pokazao kao jedan od najkvalitetnijih, što se vidi i po rezultatima koje je našao za problem veličine 40. Međutim, po vremenu izvršavanja, algoritma daleko nadmašuje sve ostale, što i nije iznenađujuće, s obzirom na složenost primjenjivanja lokalnog pretraživanja. Što se tiče ovisnosti o parametrima može se reći da veća stopa imigracije donosi određena poboljšanja u rješenjima (najveća primjenjena stopa imigracije je 5, budući da to znači da se svakih 5 iteracija primjenjuje proces imigracije, dok za ostale vrijednosti 0 i 5 je proces imigracije manje izražen). Stopa lokalnog pretraživanja se, u ovako ograničenom vremenu izvršavanja nije pokazala kao presudan parametar Međusobna usporedba različitih algoritama rješavanja Nakon određivanja ovisnosti algoritama o njihovim parametrima, pristupljeno je međusobnom uspoređivanju algoritama. Definiran je sljedeći skup instanci kvadratičnog problema pridruživanja, gdje su navedene veličine problema i vrijeme koje je pridjeljeno svakom problemu za rješavanje. Naziv problema veličina vrijeme za riješavanje (sekunde) had2 2 5 had nug nug tai30b tai40b tai50b tai60a tai80a wil Svaki od implementiranih algoritama je rješavao svaku od navedenih instanci 5 puta, te su u tablicama prikazani najbolje nađeno rješenje, te devijacija nađenih rješenja od najboljeg rješenja. 25

126 najbolje poznato rješenje najbolje nađeno Simple SimpleDiversify Robust RobustDiversify dev najbolje nađeno dev najbolje nađeno dev najbolje nađeno dev had had nug nug tai30b tai40b tai50b tai60a tai80a wil Tablica 6.. Rješenja postignuta sa tabu-search algoritmima. Iz prikazane tablice možemo zaključiti da su manje više svi implementirani tabu-search algoritmi jednako efikasni. Međutim, iznenađuju loša rješenja za probleme tai30b, tai40b i tai50a. Postignuta rješenja su, kad ih se uspoređuje sa ostalim problemima, vrlo loša, odakle se može izvući zaključak da su navedena tri problema zbog strukture svojih matrica A i B teža od ostalih. Vjerojatno bi se dužim vremenima izvršavanja postigla bolja rješenja, budući da su takva rješenja već i prijavljivana u stručnoj literaturi. Odgovor na to pitanje bi zahtijevao još dulja vremena optimizacije, te preostaje kao cilj za daljnja istraživanja. 26

127 Simple Automated Wilhelm-Ward najbolje najbolje najbolje najbolje poznato dev dev dev nađeno nađeno nađeno rješenje had had nug nug tai30b tai40b tai50b tai60a tai80a wil Tablica 6.2. Rješenja postignuta sa algoritmima simuliranog kaljenja. Rezultati dobiveni rješavanjem pomoću algoritama simuliranog kaljenja, koji su prikazani u gornjoj tablici, su u velikom neskladu sa autorovim dojmom o kvaliteti rješenja koja se mogu postići pomoću algoritma simuliranog kaljenja. Naime, prikazani rezultati su jako loši, čak bi se moglo reći i katastrofalni. Najverojatniji razlog je loše podešavanje parametara algoritma, pogotovo za prva dva korištena algoritma. Iako je u poglavlju 6.4 provedena detaljna analiza ovisnosti algoritama o njihovim parametrima, očigledno su nedostaci te analize, a koji su već spomenuti ranije i odnose se prvenstveno na ograničeno vrijeme izvršavanja, utjecali na krivo definiranje optimalnih parametara, te su dobivena rješenja jako loša. Ipak, kvaliteta Wilhelm-Ward algoritma dolazi do izražaja, pogotovo kod kompliciranijih problema. Razlog se može potražiti u načinu kontrole temeprature. Naime, prva dva algoritma na svakoj temperaturi izvode preddefinirani broj iteracija, zadan parametrom IterNumOnTemp, što sigurno nije optimalno jer se na velikim temperaturama ne stigne dovoljno istražiti okolina, a na malim temperaturama se izvode bespotrebne iteracije koje uopće ne pridonose poboljšanju funkcije cilja. Stoga se može zaključiti kako je kvalitetno određivanje trenutka prelaska na sljedeću temperaturu jako bitno. 27

128 3-tournament-sel. FFGA Greedy najbolje najbolje najbolje najbolje poznato dev dev dev nađeno nađeno nađeno rješenje had had nug nug tai30b tai40b tai50b tai60a tai80a wil Tablica 6.3. Rješenja postignuta sa genetičkim algoritmima. Iz prikazanih rezultati optimizacije dobivenih pomoću genetičkih algoritama vidimo da oni po svojoj kvaliteti nadmašuju sve ostale. I to iz vrlo jednostavnog razloga. Budući da imaju ugrađen algoritam lokalnog pretraživanja, pomoću kojega se jedinke u populaciji stalno poboljšavaju, u mogućnosti su pretražiti više lokalnih minimuma, i nakon toga križanjem, odnosno mutacijom, među razliitim jedinkama iskoristiti najbolje dijelove genetičkog materijala jedinki u stvaranju novih, poboljšanjih jedinki. Posebno se to može reći za pohlepni genetički algoritam koji se može ocijeniti najboljim algoritmom koji je u ovom radu implementiran za rješavanje kvadratičnog problema pridruživanja. 28

129 7. Primjena na problem rasporeda ispitnih rokova Nakon opisa kvadratičnog problema pridruživanja i načina njegovog rješavanja, sada se može pristupiti opisu problema koji je potaknuo moje osobno istraživanje na ovom području, a to je problem rasporeda ispitnih rokova na Fakultetu elektrotehnike i računarstva. U ovom poglavlju će najprije biti dan opis problema i njegovih ulaznih podataka, a zatim će biti opisan algoritam koji je primjenjen za njegov rješavanje. Za potrebe rješavanja je razvijena i aplikacija za operacijski sustav Windows, koja će također biti opisana, a na kraju će biti dan pregled dobivenih rezultata. 7. Opis problema Problem rasporeda ispitnih rokova je sljedeći. Na Fakultetu elektrotehnike i računarstva je upisano nekoliko tisuća studenata, na dva različita studija, sa nekoliko stotina obaveznih i izbornih predmeta i tri velika ispitna roka : zimskim, ljetnim i jesenskim. Školska godina se standardno sastoji od dva semestra, zimskog i ljetnog, a navedeni ispitnih rokovi padaju nakon ljetnog, odnosno nakon zimskog semestra, dok se jesenski ispitni rok održava prije početka akademske godine. Većina ispita se sastoji od pismenog i usmenog dijela, s time da je prolazak na pismenom dijelu uvjet polaganja usmenog dijela ispita. Na zimskom ispitnom roku se studentima za svaki ispit moraju ponuditi dva termina polaganja (odnosno ispitni rok se sastoji od dva podroka), dok se na ljetnom i jesenskom ispitnom rok moraju dati tri termina za svaki ispit. Pored ova tri glavna ispitna roka, postoje još i dva izvanredna ispitna roka: proljetni i izvanredni jesenski ali budući da traju samo jedan tjedan i imaju samo jedan termin za polaganje svakog ispita, optimizacije rasporeda održavanja ispita nije toliko nužna. Cjelokupni raspored održavanja ispita se mora oglasiti na početku godine. Pošto je za uspješan upis više godine potrebno položiti sve ispite na godini (kojih, ovisno o smjeru i godini, otprilike ima 0 na godini) studeni moraju na svakom ispitnom roku položiti više ispita, te se postavlja problem kako rasporediti termine održavanja ispita da se studentima taj posao što više olakša. Kao primjer se može uzeti ljetni ispitni rok koji traje otprilike 35 dana unutar kojih bi dobar student trebao položiti tri ispita. To vodi na optimalan razmak između polaganja od 0-5 dana, što omogućava relativno bezbolno spremanje sva tri ispita. Pitanje je međutim, da li će se datumi održavanja ispita koje student mora položiti doista tako poklopiti da student može izaći na ispit svakih 0-ak dana. Cilj optimizacije rasporeda ispitnih rokova je doći do takvog rasporeda termina ispita da su termini održavanja ispita maksimalno raspršeni tijekom cijelog ispitnog roka. 29

130 7.2 Opis struktura podataka Kako bi se moglo pristupiti rješavanju navedenog problema, potrebno je najprije doći do ulaznih podataka. Budući da je Studentska služba na Fakultetu elektrotehnike i računarstva informatizirana, odnosno postoji baza podataka sa podacima o svim studentim, predmetima, grupama predmetima i nastavnicima, prikupljanje ulaznih podataka za algoritam se moglo relativno jednostavno obaviti. Ulazni podaci koji su potrebni za rješavanje ovog problema se mogu opisati sljedećim skupovima: Predmet { ŠifPred, NazPred } - predstavlja vezu između šifre predmeta i njegovog imena GrupaPredmeta { ŠifGrupePred, NazGrupePred } - veza između šifre grupe pred IspitniRok - { ŠifIspitnogRoka, BrojPodrokova } - za svaki od ispitnih rokova definira koliko se termina za polaganje svakog ispita mora dati. Budući da su te vrijednosti deifnirane Statutom fakulteta, nisu uzete iz bazepodataka već su ukodirane direktno u program o ZIMSKI 2 o PROLJETNI o LJETNI 3 o JESENSKI 3 o IZVANREDNI JESENSKI OpisPred { 'O', 'I', 'H', 'K', 'D' } - opis vrste predmeta o O obavezni o I izborni o H humanistički o K konstrukcijski program o D diplomski ispit NastavniPlan { ŠifPred, ŠifSmjer, OpisPred, Semestar, ŠifGrupePred, BrojStud } - ŠifPred šifra predmeta za koji se definira nastavni plan - ŠifSmjer šifra smjera na kojem se predmet predaje - OpisPred - opis predmeta koji je predstavljen jednom od vrijednosti navednih u skupu OpisPredmeta - Semestar u kojem semestru se predaje predmet - ŠifGrupePred šifra grupe predmeta (vezana na podatke iz skupa GrupaPredmeta) 30

131 - BrojStud broj studenata koji sluša taj predmet u danom semestru, na danom smjeru PresjekStud { ŠifPred, ŠifPred2, BrojStud } - definira broj studenata koji istovrmeno slušaju (znači mogu polagati) predemte sa šiframa ŠifPred i ŠifPred2 IspitiIstiDan { skup ŠifPred koji moraju biti održani isti dan } S obzirom na mogućnost svih današnjih razvojnih okruženja, pa tako i Visual C++, da se povezuju na baze podataka i obavljaju upite pomoću kojih se mogu dohvaćati podaci, logično je bilo taj postupak primjeniti prilikom razvoja aplikacije i direktno iz baze podataka studentske službe dohvaćati potrebne podatke. Međutim, s obzirom da je rad sa bazama u razvojnom okruženju Visual C++ relativno složen, primjenjena je druga tehnika. Naime, s obzirom da su podaci koji su potrebni za rješavanje ovog problem statički, u smislu da su oni definirani na početku akademske godine te se nakon toga ne mijenjaju, kao puno jednostavnije rješenje se pokazalo prebacivanje podataka iz baze u tekstualne datotteke koje su zatim jednostavnim operacijama učitane u samu aplikaciju Strukture podataka Prilikom učitavanja podataka iz tekstualnih datoteka, podaci su ubacivani u strukture podataka koje su u C++ bile definirani kao razredi sa pripadnim članskim funkcijama za manipulaciju podacima. Pored toga definirana su i dva sučelja prema tim strukturama, kako bi se unutrašnji detalji tih struktura sakrili (enkapsulirali) s ciljem da ostatak programa bude nezavisan o internoj strukturi tih podataka (što omogućava lakše mijenjanje interne strukture razreda) Struktura za podatke o presjeku studenata na dva ispita Podaci o presjeku studenata na dva ispita su učitavani u razred PresjekStudData. Međutim, s ciljem razdvajanja sučelja od implementacije, najprije je definiran razred sučelja IPresjekCollection sa sljedećom deklaracijom : class IPresjekCollection { public: virtual bool setpresjek( int sifra, int sifra2, int presjek ) = 0; virtual boo l getpresjek( int sifra, int sifra2, int *presjek ) const = 0; // vraća iterator cijelog retka u kojem se nalaze podaci za danu šifru virtual bool getpresjeksifra( int sifra, std::pair<mconstiter,mconstiter> &redak ) = 0; }; virtual void clearalldata() = 0; 3

132 Unutar ovog razreda su definirane sve funkcije koje se mogu obavljati nad skupom podataka o presjecima među ispitima. U samoj definiciji razreda PresjekStudData, podaci su se pohranjivali na sljedeći način. Podatku o svakom ispitu je priduržen podatak o tome s kojim ispitom ima presjek i o koliko se studenata radi. Stoga je definiran pomoćni razred ParSifraPresjek sa sljedećom deklaracijom: struct ParSifraPresjek { public: // konstruktor, pristupne funkcije //... int m_nsifra, m_npresjek; }; U samom razredu PresjekStudData podaci su spremljeni u multimap<_key, _Data> strukturi koja dopušta neinjektivno preslikavanja sa podatka tipa _Key na podatak tipa Data, odnosno, za razliku od obične map<key, _Data> strukture, moguće je imati više istih ključeva (što će kod nas biti šifra ispita) kojima se mogu pridružiti različiti podaci. Kao što se vidi iz deklaracije razreda, pomoću multimap strukture je definirano pridruživanje sa šifre ispita na podatak tipa ParPresjekŠifra. class PresjekStudData : public IPresjekCollection { public: PresjekStudData() {} // funkcije iz definiranog sučelja bool setpresjek( int sifra, int sifra2, int presjek ); bool getpresjek( int sifra, int sifra2, int *presjek ) const; bool getpresjeksifra( int sifra, std::pair<mconstiter,mconstiter> &redak ); void clearalldata(); private: std::multimap<int, ParSifraPresjek> mmappresjek; }; Struktura sa podacima o ispitu Podaci o ispitima su modelirani na sličin način. Najprije je definirano sučelje koje određuje operacije koje će implementirati razred za sadržavanje podataka o ispitima: class IIspitCollection { public: virtual bool addispit( int insifra, char *innaziv ) = 0; virtual bool addispit( int insifra, string innaziv ) = 0; virtual bool addispit( int insifra, string innaziv, IspitDodPodaci &indodpodaci ) = 0; virtual bool addispit( int insifra, char *innaziv, IspitDodPodaci &indodpodaci ) = 0; virtual bool addispit( int insifra, char *innaziv, int insemestar, int inbrojstud,int insmjer, char inopis,int ingrupapred ) = 0; 32

133 virtual bool addispit( int insifra, string innaziv, int insemestar, int inbrojstud,int insmjer, char inopis,int ingrupapred ) = 0; virtual bool addispit( int insifra, int insemestar, int inbrojstud, int insmjer, char inopis, int ingrupapred ) = 0; virtual const Ispit& getispitindex( int index ) = 0; virtual const Ispit& getispitsifra( int sifra ) = 0; }; virtual int getbrojispita() = 0; virtual void clearalldata() = 0; Prije definiranja razeda IspitData koji će biti jednostavna kolekcija (realizirana preko običnog vektora) podataka o pojedinačnim sipitima, potrebno je najprije definirati razred Ispit koji će sadržavati podatke koji će se nalaziti u kolekciji. Ovdje se moramo suočiti s jednim problemom. Naime, podaci o određenom ispitu će se u ulaznim podacima dobivenim iz studentske službe pojavljivati više puta, svaki puta sa različitim pridruženim vrijednostima smjera, semestra i broja studenata, budući da se isti predmeti često predaju na različitim smjerovima i u ralzičitim semestrima. Stoga je za dani ispit potrebno nekako obuhvatiti sve te različite podatke u jednu cjelinu. To je napravljeno definiranjem razreda IspitDodPodaci, koji za određeni ispit upravo definira sve različite varijante održavanja tog ispita koje sepojavljuju u nastavnom planu. class IspitDodPodaci { public: IspitDodPodaci(); IspitDodPodaci( int insemestar, int inbrojstud,int int ingrupapred ); private: int m_nsemestar; int m_nbrojstud; int m_nsmjer; char m_chopis; int m_ngrupapred; }; insmjer, char inopis, Nakon definiranja razreda IspitDodPodaci, možemo navesti i deklaraciju samog razreda Ispit, koji predstavlja jednsotavnu strukturu koja sadrži podatke o danom ispitu. Može se uočiti jedino kolekcija vector<ispitdodpodaci> koja za dani ispit sadrži dodatne podatke, kako je to gore opisano. class Ispit { public: // konstruktori Ispit(); Ispit( int insifra, char *innaziv ); 33

134 Ispit( int insifra, string innaziv ); Ispit( int insifra, string innaziv, IspitDodPodaci &indodpodaci ); Ispit( int insifra, char *innaziv, IspitDodPodaci &indodpodaci ); Ispit( int insifra, char *innaziv, int insemestar, int inbrojstud, int insmjer, char inopis, int ingrupapred ); Ispit( int insifra, string innaziv, int insemestar, int inbrojstud, int insmjer, char inopis, int ingrupapred ); // funkcije za pristup članovima //... bool adddodpodaci( IspitDodPodaci &dod ); bool adddodpodaci( int insemestar, int inbrojstud, int char inopis, int ingrupapred ); insmjer, int getbrojdodpod() const { return m_vecdodpod.size(); } const IspitDodPodaci& getdodpod( int j ) const; private: int string m_nsifra; m_strnaziv; }; vector<ispitdodpodaci> m_vecdodpod; Razred kolekcije Ispita Razred IspitData koji sadži podatke o svim ispitima koji sudjeluju u optimizaciji je definiran na sljedeći način: class IspitData : public IIspitCollection { public: IspitData() {} // funkcije za dodavanje novog ispita u kolekciju bool addispit( int insifra, char *innaziv ); //... uz sve dodatne varijante već definirane u razred Ispit const Ispit& getispitindex( int index ); const Ispit& getispitsifra( int sifra ); int getbrojispita() { return vecispit.size(); } void clearalldata(); int findpredmet( int sifra ); int findpredmet( string naziv ); int findpredmet( char *naziv ); private: 34

135 }; vector<ispit> vector<int> vecispit; vecsifrauindex; Dodatna članska varijabla vecsifrauindex je potreba kako bi se na brzi način mogo doći do podataka u ispitu sa određenom šifrom (budući da podaci u kolekciji vecispit nisu indeksirani po šfiri ispita) Funkcija cilja Nakon opisa ulaznih podataka i strukura u koje su oni spremljeni unutar aplikacije, potrebno je definirati funkciju cilja koja će se optimirati. Kao što je rečeno u uvodu u poglavlje, cilj je rasporediti ispite tako da što veći broj studenata može izaći na što više ispita a da su termini održavanja tih ispita što je moguće više udaljeni. Iz samog gornjeg opisa se vidi da se radi o međusobno kontradiktornim zahtjevima, te će biti nužno napraviti određene kompromise prilikom traženja rješenja. Prije samog opisa funkcije cilja, potrebno je definirati strukturu koja će opisivati rješenje problema. Budući da rješenje problema čine termini održavanja za svaki ispit, a broj termina održavanja ovisi o ispitnom roku, očigledno se rješenje može predstaviti nekom matricom T ij = (t ij ), uz i=,..., BrojIspita i j=,.. BrojPodrokova, gdje će element t ij definirati kojeg dana ispitnog roka se treba održati i-ti ispit, a na j-tom podroku. U funkciji cilja možemo definirati sljedeće doprinose: Doprinos presjeka studenata na istom ispitu na različitim podrokovima Ovim doprinosom funkciji cilja se nastoji što više povećati udaljenost među terminima održavanja istog ispita. Pseudo kod se može ovako napisati: Za k= do BrojIspita Za i= do BrojPodrokova- Za j= do BrojPodrokova u = sqrt(t[k][i] T[k][j]); F += u * BrojStud[k]; Udaljenost je potencirana sa 0.5 jer bi u slučaju korištenja linearne skale svi rasporedi bili jednako optimalni Nepoštivanja minimalne udaljenosti između termina ispita na dva susjedna podroka Kao cilj optimizacije je postavljeno da udaljenost među terminima održavanja nekog ispita na ispitnom roku mora biti minimalno MinDist, gdje je MinDist parametar koji se definira u aplikaciji. Ukoliko je udaljenost manja, to se kažnjava doprinosom u funkciji cilja jednakim KaznaMinDist. 35

136 Za k= do Brojispita Za i = do BrojPodrokova- Za j= do BrojPodrokova Ako je Abs( T[k][i] T[k]fj] ) < MinDist F += KaznaMinDist; Presjeka studenata na različitim ispitima Ovaj doprinos funkciji cilja je najvažniji i predstavlja bit optimizacije rasporeda ispitnih rokova. Minimizacijom ovog doprinosa se udaljavaju termini održavanja ispita koji imaju veliki presjek studenata koji ih istovremeno mogu ići polagati, čime se omogućuje većem broju studenata izlazak na oba ispita. Ovdje se prilikom definiranja doprinosa trebalo odlučiti da li će se uzimati u obzir termini održavanja na svim podrokovima, ili samo nekima. Kao logičan izbor se nametnulo da će se uzimati doprinos od termina održavanja na susjednim podrokovima, što je donekle zakompliciralo implementaciju. Za k= do BrojIspita- Za l=k+ do BrojIspita Za i= to BrojPodrokova Za j= do BrojPodrokova Ako je PodrokoviSusjedni(i,j) = true u = sqrt(t[l][i] T[k][j]); F += PresjekStud[k][l] * u; Nepoštivanje podjele na podrokove Budući da je dosadašnja praksa bila da se unutar ispitnog roka mogu identificirati podrokovi unutar kojih se održavaju svi ispiti, prilikom optimizacije se to postavilo kao uvjet te se svako odstupanje od podjele na podrokove (npr. ukoliko na ljetnom ispitnom roku termini nekog ispita ne bi pali po jedan u svaki od tri podroka) kažnjavalo sa doprinosom funkciji cilja u iznosu KaznaPodjeleNaPodrokove. Za k= do BrojIspita Za i= do BrojPodrokova Ako je T[k][i] izvan intervala (PodrokDonja[i], PodrokGornja[i]) F += KaznaPodjeleNaPodrokove; gdje polja PodrokDonja[] i PodrokGornja[] definiraju interval unutar kojega se održava određeni podrok (prilikom izvođenja optimizacije ova polja su se definirala tako da se cijeli ispitni rok podijelio na dva ili tri jednaka podroka) Nepoštivanja maksimalnog opterećenja na grupi predmeta Pošto na svakoj grupi predmeta postoji ograničen broj nastavnog osoblja, prilikom optimizacije se kao dodatni cilj postavilo da se u istome danu na ispitima na istoj grupi predmeta može prijaviti maksimalno MaxBrojStudzaGrupuPred studenata, odnosno ukupan broj 36

137 studenata koji se može prijaviti na ispite na toj grupi predemta u jednom danu ne smije prelaziti vrijednost definiranu parametrom MaxBrojStudzaGrupuPred. Prilikom izračunavanja ovog doprinosa funkciji cilja, najprije je izračunat broj studenata na svakoj grupi predmeta za svaki dan ispitnog roka, gdje je taj podatak pohranjen u dvodimenzionalno polje StudDanGrupa[ BrojGrupaPred ][ BrojDanaIspitnogRoka ], te je za svaki element polja koji je svojom vrijednošću prelazio parametar MaxBrojStudZaGrupuPred, funkcija cilja povećana za KaznaGrupaPred. Svi navedeni doprinosi za trenutni raspored održavanja ispita su izračunati u funkciji Optimize, koja za definirani genetički algoritam predstavlja funkciju cilja. Pored toga, svi parametri potrebni za izračunavanje funkcije cilja su stavljeni u razred OptFuncParam, čija je deklaracija navedena ispod i gdje se u konstruktoru vidi kakve su pretpostavljene vrijednosti bile za pojedine parametre. class OptFuncParam { public: OptFuncParam() { dexponent = 0.5; dkaznapodjelenapodrokove = 3000; dkaznamindist = 3000; dkaznagrupapred = 8000; dnagradaistidan = 0000; dampblizineispita = 5; damppresjekastud = 5; nmindistance = 8; nminpresjek = 20; nmaxbrojstudzagrupupred = 300; nmaxispitaistidannaistomsmjeru = 2; dkaznaprekoracenjamaxispitanaistomsmjeru = 2000; } // pristupne funkcije ( get i set metode )... private: double dexponent; // 0.5 double dkaznapodjelenapodrokove; // 00 double dnagradaistidan; // 00 double dkaznagrupapred; // 00 double dkaznamindist; // 000 double dampblizineispita; double damppresjekastud; }; int nmindistance; // 8 int nminpresjek; int nmaxbrojstudzagrupupred; // 200 int nmaxispitaistidannaistomsmjeru; double dkaznaprekoracenjamaxispitanaistomsmjeru; 37

138 7.3 Opis korištenog algoritma Budući da je vremenski slijed razvoja u stvarnosti bio obrnut od onoga predočenog u ovome radu, naime najprije se riješavalo problem rasporeda ispitnih rokova a tek tada nakon toga je uočena njegova sličnost s kvadratičnim problemom pridurživanja, za algoritam za rješavanje se odabralo genetički algoritam 3-tournament-selection tipa. Gledajući retrospektivno s obzirom na rezultate optimizacije QAP-a pomoću raznih algoritama koji su navedeni u 6-tom poglavlju, može se reći da bi se korištenjem nekih drugih algoritama možda postigli bolji rezultati. Budući da je korišteni genetički algoritam detaljno opisan u 5-tom pogavlju, ovdje će se samo iznijeti neke specifičnosti koje su posljedica oblika ulaznih podataka. S obzirom da se kod rješavanja problema ispitnih rokova ne radi o klasičnom kvadratičnom problemu pridruživanja, bilo je potrebno donekle modificirati način rješavanja, i to uglavnom u dijelu koji se bavi strukturama podataka. Naime, dok je kod običnog QAP-a rješenje problema predstavljeno permutacijom, kod problema ispitnih rokova je rješenje predstavljeno matricom. Razlog tome je što definirano pridruživanje ispita na određene termine (dane) održavanja nije bijektivno jer se za svaki ispit treba odrediti više termina održavanja, a i na svaki termin održavanja dolazi više ispita (to naravno ovisi i o broju ispita za koji se obavlja optimizacija). Stoga je kod implementacije genetičkog algoritma bilo potrebno modificirati operator križanja, iako se u osnovi koristio standardni operator križanja kod kojeg se ista pridruživanja prenose u kromosom djeteta, dok se nepopunjeni dio konsturira na takav način da se preuzme pridruživanje jednog od roditelja. Operator mutacije je izveden na standardni način tako da se najprije slučajno odabirala jedinka iz populacije nad kojom se obavljala mutacija, a zatim su se slučajno odabirala dva ispita čiji bi se termini održavanja nakon toga zamijenili. 38

139 7.4 Opis aplikacije Aplikacija je napisana korištenjem Visual C++ razvojnog okruženja, uz korištenje MFC skupine razvoja koji omogućavaju brži razvoj Windows aplikacija. Iskoristila se standardna document/view arhitekura MFC-a. Funkcija je izvedena kao SDI (eng. Single Document Interface) aplikacija, što znači da se može raditi samo sa jednim dokumentom istovremeno Izbornik File U izborniku File, definirane su sljedeće opcije : Zapiši u ASCII datoteku Učitaj nazive ispita Učitaj nastavni plan Učitaj presjek studenata zapisuje rezultate optimizacije u ASCII datoteku iz ulazne ASCII datoteke učitava šifre i nazive ispita iz ulazne ASCII datoteke učitava nastavni plan, odnosno popunjava skup NastavniPlan iz ulazne ASCII datoteke učitava podatke o presjeku studenata na različitim ispitima Izbornik View U ovom izborniku se nalazi definirana samo jedna opcija (pored standardnih opcija Toolbar i Statusbar koje se kod MFC aplikacija standardno nalaze u tom izbornku) i to je opcija Pregledaj ispite koji trebaju biti isti dan koja omogućava korisniku da vidi popis ispita za koje je u ulaznim podacima definirano da bi se trebali održavati istog dana Izbornik Opcije U izborniku Opcije mogu se podesiti opcije programa preko sljedećih stavki izbornika: Parametri optimizacije Odredi parametre roka otvara dijalog za podešavanje parametara aplikacije (prikazan na slici 7. ) Koristi se za podešavanje koeficijenata koji se koriste kod izračunavanja fuinkcije cilja otvara dijalog za podešavanje parametara ispitog roka koji se želi optimirati (prikazan na slici 7.2) 39

140 Slika 7. Dijalog za podešavanje parametara aplikacije. Slika 7.2 Dijalog za određivanje parametara ispitnog roka. 40

141 7.4.4 Izbornik Optimizacija Izbornik Optimizacija ima samo jednu stavku, Pokreni, koja služi za pokretanje optimizacije. Odabirom ove stavke na ekranu se pojavljuje dijalog za optimizaciju, prikazan na slici 7.3. Slika 7.3. Dijalog za izvođenje optimizacije. Na dijalogu se vidi kontrola PrikazRasporedIspita, koja je opisana u šestom poglavlju, na djelu. U prvom stupcu su popisani svi ispiti koji sudjeluju u optimizaciji, gdje se u konkretnom slučaju na slici radilo o optimizaciji rasporeda ispita za prve dvije godine studija. U svakome retku, koji odgovara pojedinačnom ispitu, je pomoću kvadratića u određenom stupcu signalizirano raspoređivanje održavanja tog na dan koji je predstalvjen tim stupcem. Na kraju svakog retka je pomoću praznog kružića signalizirano koji ispiti krše pravilo o opterećenju na grupi predmeta, a pomoći kvadratića je označeno koji ispita krše pravilo o podjeli na podrokove. U dnu svakog stupa je naveden broj ispita koji se održava taj dan. Pomoću dugmeta STOP se može zaustaviti izvođenje optimizacije, a pomoću dugmeta NastaviOptimizaciju se može ponovno pokrenuti od točke gdje je prethodna optimizacija završena. Razlog uvođenja te mogućnosti je da se omogući korisniku da može promijeniti parametre za vrijeme izvođenja optimizacije, pristiskom na dugme Promjeni parametre. Dugme Zatvori formu, kao što samo ime kaže zatvara dijalog i sprema dobivene rezultate. 4

142 Ispisani podaci u donjem lijevom kutu dijaloga se koriste kao uputa korisniku koji nadzire proces optimizacije. prve tri stavke, Max.funkcija dobrote, Min.funkcija dobrote i Prosj. funkcija dobrote, se odnose na vrijednost funkcije cilja. Također je navedeno koliko je ograničenja prekršeno (podjela na podrokove, prevelika blizina ispita te ograničenje opterećenja na grupi predemta). U drugom stupcu se vidi kako je strukturirana ukupna vrijednost funkcije cilja, odnsono koliko pojedini djelovi sudjeluju u ukupnom iznosu (u postotcima) Izbornik Rezultati U posljednjem izborniku Rezultati su opcije za pregled rezultata optimizacije: Vizualni prikaz rasporeda Odabiranjem ove opcije, na ekranu se prikazuje dijalog (slika 7.4) koji u vizualnom obliku prikazuje optimirani raspored održavanja ispita. U desnom kutu se može izabrati za koji ispitni rok se želi vidjeti rezultate, a odmah do je ispisnao koliko je eksplicitnih ograničenja prekršeno u konačnom rezultatu optimizacije. Slika 7.4. Dijalog za vizualni prikaz rasporeda održavanja ispita. Nakon opcije vizualni prikaz raspored, slijedi skupina sličnih opcija koje sve prikazuju dobiveno rješenje u tabličnom obliku, s time da se razlikuju po tome kojim redoslijedom se ispisuju ti podaci. 42

143 Pregled po semestrima Pregled po ispitima ispiti su prilikom ispisa sortirani po semestrima u kojima se održavaju (slika 7.5) sortiranje po šifri predmeta Pregled po grupama predmeta sortiranje po grupama predmeta (slika 7.6) Pregled po smjerovima sortiranje po smjerovima Kod pregleda po grupama predmeta, zadebljano se ispisuju oni termini koji krše pravilo o maksimalnom opterećenju na grupi predmeta, kako bi se lakše uočili. Slika 7.5. Dijalog za prikaz rasporeda ispita po semestrima. Slika 7.6. Dijalog za pregled rezultata optimizacije u tabličnom obliku, sortiran po grupama predmeta. 43

144 Pregled po smjerovima i godinama vizualno Ova opcija omogućava vizualni pregled rasporeda održavanja ispita, s time da se mogu odabrati godina studija i smjer za koji se žele pregledati ispiti. Dijalog pomoću kojeg se može obavljati pregledavanje je prikazan na slici 7.7. Slika 7.7. Dijalog za pregled rasporeda održavanja ispita po godinama i smjerovima. 7.5 Rezultati Razvijena aplikacija je iskorištena za optimiranje rasporeda ispitnih rokova na Fakultetu elektrotehnike i računarstva u školskoj godini 999/2000. Rezultati optimizacije se mogu ocijeniti kao zadovoljavajući. Kod optimiranja rasporeda ispitnih rokova za prvu i drugu godinu studija (gdje se radilo o rasporedu otprilike 20-ak ispita), dobiveni rezultati su bili izvrsni, čak i za jesenski ispitni rok koji je sa svojih 20 radnih dana unutar kojih se trebalo za svaki ispit definirati tri ispitna termina, pokazao kao najtvrđi orah prilikom optimizacije. Ispiti su bivali raspoređeni ravnomjerno tijekom cijelog ispitnog perioda uz poštovanje rasporeda na podrokove i vidljivo uzimanje u obzir presjeka studenata na različitim ispitima. Korišteni genetički algoritam se pokazao učinkovitim u pronalaženju dobrog rasporeda ispitnih termina, a na slici 7.8 je prikazan napredak algoritma kroz određeni broj iteracija. Na grafu je prikazano najbolje rješenje (odnosno jedinka) i prosječna vrijednost funkcije cilja u cijeloj populaciji. Na PC računalu sa procesorom Intel Celeron na 433 MHz, optimizacija je trajala otprilike pola sata, što je omogućilo opsežno eksperimentiranje sa različitim vrijednostima parametara. 44