Problem plecakowy. Dokumentacja. 3 kwietnia. Algorytm dokładny oparty na metodzie programowania dynamicznego

Transkrypt

1 Dokumentacja 3 kwietnia 2009 Problem plecakowy Algorytm dokładny oparty na metodzie programowania dynamicznego Optymalizacja w systemach dyskretnych Prowadzący: dr inż. Jarosław Pempera Termin: ŚR/P/9 15 Paweł Porombka (148955)

2 1. PROBLEM PLECKOWY ROZWIĄZNIE PROBLEM PLECAKOWY 1.1 Problem Plecakowy - (ang. Knapsack problem), jest jednym z typowych problemów dyskretnych. Bardzo często przytaczany jako przykład w literaturze i bardzo często właśnie na tym problemie tłumaczone są techniki programowania dynamicznego. Formalnie dyskretny problem plecakowy możemy sformułować następująco: Mamy zbór przedmiotów A: gdzie każdy przedmiot posiada dwie właściwości w postaci liczb całkowitych (dla nas nieujemnych): Jeżeli zdefiniujemy pewien plecak (pojemnik), który posiada skończoną pojemność P, oraz zbiór zmiennych binarnych możemy zdefiniować następujący problem optymalizacyjny, który będzie polegał na maksymalizacji funkcji celu postaci: przy spełnionych ograniczeniach: W ten sposób sformułowaliśmy dyskretny problem plecakowy. Oczywiście możemy rozważać zmienne, wówczas mówilibyśmy o ciągłym problemie plecakowym, jednakże program rozważa dyskretną formę problemu. Otrzymaliśmy zatem konkretny problem, który polega na znalezieniu takiej grupy przedmiotów (zbioru), spośród określonych wcześniej, których wartość będzie największa uzyskamy największy zysk, ale które to przedmioty zmieszczą się do plecaka, czyli ich sumaryczna waga nie przekroczy dopuszczalnej wagi plecaka. Potocznie zwany problemem złodzieja okradającego jubilera, problem plecakowy jest praktycznym problemem, z którym borykają się choćby firmy transportowe. Wówczas polega on na optymalnym załadowaniu nie tylko przedmiotów o określonej wadze do środka transportu, ale również na odpowiednim rozłożeniu tych przedmiotów, by zmieściło się ich jak najwięcej. Jest to jednak problem bardziej złożony. 2

3 PROGRAMOWANIE DYNAMICZNE 1.2 Jednymi z interesujących technik programistycznych, są techniki programowania dynamicznego. Strategia programowania dynamicznego została wymyślona przez Richarda Bellman a. Jej założenia są dość proste rozłożyć problem na mniejsze podproblemy, które dość łatwo możemy rozwiązać, jeżeli tylko spełniają one własność optymalnej podstruktury 1. Takie rozwiązania cząstkowe pozwalają systematycznie zbliżać się do optimum problemu, przy czym a kolejnych krokach wykorzystujemy najlepsze poprzednie rozwiązania. Metoda ta pozwala wykorzystać rekurencyjną zależność między rozwiązaniami w kolejnych krokach algorytmu i tym samym obliczać każdy problem tylko raz. Parametry wykorzystywane w programowaniu dynamicznym (najczęściej w liczbie dwóch) ustalamy arbitralnie, gdyż to my budujemy algorytm, który ma rozwiązać nasz problem. Zatem bardzo ważnym elementem okazuje się być odpowiedni wybór parametrów i dostosowanie ich do postaci wykorzystywanej w technice programowania dynamicznego. Zdarza się oczywiście, że liczba parametrów wzrasta a ich dobór jest dość skomplikowany, jednakże należy pamiętać, że w programowaniu dynamicznym najczęściej wykorzystanie zasobów (pamięci) wzrasta proporcjonalnie do iloczynu największych wartości parametrów, zatem i czas wykonywania się wydłuża. Z tych powodów rzadko stosuje się więcej niż dwa parametry, gdyż przestaje to być efektywne. W jaki sposób definiować problem dla programowania dynamicznego? Na początek należy poznać podstawowe pojęcie programowania dynamicznego: etap (stadium) fragment procesu szukania rozwiązania, jest charakteryzowany przez pewien stan rozpatrywanego procesu. Z etap możemy przyjąć pewien odcinek czasu, czy drogi. Stadium może stanowić również pewien etap w myśleniu o procesie. Najogólniej rzecz ujmując etap polega na wprowadzeniu nowego wariantu rozwiązania. Dokładnie ilustruje to Rys.1. Widzimy tutaj zależność wykorzystania poprzedniego wyniku by wykonać kolejny krok. Oczywiście nie zawsze musimy korzystać z poprzedniego wyniku, może to być wiele wyników wstecz. x 1 x 2 x n S 0 S 1 S 2 S n-1 S n Rys.1. Schemat wieloetapowego procesu decyzyjnego, który doskonale pokazuje sposób realizacji programowania dynamicznego. S i to wyniki poprzednich problemów (w zerowym kroku najczęściej 0), x i to kolejne decyzje podejmowane w każdym etapie. 1 Dotyczy problemów rozwiązywalnych algorytmami. Własność optymalnej podstruktury spełniają rozwiązania optymalne, które są funkcją rozwiązań optymalnych podproblemów. 3

