Szanowni Państwo, przed zadaniem pytania uprzejmie proszę o zapoznanie się z zawartością niniejszej strony, w tym z informacjami o możliwościach konsultacji.
Nie używam Teams, w razie potrzeby proszę kontaktować się mailem.
Ważne
W ramach projektu z UMA należy wykonać własną implementację wskazanego w temacie zadania algorytmu. Należy również zbadać własności stworzonego algorytmu.
W ramach badań należy wypróbować różne zestawy parametrów i/lub dokonać prostych modyfikacji algorytmu, po czym rzetelnie
porównać osiągnięte wyniki i wyciągnąć wnioski. Jeżeli w R lub Pythonie istnieje implementacja wskazanego algorytmu to należy porównać wyniki własnej implementacji z wynikami już istniejącej (ewentualne rozbieżności należy rozsądnie skomentować). Jeżeli w ramach projektu należy dokonać prostej modyfikacji standardowego algorytmu to uzyskane wyniki należy porównać z wynikami klasycznej wersji zmodyfikowanego algorytmu.
Niezastosowanie się do wymagań/wskazówek opisanych na tej stronie i jej podstronach powoduje znaczące obniżenie oceny. Przykładowo: użycie nieprawidłowego separatora dziesiętnego generalnie nie stanowi dużego problemu, tu jednak spowoduje obniżenie oceny, ponieważ poniżej wprost napisałem „W Polsce separatorem dziesiętnym jest przecinek, nie kropka”.
- 24 III - wybór tematu projektu,
- 14 IV - przysłanie założeń wstępnych (dokumentacji wstępnej),
- 09 VI - przysłanie kodu oraz dokumentacji końcowej,
- 14 VI - ostateczny termin oddawania projektów, po 09 VI naliczana jest kara za spóźnienie.
Za opóźnienia przewidziano kary podane na stronie prowadzącego przedmiot.
Uznaję, że termin został dotrzymany, jeśli do północy wskazanego dnia otrzymam e-mail z odpowiednimi załącznikami.
- Projekty realizowane są w zespołach dwuosobowych.
- Wyboru tematów dokonujemy przy użyciu systemu Assigner (uwierzytelnianie USOS, w tej chwili działa tylko z adresów z PW - jeśli komuś zależy na dostępie z domu to można zrobić sobie tunel+skonfigurować proxy). Po zalogowaniu należy wybrać przedmiot "UMA", po czym grupę taką jaką pokazuje USOS w przedmiocie UMA, np. osoby z grupy 102 w USOS klikną w Assigner na: 101_102.
- Należy uformować zespoły dwuosobowe film instruktażowy (mp4). Osoba, która tworzy zespół automatycznie staje się jego członkiem. Powinna ona wygenerować kod dostępu i przekazać go drugiej osobie, która powinna dołączyć do zespołu.
- Każdy zespół ustala własne preferencje co do tematów zadań. System maksymalizuje średnie zadowolenie studentów. Proces optymalizacji zostanie uruchomiony 24 III, przed tym terminem wszyscy powinni podać swoje preferencje, po tym terminie zespoły zobaczą jaki temat im przypadł i mogą rozpocząć jego realizację.
- System w oknie tematu zadania ma forum - nie ma sensu tego używać, ponieważ nikt tego nie czyta. Ewentualne błędy w treści zadania proszę zgłaszać mailem.
- Należy zapisać u siebie przydzieloną treść zadania (poprzedni system miał długie przerwy w pracy w czasie semestru).
- Proszę zapoznać się z zawartością strony prowadzącego przedmiot.
- Dane do większości eksperymentów można pobrać z Internetu, np. ze strony
UCI lub Kaggle (wymaga utworzenia konta).
- Program można zaimplementować w jednym z darmowych języków programowania - w kolejności preferencji: R, Python, C++, C. Programy muszą działać pod kontrolą systemu Ubuntu Linux 22.04 (a od kwietnia na 24.04).
- Dokumentację wstępną oraz końcową proszę przysłać w formie elektronicznej (rafal.biedrzycki [at] pw.edu.pl)
- Wszelka korespondencja e-mail związana z przedmiotem powinna mieć w temacie e-maila napis UMA, po czym powinna wystąpić dalsza część tematu.
- Jeżeli członek zespołu nie wnosi wkładu do projektu, to jak najwcześniej należy rozwiązać zespół poprzez wysłanie do partnera e-maila (z kopią do mnie) z informacją, że wobec braku współpracy zespół ulega rozwiązaniu. Po rozwiązaniu zespołu należy zmniejszyć wymagania funkcjonalnie (należy przysłać propozycję zmian zakresu projektu do zatwierdzenia). Zwykle żeby projekt nadal miał sens nie da się okroić go aż o połowę. Proszę zatem przy każdym ocenianym etapie przypominać, że projekt realizowany jest jednoosobowo.
- Podczas implementacji może się okazać, że pewnych szczegółów niektórych algorytmów nie podano na wykładzie. Szczegóły te należy zaimplementować tak, jak podano w artykule naukowym opisującym dany algorytm. W przypadku trudności w znalezieniu/zrozumieniu artykułu należy doprecyzować wedle własnego uznania (należy opisać to w dokumentacji).
- Zaproponowane w tematach projektu modyfikacje metod klasycznych mogą prowadzić do uzyskania gorszych wyników na wielu zbiorach danych. W przypadku uzyskania gorszych wyników na wybranym zbiorze należy zastanowić się (i napisać w dokumentacji) co zmienia wprowadzona modyfikacja i dla jakiego zbioru danych może ona mieć sens - czy da się taki zbiór znaleźć lub wygenerować?
- Nie można wyciągać wniosków na podstawie jednego uruchomienia metody wykorzystującej liczby pseudolosowe. Należy pracować na zagregowanych wynikach z min. 25 uruchomień. Dla takich algorytmów podaje się średnią, odchylenia standardowe, najlepszy i najgorszy wynik. Należy o tym napisać już w dokumentacji wstępnej.
- Implementacja powinna być zawarta w plikach z kodem, nie w notatnikach (jupyter).
- Eksperymenty wymagają czasu, zwłaszcza tam gdzie konieczne jest wielokrotne ich powtarzanie ze względu na losowość algorytmu.
- Należy krytycznie podchodzić do uzyskanych wyników. Często bezsensowne wyniki, czy nielogiczne zachowanie algorytmu, są skutkiem istnienia błędu w kodzie.
W założeniach wstępnych projektu należy doprecyzować temat zadania, a oprócz tego:
- Zawrzeć precyzyjny opis algorytmów, które będą wykorzystane, wraz z przykładowymi obliczeniami. Na podstawie tego opisu nie znający tematyki przedmiotu programista powinien być w
stanie wykonać poprawną implementację.
- Przedstawić plan eksperymentów.
- Określić jakie miary jakości zostaną wykorzystane. Dla zadań klasyfikacji nie wolno zapomnieć o podaniu dokładności i tabeli pomyłek ("confusion matrix").
- Tam gdzie ma to sens (np. w zdaniach związanych z klasyfikacją) należy wybrać i opisać zbiory danych (w tym podać liczbę przykładów poszczególnych klas), które będą używane do badań, należy określić jak zostanie wyłoniony i użyty zbiór trenujący.
- Nie potrzebuję strony tytułowej i spisu treści. Zawartość merytoryczną należy rozpocząć przywołaniem treści zadania, dokładnie w takiej postaci w jakiej podałem, po czym powinna nastąpić interpretacja treści zadania, doprecyzowanie.
- Proszę nie zamieszczać rozwlekłych wywodów erudycyjnych, zwłaszcza tych nie związanych z treścią zadania, np. algorytmy ... są inspirowane ... Ich początki sięgają lat ...
Dokumentację wstępną należy wysłać e-mailem. W temacie proszę napisać UMA, a załącznik proszę nazwać tak jak imię i nazwisko autora, np. JanKowalski.pdf.
Oddawanie projektów przebiega w sposób następujący: Student wysyła e-mail z załącznikiem zawierającym wszystko to, co tej pory powstało w związku z projektem, po czym czeka na ocenę lub na zaproszenie na rozmowę. W temacie e-maila proszę koniecznie wpisać UMA. Sprawdzanie projektów zwykle trwa kilka dni, aby uniknąć pytań w stylu "czy mój e-mail dotarł do Pana" można przy wysyłaniu projektu zaznaczyć opcję "żądaj potwierdzenia doręczenia".
Dokumentacja końcowa musi być samowystarczalnym dokumentem, nie można założyć, że pamiętam ustalenia z dokumentacji wstępnej. Dokumentację końcową należy zacząć od przytoczenia oryginalnego brzmienia tematu zadania, po czym należy przypomnieć istotne fragmenty dokumentacji wstępnej, czy ustalenia z konsultacji, np. szczegóły konkretyzacji tematu, przyjęte założenia, krótką charakterystykę zbiorów danych (ile przykładów poszczególnych klas). Jeżeli nastąpiły odstępstwa od uzgodnień z dokumentacji wstępnej czy konsultacji to należy je wskazać i uzasadnić.
Oczywiście najciekawszym elementem dokumentacji końcowej są odpowiednio zaprezentowane wyniki badań, ich opis oraz wnioski.
Reguły biurokracji wymagają aby w przesłanym archiwum wraz z projektem końcowym przysłać również wszystko to, co się wcześniej wytworzyło. Archiwum powinno nazywać się tak jak imię i nazwisko autora, np. JanKowalski.zip.
W archiwum powinien być porządek, dokumentacja końcowa niech nazywa się "dokumentacja końcowa.pdf", dokumentacja wstępna "dokumentacja wstępna.pdf", a w katalogu ,,kod'' niech znajduje się kod rozwiązania zadania oraz skrypty używane do przeprowadzenia eksperymentów. Oprócz tego w archiwum powinien istnieć plik ,,temat projektu.txt'' zawierający temat projektu w formie takiej jak podałem.
Nie należy używać formatu .rar do pakowania kodu projektów przed wysłaniem. Preferowany format to .zip.
Rozsądnie jest pochwalić się wynikami prac na kilka tygodni przed oficjalnym oddaniem projektu. Dokumentację wraz z kodem proszę przesłać mi e-mailem, pisząc "konsultacje UMA" w temacie e-maila. Dzięki temu mają Państwo szansę poznać moje uwagi dotyczące projektu. Uwagi te otrzymają również Państwo przy okazji oceny projektu - wtedy jednak będą one okupione utratą punktów. Przysłanie projektu do oceny powoduje otrzymanie oceny - wtedy na konsultacje jest już za późno. Nie dopuszczam poprawiania ocen. Najważniejsze to upewnić się, że prawidłowo rozumieją Państwo temat zadania.
Na ocenę z projektu (50 punktów) składa się:
- ocena założeń wstępnych (10 p.),
- ocena implementacji (jakość, przydatność, uniwersalność, testy) (25 p.),
- ocena badań eksperymentalnych i dokumentacji końcowej (15 p.).
Szczegóły oceny, typowe błędy:
- Kod programu powinien być czytelny (samodokumentujący się). Fragmenty z konieczności niezrozumiałe (np. użycie skomplikowanego wzoru matematycznego) należy opatrzyć komentarzem.
- Próba oddania kodu innej osoby lub kodu z Internetu kończy się uzyskaniem oceny 0 (może mieć też dalej idące konsekwencje). Posiadamy bazę implementacji istniejących w Internecie oraz kody z poprzednich realizacji przedmiotu. Zmiana nazw zmiennych, funkcji i klas, czy dodanie komentarzy, nie wystarczy do uznania kodu za nowy.
- Należy się upewnić, że implementacja nie zawiera błędów. W tym celu jej wyniki należy porównać z wynikami metody referencyjnej. W przypadku braku metody referencyjnej, działanie algorytmu można sprawdzić ręcznie na niewielkim zbiorze danych - najlepiej napisać testy jednostkowe. Opis sposobu upewnienia się co do prawidłowości implementacji powinien znaleźć się w dokumentacji końcowej.
- W nagłówku każdego pliku z kodem należy umieścić informację o autorze.
- Zaimplementowany algorytm musi być uniwersalny - nie może być związany z konkretnym zbiorem danych.
- Należy zadbać o odpowiedni podział kodu na pliki. Implementacja algorytmu musi się znaleźć w jednym pliku. Funkcja pomocnicza (np. służąca do raportowania wyników) powinna być w innym pliku. W kolejnym pliku powinno znaleźć się wywołanie algorytmu.
- W części badawczej należy zamieścić opis stosowanej procedury eksperymentalnej i używanych danych, uzyskane wyniki, dyskusję wyników i wnioski.
- Należy zbadać jak algorytm zachowuje się w różnych przypadkach, np. dla zbiorów o różnym charakterze, przy zmianie parametrów.
- Należy zbadać i ocenić czy nastąpiło nadmierne dopasowanie (ang. overfitting).
- Przez wyniki rozumie się zestawienie tabelaryczne (nie zrzuty ekranu). Zawsze należy jasno określić na jakim zbiorze uzyskano prezentowane wyniki. (trenujący/testujący)
- Po każdej tabeli z wynikami powinien być opis wyjaśniający co w niej widać (np. dla jakich wartości uzyskano najlepsze wyniki), po czym wnioski (wnioski z wyników powinny być możliwie blisko tych wyników). Na koniec sprawozdania wnioski końcowe.
- Należy dbać o czytelność tabel. W tabeli zmieniamy tylko jedną rzecz na raz. Przykładowo: badając wpływ 2 parametrów na wyniki należy utworzyć 2 tabele.
- Najlepsze wyniki należy wyróżnić pogrubieniem czcionki.
- Podawanie wielu cyfr po przecinku nie ma sensu. Zwykle podaje się 2 cyfry po przecinku.
- Jak ze wzrostem wartości danego parametru rośnie jakość wyniku, to trzeba dopóty go zwiększać, dopóki nie nastąpi złamanie tego trendu (analogicznie jeśli zaczynamy od dużych wartości parametru i prowadzimy eksperymenty w kierunku małych). Nie ma konieczności liniowej modyfikacji wartości parametru (możemy sprawdzić np. 1, 2, 5, 10, 20, 50, po czym zbadać jeszcze okolice najlepszej wartości).
- Czasem wyniki różnią się nieznacznie, nie można wtedy na siłę wyciągać wniosku o tym, który wiersz w tabeli jest najlepszy.
- Jeżeli w zbiorze danych wyróżniony był zbiór testowy to należy go użyć. Jeżeli nie było zbioru testowego to stosuje się walidację krzyżową.
- W Polsce separatorem dziesiętnym jest przecinek, nie kropka.
- Jeśli w dokumentacji ktoś napisał w stylu "widać że wraz ze wzrostem A rośnie B" to są to bardzo płytkie wnioski, aby je pogłębić należy wyjaśnić dlaczego, przeprowadzić dodatkowe badania, ustosunkować się całościowo do metody - "nadaje się do zadań typu ..., nie nadaje się ponieważ ...".
- Proszę napisać czego nauczyli się Państwo dzięki realizacji projektu.
- Dokumentacja powinna być oficjalnym, dopracowanym dokumentem. W dobie automatycznego sprawdzania pisowni pojawienie się literówek w dokumentacjach jest niedopuszczalne. Proszę zadbać o prawidłowe używanie poznanego na wykładach słownictwa (jeśli nie było jeszcze o czymś mowy na wykładzie to należy zajrzeć do zalecanej literatury, w ostateczności do Wikipedii).