Projekt realizowany jest w zespołach dwuosobowych.
Osoby tworzące zespół zobowiązane są do:
zgłoszenia składu osobowego zespołu
wyboru jednego z zadań projektowych
dostarczenia dokumentacji wstępnej projektu
dostarczenia dokumentacji końcowej projektu
Do terminu 08.04.2024 zespół zobowiązany jest do wysłania wiadomości e-mail, w której zostaną zawarte następujące informacje:
Zgłoszenia należy wysyłać na adres:
eryk.warchulski(ʕ •ᴥ• ʔ)pw.edu.pl
Temat każdej wiadomości, która dotyczy zagadnień związanych z przedmiotem,
należy rozszerzyć o tag [AMHE].
Brak zgłoszenia zespołu oraz zadnia projektowego do wskazanego powyżej terminu rownoważny jest rezygnacji z wykonywania projektu.
Do terminu 06.05.2024 zespół zobowiązany jest przekazać dokumentację wstępną w postaci pliku pdf. Plik dokumentacji należy zatytułować w nastepujący sposób:
amhe-init-@.pdf
Przy czym za symbol @ należy podstawić numer zadania projektowego.
Treść dokumentacji wstępnej powinna składać się z:
opisu problemu i jego sposobu rozwiązania
planowanych eksperymentów numerycznych
wyboru technologii, w której realizowany będzie projekt.
Dokument nie powinien przekraczać 2 stron A4.
Ponadto należy mieć na uwadze, że celem dokumentacji wstępnej jest przedstawienie swojej pierwszej wizji dotyczącej realizowanego projektu, która pozwoli prowadzącemu ocenić czy zespół poprawnie zrozumiał dany temat i wybrał odpowiednie narzędzia. Ewolucja wizji (nawet skrajna) w trakcie realizacji jest jak najbardziej akceptowalna.
Dokumentacja wstępna oceniana jest binarnie. Niedostarczenie dokumentacji wstępnej w powyżej wskazanym terminie rownóważny jest rezygnacji z realizacji projektu.
Do terminu 17.06.2024 zespół zobowiązany jest przekazać drogą
mailową sprawozdanie końcowe w postaci pliku pdf.
Plik należy zatytułować w następujący sposób:
amhe-end-@.pdf
Przy czym za symbol @ należy podstawić numer zadania projektowego.
Dokumentacja końcowa stanowi rozszerzenie dokumentacji wstępnej, w której powinnien znaleźć się szczegółowy opis: problemu, zastosowanych algorytmów, przeprowadzonych eksperymentów oraz ich wyników. Ponadto jeśli między dokumentacja wstępną, a końcowa występują znaczące rożnice, to należy je opisać w stosownej sekcji dokumentacji końcowej.
Należy zadbać o to, aby dostarczony kod źródłowy był jak najbardziej
przenośny. Koniecznie musi dać się kompilować/interpretować pod systemem
Linux. Ze względu na stosowanie zależności zewnętrznych w kodzie warto rozważyć konteneryzacje (via Docker czy
lxc).
Wszystkie przeprowadzone eksperymenty numeryczne w ramach projektu powinny dać się zreprodukować. Poza danymi i ziarnami mile widziane byłoby dołączenie skryptu, który pozwoliłby odtworzyć przeprowadzone eksperymenty.
Dokumentacja końcowa oceniania jest w skali 0-50 punktów. Na ocenę składają się:
Oceny końcowe prac dostarczonych między 18.06-22.06 przemnażane są przez mnożnik 0.9.
Prace dostarczone po 24.06 nie będą oceniane.
Zespoły, które złożą wymagane pliki w terminie, zobowiązane są do krótkiej prezentacji (niekoniecznie multimedialnej) swoich projektów (maksymalnie 8-10 minut). Po odbyciu prezentacji zespół zostanie poinformowany o proponowanej ocenie. Termin prezentacji proponowany jest przez zespół i nie może przekroczyć tygodnia od momentu złożenia projektu.
W przypadku większości tematów projektowych czytelność kodu zródłowego nie podlega ocenie, o ile dostarczony kod nie będzie wybitnie nieczytelny. Zalecane jest, aby kod był sformatowany zgodnie tylko z jednym stylem (np. zgodnie z Google Style Guides).
Projekt można realizować w dowolnym języku programowania z wyłączeniem języków ezoterycznych.
| Etap | Artefakt | Ostateczne terminy |
|---|---|---|
| Zgłoszenie zespołu i wybór tematu | Mail z numerem projektu i danymi wykonawców | 08.04.2024 |
| Dokumentacja wstępna | Mail z raportem wstępnym | 06.05.2024 |
| Dokumentacja końcowa | Mail z kodem, raportem i danymi | 17.06.2024 |
Poniżej znajdują się zadania projektowe. Należy wybrać jedno z nich i zgłosić wybrany temat przy pomocy wiadomości e-mail.
Zadania projektowe, które są już zajęte, oznaczone są przekreśleniem.
Jeśli realizują Państwo projekt uczelniany lub Państwa praca dyplomowa dotyczy zagadnień poruszanych na AMHE, to dopuszcza się możliwość zgłoszenia własnego tematu projektowego.
Zaimplementuj algorytm DES w języku Nim.
Zbadaj przebieg zbieżności algorytmu na wybranych funkcjach testowych oraz porównaj czas działania względem implementacji algorytmu w języku R.
W celu redukcji liczby ewaluacji funkcji celu algorytmy ewolucyjne rozszerza się o model zastępczy (ang. surrogate). Rozszerz algorytm DES o model zastępczy i porównaj jego działanie z klasyczną wersją algorytmu. W tym celu użyj benchmarku BBOB z frameworku coco.
Rozszerz algorytm MA-ES o heurystykę IPOP i zbadaj działanie algorytmu.
Porównaj zmodyfikowany algorytm z algorytmem CMA-ES. W tym celu skorzystaj z benchmarku BBOB z frameworku coco.
Dokonaj hybrydazacji algorytmu NL-SHADE-RSP oraz DES.
Porównaj działanie algorytmu z klasyczną wersją NL-SHADE oraz DES. Użyj w tym
celu benchmarku CEC 2022.
Zmodyfikuj algorytm ewolucji różnicowej w wariancie rand/1/bin tak, aby zasięg mutacji F był strojony zgodnie z metodą MSR (ang. Median Success Rule) oraz PSR (ang. Population Success Rule).
Zbadaj działanie zmodyfikowanych wersji algorytmu, używając benchmarku CEC 2017, dla wymiarowości D ∈ {10, 30}.
Zbadaj wpływ różnych metod uwzględniania ograniczeń w algorytmie DES. Warianty
algorytmów porównaj, używając benchmarku BBOB z frameworku coco.
Zmodyfikuj algorytm ewolucji różnicowej w wariancie rand/1/bin tak, aby zasięg mutacji F był strojony zgodnie z metodą MSR (ang. Median Success Rule) oraz TPA (ang. Two Point Adaptation).
Algorytmy ewolucyjne często narażone są na przedwczesną zbieżność do optimum lokalnego. W celu uniknięcia takiego stanu stosuje się różne heurystyki, które pozwalają zachować odpowiedni poziom różnorodności populacji w trakcie fazy eksploracji. Jedyną z takich heurystyk jest DG (ang. Diverity-Guided).
Rozszerz wybrany przez siebie wariant ewolucji różnicowej o heurystykę DG oraz porównaj działanie zmodyfikowanego algorytmu z jego klasyczną wersją. Użyj w tym celu benchmarku BBOB z frameworku coco.
Dysponujesz zbiorem zadań $T$, wymaganym pierszeństwem $p:\;T\times T\rightarrow N$ oraz czasem wykonania każdego zadania $l:\;T\rightarrow N$.
Twoim zadaniem jest opracowanie metody podziału zadań między $M$ grupy pracowników tak, aby zadania, na których określone jest pierszeństwo wykonania, przydzielone dwóm rożnym grupom były uporządkowane według zasady: od wcześniejszego do późniejszego. Do rozwiązania zadania wykrozystaj znane Ci algorytmy ewolucyjne.
Kontrola przystosowania punktu środkowego populacji jest sposobem na poprawienie jakości działania algorytmów ewolucyjnych. Na wybranym przez siebie algorytmie ewolucyjnym zbadaj wpływ sposobu zdefiniowania punktu środkowego na działanie tego algorytmu.
Poza statystykami jak średnia arytmetyczna lub mediana zbadaj różne warianty średniej ważonej oraz statystyki odporne. Wykorzystaj wybrane funkcje testowe.
Rozszerz algorytm MA-ES o heurystykę IPOP i zbadaj działanie algorytmu.
Porównaj zmodyfikowany algorytm z algorytmem CMA-ES. W tym celu
skorzystaj z benchmarku BBOB z frameworku coco.
Na wybranym algorytmie ewolucyjnym porównaj działanie dwóch technik zwiększania rożnorodności w populacji: metodę clearingu oraz crowdingu. W tym celu wykorzystaj wybrane przez siebie funkcje testowe.
Temat własny.