Semestr 25L
Boty do GTO Texas Hold’em
Grupa: JSM
Celem jest stworzenie prostej aplikacji, która umożliwia człowiekowi grę z botami grającymi mniej więcej zgodnie z założeniami Game Theory Optimal (GTO) Poker. Problem implentacji GTO w Texas Hold’em pozostaje nierozwiązany, tutaj interesuje nas stworzenie funkcjonalnych przeciwników, którzy posługując się mieszanką strategii wynikłych z GTO oraz arbitralnych heurystyk są w stanie prowadzić rozgrywkę między sobą oraz z ludzkim agentem. Rozgrywka może odbywać się w terminalu. Podstawowe założenia:
- Implementacja cash game z limitem rozdań oraz 2 wariantami – z możliwością powtórnego wkupienia się i bez.
- Początkowa liczba graczy przy stole wynosi 2-6.
- Każdy z agentów może mieć ustawione inne własności początkowe (np. prawdopobieństwo blefu, maksymalny procent potu dla value bet itp).
- Boty nie powinny wykonywać ruchów natychmiastowo, ale mieć timery zależne od decyzji, jaką podejmują (symulować namysł).
Dodatkowo można spróbować zrobić z tego aplikację z interfejsem graficzym.
Aplikacja do korekcji artefaktów w EKG
Grupa: Sosnowiec
Celem jest stworzenie aplikacji graficznej, która umożliwia analizę i ręczną korektę wykrywania pików w EKG. Powinna być nabudowana wokół Neurokit2. Zakładane funkcjonalności:
- Generowanie tagów oznaczających położenie pików w sygnale EKG za pomocą Neurokit2.
- Interfejs umożliwiający przejrzenie sygnału wraz z zanzaczonymi pikami oraz ich ręczną korektę (zmianę położenia wykrytego piku przez np. przeciągnięcie markera na pożądaną pozycję) i zapisanie poprawionych tagów do pliku.
- Zaznaczenie w interfejsie odcinków wewnątrz, które powinny zostać całkowicie wykluczone z dalszej analizy.
- Możliwość tworzenia arbitralnych tagów – zarówno punktowych, jak i odcinków – wraz nazwami i opisem, i zapisu do pliku.
- Wszystkie rodzaje tagów powinny być możliwe do wyeksportowania do pliku .tag kompatybilnego ze SVAROGiem. Poza tym powinien być stworzony format do przechowywania pozycji pików.
- Analiza rytmów we wczytanych i skorygowanych zapisach z poziomu interfejsu, np.: miary oparte na entropii, detrended fluctuation analysis (DFA), estymaty HRV i inne miary uzgodnione z prowadzącym. Musi poprawnie sobie radzić z wyciętymi fragmentami niezależnie od parametrów ustawionych w estymatorach.
- Projekt musi umożliwiać łatwe dodanie nowych estymatorów działających na skorygowanych danych.
Po zakończeniu projektu programistycznego możliwa dalsza współpraca badawcza z użyciem stworzonego narzędzia – problem występowania cyklów okołodobowych w EKG i ich związek z zaburzeniami świadomości.
Gra do nauki komend w bashu
Grupa: żółwie ninja
Projekt zaproponowany przez studentów.
Syntezator modularny z wejściem z dozymetru
Grupa: atofuwki
Projekt zaproponowany przez studentów.
Semestr 24L
Syntezator
Celem jest stworzenie polifonicznego syntezatora umożliwiającego syntezę FM – posiadającego kilka oscylatorów FM i umożliwiającego sumowanie generowanych przez nie fal w celu uzyskania wyjścia. Całość powinna działać w czasie rzeczywistym i posiadać GUI. W szczególności syntezator powinien zawierać:
- Tworzenie dźwięku na podstawie kilku dostępnych oscylacji (np. sinus, piła, schodek) modulowanych w częstości jedną z kilku dostępnych oscylacji, razem z dobrodziejstwem inwentarza typowego syntezatora FM (regulacja wet/dry, częstości modulacji itd).
- Dodanie szumu do sygnału.
- Osobne modyfikowanie głośności i oktawy dla każdego źródła (oscylatory i szum) oraz master.
- Kilka LFO o wybieralnej częstości i kształcie oscylacji, których można użyć do modyfikowania parametrów oscylatorów lub efektów.
- Efekty: filtry, chorus, reverb, delay; nakładalne na konkretny oscylator i na master.
- Obsługa wejścia midi (może przydać się biblioteka
mido).
Wizualizator pojęć z analizy sygnałów
Celem jest stworzenie aplikacji (posiadającej GUI) umożliwiającej interaktywną wizualizację kluczowych pojęć czy zagadnień z analizy sygnałów i eksperymentowanie sobie z nimi:
- Aliasing i relacja częstości rzeczywistej, obserwowanej i próbkowania.
- Szereg Fouriera jako rzutowanie sygnału na bazę ortogonalnych sinusów; dyskretna transformata Fouriera analogicznie (w tym przypadku można explicite pokazać całą bazę i zależność bazy od długości sygnału i częstości próbkowania).
- Rekonstrukcja sygnału ze współczynników szeregu Fouriera.
- Splot i okienkowanie.
- Metody Welcha i Thompsona – zależność od ich parametrów oraz porównanie z periodogramem.
- Projektowanie filtrów, oglądanie charakterystyk i filtrowanie sygnału.
- Spektrogram w zależności od długości i rodzaju okna.
- Dekompozycja Matching Pursuit (iteracja po iteracji).
Dla każdego pojęcia wymagającego sygnału do przeanalizowania (w sumie wszystko prócz 1 i ew 3) powinna być pula gotowych sygnałów testowych (sterylnych typu suma 2 sinusów i bardziej realistycznych) oraz możliwość wgrania własnego sygnału.
Zasady oceniania projektu
Każda grupa powinna założyć repozytorium na Gitlabie i dodać mnie (@pbieganski) w roli developer.
Podczas pracy ocenie podlegają dobre praktyki, czyli stosowanie się do dobrych praktyk oraz systematyczność pracy. W szczególności: równy podział pracy pomiędzy członków zespołu; regularność rozwoju aplikacji oraz commitów; właściwy podział na gałęzie; klarowne nazewnictwo gałęzi i commitów; regularne prowadzenie code review; dokumentowanie kodu na bieżąco; statyczne typowanie; trzymanie się PEP-8; testy jednostkowe; potok CI/CD; zaplanowanie i zaprojektowanie struktury kodu; klarowność kodu i jego struktury. Przed rozpoczęciem programowania należy stworzyć i wrzucić do repozytorium diagram UML planowego kodu.
Po ukończeniu projektu należy umówić się na jego obronę. W jej trakcie projekt i najważniejsze funkcjonalności powinny zostać zaprezentowane. Każda osoba z zespołu musi być obecna na obronie, w wyjątkowych przypadkach – do ustalenia indywidualnie.
Po wykonaniu pracy ocenie podlega efekt końcowy: jakość i działanie wyniku końcowego; kompletność wypełnienia minimalnych założeń projektu; przenośność między platformami i urządzeniami; ewentualne dodatkowe (wykraczające poza minimum) funkcjonalności.
Zasady dotyczące użycia sztucznej inteligencji: W trakcie tworzenia projektu można wykorzystywać dowolne LLMy w dowolnym zakresie. README musi zawierać informację o zakresie i sposobie wykorzystania SI przy tworzeniu projektu (w tym o jego braku). Odpowiedzialność za kod stworzony przez LLM spoczywa na osobie używającej LLMa do jego produkcji. Osoba odpowiedzialna za dany fragment kodu musi umieć wyjaśnić jego działanie. Nieumiejętność wytłumaczenia własnego kodu skutkuje wyzerowaniem punktów za dobre praktyki.