4 W ten sposób znając pewne własności możemy podsumować teorię programowania dynamicznego podstawowymi dwoma stwierdzeniami, które są filarami całej techniki: a) n wymiarowa funkcja celu powinna mieć postać sumy n funkcji celu, o jednej zmiennej decyzyjnej dla różnych etapów procesu, b) Wartość uzyskana na pewnym etapie zależy od stanu w etapie poprzednim, oraz decyzji uzyskanej w rozważanym stadium. Taka wartość nie powinna jednak zależeć od tego w jaki sposób (jaką drogą) zostało uzyskane rozwiązanie tzw. własność Markowa. Do procesu spełniającego własność Markowa stosuje się podstawową własność strategii optymalnej Bellman a: Polityka optymalna ma tę własność, że niezależnie od początkowego stanu i początkowej decyzji pozostałe decyzje muszą stanowić politykę optymalną ze względu na stan wynikający z pierwszej decyzji. 4

5 PROGRAMOWANIE DYNAMICZNE PROBLEM PLECAKOWY 1.3 Spróbujmy rozważyć problem plecakowy, którym mamy się zająć, przy użyciu techniki programowania dynamicznego. Na początek należy przyjąć, które ze zmiennych zdefiniowanych w problemie ( Rozdz. I ) będą wykorzystane do stworzenia struktury wieloetapowej algorytmu. Biorąc pod uwagę, że problem ma zostać podzielony na podproblemy, które stanowią częściowe rozwiązanie i powinny być elementarne, spróbujmy przeanalizować funkcję celu: przy ograniczeniach: Pierwszą ze zmiennych z pewnością będzie numer kolejno wybieranego elementu - i, gdyż będziemy w stanie określić wagę i wartość tego elementu. Kolejna zmienna decyzyjna powinna zawężać lub poszerzać problem, zatem będzie to rozmiar plecaka P. Im mniejszy rozmiar tym prostsze znalezienie optymalnego upakowania. W ten sposób możemy już stworzyć odpowiednią tablicę (Rys.2.), która pozwoli realizować algorytm n i-ty element P 0 OPT optimum Pojemność plecaka Rys.2. Przyjęta tablica rozwiązań cząstkowych dla programowania dynamicznego Umieszczone zera w pierwszym wierszu i kolumnie zostaną wyjaśnione później. Zatem poszukujemy takiego upakowania plecaka, by otrzymać jak największą wartość i nie przekroczyć ograniczeń. Z tego powodu w tabeli będziemy umieszczać kolejne optymalne wartości plecaka przy konkretnej pojemności plecaka oraz konkretny przedmiot, brany pod uwagę. Stąd definiujemy tabelę Q i,j która zawiera wartość plecaka (jego stan) w danym etapie procesu. Ściślej jest to funkcja celu, o nieco zmienionych ograniczeniach: 5

6 Należy już tylko ustalić w jaki sposób będziemy obliczali stany poszczególnych etapów (wartości komórek tabeli) procesu rozwiązywania problemu. Otóż zaproponujmy następujący algorytm rozwiązania stosujący wprowadzone oznaczenia, który ilustruje pseudokod na Rys.3. FOR TO DO BEGIN END FOR TO DO BEGIN END IF THEN := //(1) ELSE //(2) //rozwiązanie optymalne Rys.3. Algorytm rozwiązujący problem plecakowy, przy użyciu technik dynamicznych Analizując algorytm łatwo zauważyć skąd zera w pierwszej kolumnie i pierwszym wierszu. Otóż algorytm działa w ten sposób, że wykorzystuje znalezione wcześniej optymalne rozwiązanie dla danych etapów. Rozwiązanie składa się z dwóch kroków: 1. Jeżeli aktualny przedmiot nie zmieści się w bieżącym plecaku p i, to zwyczajnie przepisz poprzednie optymalne upakowanie z etapu wcześniejszego i-1 (1) 2. W przeciwnym wypadku sprawdź, które upakowanie będzie lepsze (większa wartość), to z poprzedniego etapu, czy to, które będzie zawierać aktualny element (2). W tej sytuacji dodajemy wartość aktualnego elementu, do stanu plecaka, który był optymalny w chwili, gdy pojemność plecaka była mniejsza o wagę bieżącego elementu (j w i ). W ten sposób odwołujemy się do innego najlepszego upakowania plecaka, które zostało już policzone. Zauważmy jak prosty jest algorytm a jego złożoność jest równa. Widzimy, zatem, że dla małych wielkości pojemności plecaka, oraz dla małej puli przedmiotów algorytm jest wielomianowy, jednakże w miarę wzrostu obu wartości staje się bardzo złożony, stąd nazwa algorytm pseudowielomianowy. Algorytmy te są o tyle praktyczne, że pozwalają na zalezienie rozwiązania danego problemu w czasie pseudowielomianowym. Sens tych technik kryje się właśnie w tej własności. Problemy, które dla innych algorytmów rozwiązań są NP-trudne, mają wykładniczą złożoność, dla pewnej grupy instancji problemów dają się rozwiązać w czasie wielomianowym. Jak się okazuje wiele problemów trudnych można rozwiązać dla praktycznych danych w czasie wielomianowym. 6

7 Analizując pseudo kod przedstawiony powyżej, możemy dojść do wniosku, że jest możliwe zredukowanie zużycia pamięci operacyjnej poprzez ograniczenie tablicy do jednego wektora głównego V1 j i jednego pomocniczego V0 j, gdzie oba odpowiadają kolumnom tabeli Q i,j. Wówczas otrzymamy następujący pseudokod: FOR TO DO BEGIN CHANGE //(1) END FOR TO DO BEGIN END IF THEN := //(2) ELSE //(3) //rozwiązanie optymalne Rys.4. Zoptymalizowany algorytm rozwiązujący problem plecakowy, przy użyciu technik dynamicznych Widzimy, że jedyną zmianą w naszym algorytmie jest dodanie nowego kroku (1), który zamienia nam miejscami dwa wektory. Możemy to oczywiście wykonać w innej formie, bez zamiany wektorów, a jedynie biorąc pod uwagę na przemian wektor V1 jako V0 i odwrotnie. W implementacji zastosowano język C#, który operując na referencjach nie wymaga tutaj żadnego nakładu obliczeniowego, stąd zamiana jest natychmiastowa. 7

8 2. ROZWIĄZANIE IMPELEMENTACYJNE W celu rozwiązania DPP (dyskretnego problemu plecakowego), czyli znalezienia rozwiązania optymalnego, w aplikacji wykorzystano programowanie dynamiczne. W klasie rozwiązującej ten problem zaimplementowano 2 formy funkcji rozwiązującej. Było to spowodowane ewolucją rozwiązań. W rezultacie udało się osiągnąć pojedynczy wektor o długości P, na którym pracuje algorytm zamiast tablicy 2D (n x P). Złożoność tak otrzymanego algorytm wynosi cały czas, jednakże po optymalizacji zajętość pamięci modyfikujemy z n x P ilości komórek tablicy do zaledwie P. CELE PROJEKTU Rozwiązanie problemu plecakowego przy użyciu technik programowania dynamicznego. 2. Możliwość przetwarzania dużej liczby przedmiotów. 3. Określenie granicznego rozmiaru plecaka, z powodów wydajności. 4. Możliwość przetwarzania wsadowego plików z danymi (parametry linii komend). 5. Możliwość zapisu rozwiązania optymalnego do pliku. 6. Realizacja projektu w języku C# 3.0 (Windows Presentation Foundation) na platformie.net. 7. Wizualizacja obiektów z możliwością edycji ich parametrów. 8. Realizacja okienka Splash-Screen 2. 2 Ten element traktujemy jako dodatkowy, nie musi zostać zrealizowany. 8

9 SPECYFIKACJA WYMAGAŃ ROZWIĄZANIE - PROGRAMOWANIE DYNAMICZNE A. Rozwiązanie problemu plecakowego, zrealizowane przy użyciu technik programowania dynamicznego. B. Optymalizacja algorytmu w taki sposób, by nie było potrzeby tworzenia nierzadko ogromnej tablicy danych na potrzeby programowania dynamicznego. C. Wynikiem powinna być pojedyncza liczba określająca wartość (sumę wartości wszystkich przedmiotów), przy optymalnie upakowanym plecaku. 2. WYDAJNOŚĆ A. Ograniczenie liczby przedmiotów do obiektów. B. Ograniczenie rozmiaru plecaka do 500. C. Ograniczenie grafiki rastrowej w interfejsie programu, na korzyść grafiki wektorowej ze względu na charakter WPF. D. Pewna ograniczona (najlepiej stała ) liczba przedmiotów, wykorzystywana do wizualizacji (patrz pkt. 4.A.). 3. PRZETWARZANIE WSADOWE A. Możliwość przetwarzania wsadowego plików z gotowymi danymi opisującymi przedmioty oraz plecak. B. Dane w plikach wejściowych są w określonym formacie, opisanym poniżej a) Plik jest w formacie tekstowym UTF-8/ASCII b) Plik zbudowany jest z dwóch kolumn c) Nagłówek pliku: - Pierwsza kolumna N = ilość wszystkich przedmiotów - Druga kolumna W = pojemność plecaka (maksymalna waga) d) Kolejne N wierszy (i = 1 N): - Pierwsza kolumna waga i-tego przedmiotu - Druga kolumna wartość i-tego przedmiotu C. Pliki wyjściowe to pliki w formacie UTF-8, zawierające jedną liczbę optymalne rozwiązanie problemu. D. Podczas przetwarzania wsadowego nie powinno pojawiać się okienko aplikacji. E. Po skończeniu przetwarzania pliku wejściowego, zapisywany jest wynik w pliku wyjściowym, a program zostaje zamknięty. 9

10 4. JĘZYK PROGRAMOWANIA C# 3.0/XAML (WPF), PLATFORMA.NET A. Wykonanie ciekawego interfejsu graficznego z prezentacją wizualną pewnej puli przedmiotów, których parametry (waga i wartość) mogą być modyfikowane w prosty sposób. Pula tych przedmiotów nie musi być wczytywana z pliku, może być zdefiniowana w programie. B. Musi być możliwość modyfikowania zdefiniowanych wartości w.w. przedmiotów oraz pojemności plecaka, w celu arbitralnego parametryzowania problemu. C. Program powinien wykorzystywać MS Framework 3.0/ REALIZACJA OKIENKA POWITALNEGO SPLASH-SCREEN 3 A. Okienko pojawiające się przed załadowaniem właściwego kodu programu oraz głownego okna aplikacji. B. Zabrania się umieszczania animacji i dużej ilości grafiki na tym okienku, ze względu na jego przeznaczenie. Musi się ono błyskawicznie załadować do pamięci. 3 Ten punkt specyfikacji wymagań jest opcjonalny 10

11 SPECYFIKACJA PROJEKTU ROZWIĄZANIE PRZY UŻYCIU TECHNIK PROGRAMOWANIA DYNAMICZNEGO A. Optymalizacja algorytmu do postaci wykorzystującej tylko jeden 4 wektor danych w pamięci, zamiast dwuwymiarowej tablicy rozwiązań cząstkowych, co powoduje znaczne zmniejszenie zajętości pamięci B. Za wynik przyjmujemy liczbę znajdującą się w przetwarzanym wektorze w ostatniej jego komórce. W przypadku analizowania tablicy 2D byłby to element znajdujący się w prawym dolnym rogu tabeli. 2. UWZGLĘDNIENIE OGRANICZEŃ WYDAJNOŚCIOWYCH A. Ograniczenie liczby przedmiotów do obiektów oraz pojemności plecaka do 500, realizuje konkretna funkcja TryAddParameters( ). Polega to wyłącznie na weryfikacji wejściowych parametrów pod względem zgodności z założeniami. 3. PRZETWARZANIE WSADOWE PLIKÓW Z DANYMI A. Przetwarzanie wsadowe zostaje włączone tylko i wyłącznie, gdy liczba parametrów linii komend pliku aplikacji jest równa 3. Pierwszy parametr to typ operacji jaki chcemy wykonać, następne dwa to kolejno plik wejściowy i wyjściowy. Argumenty w linii poleceń wyglądają następująco: program.exe -wsadowo plik_wejściowy.txt wynik.txt W tej sytuacji zostanie przetworzony plik plik_wejściowy.txt, a wynik zapisany w pliku wynik.txt. B. Podczas przetwarzania wsadowego nie pojawia się okienko aplikacji (nie jest w ogóle ładowane), natomiast pod koniec przetwarzania otrzymujemy komunikat w postaci okna dialogowego (podsumowanie i wynik). Po kliknięciu przycisku OK., program zostaje zamknięty. 4. REALIZACJA PROJEKTU W JĘZYKU C# 3.0/XAML (TECHNOLOGIA WPF), PLATFORMA.NET A. Program został wykonany w oparciu o MS Framework 3.5. B. Interfejs graficzny został zrealizowany w postaci pojedynczego okna głównego, w którego obszarze roboczym pracujemy. Kolejne okienka stanowią zwyczajnie kolejną warstwę (siatkę), która pojawia się (animacja) po konkretnym zdarzeniu. W ten sposób uzyskano dość efektowną aplikację. C. Wizualizacja obiektów polega na przedstawieniu zbioru ikonek (piłka, lornetka, itd.), które w rzeczywistości są komponentami stworzonymi na potrzeby aplikacji. Każdy komponent zawiera dodatkowe właściwości: wagę, wartość oraz nazwę danego przedmiotu. W ten sposób są one identyfikowane (patrz. Dokumentacja Interfejsu Graficznego). 4 Nie do końca jeden, gdyż zawsze musi być dodatkowy wektor tymczasowy. Oba wektory są przetwarzane na zmianę. Co zapobiega przepisywaniu wartości z jednego do drugiego. 11

12 D. Modyfikacja obiektów odbywa się w prosty sposób, klikając dwukrotnie na daną ikonkę. Wówczas mamy możliwość zmodyfikowania również pojemności plecaka. Więcej na ten temat w części Dokumentacja Interfejsu Graficznego. 5. REALIZACJA OKIENKA POWITALNEGO SPLASH-SCREEN A. Udało się zrealizować okienko pojawiające się podczas ładowania głównej części aplikacji. B. Okienko Splash-Screen, musi wywoływać ładowanie pozostałej części aplikacji w osobnym wątku STA (interfejsu graficznego). Wynika to ze struktury realizacji interfejsu w WPF. C. Po utworzeniu obiektu aplikacji głównej oraz załadowaniu bibliotek pojawia się nam okienko główne aplikacji, natomiast Splash-Screen znika. D. Zgodnie z przyjętymi ograniczeniami, okno powitalne nie realizuje żadnych skomplikowanych animacji, a jedynie jest wariacją dwóch obrazków plecaka z przedmiotami (jeden to odblask na podłodze) oraz tekst LOADING. 12

13 MODEL ROZWIĄZANIA 2.4 Do modelowania problemu oraz aplikacji wykorzystano narzędzia do projektowania w języku UML: a) Poseidon for UML 6.0, b) Visual Paradigm for UML 6.4. Modelowanie podzielono na kilka etapów, których realizacją były diagramy poszczególnych problemów OGÓLNY MODEL SYSTEMU Na rys.5. przedstawiono prosty diagram obrazujący ogólną strukturę całego systemu. Rys.5. Diagram zaimplementowanego systemu 13

14 DIAGRAM DZIAŁANIA ALGORYTMU Na rys.6. przedstawiono diagram algorytmu rozwiązującego problem plecakowy. Na diagramie uwzględniono oznaczenia oryginalne z implementacji, opisane w części 2.5. Rys.6. Diagram działania algorytmu 14

15 DIAGRAM DZIAŁANIA INTERFEJSU Rys.7. Diagram działania interfejsu użytkownika na zasadzie diagramu akcji UML 15

16 DIAGRAM PODSTAWOWYCH KLAS APLIKACJI Rys.8. Diagram klas utworzonych na potrzeby systemu 16

17 DOKUMENTACJA KODU 2.5 class KnapsackSolver Klasa zawierająca zaimplementowany algorytm rozwiązania problemu plecakowego, przy użyciu technik programowania dynamicznego. Klasa jest nieskomplikowana, a jej obsługa wyjątkowo prosta. Na potrzeby projektu została ona zamknięta w osobnym pliku, przy czym postanowiono, że nie zostanie utworzona w postaci biblioteki DLL. const int BagLimit = 500; Pole prywatne (stała typu liczba całkowita), przechowuje maksymalną dopuszczalną wartość plecaka, która została poddana weryfikacji: TryAddParameters( ). const int ObjectsLimit = ; Pole prywatne (stała typu liczba całkowita), przechowuje maksymalną dopuszczalną liczbę przedmiotów w puli, która została poddana weryfikacji: TryAddParameters( ). private int[] _Weights Pole prywatne (tablica liczb całkowitych), określające wagi wszystkich przedmiotów wczytane do instancji klasy. Indeksacja od 0.._ItemsCount. To pole zostaje przypisane w chwili dodania poprawnych danych metodą TryAddParameters( ), bądź wymuszenia dodania danych przy użyciu ForceAddParameters( ). 17

18 private int[] _Values Pole prywatne (tablica liczb całkowitych), określające wszystkie wartości (ceny) dodanych przedmiotów. Indeksacja od 0.._ItemsCount. To pole zostaje przypisane w chwili dodania poprawnych danych metodą TryAddParameters( ), bądź wymuszenia dodania danych przy użyciu ForceAddParameters( ). private int _TotalWeight Pole prywatne (liczba całkowita), określające maksymalną dopuszczalną wagę plecaka. To pole zostaje przypisane w chwili dodania poprawnych danych metodą TryAddParameters( ), bądź wymuszenia dodania danych przy użyciu ForceAddParameters( ). private int _ItemsCount Pole prywatne (liczba całkowita), określające ilość przedmiotów, które zostały dodane do puli w instancji klasy. To pole zostaje przypisane w chwili dodania poprawnych danych metodą TryAddParameters( ), bądź wymuszenia dodania danych przy użyciu ForceAddParameters( ). Z zewnątrz klasy pole jest dostępne jako właściwość tylko do odczytu: ItemsCount. private int[,] _Results Pole prywatne (dwuwymiarowa tablica liczb całkowitych), zawierające wyniki w postaci tablicy kroków algorytmu programowania dynamicznego. Pole jest inicjalizowane tylko po wywołaniu metody pierwszej wersji rozwiązywania algorytmu: SolveProblem1(). Z zewnątrz klasy pole jest dostępne jako właściwość tylko do odczytu: Results. Rozwiązanie jest przechowywane naturalnie w prawym dolnym rogu tablicy (jest to rozwiązanie optymalne). 18

19 public int[,] Results Właściwość publiczna (dwuwymiarowa tablica liczb całkowitych), pozwalająca na dostęp do tablicy rozwiązań cząstkowych algorytmu dynamicznego. Odpowiada prywatnemu polu: _Results. Właściwość tylko-do-odczytu. public int ItemsCount Właściwość publiczna (liczba całkowita), pozwalająca na dostęp do liczby określającej ilość przedmiotów zaakceptowanych w instancji klasy. Odpowiada prywatnemu polu: _ ItemsCount. Właściwość tylko-do-odczytu. public readonly int BagSizePercentage Właściwość publiczna (liczba całkowita), pozwalająca na dostęp do liczby określającej, jaka może być maksymalna suma wag wszystkich dodanych przedmiotów w stosunku do pojemności plecaka. Wartość ta jest określana z góry podczas tworzenia instancji obiektu klasy i wyrażona jest w procentach wielkości plecaka. Domyślnie ustawiana na jest na 70(%) i nie może zostać zmodyfikowana. Pozwala nałożyć pewne wymogi co do parametrów przedmiotów. Ta wartość m.in. jest wykorzystywana podczas weryfikacji danych metodą TryAddParameters( ). Właściwość tylko-do-odczytu. public KnapsackSolver(int BagSizePercent) Publiczny konstruktor parametryzujący. Tworzy instancję obiektu klasy. 19

20 Parametry: int BagSizePercent - określa procentowy udział wielkości przedmiotów, w wielkości plecaka (patrz BagSizePercentage) Konstruktor ustawia podaną wartość jednorazowo, później właściwość jest już niemodyfikowalna. public KnapsackSolver() Publiczny konstruktor domyślny. Tworzy instancję obiektu klasy, ustawiając od razu domyślna wartość parametru BagSizePercentage na 70(%). Konstruktor ustawia podaną wartość jednorazowo, później właściwość jest już niemodyfikowalna. public Boolean TryAddParameters( int[] ItemsWeights, int[] ItemsValues, int BagMaxWeight ) Publiczna metoda. Pozwala na weryfikację dodawanych danych, które będą przetwarzane przy użyciu metod rozwiązujących w dwóch wersjach: SolveProblem1() oraz SolveProblem2(). Parametry: int[] ItemsWeights - Wektor określający wagi wszystkich przedmiotów dodawanych do puli elementów w klasie (patrz _Weights). int[] ItemsValues - Wektor określający wartości wszystkich przedmiotów dodawanych do puli elementów w klasie (patrz _Values). int BagMaxWeight - Liczba całkowita określająca maksymalny rozmiar plecaka, 20

21 czyli jego pojemność (patrz _TotalWeight). Wynik: Boolean zwracany wynik to true, gdy dodano poprawnie nowe parametry, lub false, gdy parametry są nie poprawne i nie zostały dodane. Dzięki tej metodzie jest możliwość weryfikacji, czy dany problem jest już rozwiązanym gdyż pula przedmiotów o sumarycznej wadze mniejszej, równej pojemności plecaka może w całości mieścić się w nim. Co za tym idzie nie ma tutaj sensu rozwiązywanie algorytmu. Kolejnym wariantem jest sprawdzenie ilości przedmiotów oraz wielkości plecaka, które są ograniczone zgodnie ze specyfikacją. public void ForceAddParameters( int[] ItemsWeights, int[] ItemsValues, int BagMaxWeight ) Publiczna metoda. Pozwala na dodanie nowych danych o przedmiotach do puli klasy, bez weryfikacji ich poprawności. Dalej dane te są przetwarzane przez jedną z metod rozwiązujących: SolveProblem1() oraz SolveProblem2(). Parametry: int[] ItemsWeights - Wektor określający wagi wszystkich przedmiotów dodawanych do puli elementów w klasie (patrz _Weights). int[] ItemsValues - Wektor określający wartości wszystkich przedmiotów dodawanych do puli elementów w klasie (patrz _Values). int BagMaxWeight - Liczba całkowita określająca maksymalny rozmiar plecaka, czyli jego pojemność (patrz _TotalWeight). 21

22 Metoda ta zwyczajnie wymusza wykonanie algorytmu dla wszystkich podanych danych. Jest wykorzystywana podczas przetwarzania wsadowego. public int[,] SolveProblem1() Publiczna metoda rozwiązująca. Metoda, która znajduje rozwiązanie optymalne metodą techniki programowania dynamicznego, z wykorzystaniem dwuwymiarowej tablicy cząstkowych rozwiązań. Ma to związek z charakterem programowania dynamicznego. Metoda opracowana na potrzeby prezentacji wyników w postaci tablicy, oraz dla potrzeb interfejsu (mniej wydajna niż SolveProblem2()). Wynik: int[,] zwracany wynik to dwuwymiarowa tablica liczb całkowitych, która jest wspomnianą tablicą cząstkowych rozwiązań problemu. Prawy dolny róg tabeli (komórka) zawiera znalezione optymalne rozwiązanie. Ze względów wydajnościowych nie jest ona raczej stosowana, do przetwarzania wsadowego wykorzystuje się metodę w wersji 2. public int SolveProblem2() Publiczna metoda rozwiązująca. Metoda, która znajduje rozwiązanie optymalne metodą techniki programowania dynamicznego, z wykorzystaniem jednowymiarowej tablicy (wektora) cząstkowych rozwiązań. Ma to związek z charakterem programowania dynamicznego. Metoda stanowi ulepszenie metody w wersji 1 (SolveProblem1()) w sferze wydajnościowej, zajętości pamięci oraz szybkości. Tak naprawdę w metodzie jest wykorzystywany jeszcze jeden wektor pomocniczy, zatem operacje odbywają się na dwóch identycznych wektorach zamienianych miejscami. Wadą tej techniki jest niemożność odzyskania sekwencji dodanych do plecaka przedmiotów, przy sensownej wydajności. Wynik: 22

23 int zwracany wynik to optymalne upakowanie plecaka, a dokładnie optymalne rozwiązanie, którym jest wartość plecaka tak upakowanego. class FileOperations Klasa pozwalająca na wczytywanie plików z danymi dotyczącymi problemu. Format danych opisano w specyfikacji programu. public static Boolean ReadDataFromFile( String FileName, out int[] w_i, out int[] c_i, out int W ) Publiczna metoda statyczna. Wczytuje parametry algorytmu z pliku tekstowego o określonym formacie (UTF-8), oraz zwraca te parametry w postaci argumentów oznaczonych operatorem out. Parametry: String FileName - Łańcuch znaków opisujący ścieżkę do pliku wraz z jego nazwą, int[] w_i int[] c_i int[] W - Wektor określający wagi poszczególnych przedmiotów. Operator out definiuje, że podany parametr jest zwracany w tym miejscu, zatem pod tą zmienną zostanie podstawiony wynik, - Wektor określający wartości poszczególnych przedmiotów, - Pojemność plecaka. poszczególnych przedmiotów. Operator out definiuje, że podany parametr jest zwracany w tym miejscu, zatem pod tą zmienną 23

24 zostanie podstawiony wynik. Wynik: Boolean zwracany wynik to true, gdy wczytano poprawnie nowe parametry, lub false, gdy plik FileName nie istniał. Metoda ta jest wykorzystywana podczas przetwarzania wsadowego do wczytywania danych z pliku wejściowego. 24

25 INTERFEJS (UI) 2.6 Ponieważ interfejs został wykonany w jednej z nowszych technologii firmy Microsoft, postanowiono, że opis tegoż przedsięwzięcia powinien również stanowić część dokumentacji. Platforma.NET pozwala na niezwykle rozwijanie się w sferze nowych technologii. Tego typu technologia jest Windows Presentation Foundation (WPF), która stanowy śmiały krok na przód w dziedzinie projektowania interfejsów. Ten wyjątkowy pakiet dostępny w bibliotekach MS Framework od wersji 3.0, posiada niesamowite możliwości. Teraz okienko staje się przestrzenią dla animacji zarówno 2D jak i 3D, a efekty graficzne są tutaj na bardzo wysokim poziomie. Cała technologia jest oparta o MS DirectX od wersji 9.0c, co powoduje, że wspiera wszelką grafikę wektorową SPLASH SCREEN Ponieważ, jak wspomniano w specyfikacji projektu, WPF wymaga załadowania kilku bibliotek DirectX, oraz wygenerowania pewnej liczby elementów graficznych, pierwsze uruchomienie aplikacji zajmuje trochę czasu. Z tego powodu w projekcie po raz pierwszy uwzględniono okno powitalne, które aktualnie stosuje praktycznie w każdej aplikacji. Okienko pojawia się tuż po uruchomieniu aplikacji, i znika w chwili załadowania się okienka głównego z wygenerowaną i przygotowaną grafiką. Wówczas pojawia się główne okienko programu. Jest praktycznie jedyna rola tego elementu graficznego (Rys.9.) aplikacji. Rys.9. Splash Screen aplikacji KnapsackProblem 25

26 OKNO GŁÓWNE APLIKACJI Interfejs programu stanowi główne okno aplikacji przedstawione na Rys.10. Rys.10. Główne okienko aplikacji Po lewej widzimy zbiór przykładowych przedmiotów w postaci ikon. Każdy przedmiot stanowi osobny komponent UI, który posiada trzy właściwości: Nazwę (String), Wagę (int), Wartość (int). Dzięki nim klikając na konkretny element dwukrotnie jesteśmy w stanie w prosty sposób modyfikować te właściwości, wraz ze zmianą pojemności plecaka (Rys.11.) 26

27 Rys.11. Modyfikacja parametrów dostępnych przedmiotów Oznaczenia na rysunku dotyczą w tym przypadku obiektu Lornetka. Oczywiście nazwa przedmiotu może również zostać zmodyfikowana w tym okienku. Klikając OK zatwierdzamy wprowadzone zmiany ROZWIAZANIE PROBLEMU Gdy skonfigurowaliśmy przedmioty w wymagany sposób możemy przystąpić do obejrzenia wyników. Ponieważ obiektów jest dość mało, obliczenia trwają ułamek sekundy. W tym celu wystarczy kliknąć na plecak (Rys.12.), co powoduje uruchomienia algorytmu. Rys.12. Przycisk rozwiązujący problem 27

28 Wynik otrzymujemy w postaci wartości plecaka, który został optymalnie upakowany (Rys. 13.). Rys.13. Wynik obliczeń W przypadku domyślnych ustawień przedmiotów wartość ta wynosi 38. Dodatkowo, ponieważ algorytm wykorzystuje drugą wersję metody rozwiązującej, mamy możliwość obejrzenia tablicy cząstkowych wyników, które zostały wykorzystane podczas rozwiązywania. W tym celu klikamy fioletową tabelę w prawym górnym rogu otwartego okienka (Rys. 14.). Rys.14. Przycisk pokazujący tabelę rozwiązań cząstkowych 28

29 Pojawi się wówczas okienko z tabelą, której kolejno numerowane wiersze odpowiadają kolejnym rozmiarom plecaka, natomiast pierwszy wiersz to indeksy kolumn numery przedmiotów (pula). Rozwiązanie optymalne znajduje się w prawym dolnym rogu tabeli (Rys. 15.). Rys.15. Wynik obliczeń w postaci tabeli rozwiązań cząstkowych Poszczególne okienka zamyka się z reguły klikając na nie, jednakże w przypadku tabeli korzystamy z przycisku w kształcie litery X. 29

30 3. WYDAJNOŚĆ I WYMAGANIA WYMAGANIA APLIKACJI 3.1 Program został napisany z uwzględnieniem następujących wymogów 1. System Microsoft Windows XP SP3 lub nowszy 2. Zainstalowany MS Framework 3.5 SP1 3. Komputer z procesorem co najmniej 800MHz 4. Z minimalną ilością pamięci operacyjnej 256MB 5. Miejscem na dysku twardym ok. 2MB 6. Dodatkowo system koniecznie musi posiadać Microsoft DirectX 9.0c lub nowszy (Win XP posiada już zainstalowany ten zestaw modułów) WYDAJNOŚĆ 3.2 Aplikacja została przetestowana pod względem realizacji wielokrotnego rozwiązywania problemu dostępnymi dwoma sposobami, w celu wykazania różnicy. Testy wykonano na dość szybkim komputerze Athlon Core 2 Duo 4.2GHz, pamięci operacyjnej 2GB/800MHz, dysku twardym ATA, oraz systemie operacyjnym MS Windows XP spełniającym stawiane wcześniej wymagania. 16 Zależność czasu wykonywania algorytmów od ilości dostępnych przedmiotów Pojemnoość plecaka P = 150 Czas wykonywania algorytmów [ms] Algorytm wykorzystujący tablicę 2D danych cząstkowych Algorytm zoptymalizowany, wykorzystuje jeden wektor danych Ilość dostępnych przedmiotów n 30

31 3 Zależność czasu wykonywania algorytmów od rozmiaru plecaka Ilość przedmiotów n = 100 Czas wykonywania algorytmów [ms] 2,5 2 1,5 1 0,5 0 Algorytm zoptymalizowany, wykorzystuje jeden wektor danych Algorytm wykorzystujący tablicę 2D danych cząstkowych Rozmiar plecaka P Przedstawione wykresy ilustrują wpływ poszczególnych parametrów na czasy wykonywania algorytmów. Widzimy, że oba wykresy wyraźnie wraz ze wzrostem rozmiaru plecaka i ilości przedmiotów zaczynają rozbiegać się w stronę nieskończoności. Jest to spowodowane różnicami w algorytmach, które testowano. Przedstawione dwa podejścia wyraźnie ilustrują przewagę drugiej metody nad pierwszą. Optymalizacja zajętości pamięci spowodowała również przyspieszenie algorytmu. W ogólnym rozrachunku są to dość duże zmiany, skąd wniosek, że optymalizacja działa bardzo dobrze. Dla formalności testy realizowano poprzez wczytywanie danych z plików wejściowych. Początkowo wygenerowano odpowiednie zestawy danych, następnie wczytywano je i przetwarzano. Podczas pomiaru czasu uwzględniono tylko czas wykonywania się algorytmu, zaniechano pomiaru całościowego wraz z odczytem danych, gdyż byłoby to nie obiektywne (różne prędkości dysków twardych itp.) 31

32 4. BIBLIOGRAFIA 1. Sysło M., Deo N., Kowalik J. Algorytmy optymalizacji dyskretnej. PWN Warszawa Wikipedia wolna encyklopedia: 3. Studia informatyczne beta: Opracowania z zakresu programowania dynamicznego i zaawansowanego 4. Wykład z programowania dynamicznego: 32