diff --git a/pytania/odpowiedzi/01-automaty-jezyki.md b/pytania/odpowiedzi/01-automaty-jezyki.md new file mode 100644 index 0000000..ca34a12 --- /dev/null +++ b/pytania/odpowiedzi/01-automaty-jezyki.md @@ -0,0 +1,338 @@ +# Pytanie 1: Porównanie automatów i rozpoznawanych klas języków + +## Pytanie +**"Porównać 'siłę wyrazu' automatu skończonego, automatu ze stosem oraz maszyny Turinga. Jakie klasy języków rozpoznaje każdy z nich?"** + +Przedmiot: AISDI (Algorytmy i Struktury Danych) + +--- + +## 📚 Odpowiedź główna + +### Hierarchia Chomsky'ego - fundament teoretyczny + +Noam Chomsky w 1956 roku zaproponował hierarchię czterech klas języków formalnych, gdzie każda kolejna klasa zawiera poprzednią: + +``` +Typ 0: Języki rekurencyjnie przeliczalne (Recursively Enumerable) + ⊃ +Typ 1: Języki kontekstowe (Context-Sensitive) + ⊃ +Typ 2: Języki bezkontekstowe (Context-Free) + ⊃ +Typ 3: Języki regularne (Regular) +``` + +### 1. Automat Skończony (Finite Automaton - FA) + +#### Definicja formalna +Automat skończony to piątka: **M = (Q, Σ, δ, q₀, F)** +- **Q** - skończony zbiór stanów +- **Σ** - alfabet wejściowy (skończony zbiór symboli) +- **δ** - funkcja przejścia: Q × Σ → Q (DFA) lub Q × Σ → P(Q) (NFA) +- **q₀** - stan początkowy (q₀ ∈ Q) +- **F** - zbiór stanów akceptujących (F ⊆ Q) + +#### Rozpoznawana klasa języków +**Języki regularne (Typ 3)** - najsłabsza klasa w hierarchii Chomsky'ego + +#### Charakterystyka +- **Pamięć**: Brak pamięci pomocniczej - tylko aktualny stan +- **Moc obliczeniowa**: Nie potrafi "liczyć" (porównywać ilości) +- **Równoważne formalizmy**: + - Wyrażenia regularne (regex) + - Gramatyki regularne (prawo- lub lewostronnie liniowe) + - DFA ≡ NFA ≡ ε-NFA (równoważne pod względem mocy) + +#### Przykłady języków rozpoznawalnych +- L = {w ∈ {a,b}* : w zawiera podciąg "ab"} +- L = {w ∈ {0,1}* : w jest podzielne przez 3 (interpretowane binarnie)} +- Identyfikatory w językach programowania: `[a-zA-Z_][a-zA-Z0-9_]*` + +#### Przykłady języków NIEROZPOZNAWALNYCH +- L = {aⁿbⁿ : n ≥ 0} - wymaga liczenia +- L = {ww : w ∈ {a,b}*} - wymaga zapamiętania w +- Poprawnie zagnieżdżone nawiasy + +#### Lemat o pompowaniu (Pumping Lemma) dla języków regularnych +Dla każdego języka regularnego L istnieje stała p (długość pompowania), taka że: +każde słowo w ∈ L, gdzie |w| ≥ p, można podzielić na w = xyz, gdzie: +1. |y| > 0 +2. |xy| ≤ p +3. ∀i ≥ 0: xyⁱz ∈ L + +--- + +### 2. Automat ze Stosem (Pushdown Automaton - PDA) + +#### Definicja formalna +Automat ze stosem to siódemka: **M = (Q, Σ, Γ, δ, q₀, Z₀, F)** +- **Q** - skończony zbiór stanów +- **Σ** - alfabet wejściowy +- **Γ** - alfabet stosowy +- **δ** - funkcja przejścia: Q × (Σ ∪ {ε}) × Γ → P(Q × Γ*) +- **q₀** - stan początkowy +- **Z₀** - początkowy symbol na stosie +- **F** - zbiór stanów akceptujących + +#### Rozpoznawana klasa języków +**Języki bezkontekstowe (Typ 2)** - Context-Free Languages (CFL) + +#### Charakterystyka +- **Pamięć**: Stos (LIFO) - pamięć potencjalnie nieskończona, ale z ograniczonym dostępem +- **Moc obliczeniowa**: Potrafi "liczyć" (porównywać pary ilości) +- **DPDA ⊂ NPDA**: Deterministyczne PDA są SŁABSZE niż niedeterministyczne! +- **Równoważne formalizmy**: Gramatyki bezkontekstowe (CFG) + +#### Dwa tryby akceptacji +1. **Przez stan końcowy**: automat jest w stanie z F po przeczytaniu całego słowa +2. **Przez pusty stos**: stos jest pusty po przeczytaniu całego słowa + +Oba tryby są równoważne pod względem mocy. + +#### Przykłady języków rozpoznawalnych +- L = {aⁿbⁿ : n ≥ 0} - klasyczny przykład +- L = {w ∈ {a,b}* : #a(w) = #b(w)} - równa liczba a i b +- Poprawnie zagnieżdżone nawiasy: (), (()), (()()), ... +- Palindromy: L = {wwᴿ : w ∈ {a,b}*} + +#### Przykłady języków NIEROZPOZNAWALNYCH +- L = {aⁿbⁿcⁿ : n ≥ 0} - wymaga liczenia trzech rzeczy +- L = {ww : w ∈ {a,b}*} - kopiowanie (nie odwracanie!) +- L = {aⁱbʲcᵏ : i = j lub j = k} - to jest CFL! (suma dwóch CFL) + +#### DPDA vs NPDA +**Deterministyczne PDA** rozpoznają **właściwy podzbiór** języków bezkontekstowych: +- DPDA: L = {aⁿbⁿ : n ≥ 0} ✓ +- NPDA only: L = {wwᴿ : w ∈ {a,b}*} - palindromy parzyste + +--- + +### 3. Maszyna Turinga (Turing Machine - TM) + +#### Definicja formalna +Maszyna Turinga to siódemka: **M = (Q, Σ, Γ, δ, q₀, qaccept, qreject)** +- **Q** - skończony zbiór stanów +- **Σ** - alfabet wejściowy (nie zawiera symbolu pustego ␣) +- **Γ** - alfabet taśmowy (Σ ⊂ Γ, ␣ ∈ Γ) +- **δ** - funkcja przejścia: Q × Γ → Q × Γ × {L, R} +- **q₀** - stan początkowy +- **qaccept** - stan akceptujący +- **qreject** - stan odrzucający + +#### Rozpoznawana klasa języków +**Języki rekurencyjnie przeliczalne (Typ 0)** - Recursively Enumerable (RE) + +Podklasa: **Języki rekurencyjne (rozstrzygalne)** - TM zawsze się zatrzymuje + +#### Charakterystyka +- **Pamięć**: Taśma nieskończona z dostępem swobodnym (R/W) +- **Moc obliczeniowa**: Maksymalna możliwa (teza Churcha-Turinga) +- **DTM ≡ NTM**: Deterministyczne i niedeterministyczne TM są RÓWNOWAŻNE pod względem mocy (ale różnią się złożonością czasową) + +#### Warianty równoważne +- Wielotaśmowa TM +- Niedeterministyczna TM +- RAM (Random Access Machine) +- Języki programowania (Turing-complete) + +#### Przykłady języków rozpoznawalnych +- L = {aⁿbⁿcⁿ : n ≥ 0} +- L = {ww : w ∈ {a,b}*} +- Wszystkie języki bezkontekstowe +- Wszystkie języki kontekstowe +- Problem stopu (HP) - ale TM może się nie zatrzymać! + +#### Przykłady języków NIEROZPOZNAWALNYCH +- Komplement problemu stopu: L = {⟨M,w⟩ : M nie zatrzymuje się na w} +- Problem odpowiedniości Posta (PCP) + +--- + +## 📊 Tabela porównawcza + +| Cecha | FA | PDA | TM | +|-------|-----|-----|-----| +| **Pamięć** | Brak (tylko stan) | Stos (LIFO) | Taśma (R/W swobodny) | +| **Klasa języków** | Regularne (Typ 3) | Bezkontekstowe (Typ 2) | Rek. przeliczalne (Typ 0) | +| **Gramatyka** | Regularna | Bezkontekstowa (CFG) | Nieograniczona | +| **DET = NIEDET?** | TAK | NIE | TAK (moc), NIE (złożoność) | +| **Domknięcie ∪** | TAK | TAK | TAK | +| **Domknięcie ∩** | TAK | NIE | TAK | +| **Domknięcie ¬** | TAK | NIE | NIE (RE), TAK (rekurencyjne) | +| **Rozstrzygalność pustości** | TAK | TAK | NIE | +| **Zastosowanie** | Leksery, regex | Parsery, kompilatory | Obliczenia ogólne | + +--- + +## 🔄 Relacje między klasami + +``` +┌─────────────────────────────────────────────────────────────┐ +│ Typ 0: Rekurencyjnie przeliczalne (TM) │ +│ ┌───────────────────────────────────────────────────────┐ │ +│ │ Rekurencyjne (TM zatrzymująca się) │ │ +│ │ ┌─────────────────────────────────────────────────┐ │ │ +│ │ │ Typ 1: Kontekstowe (LBA) │ │ │ +│ │ │ ┌───────────────────────────────────────────┐ │ │ │ +│ │ │ │ Typ 2: Bezkontekstowe (PDA) │ │ │ │ +│ │ │ │ ┌─────────────────────────────────────┐ │ │ │ │ +│ │ │ │ │ Deterministyczne CFL (DPDA) │ │ │ │ │ +│ │ │ │ │ ┌───────────────────────────────┐ │ │ │ │ │ +│ │ │ │ │ │ Typ 3: Regularne (FA) │ │ │ │ │ │ +│ │ │ │ │ └───────────────────────────────┘ │ │ │ │ │ +│ │ │ │ └─────────────────────────────────────┘ │ │ │ │ +│ │ │ └───────────────────────────────────────────┘ │ │ │ +│ │ └─────────────────────────────────────────────────┘ │ │ +│ └───────────────────────────────────────────────────────┘ │ +└─────────────────────────────────────────────────────────────┘ +``` + +--- + +## 🧠 Mnemoniki + +### "STOS LIFO" +- **S**kończony automat - **S**tan tylko (bez pamięci) +- **T**ylko regex - języki regularne +- **O**graniczony PDA - **O**dnosi się do stosu +- **S**tos = bezkontekstowe + +### "TuRing = Total Random access" +- **T**aśma nieskończona +- **R**andom access (czytanie i pisanie) +- **Total** - wszystko może obliczyć (co jest obliczalne) + +### "3-2-1 START" +- **3** = Typ 3 = FA = regex (najsłabszy) +- **2** = Typ 2 = PDA = CFG (parser) +- **1** = Typ 1 = kontekstowe (LBA) +- **0** = Typ 0 = TM = wszystko (START od zera = najpotężniejszy) + +### "FA NIC nie pamięta, PDA pamięta ALE odwraca, TM pamięta WSZYSTKO" +- FA: nie liczy +- PDA: liczy ale LIFO (stąd aⁿbⁿ tak, aⁿbⁿcⁿ nie) +- TM: liczy wszystko + +### Akronim "CHOMSKY" dla hierarchii: +- **C**omputable all (Typ 0 - TM) +- **H**ard context-sensitive (Typ 1) +- **O**K with stack (Typ 2 - PDA) +- **M**inimal - regex only (Typ 3 - FA) +- **S**trict inclusion (każda klasa zawiera niższą) +- **K**ey for compilers (zastosowania) +- **Y**ears of theory (od 1956) + +--- + +## ❓ Możliwe pytania dodatkowe (follow-up) + +### Q1: "Udowodnij, że język L = {aⁿbⁿ} nie jest regularny" + +**Odpowiedź:** +Stosujemy lemat o pompowaniu. Załóżmy, że L jest regularny z długością pompowania p. + +Weźmy w = aᵖbᵖ ∈ L, |w| = 2p ≥ p + +Według lematu: w = xyz, gdzie |xy| ≤ p, |y| > 0 + +Ponieważ |xy| ≤ p, to xy składa się tylko z 'a' (pierwsze p znaków to same 'a'). +Zatem y = aᵏ dla pewnego k > 0. + +Pompujemy: xy²z = aᵖ⁺ᵏbᵖ + +Ale p + k ≠ p, więc xy²z ∉ L. **Sprzeczność!** ∎ + +--- + +### Q2: "Dlaczego DPDA ⊂ NPDA, ale DFA = NFA?" + +**Odpowiedź:** + +**DFA = NFA:** +- Można przekształcić NFA w DFA przez konstrukcję potęgową (subset construction) +- Każdy stan DFA odpowiada podzbiorowi stanów NFA +- Wykładniczy wzrost stanów, ale ta sama moc + +**DPDA ⊂ NPDA:** +- PDA ma stos - niedeterminizm pozwala "zgadywać" środek palindromu +- DPDA nie może rozpoznać {wwᴿ} bo nie wie, kiedy kończy się w +- DPDA rozpoznaje języki z własnością prefiksową +- Niedeterminizm w PDA NIE daje się wyeliminować (brak konstrukcji analogicznej do potęgowej dla stosów) + +--- + +### Q3: "Co to jest LBA i gdzie się mieści w hierarchii?" + +**Odpowiedź:** +**Linear Bounded Automaton (LBA)** - maszyna Turinga z ograniczoną taśmą: +- Taśma ograniczona do długości liniowej względem wejścia: O(n) +- Rozpoznaje języki kontekstowe (Typ 1) +- NLBA > DLBA? - otwarty problem! +- Przykład: L = {aⁿbⁿcⁿ} - kontekstowy, ale nie bezkontekstowy + +--- + +### Q4: "Jakie są praktyczne zastosowania każdego typu automatu?" + +**Odpowiedź:** + +| Automat | Zastosowania praktyczne | +|---------|------------------------| +| **FA/DFA** | Leksery (tokenizacja), walidacja regex, kontrolery stanów w grach, protokoły sieciowe, automaty w VHDL/Verilog | +| **PDA** | Parsery (analiza składniowa), kompilatory (CFG), walidacja XML/JSON, sprawdzanie nawiasów | +| **TM** | Model teoretyczny obliczeń, dowody nierozstrzygalności, złożoność obliczeniowa (P vs NP) | + +--- + +### Q5: "Co to jest teza Churcha-Turinga?" + +**Odpowiedź:** +**Teza Churcha-Turinga** (nieformalnie): +> "Każda funkcja, która może być obliczona przez jakikolwiek algorytm, może być obliczona przez maszynę Turinga." + +**Równoważne formalizmy:** +- Maszyna Turinga +- Rachunek lambda (Church) +- Funkcje rekurencyjne (Gödel) +- Maszyna RAM +- Języki Turing-complete (C, Python, Java...) + +**To jest TEZA, nie twierdzenie** - nie można jej udowodnić, bo "algorytm" nie ma formalnej definicji. + +--- + +### Q6: "Czy istnieje język, który nie jest rekurencyjnie przeliczalny?" + +**Odpowiedź:** +TAK! Argument przekątniowy (diagonalizacja): + +**L_d** = {⟨M⟩ : M nie akceptuje ⟨M⟩} + +Ten język nie jest RE (rekurencyjnie przeliczalny). + +**Dowód:** +Załóżmy, że TM M_d rozpoznaje L_d. +- Czy M_d akceptuje ⟨M_d⟩? +- Jeśli TAK → ⟨M_d⟩ ∉ L_d → M_d nie powinno akceptować (sprzeczność) +- Jeśli NIE → ⟨M_d⟩ ∈ L_d → M_d powinno akceptować (sprzeczność) + +Zatem M_d nie istnieje, więc L_d ∉ RE. ∎ + +--- + +## 🎯 Kluczowe punkty do zapamiętania + +1. **Hierarchia jest ścisła**: Reg ⊂ CFL ⊂ CSL ⊂ RE +2. **Pamięć = moc**: brak < stos < taśma +3. **FA: DET = NIEDET**, PDA: DET < NIEDET, TM: DET = NIEDET (moc) +4. **Domknięcie na dopełnienie**: FA tak, CFL nie, RE nie +5. **Praktyka**: FA = regex/lexer, PDA = parser, TM = teoria + +--- + +## 📖 Źródła do pogłębienia + +1. Hopcroft, Motwani, Ullman - "Introduction to Automata Theory, Languages, and Computation" +2. Sipser - "Introduction to the Theory of Computation" +3. Kozen - "Automata and Computability" diff --git a/pytania/odpowiedzi/02-algorytmy-najkrotszej-sciezki.md b/pytania/odpowiedzi/02-algorytmy-najkrotszej-sciezki.md new file mode 100644 index 0000000..32dd04b --- /dev/null +++ b/pytania/odpowiedzi/02-algorytmy-najkrotszej-sciezki.md @@ -0,0 +1,487 @@ +# Pytanie 2: Algorytmy najkrótszej ścieżki + +## Pytanie +**"Omówić i porównać algorytmy najkrótszej ścieżki wskazując ich kluczowe właściwości i logikę budowy: Dijkstry, Belmana-Forda, A*."** + +Przedmiot: AISDI (Algorytmy i Struktury Danych) + +--- + +## 📚 Odpowiedź główna + +### Wprowadzenie - problem najkrótszej ścieżki + +**Problem:** Dany jest graf G = (V, E) z funkcją wag w: E → ℝ. Znajdź ścieżkę z wierzchołka źródłowego s do wierzchołka docelowego t o minimalnej sumie wag krawędzi. + +**Warianty problemu:** +1. **Single-Source Shortest Path (SSSP)** - z jednego źródła do wszystkich wierzchołków +2. **Single-Pair Shortest Path** - z s do konkretnego t +3. **All-Pairs Shortest Path (APSP)** - między wszystkimi parami (Floyd-Warshall) + +--- + +## 1. Algorytm Dijkstry + +### Charakterystyka +- **Autor:** Edsger Dijkstra (1956, opublikowany 1959) +- **Typ:** Zachłanny (greedy) +- **Problem:** SSSP - najkrótsze ścieżki z jednego źródła do wszystkich wierzchołków +- **Ograniczenie:** ⚠️ **Tylko nieujemne wagi krawędzi** (w(e) ≥ 0) + +### Idea algorytmu (logika budowy) +1. **Relaksacja:** Stopniowe ulepszanie oszacowań odległości +2. **Zachłanność:** W każdym kroku wybieramy wierzchołek o najmniejszej znanej odległości +3. **Optymalna podstruktura:** Najkrótsza ścieżka składa się z najkrótszych podścieżek + +### Pseudokod + +``` +DIJKSTRA(G, w, s): + // Inicjalizacja + for each v ∈ V: + d[v] ← ∞ + π[v] ← NIL + d[s] ← 0 + + Q ← priority_queue(V) // min-heap według d[v] + S ← ∅ // zbiór przetworzonych + + while Q ≠ ∅: + u ← EXTRACT-MIN(Q) + S ← S ∪ {u} + + for each v ∈ Adj[u]: // relaksacja + if d[u] + w(u,v) < d[v]: + d[v] ← d[u] + w(u,v) + π[v] ← u + DECREASE-KEY(Q, v, d[v]) + + return d, π +``` + +### Złożoność czasowa + +| Implementacja kolejki | EXTRACT-MIN | DECREASE-KEY | Całkowita | +|----------------------|-------------|--------------|-----------| +| Lista/tablica | O(V) | O(1) | **O(V²)** | +| Kopiec binarny | O(log V) | O(log V) | **O((V + E) log V)** | +| Kopiec Fibonacciego | O(log V)* | O(1)* | **O(V log V + E)** | + +*amortyzowane + +### Dlaczego nie działa dla ujemnych wag? + +``` + A ---(-5)--- B + | | + (1) (1) + | | + S -----------C + (2) +``` + +Dijkstra przetwarza wierzchołki w kolejności rosnącej odległości i oznacza je jako "zakończone". Jeśli waga może być ujemna, późniejszy wierzchołek może "poprawić" już zakończony. + +**Przykład:** S→C = 2 (Dijkstra ustala jako finalne), ale S→A→B→C = 1 + (-5) + 1 = -3 < 2 + +--- + +## 2. Algorytm Bellmana-Forda + +### Charakterystyka +- **Autorzy:** Richard Bellman, Lester Ford Jr. (1958) +- **Typ:** Programowanie dynamiczne +- **Problem:** SSSP z wykrywaniem cykli ujemnych +- **Zaleta:** ✅ **Działa dla ujemnych wag** +- **Ograniczenie:** ⚠️ Graf nie może mieć cyklu o ujemnej sumie wag (ale algorytm go wykrywa!) + +### Idea algorytmu (logika budowy) +1. **Indukcja po liczbie krawędzi:** d^(k)[v] = najkrótsza ścieżka do v używająca ≤ k krawędzi +2. **|V|-1 iteracji:** Najkrótsza ścieżka bez cykli ma co najwyżej |V|-1 krawędzi +3. **Relaksacja wszystkich krawędzi:** W każdej iteracji relaksujemy każdą krawędź + +### Pseudokod + +``` +BELLMAN-FORD(G, w, s): + // Inicjalizacja + for each v ∈ V: + d[v] ← ∞ + π[v] ← NIL + d[s] ← 0 + + // Główna pętla: |V|-1 iteracji + for i ← 1 to |V| - 1: + for each edge (u, v) ∈ E: + if d[u] + w(u,v) < d[v]: // relaksacja + d[v] ← d[u] + w(u,v) + π[v] ← u + + // Wykrywanie cyklu ujemnego + for each edge (u, v) ∈ E: + if d[u] + w(u,v) < d[v]: + return "CYKL UJEMNY" + + return d, π +``` + +### Złożoność czasowa +**O(V · E)** - zawsze, niezależnie od implementacji + +Dla grafów gęstych (E ≈ V²): O(V³) - wolniejszy niż Dijkstra O(V²) + +### Wykrywanie cyklu ujemnego +Po |V|-1 iteracjach, wszystkie najkrótsze ścieżki (bez cykli) są znalezione. +Jeśli w iteracji |V| nadal można zrelaksować krawędź → istnieje cykl ujemny. + +### Optymalizacja: wczesne zakończenie +``` +for i ← 1 to |V| - 1: + changed ← false + for each edge (u, v) ∈ E: + if d[u] + w(u,v) < d[v]: + d[v] ← d[u] + w(u,v) + π[v] ← u + changed ← true + if not changed: + break // Brak zmian = gotowe wcześniej +``` + +--- + +## 3. Algorytm A* (A-star) + +### Charakterystyka +- **Autorzy:** Peter Hart, Nils Nilsson, Bertram Raphael (1968) +- **Typ:** Heurystyczny (informed search) +- **Problem:** Single-Pair - najkrótsza ścieżka z s do konkretnego t +- **Zaleta:** ✅ **Znacznie szybszy niż Dijkstra** dla problemu s→t +- **Wymóg:** Heurystyka dopuszczalna (admissible) + +### Idea algorytmu (logika budowy) +1. **Rozszerzenie Dijkstry:** Dodajemy funkcję heurystyczną +2. **f(n) = g(n) + h(n):** + - g(n) = koszt dotarcia do n (znany) + - h(n) = heurystyczne oszacowanie kosztu n → cel (szacowany) + - f(n) = całkowite oszacowanie kosztu ścieżki przez n +3. **Wybieramy wierzchołek o minimalnym f(n)** zamiast minimalnym g(n) + +### Pseudokod + +``` +A-STAR(G, w, s, t, h): + // Inicjalizacja + for each v ∈ V: + g[v] ← ∞ + f[v] ← ∞ + π[v] ← NIL + g[s] ← 0 + f[s] ← h(s) + + OPEN ← priority_queue({s}) // min-heap według f[v] + CLOSED ← ∅ + + while OPEN ≠ ∅: + u ← EXTRACT-MIN(OPEN) + + if u = t: + return RECONSTRUCT-PATH(π, t) + + CLOSED ← CLOSED ∪ {u} + + for each v ∈ Adj[u]: + if v ∈ CLOSED: + continue + + tentative_g ← g[u] + w(u, v) + + if v ∉ OPEN: + OPEN ← OPEN ∪ {v} + else if tentative_g ≥ g[v]: + continue + + π[v] ← u + g[v] ← tentative_g + f[v] ← g[v] + h(v) + + return "BRAK ŚCIEŻKI" +``` + +### Heurystyka - kluczowy element + +#### Wymagane właściwości: + +1. **Dopuszczalność (Admissibility):** + h(n) ≤ h*(n) dla każdego n + + gdzie h*(n) = rzeczywisty koszt n → cel + + → Gwarantuje optymalność rozwiązania + +2. **Spójność/Monotoniczność (Consistency):** + h(n) ≤ w(n, m) + h(m) dla każdej krawędzi (n, m) + + → Gwarantuje, że węzeł nie musi być ponownie otwarty + → Spójność implikuje dopuszczalność + +#### Popularne heurystyki (dla siatek 2D): + +| Heurystyka | Wzór | Ruch | +|------------|------|------| +| **Manhattan** | \|x₁-x₂\| + \|y₁-y₂\| | 4 kierunki | +| **Euklidesowa** | √((x₁-x₂)² + (y₁-y₂)²) | dowolny kąt | +| **Czebyszewa** | max(\|x₁-x₂\|, \|y₁-y₂\|) | 8 kierunków | +| **Oktylowa** | max(Δx, Δy) + (√2-1)·min(Δx, Δy) | 8 kier. + przekątne | + +### Złożoność czasowa +- **Najgorszy przypadek:** O((V + E) log V) - jak Dijkstra +- **Praktycznie:** Znacznie lepiej dzięki heurystyce - przeszukuje mniej wierzchołków +- **Zależy od jakości h:** Im lepsza heurystyka, tym mniej eksploracji + +### Przypadki specjalne: +- **h(n) = 0:** A* = Dijkstra +- **h(n) = h*(n):** A* idzie prosto do celu (idealna heurystyka) +- **h(n) > h*(n):** Może nie znaleźć optymalnej ścieżki! + +--- + +## 📊 Tabela porównawcza + +| Cecha | Dijkstra | Bellman-Ford | A* | +|-------|----------|--------------|-----| +| **Typ** | Zachłanny | Prog. dynamiczne | Heurystyczny | +| **Problem** | SSSP | SSSP | Single-pair (s→t) | +| **Ujemne wagi** | ❌ NIE | ✅ TAK | ❌ NIE | +| **Cykle ujemne** | Błędny wynik | Wykrywa | Błędny wynik | +| **Złożoność** | O(V log V + E) | O(V·E) | O((V+E) log V)* | +| **Pamięć** | O(V) | O(V) | O(V) | +| **Optymalizacja** | Kolejka priorytetowa | Wczesne zakończenie | Heurystyka | +| **Zastosowanie** | Grafy nieujemne | Grafy z ujemnymi | Pathfinding w grach | + +*praktycznie często znacznie mniej + +--- + +## 🎮 Zastosowania praktyczne + +### Dijkstra +- **Nawigacja GPS** (drogi nie mają ujemnych odległości) +- **Routing w sieciach** (OSPF protocol) +- **Mapy Google/Apple** (dla małych obszarów) + +### Bellman-Ford +- **Routing w sieciach** (RIP protocol - prostszy) +- **Arbitraż walutowy** (szukanie cykli ujemnych = zysk!) +- **Systemy z "karami"** (ujemne wagi = bonusy) + +### A* +- **Gry komputerowe** - pathfinding NPC, RTS +- **Robotyka** - planowanie ruchu +- **Puzzle** - 8-puzzle, 15-puzzle +- **Nawigacja** - gdy znamy pozycję celu + +--- + +## 🔄 Relaksacja - wspólny element + +Wszystkie trzy algorytmy używają **relaksacji krawędzi**: + +``` +RELAX(u, v, w): + if d[u] + w(u,v) < d[v]: + d[v] ← d[u] + w(u,v) + π[v] ← u +``` + +**Różnica w kolejności relaksacji:** +- **Dijkstra:** Relaksuje krawędzie wychodzące z wierzchołka o minimalnym d[v] +- **Bellman-Ford:** Relaksuje wszystkie krawędzie w każdej z |V|-1 iteracji +- **A*:** Relaksuje krawędzie wychodzące z wierzchołka o minimalnym f[v] = g[v] + h[v] + +--- + +## 🧠 Mnemoniki + +### "DBF - Dijkstra Bellman Ford" +- **D**ijkstra = **D**odatnie wagi tylko +- **B**ellman-Ford = **B**ez ograniczeń (ujemne OK) +- **F**ind cycles = wykrywa cykle ujemne + +### "A* = A sterowana" +- **A**lgorytm **A**sterowany heurystyką +- **A**le heurystyka musi być **A**dmissible + +### "GREP" dla Dijkstry: +- **G**reedy (zachłanny) +- **R**elaksacja krawędzi +- **E**xtract-min z kolejki +- **P**riority queue kluczowa + +### "VE" dla Bellman-Ford: +- **V**-1 iteracji +- **E** krawędzi relaksowanych w każdej + +### "HIG" dla A*: +- **H**eurystyka kieruje +- **I**nformed search +- **G**oal-oriented (zorientowany na cel) + +### Złożoność - "Dijkstra lubi VlogV, Bellman lubi VE": +- Dijkstra: O(V log V + E) z kopcem Fibonacciego +- Bellman-Ford: O(V · E) + +--- + +## ❓ Możliwe pytania dodatkowe (follow-up) + +### Q1: "Pokaż działanie algorytmu Dijkstry na przykładzie" + +**Odpowiedź:** + +``` +Graf: + A ---(1)--- B + | | + (4) (2) + | | + S ---(2)--- C ---(1)--- D +``` + +| Krok | Przetwarzany | d[S] | d[A] | d[B] | d[C] | d[D] | +|------|--------------|------|------|------|------|------| +| Init | - | 0 | ∞ | ∞ | ∞ | ∞ | +| 1 | S | 0 | 4 | ∞ | 2 | ∞ | +| 2 | C | 0 | 4 | 4 | 2 | 3 | +| 3 | D | 0 | 4 | 4 | 2 | 3 | +| 4 | A | 0 | 4 | 4 | 2 | 3 | +| 5 | B | 0 | 4 | 4 | 2 | 3 | + +Najkrótsza ścieżka S→D: S → C → D (koszt 3) + +--- + +### Q2: "Jak wykryć ujemny cykl algorytmem Bellman-Forda?" + +**Odpowiedź:** + +Po |V|-1 iteracjach, wykonujemy jeszcze jedną iterację po wszystkich krawędziach: + +```python +# Po głównej pętli +for (u, v) in edges: + if d[u] + w[u][v] < d[v]: + return "UJEMNY CYKL ISTNIEJE" +``` + +**Dlaczego to działa?** +- Najkrótsza ścieżka prosta (bez cykli) ma co najwyżej |V|-1 krawędzi +- Po |V|-1 iteracjach wszystkie takie ścieżki są znalezione +- Jeśli |V|-ta iteracja poprawia cokolwiek → ścieżka przez cykl jest krótsza → cykl ujemny + +--- + +### Q3: "Dlaczego heurystyka musi być dopuszczalna w A*?" + +**Odpowiedź:** + +**Dopuszczalność:** h(n) ≤ h*(n) - nigdy nie przeszacowujemy kosztu + +**Dowód optymalności:** +1. Załóżmy, że A* zwraca ścieżkę P o koszcie g(P) +2. Niech P* będzie optymalną ścieżką o koszcie g(P*) +3. Jeśli g(P) > g(P*), to w momencie zwrócenia P: + - Jakiś węzeł n na P* był w OPEN + - f(n) = g(n) + h(n) ≤ g(n) + h*(n) = g(P*) < g(P) = f(goal) + - Ale A* wybrał goal zamiast n → sprzeczność! + +**Przykład niedopuszczalnej heurystyki:** +``` +S ---(1)--- A ---(1)--- T + \ / + \---(10)--------/ +``` +Jeśli h(A) = 5 (a h*(A) = 1), A* może wybrać ścieżkę S→T (koszt 10) zamiast S→A→T (koszt 2). + +--- + +### Q4: "Porównaj A* z Dijkstrą - kiedy użyć którego?" + +**Odpowiedź:** + +| Sytuacja | Lepszy algorytm | +|----------|-----------------| +| Szukam ścieżki do WSZYSTKICH wierzchołków | **Dijkstra** | +| Szukam ścieżki do JEDNEGO celu | **A*** | +| Nie mam dobrej heurystyki | **Dijkstra** | +| Graf ma strukturę geometryczną (mapa 2D) | **A*** | +| Graf abstrakcyjny (np. stanów) | Zależy od heurystyki | +| Potrzebuję gwarancji optymalności | Oba (A* z dopuszczalną h) | + +**Praktycznie:** +- A* z h(n)=0 to Dijkstra +- Dobra heurystyka może zredukować eksplorację o rzędy wielkości +- W grach A* jest standardem (Unity NavMesh używa wariantu A*) + +--- + +### Q5: "Co to jest algorytm Floyd-Warshalla i jak się ma do omawianych?" + +**Odpowiedź:** + +**Floyd-Warshall** rozwiązuje **All-Pairs Shortest Path (APSP)**: +- Znajduje najkrótsze ścieżki między WSZYSTKIMI parami wierzchołków +- Złożoność: O(V³) +- Działa z ujemnymi wagami (wykrywa cykle ujemne) +- Programowanie dynamiczne + +``` +for k ← 1 to V: + for i ← 1 to V: + for j ← 1 to V: + d[i][j] ← min(d[i][j], d[i][k] + d[k][j]) +``` + +**Porównanie:** +- SSSP z dodatnimi wagami: Dijkstra O(V log V + E) +- SSSP z ujemnymi wagami: Bellman-Ford O(VE) +- APSP: Floyd-Warshall O(V³) lub V × Dijkstra O(V² log V + VE) + +--- + +### Q6: "Jakie są warianty algorytmu Dijkstry?" + +**Odpowiedź:** + +1. **Bidirectional Dijkstra:** + - Równoczesne przeszukiwanie z s i z t + - Spotykają się w środku + - ~2× szybszy w praktyce + +2. **Dial's Algorithm:** + - Dla małych, całkowitych wag [0, C] + - O(V + E + C) zamiast O((V+E) log V) + - Używa "bucket queue" + +3. **Johnson's Algorithm:** + - APSP dla grafów rzadkich + - Używa Bellman-Ford + V × Dijkstra + - O(VE + V² log V) - lepszy niż Floyd-Warshall dla rzadkich grafów + +--- + +## 🎯 Kluczowe punkty do zapamiętania + +1. **Dijkstra** = zachłanny, tylko nieujemne wagi, najszybszy dla SSSP +2. **Bellman-Ford** = prog. dynamiczne, ujemne wagi OK, wykrywa cykle ujemne +3. **A*** = Dijkstra + heurystyka, szybki dla single-pair, wymaga h admissible +4. **Relaksacja** = wspólna operacja, różnica w kolejności +5. **Złożoność:** Dijkstra O(V log V + E), BF O(VE), A* zależy od h + +--- + +## 📖 Źródła do pogłębienia + +1. Cormen, Leiserson, Rivest, Stein - "Introduction to Algorithms" (CLRS) +2. Sedgewick, Wayne - "Algorithms" +3. Hart, Nilsson, Raphael - "A Formal Basis for the Heuristic Determination of Minimum Cost Paths" (1968) +4. Red Blob Games - "Introduction to A*" (online, interaktywny) diff --git a/pytania/odpowiedzi/03-redundancja-normalizacja.md b/pytania/odpowiedzi/03-redundancja-normalizacja.md new file mode 100644 index 0000000..d34a7e4 --- /dev/null +++ b/pytania/odpowiedzi/03-redundancja-normalizacja.md @@ -0,0 +1,515 @@ +# Pytanie 3: Redundancja i normalizacja w relacyjnej bazie danych + +## Pytanie +**"Omówić zagadnienia redundancji i normalizacji w relacyjnej bazie danych oraz wynikające z tego wymagania."** + +Przedmiot: BD2 (Bazy Danych 2) + +--- + +## 📚 Odpowiedź główna + +### Wprowadzenie + +**Redundancja** (nadmiarowość) i **normalizacja** to dwa fundamentalne, przeciwstawne pojęcia w projektowaniu relacyjnych baz danych: + +- **Redundancja** = niepożądane powtarzanie danych +- **Normalizacja** = proces eliminacji redundancji poprzez dekompozycję relacji + +--- + +## 1. Redundancja danych + +### Definicja +**Redundancja** występuje, gdy ta sama informacja jest przechowywana w wielu miejscach bazy danych, co prowadzi do: +- Marnowania pamięci +- Niespójności danych (anomalii) +- Trudności w utrzymaniu + +### Anomalie wynikające z redundancji + +#### Przykład - tabela z redundancją: + +| StudentID | Imię | Nazwisko | KursID | NazwaKursu | Prowadzący | +|-----------|------|----------|--------|------------|------------| +| 1 | Jan | Kowalski | BD1 | Bazy Danych | Dr Nowak | +| 1 | Jan | Kowalski | AISDI | Algorytmy | Prof. Wiśniewski | +| 2 | Anna | Nowak | BD1 | Bazy Danych | Dr Nowak | +| 2 | Anna | Nowak | BD1 | Bazy Danych | Dr Nowak | + +**Problemy:** +- "Bazy Danych" i "Dr Nowak" powtórzono 3 razy +- "Jan Kowalski" powtórzono 2 razy + +### Trzy typy anomalii + +#### 1. Anomalia wstawiania (Insertion Anomaly) +**Problem:** Nie można dodać danych bez dodania innych, niepotrzebnych danych. + +**Przykład:** Nie możemy dodać nowego kursu "Sieci komputerowe" bez przypisania do niego studenta. + +#### 2. Anomalia usuwania (Deletion Anomaly) +**Problem:** Usunięcie danych powoduje niezamierzoną utratę innych informacji. + +**Przykład:** Jeśli Anna Nowak zrezygnuje ze studiów, tracimy informację, że kurs BD1 prowadzi Dr Nowak (jeśli była jedynym studentem tego kursu). + +#### 3. Anomalia modyfikacji (Update Anomaly) +**Problem:** Zmiana jednej informacji wymaga modyfikacji wielu wierszy. + +**Przykład:** Jeśli Dr Nowak zmieni nazwisko, musimy zaktualizować wszystkie wiersze z kursem BD1. + +--- + +## 2. Normalizacja + +### Definicja +**Normalizacja** to proces organizowania danych w bazie w celu: +- Eliminacji redundancji +- Zapewnienia integralności danych +- Ułatwienia utrzymania i modyfikacji + +### Podstawowe pojęcia + +#### Zależność funkcyjna (Functional Dependency - FD) +**X → Y** oznacza: wartość X jednoznacznie określa wartość Y + +**Przykład:** StudentID → (Imię, Nazwisko) +- Znając StudentID, możemy jednoznacznie określić imię i nazwisko + +#### Klucz główny (Primary Key) +Minimalny zbiór atrybutów, który jednoznacznie identyfikuje krotkę (wiersz). + +#### Klucz kandydujący (Candidate Key) +Każdy minimalny zbiór atrybutów, który mógłby być kluczem głównym. + +#### Atrybut pierwszy (Prime Attribute) +Atrybut należący do jakiegokolwiek klucza kandydującego. + +#### Atrybut wtórny (Non-prime Attribute) +Atrybut nienależący do żadnego klucza kandydującego. + +--- + +## 3. Postacie normalne + +### Hierarchia postaci normalnych + +``` +5NF ⊂ 4NF ⊂ BCNF ⊂ 3NF ⊂ 2NF ⊂ 1NF +``` + +Każda wyższa postać implikuje niższą. + +--- + +### 1NF - Pierwsza Postać Normalna + +#### Wymagania: +1. **Atomowość wartości** - każda komórka zawiera jedną, niepodzielną wartość +2. **Brak powtarzających się grup** - brak tablic/list w komórkach +3. **Istnieje klucz główny** + +#### ❌ Naruszenie 1NF: + +| StudentID | Imię | Telefony | +|-----------|------|----------| +| 1 | Jan | 123456, 789012 | + +#### ✅ Po normalizacji do 1NF: + +**Studenci:** +| StudentID | Imię | +|-----------|------| +| 1 | Jan | + +**Telefony:** +| StudentID | Telefon | +|-----------|---------| +| 1 | 123456 | +| 1 | 789012 | + +--- + +### 2NF - Druga Postać Normalna + +#### Wymagania: +1. Spełnia 1NF +2. **Każdy atrybut wtórny jest w pełni funkcyjnie zależny od całego klucza głównego** (nie od jego części) + +Dotyczy tylko tabel z **kluczem złożonym** (wielokolumnowym). + +#### ❌ Naruszenie 2NF: + +| StudentID | KursID | NazwaKursu | Ocena | +|-----------|--------|------------|-------| +| 1 | BD1 | Bazy Danych | 5 | +| 2 | BD1 | Bazy Danych | 4 | + +Klucz: (StudentID, KursID) +- NazwaKursu zależy tylko od KursID, nie od całego klucza! +- KursID → NazwaKursu (częściowa zależność) + +#### ✅ Po normalizacji do 2NF: + +**Oceny:** +| StudentID | KursID | Ocena | +|-----------|--------|-------| +| 1 | BD1 | 5 | +| 2 | BD1 | 4 | + +**Kursy:** +| KursID | NazwaKursu | +|--------|------------| +| BD1 | Bazy Danych | + +--- + +### 3NF - Trzecia Postać Normalna + +#### Wymagania: +1. Spełnia 2NF +2. **Brak przechodnich zależności funkcyjnych** - atrybuty wtórne nie zależą od innych atrybutów wtórnych + +**Formalnie:** Dla każdej nietrywialnej FD X → A: +- X jest nadkluczem, LUB +- A jest atrybutem pierwszym (należy do klucza) + +#### ❌ Naruszenie 3NF: + +| StudentID | Imię | WydziałID | NazwaWydziału | +|-----------|------|-----------|---------------| +| 1 | Jan | W4 | Elektroniki | + +Klucz: StudentID +- StudentID → WydziałID → NazwaWydziału (przechodnia zależność!) + +#### ✅ Po normalizacji do 3NF: + +**Studenci:** +| StudentID | Imię | WydziałID | +|-----------|------|-----------| +| 1 | Jan | W4 | + +**Wydziały:** +| WydziałID | NazwaWydziału | +|-----------|---------------| +| W4 | Elektroniki | + +--- + +### BCNF - Postać Normalna Boyce'a-Codda + +#### Wymagania: +1. Spełnia 3NF +2. **Dla każdej nietrywialnej FD X → Y, X jest nadkluczem** + +BCNF jest silniejsza niż 3NF - eliminuje przypadki, gdy atrybut pierwszy zależy od atrybutu niebędącego nadkluczem. + +#### ❌ Naruszenie BCNF (ale spełnia 3NF): + +| Student | Przedmiot | Prowadzący | +|---------|-----------|------------| +| Jan | Bazy Danych | Dr Nowak | +| Jan | Algorytmy | Dr Nowak | +| Anna | Bazy Danych | Dr Kowalski | + +Klucze kandydujące: {Student, Przedmiot}, {Student, Prowadzący} +- Prowadzący → Przedmiot (jeden prowadzący = jeden przedmiot) +- Ale Prowadzący nie jest nadkluczem! + +#### ✅ Po normalizacji do BCNF: + +**Zapisy:** +| Student | Prowadzący | +|---------|------------| +| Jan | Dr Nowak | +| Anna | Dr Kowalski | + +**Prowadzący:** +| Prowadzący | Przedmiot | +|------------|-----------| +| Dr Nowak | Bazy Danych | +| Dr Kowalski | Bazy Danych | + +--- + +### 4NF - Czwarta Postać Normalna + +#### Wymagania: +1. Spełnia BCNF +2. **Brak nietrywialnych zależności wielowartościowych** (MVD - Multivalued Dependencies) + +**Zależność wielowartościowa X ↠ Y:** Dla danego X istnieje zbiór wartości Y niezależny od innych atrybutów. + +#### ❌ Naruszenie 4NF: + +| Pracownik | Umiejętność | Język | +|-----------|-------------|-------| +| Jan | Java | Angielski | +| Jan | Java | Niemiecki | +| Jan | Python | Angielski | +| Jan | Python | Niemiecki | + +Pracownik ↠ Umiejętność i Pracownik ↠ Język (niezależne!) + +#### ✅ Po normalizacji do 4NF: + +**PracownikUmiejętności:** +| Pracownik | Umiejętność | +|-----------|-------------| +| Jan | Java | +| Jan | Python | + +**PracownikJęzyki:** +| Pracownik | Język | +|-----------|-------| +| Jan | Angielski | +| Jan | Niemiecki | + +--- + +### 5NF - Piąta Postać Normalna (PJNF) + +#### Wymagania: +1. Spełnia 4NF +2. **Brak zależności połączeniowych** (Join Dependencies) +3. Dekompozycja bez strat tylko na podstawie kluczy kandydujących + +5NF eliminuje redundancję wynikającą z niemożliwości odtworzenia oryginalnej relacji przez złączenie jej projekcji. + +--- + +## 📊 Tabela porównawcza postaci normalnych + +| Postać | Eliminuje | Wymaga | +|--------|-----------|--------| +| **1NF** | Wielowartościowe atrybuty | Atomowość, klucz główny | +| **2NF** | Częściowe zależności | Pełna zależność od klucza | +| **3NF** | Przechodnie zależności | Brak X → A gdzie X nie jest nadkluczem i A nie jest pierwszym | +| **BCNF** | Zależności od nie-nadkluczy | Każdy determinant jest nadkluczem | +| **4NF** | Wielowartościowe zależności | Brak nietrywialnych MVD | +| **5NF** | Zależności połączeniowe | Dekompozycja tylko przez klucze | + +--- + +## 4. Proces normalizacji + +### Algorytm dekompozycji do 3NF + +1. **Znajdź pokrycie kanoniczne** zbioru zależności funkcyjnych +2. **Dla każdej FD X → A** utwórz relację R(X, A) +3. **Jeśli żadna relacja nie zawiera klucza kandydującego**, dodaj relację z atrybutami klucza +4. **Usuń relacje zawarte w innych relacjach** + +### Własności dobrej dekompozycji + +#### 1. Bezstratność (Lossless Join) +Po dekompozycji można odtworzyć oryginalną relację przez złączenie naturalne. + +**Twierdzenie:** Dekompozycja R na R₁ i R₂ jest bezstratna wtw gdy: +- R₁ ∩ R₂ → R₁, lub +- R₁ ∩ R₂ → R₂ + +#### 2. Zachowanie zależności (Dependency Preservation) +Wszystkie oryginalne FD można zweryfikować w pojedynczych tabelach wynikowych (bez złączeń). + +--- + +## 5. Denormalizacja + +### Kiedy stosować? +- **Optymalizacja wydajności** - złączenia są kosztowne +- **Systemy OLAP/hurtownie danych** - dane głównie odczytywane +- **Raportowanie** - predefiniowane zapytania + +### Techniki denormalizacji: +1. **Dodanie redundantnych kolumn** - unikanie złączeń +2. **Tabele podsumowujące** - agregaty +3. **Tabele historyczne** - snapshoty +4. **Materializowane widoki** - cache wyników + +### Kompromis: +``` +NORMALIZACJA ←————————————→ DENORMALIZACJA +Integralność Wydajność odczytu +Mniej redundancji Więcej redundancji +Wolniejsze odczyty Szybsze odczyty +Szybsze zapisy Wolniejsze zapisy +``` + +--- + +## 🧠 Mnemoniki + +### "1-2-3-BC" dla postaci normalnych: +- **1**NF = **1** wartość w komórce (atomowość) +- **2**NF = **2** słowa: "pełna zależność" (od całego klucza) +- **3**NF = **3** słowa: "brak przechodniości" (A→B→C eliminowane) +- **BC**NF = **B**ardzo **C**isty (każdy determinant = nadklucz) + +### "AIU" dla anomalii: +- **A**nomalia wstawiania (**A**dding) - nie można dodać +- **I**nsercja usuwania (**I**nterrupts) - traci dane przy DELETE +- **U**pdate modyfikacji - trzeba zmieniać wiele wierszy + +### "KAP" dla kluczy: +- **K**lucz główny - wybrany unikalny identyfikator +- **A**lternatywny (kandydujący) - mógłby być głównym +- **P**ierwszy atrybut - należy do jakiegoś klucza + +### Wzór na 3NF: +> "Każdy atrybut zależy od **klucza**, **całego klucza** i **tylko od klucza**." +> (The key, the whole key, and nothing but the key - so help me Codd!) + +--- + +## ❓ Możliwe pytania dodatkowe (follow-up) + +### Q1: "Podaj przykład dekompozycji do 3NF z zachowaniem bezstratności" + +**Odpowiedź:** + +**Relacja:** R(A, B, C, D) +**FD:** A → B, B → C, C → D + +**Klucz:** A + +**Dekompozycja:** +1. R₁(A, B) - z FD A → B +2. R₂(B, C) - z FD B → C +3. R₃(C, D) - z FD C → D + +**Sprawdzenie bezstratności:** +- R₁ ∩ R₂ = {B}, B → C (B jest kluczem R₂) ✓ +- R₂ ∩ R₃ = {C}, C → D (C jest kluczem R₃) ✓ + +--- + +### Q2: "Czym się różni 3NF od BCNF?" + +**Odpowiedź:** + +| Cecha | 3NF | BCNF | +|-------|-----|------| +| **Warunek** | X nadklucz LUB A pierwszy | X zawsze nadklucz | +| **Siła** | Słabsza | Silniejsza | +| **Dekompozycja** | Zachowuje zależności | Może nie zachować | +| **Redundancja** | Możliwa minimalna | Brak | + +**Przykład różnicy:** + +R(Student, Przedmiot, Prowadzący) +- Klucze: {Student, Przedmiot}, {Student, Prowadzący} +- FD: Prowadzący → Przedmiot + +**3NF:** ✅ spełniona (Przedmiot jest atrybutem pierwszym) +**BCNF:** ❌ naruszona (Prowadzący nie jest nadkluczem) + +--- + +### Q3: "Jak sprawdzić, czy relacja jest w 3NF?" + +**Odpowiedź:** + +**Algorytm:** +1. Znajdź wszystkie nietrywialne FD +2. Dla każdej FD X → A sprawdź: + - Czy X jest nadkluczem? → OK + - Czy A jest atrybutem pierwszym? → OK + - Jeśli żadne → NIE jest w 3NF + +**Przykład:** +R(A, B, C), FD: {A → B, B → C} + +Klucz: A +- A → B: A jest nadkluczem ✓ +- B → C: B nie jest nadkluczem, C nie jest pierwszy ✗ + +**Wniosek:** R NIE jest w 3NF + +--- + +### Q4: "Kiedy normalizacja może zaszkodzić?" + +**Odpowiedź:** + +1. **Systemy OLAP/raportowe:** + - Złączenia wielu tabel są kosztowne + - Dane głównie odczytywane, rzadko modyfikowane + - Lepiej: denormalizacja, schematy gwiazdy/płatka śniegu + +2. **Aplikacje o wysokiej wydajności:** + - Każde złączenie to koszt + - Cache'owanie i replikacja danych może być szybsze + +3. **Systemy czasu rzeczywistego:** + - Determinizm ważniejszy niż oszczędność miejsca + - Redundancja może przyspieszyć dostęp + +**Zasada:** Normalizuj dla OLTP, denormalizuj dla OLAP + +--- + +### Q5: "Co to jest zależność wielowartościowa (MVD)?" + +**Odpowiedź:** + +**Zależność wielowartościowa X ↠ Y:** +Dla każdej wartości X istnieje zbiór wartości Y, który jest niezależny od innych atrybutów relacji. + +**Formalnie:** X ↠ Y w R(X, Y, Z) gdy: +Dla każdych dwóch krotek t₁, t₂ takich że t₁[X] = t₂[X]: +istnieje krotka t₃ gdzie: +- t₃[X] = t₁[X] = t₂[X] +- t₃[Y] = t₁[Y] +- t₃[Z] = t₂[Z] + +**Intuicja:** Y i Z są "niezależne" przy danym X. + +**Przykład:** +Pracownik ↠ Umiejętność (niezależne od języka) +Pracownik ↠ Język (niezależne od umiejętności) + +--- + +### Q6: "Wyjaśnij pojęcie pokrycia kanonicznego" + +**Odpowiedź:** + +**Pokrycie kanoniczne** to minimalny zbiór FD równoważny oryginalnemu. + +**Właściwości:** +1. Prawa strona każdej FD ma jeden atrybut +2. Lewa strona jest minimalna (brak nadmiarowych atrybutów) +3. Brak redundantnych FD + +**Algorytm:** +1. Rozłóż prawe strony: A → BC na A → B, A → C +2. Usuń nadmiarowe atrybuty z lewych stron +3. Usuń redundantne FD (te wynikające z innych) + +**Przykład:** +F = {A → BC, B → C, A → B, AB → C} + +Pokrycie kanoniczne: +Fc = {A → B, B → C} + +--- + +## 🎯 Kluczowe punkty do zapamiętania + +1. **Redundancja** = powtarzanie danych → anomalie AIU +2. **Normalizacja** = dekompozycja eliminująca redundancję +3. **3NF** = standard praktyczny (zachowuje zależności) +4. **BCNF** = silniejsza, ale może gubić zależności +5. **Wzór 3NF:** "klucz, cały klucz, tylko klucz" +6. **Kompromis:** normalizacja vs wydajność + +--- + +## 📖 Źródła do pogłębienia + +1. Date, C.J. - "An Introduction to Database Systems" +2. Elmasri, Navathe - "Fundamentals of Database Systems" +3. Codd, E.F. - "A Relational Model of Data for Large Shared Data Banks" (1970) +4. Garcia-Molina, Ullman, Widom - "Database Systems: The Complete Book" diff --git a/pytania/odpowiedzi/04-baza-danych-fundament.md b/pytania/odpowiedzi/04-baza-danych-fundament.md new file mode 100644 index 0000000..06a1b3e --- /dev/null +++ b/pytania/odpowiedzi/04-baza-danych-fundament.md @@ -0,0 +1,434 @@ +# Pytanie 4: Baza danych jako fundament systemów informatycznych + +## Pytanie +**"Dlaczego baza danych stanowi dobry fundament do budowy wielu systemów informatycznych?"** + +Przedmiot: BD2 (Bazy Danych 2) + +--- + +## 📚 Odpowiedź główna + +### Wprowadzenie + +Baza danych to **centralny komponent** większości systemów informatycznych, ponieważ zapewnia: +- Trwałe przechowywanie danych +- Współbieżny dostęp +- Integralność i spójność +- Niezależność danych od aplikacji + +--- + +## 1. Kluczowe właściwości baz danych (ACID) + +### Transakcyjność - gwarancje ACID + +| Właściwość | Opis | Znaczenie | +|------------|------|-----------| +| **A**tomicity (Atomowość) | Transakcja wykonuje się w całości lub wcale | Brak częściowych zmian | +| **C**onsistency (Spójność) | Dane przechodzą z jednego spójnego stanu w drugi | Reguły biznesowe zawsze spełnione | +| **I**solation (Izolacja) | Równoległe transakcje nie widzą swoich zmian | Brak efektów ubocznych | +| **D**urability (Trwałość) | Zatwierdzone zmiany przetrwają awarie | Bezpieczeństwo danych | + +### Przykład znaczenia ACID + +**Przelew bankowy:** +```sql +BEGIN TRANSACTION; + UPDATE Konta SET saldo = saldo - 1000 WHERE id = 1; -- Odejmij + UPDATE Konta SET saldo = saldo + 1000 WHERE id = 2; -- Dodaj +COMMIT; +``` + +Bez ACID: +- Awaria po pierwszym UPDATE = utrata pieniędzy (brak atomowości) +- Saldo < 0 mimo ograniczenia (brak spójności) +- Inna transakcja widzi stan pośredni (brak izolacji) +- Po zatwierdzeniu dane giną (brak trwałości) + +--- + +## 2. Niezależność danych + +### Trójpoziomowa architektura ANSI/SPARC + +``` +┌─────────────────────────────────────────┐ +│ Poziom zewnętrzny (widoki) │ ← Aplikacje widzą różne "okna" +├─────────────────────────────────────────┤ +│ Poziom konceptualny (logiczny) │ ← Struktura logiczna danych +├─────────────────────────────────────────┤ +│ Poziom wewnętrzny (fizyczny) │ ← Sposób przechowywania +└─────────────────────────────────────────┘ +``` + +### Rodzaje niezależności + +#### 1. Niezależność fizyczna +Zmiana sposobu przechowywania (indeksy, partycjonowanie, kompresja) **nie wpływa** na aplikacje. + +**Przykład:** Dodanie indeksu przyspiesza zapytania bez zmiany kodu aplikacji. + +#### 2. Niezależność logiczna +Zmiana struktury logicznej (dodanie kolumn, widoków) **minimalizuje** wpływ na aplikacje. + +**Przykład:** Podział tabeli na dwie + widok łączący = stare aplikacje działają bez zmian. + +--- + +## 3. Współbieżność i wielodostęp + +### Problem współbieżności + +Wiele aplikacji/użytkowników **jednocześnie** korzysta z tych samych danych. + +### Mechanizmy kontroli współbieżności + +| Mechanizm | Opis | Zastosowanie | +|-----------|------|--------------| +| **Blokady (Locks)** | Pesymistyczne - blokuj przed dostępem | Wysokie konflikty | +| **MVCC** | Optymistyczne - wersjonowanie | Dużo odczytów | +| **Timestamp Ordering** | Szeregowanie po czasie | Systemy rozproszone | +| **Snapshot Isolation** | Izolacja migawkowa | Analityka | + +### Poziomy izolacji (SQL Standard) + +| Poziom | Dirty Read | Non-repeatable Read | Phantom Read | +|--------|------------|---------------------|--------------| +| READ UNCOMMITTED | Możliwy | Możliwy | Możliwy | +| READ COMMITTED | Niemożliwy | Możliwy | Możliwy | +| REPEATABLE READ | Niemożliwy | Niemożliwy | Możliwy | +| SERIALIZABLE | Niemożliwy | Niemożliwy | Niemożliwy | + +--- + +## 4. Integralność danych + +### Mechanizmy wymuszania integralności + +#### 1. Ograniczenia deklaratywne +```sql +CREATE TABLE Zamowienia ( + id INT PRIMARY KEY, -- Klucz główny + klient_id INT NOT NULL, -- NOT NULL + data DATE DEFAULT CURRENT_DATE, -- Wartość domyślna + kwota DECIMAL(10,2) CHECK (kwota > 0), -- Warunek CHECK + FOREIGN KEY (klient_id) REFERENCES Klienci(id) -- Klucz obcy +); +``` + +#### 2. Wyzwalacze (Triggers) +```sql +CREATE TRIGGER sprawdz_saldo +BEFORE UPDATE ON Konta +FOR EACH ROW +BEGIN + IF NEW.saldo < 0 THEN + SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Brak środków'; + END IF; +END; +``` + +#### 3. Procedury składowane +Logika biznesowa w bazie = jednolite reguły dla wszystkich aplikacji. + +--- + +## 5. Wydajność i optymalizacja + +### Optymalizator zapytań + +SZBD automatycznie: +1. **Analizuje zapytanie** (parsing) +2. **Generuje plany wykonania** (alternatywy) +3. **Szacuje koszty** (statystyki) +4. **Wybiera najlepszy plan** (optymalizacja) + +### Mechanizmy wydajności + +| Mechanizm | Funkcja | +|-----------|---------| +| **Indeksy** | Szybkie wyszukiwanie (B-tree, Hash, GiST) | +| **Buforowanie** | Cache często używanych danych | +| **Partycjonowanie** | Podział dużych tabel | +| **Materializowane widoki** | Prekompilowane złączenia | +| **Query cache** | Cache wyników zapytań | + +--- + +## 6. Bezpieczeństwo + +### Wielopoziomowe zabezpieczenia + +``` +┌─────────────────────────────────────────┐ +│ Autoryzacja (GRANT/REVOKE) │ +├─────────────────────────────────────────┤ +│ Autentykacja (użytkownicy, role) │ +├─────────────────────────────────────────┤ +│ Szyfrowanie (TDE, SSL/TLS) │ +├─────────────────────────────────────────┤ +│ Audyt (logi, śledzenie zmian) │ +└─────────────────────────────────────────┘ +``` + +### Kontrola dostępu +```sql +-- Tworzenie roli +CREATE ROLE analityk; +GRANT SELECT ON Sprzedaz TO analityk; + +-- Przypisanie użytkownika +GRANT analityk TO jan_kowalski; + +-- Widok ograniczający dane +CREATE VIEW MojeZamowienia AS + SELECT * FROM Zamowienia WHERE sprzedawca = CURRENT_USER; +``` + +--- + +## 7. Skalowalność i dostępność + +### Skalowanie pionowe (Scale-up) +- Więcej RAM, szybsze CPU, dyski SSD +- Proste, ale ograniczone + +### Skalowanie poziome (Scale-out) +- **Replikacja** - kopie do odczytu +- **Sharding** - podział danych między serwery +- **Klastry** - wysoka dostępność + +### Wysoka dostępność (HA) + +| Rozwiązanie | Opis | +|-------------|------| +| **Replikacja Master-Slave** | Odczyty z replik | +| **Replikacja Master-Master** | Zapisy na wielu węzłach | +| **Failover automatyczny** | Przełączanie przy awarii | +| **Backup/Recovery** | Odtwarzanie po katastrofie | + +--- + +## 8. Standaryzacja i ekosystem + +### SQL jako lingua franca +- **Standardowy język** - SQL:2016, SQL:2023 +- **Przenośność** - kod działa na różnych SZBD +- **Narzędzia** - uniwersalne IDE, ORM, ETL + +### Bogaty ekosystem +- **ORM** (Hibernate, Entity Framework, SQLAlchemy) +- **Narzędzia migracji** (Flyway, Liquibase) +- **Monitorowanie** (Grafana, Datadog) +- **Backup** (pg_dump, mysqldump, RMAN) + +--- + +## 9. Różnorodność modeli danych + +### Jeden fundament, wiele modeli + +| Model | SZBD | Zastosowanie | +|-------|------|--------------| +| **Relacyjny** | PostgreSQL, MySQL, Oracle | OLTP, dane strukturalne | +| **Dokumentowy** | MongoDB, CouchDB | JSON, elastyczne schematy | +| **Klucz-wartość** | Redis, DynamoDB | Cache, sesje | +| **Grafowy** | Neo4j, Amazon Neptune | Relacje, sieci społeczne | +| **Kolumnowy** | Cassandra, ClickHouse | Analityka, time-series | +| **Czasowy** | TimescaleDB, InfluxDB | IoT, metryki | + +### Polyglot Persistence +Nowoczesne systemy często używają **wielu baz** - każda do swojego celu. + +--- + +## 📊 Porównanie: z bazą vs bez bazy + +| Aspekt | Bez bazy (pliki) | Z bazą danych | +|--------|------------------|---------------| +| **Współbieżność** | Ręczne blokady | Automatyczna | +| **Integralność** | W kodzie aplikacji | Deklaratywna | +| **Zapytania** | Parsowanie plików | SQL/indeksy | +| **Backup** | Kopiowanie plików | Spójne snapshoty | +| **Skalowanie** | Trudne | Replikacja/sharding | +| **Bezpieczeństwo** | OS-level | Granularne uprawnienia | + +--- + +## 🧠 Mnemoniki + +### "ACID" - już sam w sobie mnemonik: +- **A**tomowość - **A**ll or nothing +- **C**onsistency - **C**orrect always +- **I**solation - **I**ndependent transactions +- **D**urability - **D**ata survives + +### "BDSM" dla korzyści bazy danych: +- **B**ezpieczeństwo (autoryzacja, audyt) +- **D**ane niezależne (od aplikacji) +- **S**kalowalność (replikacja, sharding) +- **M**echanizmy integralności (FK, CHECK) + +### "CIA" dla bezpieczeństwa: +- **C**onfidentiality - kto może czytać +- **I**ntegrity - kto może zmieniać +- **A**vailability - dostępność usługi + +### "CRUD = baza umie wszystko": +- **C**reate - INSERT +- **R**ead - SELECT +- **U**pdate - UPDATE +- **D**elete - DELETE + +--- + +## ❓ Możliwe pytania dodatkowe (follow-up) + +### Q1: "Wyjaśnij różnicę między blokadami pesymistycznymi a optymistycznymi" + +**Odpowiedź:** + +| Cecha | Pesymistyczne | Optymistyczne | +|-------|---------------|---------------| +| **Założenie** | Konflikty są częste | Konflikty są rzadkie | +| **Działanie** | Blokuj przed dostępem | Sprawdź przy zatwierdzeniu | +| **Implementacja** | Locki (S, X, IS, IX) | Wersjonowanie (MVCC) | +| **Zaleta** | Gwarancja sukcesu | Brak blokowania | +| **Wada** | Deadlocki możliwe | Rollback przy konflikcie | +| **Zastosowanie** | Dużo zapisów | Dużo odczytów | + +**MVCC (Multi-Version Concurrency Control):** +- Każdy zapis tworzy nową wersję wiersza +- Odczyt widzi "migawkę" z początku transakcji +- Brak blokowania między odczytem a zapisem + +--- + +### Q2: "Co to jest CAP theorem i jak wpływa na projektowanie?" + +**Odpowiedź:** + +**Twierdzenie CAP** (Brewer, 2000): +W systemie rozproszonym można mieć **co najwyżej 2 z 3** właściwości: + +- **C**onsistency - wszystkie węzły widzą te same dane +- **A**vailability - każde żądanie otrzymuje odpowiedź +- **P**artition tolerance - system działa mimo podziału sieci + +**Konsekwencje:** + +| Wybór | Poświęca | Przykład | +|-------|----------|----------| +| **CA** | Partition tolerance | Tradycyjne RDBMS (single node) | +| **CP** | Availability | MongoDB, HBase | +| **AP** | Consistency | Cassandra, DynamoDB | + +**Praktyka:** Systemy rozproszone MUSZĄ być P (partycje się zdarzają), więc wybór to C vs A. + +--- + +### Q3: "Kiedy baza relacyjna, a kiedy NoSQL?" + +**Odpowiedź:** + +| Kryteria | Relacyjna (SQL) | NoSQL | +|----------|-----------------|-------| +| **Struktura danych** | Stała, dobrze zdefiniowana | Zmienna, elastyczna | +| **Transakcje** | ACID wymagane | BASE akceptowalne | +| **Relacje** | Złożone złączenia | Proste lub brak | +| **Skala** | Pionowa (scale-up) | Pozioma (scale-out) | +| **Przykłady** | Finanse, ERP, CRM | Social media, IoT, gaming | + +**BASE** (dla NoSQL): +- **B**asically **A**vailable - zazwyczaj dostępny +- **S**oft state - stan może być nieaktualny +- **E**ventually consistent - ostatecznie spójny + +--- + +### Q4: "Jak baza danych wspiera architekturę mikroserwisów?" + +**Odpowiedź:** + +**Wzorzec: Database per Service** +- Każdy mikroserwis ma **własną bazę** +- Brak bezpośredniego dostępu do cudzych danych +- Komunikacja przez API/eventy + +**Wyzwania:** +1. **Rozproszone transakcje** → Saga pattern +2. **Spójność danych** → Event sourcing, CQRS +3. **Złączenia** → Denormalizacja, API composition + +**Rozwiązania:** +``` +┌─────────────┐ ┌─────────────┐ ┌─────────────┐ +│ Zamówienia │ │ Klienci │ │ Produkty │ +│ (MongoDB) │ │ (PostgreSQL)│ │ (Redis) │ +└─────────────┘ └─────────────┘ └─────────────┘ + ↓ ↓ ↓ + └──────── Message Broker (Kafka) ─────┘ +``` + +--- + +### Q5: "Co to jest indeks i jakie są rodzaje?" + +**Odpowiedź:** + +**Indeks** = struktura danych przyspieszająca wyszukiwanie. + +| Typ | Struktura | Zastosowanie | +|-----|-----------|--------------| +| **B-tree** | Zbalansowane drzewo | Ogólne, zakresy, sortowanie | +| **Hash** | Tablica mieszająca | Równość (=), bardzo szybki | +| **GiST** | Drzewo uogólnione | Geodane, full-text | +| **GIN** | Inverted index | Tablice, JSONB, full-text | +| **BRIN** | Block Range Index | Duże tabele, dane posortowane | + +**Kompromis:** +- Indeks **przyspiesza** SELECT +- Indeks **spowalnia** INSERT/UPDATE/DELETE +- Indeks **zajmuje** miejsce na dysku + +--- + +### Q6: "Wyjaśnij pojęcie normalizacji vs denormalizacji w kontekście wydajności" + +**Odpowiedź:** + +| Aspekt | Normalizacja | Denormalizacja | +|--------|--------------|----------------| +| **Redundancja** | Minimalna | Celowa | +| **Złączenia** | Wymagane | Minimalne | +| **Zapisy** | Szybkie | Wolniejsze | +| **Odczyty** | Wolniejsze | Szybsze | +| **Spójność** | Łatwa | Trudniejsza | +| **Zastosowanie** | OLTP | OLAP, cache | + +**Praktyka:** +- **OLTP** (transakcje) → 3NF/BCNF +- **OLAP** (analityka) → Star/Snowflake schema +- **Cache** → Pełna denormalizacja (Redis) + +--- + +## 🎯 Kluczowe punkty do zapamiętania + +1. **ACID** = gwarancje transakcyjne fundamentem niezawodności +2. **Niezależność danych** = zmiany struktury nie psują aplikacji +3. **Współbieżność** = tysiące użytkowników jednocześnie +4. **Integralność** = reguły biznesowe wymuszone w bazie +5. **Optymalizator** = automatyczne przyspieszanie zapytań +6. **Bezpieczeństwo** = wielopoziomowa kontrola dostępu +7. **Skalowalność** = od jednego serwera do klastra globalnego + +--- + +## 📖 Źródła do pogłębienia + +1. Date, C.J. - "An Introduction to Database Systems" +2. Kleppmann, M. - "Designing Data-Intensive Applications" +3. Garcia-Molina, Ullman, Widom - "Database Systems: The Complete Book" +4. Hellerstein, Stonebraker - "Readings in Database Systems" (Red Book) diff --git a/pytania/odpowiedzi/05-stl-kategorie.md b/pytania/odpowiedzi/05-stl-kategorie.md new file mode 100644 index 0000000..e3c620b --- /dev/null +++ b/pytania/odpowiedzi/05-stl-kategorie.md @@ -0,0 +1,685 @@ +# Pytanie 5: Główne kategorie elementów biblioteki STL + +## Pytanie +**"Omówić główne kategorie elementów biblioteki STL. Jaka jest ich rola i wzajemne powiązania? Odpowiedź uzasadnić na przykładach."** + +Przedmiot: PROI (Programowanie Obiektowe) + +--- + +## 📚 Odpowiedź główna + +### Wprowadzenie + +**STL (Standard Template Library)** to część standardowej biblioteki C++ zawierająca generyczne struktury danych i algorytmy. Została zaprojektowana przez Alexandra Stepanova i weszła do standardu C++98. + +### Filozofia STL +- **Generyczność** - szablony (templates) umożliwiają pracę z dowolnymi typami +- **Wydajność** - zero-overhead abstraction +- **Modularność** - komponenty są niezależne i wymienne +- **Ortogonalność** - kontenery i algorytmy są rozdzielone (przez iteratory) + +--- + +## Cztery główne kategorie STL + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ STL │ +├─────────────┬─────────────┬─────────────┬─────────────────────┤ +│ KONTENERY │ ITERATORY │ ALGORYTMY │ FUNKTORY │ +│ (co?) │ (jak?) │ (operacje) │ (parametryzacja) │ +├─────────────┼─────────────┼─────────────┼─────────────────────┤ +│ vector │ input │ sort │ less │ +│ list │ output │ find │ greater │ +│ map │ forward │ transform │ plus │ +│ set │ bidirect. │ copy │ lambdy │ +│ ... │ random │ ... │ ... │ +└─────────────┴─────────────┴─────────────┴─────────────────────┘ +``` + +--- + +## 1. Kontenery (Containers) + +### Definicja +**Kontenery** to struktury danych przechowujące kolekcje obiektów. Zarządzają pamięcią automatycznie. + +### Kategorie kontenerów + +#### 1.1 Kontenery sekwencyjne (Sequence Containers) + +Przechowują elementy w określonej kolejności. + +| Kontener | Struktura | Dostęp | Wstawianie | Usuwanie | +|----------|-----------|--------|------------|----------| +| `vector` | Tablica dynamiczna | O(1) random | O(1) koniec, O(n) środek | O(1) koniec, O(n) środek | +| `deque` | Tablica tablic | O(1) random | O(1) początek/koniec | O(1) początek/koniec | +| `list` | Lista dwukierunkowa | O(n) | O(1) wszędzie* | O(1) wszędzie* | +| `forward_list` | Lista jednokierunkowa | O(n) | O(1) po elemencie | O(1) po elemencie | +| `array` | Tablica statyczna | O(1) random | N/A | N/A | + +*po znalezieniu pozycji + +```cpp +#include +#include +#include + +// vector - najczęściej używany +std::vector vec = {1, 2, 3, 4, 5}; +vec.push_back(6); // O(1) amortyzowane +vec[2] = 10; // O(1) dostęp +vec.insert(vec.begin(), 0); // O(n) - przesunięcie + +// list - szybkie wstawianie/usuwanie +std::list lst = {1, 2, 3}; +auto it = lst.begin(); +std::advance(it, 1); +lst.insert(it, 99); // O(1) po znalezieniu miejsca + +// deque - szybki dostęp do obu końców +std::deque deq; +deq.push_front(1); // O(1) +deq.push_back(2); // O(1) +``` + +#### 1.2 Kontenery asocjacyjne (Associative Containers) + +Przechowują pary klucz-wartość, posortowane według klucza (drzewo czerwono-czarne). + +| Kontener | Klucze | Wartości | Złożoność | +|----------|--------|----------|-----------| +| `set` | Unikalne | Brak | O(log n) | +| `multiset` | Duplikaty OK | Brak | O(log n) | +| `map` | Unikalne | Tak | O(log n) | +| `multimap` | Duplikaty OK | Tak | O(log n) | + +```cpp +#include +#include + +// set - zbiór unikalnych, posortowanych elementów +std::set s = {3, 1, 4, 1, 5}; // {1, 3, 4, 5} - bez duplikatów +s.insert(2); // O(log n) +bool exists = s.count(3) > 0; // O(log n) + +// map - słownik klucz->wartość +std::map ages; +ages["Jan"] = 25; // O(log n) +ages["Anna"] = 30; +for (const auto& [name, age] : ages) { + std::cout << name << ": " << age << "\n"; // Posortowane alfabetycznie +} +``` + +#### 1.3 Kontenery asocjacyjne nieuporządkowane (Unordered Associative) + +Implementacja: tablica haszująca (hash table). + +| Kontener | Klucze | Wartości | Złożoność średnia | +|----------|--------|----------|-------------------| +| `unordered_set` | Unikalne | Brak | O(1) | +| `unordered_multiset` | Duplikaty OK | Brak | O(1) | +| `unordered_map` | Unikalne | Tak | O(1) | +| `unordered_multimap` | Duplikaty OK | Tak | O(1) | + +```cpp +#include +#include + +// unordered_map - szybsza od map dla dużych zbiorów +std::unordered_map umap; +umap["klucz"] = 42; // O(1) średnio +auto it = umap.find("klucz"); // O(1) średnio + +// unordered_set +std::unordered_set uset = {1, 2, 3}; +uset.insert(4); // O(1) średnio +``` + +#### 1.4 Adaptery kontenerów (Container Adapters) + +Interfejsy ograniczające funkcjonalność bazowego kontenera. + +| Adapter | Domyślny kontener | Operacje | +|---------|-------------------|----------| +| `stack` | deque | push, pop, top (LIFO) | +| `queue` | deque | push, pop, front (FIFO) | +| `priority_queue` | vector | push, pop, top (max-heap) | + +```cpp +#include +#include + +// stack - LIFO +std::stack stk; +stk.push(1); +stk.push(2); +stk.top(); // 2 +stk.pop(); // usuwa 2 + +// queue - FIFO +std::queue q; +q.push(1); +q.push(2); +q.front(); // 1 +q.pop(); // usuwa 1 + +// priority_queue - max-heap domyślnie +std::priority_queue pq; +pq.push(3); +pq.push(1); +pq.push(4); +pq.top(); // 4 (największy) +``` + +--- + +## 2. Iteratory (Iterators) + +### Definicja +**Iteratory** to uogólnione wskaźniki - abstrakcja umożliwiająca jednolity dostęp do elementów kontenerów. + +### Hierarchia iteratorów + +``` + Input Iterator Output Iterator + ↓ ↓ + Forward Iterator ←────────┘ + ↓ + Bidirectional Iterator + ↓ + Random Access Iterator + ↓ + Contiguous Iterator (C++17) +``` + +### Kategorie iteratorów + +| Kategoria | Operacje | Przykłady kontenerów | +|-----------|----------|---------------------| +| **Input** | `++`, `*`, `==`, `!=` | istream_iterator | +| **Output** | `++`, `*` (zapis) | ostream_iterator | +| **Forward** | Input + wielokrotne przejście | forward_list, unordered_* | +| **Bidirectional** | Forward + `--` | list, set, map | +| **Random Access** | Bidirectional + `+`, `-`, `[]`, `<` | vector, deque, array | +| **Contiguous** | Random + ciągła pamięć | vector, array, string | + +```cpp +#include +#include +#include + +std::vector vec = {1, 2, 3, 4, 5}; + +// Random access iterator +auto it = vec.begin(); +it += 3; // OK - random access +std::cout << *it; // 4 +std::cout << it[1]; // 5 + +std::list lst = {1, 2, 3, 4, 5}; + +// Bidirectional iterator +auto lit = lst.begin(); +++lit; // OK +--lit; // OK - bidirectional +// lit += 3; // BŁĄD! - brak random access + +// Pomocnicze funkcje +std::advance(lit, 3); // Działa dla każdego iteratora +auto dist = std::distance(lst.begin(), lst.end()); // 5 +``` + +### Iteratory specjalne + +```cpp +#include +#include +#include + +std::vector vec = {1, 2, 3}; + +// Iteratory wstawiające +std::vector dest; +std::copy(vec.begin(), vec.end(), std::back_inserter(dest)); // push_back + +// Iteratory strumieni +std::copy(vec.begin(), vec.end(), + std::ostream_iterator(std::cout, " ")); // wypisuje: 1 2 3 + +// Iteratory odwrotne +for (auto rit = vec.rbegin(); rit != vec.rend(); ++rit) { + std::cout << *rit << " "; // 3 2 1 +} +``` + +--- + +## 3. Algorytmy (Algorithms) + +### Definicja +**Algorytmy** to funkcje szablonowe operujące na zakresach (parach iteratorów). Są **oddzielone od kontenerów** - działają przez iteratory. + +### Kategorie algorytmów + +#### 3.1 Algorytmy niemodyfikujące + +```cpp +#include +#include + +std::vector vec = {1, 2, 3, 4, 5, 3}; + +// Wyszukiwanie +auto it = std::find(vec.begin(), vec.end(), 3); // pierwszy 3 +int cnt = std::count(vec.begin(), vec.end(), 3); // 2 +bool any = std::any_of(vec.begin(), vec.end(), + [](int x) { return x > 4; }); // true + +// Porównywanie +std::vector vec2 = {1, 2, 3, 4, 5, 3}; +bool eq = std::equal(vec.begin(), vec.end(), vec2.begin()); // true + +// Zliczanie +auto [min_it, max_it] = std::minmax_element(vec.begin(), vec.end()); +``` + +#### 3.2 Algorytmy modyfikujące + +```cpp +std::vector vec = {3, 1, 4, 1, 5, 9}; + +// Sortowanie +std::sort(vec.begin(), vec.end()); // {1, 1, 3, 4, 5, 9} +std::sort(vec.begin(), vec.end(), std::greater<>()); // malejąco + +// Przekształcanie +std::transform(vec.begin(), vec.end(), vec.begin(), + [](int x) { return x * 2; }); // podwojenie + +// Usuwanie (erase-remove idiom) +vec.erase(std::remove(vec.begin(), vec.end(), 1), vec.end()); + +// Wypełnianie +std::fill(vec.begin(), vec.end(), 0); +std::iota(vec.begin(), vec.end(), 1); // {1, 2, 3, ...} + +// Kopiowanie +std::vector dest(vec.size()); +std::copy(vec.begin(), vec.end(), dest.begin()); +``` + +#### 3.3 Algorytmy partycjonujące i sortujące + +```cpp +std::vector vec = {3, 1, 4, 1, 5, 9, 2, 6}; + +// Partycjonowanie +auto pivot = std::partition(vec.begin(), vec.end(), + [](int x) { return x < 5; }); +// Teraz: elementy < 5 | pivot | elementy >= 5 + +// Częściowe sortowanie +std::partial_sort(vec.begin(), vec.begin() + 3, vec.end()); +// Pierwsze 3 elementy posortowane, reszta nieokreślona + +// N-ty element +std::nth_element(vec.begin(), vec.begin() + 4, vec.end()); +// Element na pozycji 4 jest taki jak po pełnym sortowaniu + +// Sortowanie stabilne +std::stable_sort(vec.begin(), vec.end()); // zachowuje kolejność równych +``` + +#### 3.4 Algorytmy na zbiorach (posortowanych!) + +```cpp +std::vector a = {1, 2, 3, 4, 5}; +std::vector b = {3, 4, 5, 6, 7}; +std::vector result; + +// Suma zbiorów +std::set_union(a.begin(), a.end(), b.begin(), b.end(), + std::back_inserter(result)); // {1,2,3,4,5,6,7} + +// Przecięcie +result.clear(); +std::set_intersection(a.begin(), a.end(), b.begin(), b.end(), + std::back_inserter(result)); // {3,4,5} + +// Różnica +result.clear(); +std::set_difference(a.begin(), a.end(), b.begin(), b.end(), + std::back_inserter(result)); // {1,2} +``` + +#### 3.5 Algorytmy numeryczne (``) + +```cpp +#include + +std::vector vec = {1, 2, 3, 4, 5}; + +int sum = std::accumulate(vec.begin(), vec.end(), 0); // 15 +int product = std::accumulate(vec.begin(), vec.end(), 1, + std::multiplies<>()); // 120 + +// Iloczyn skalarny +std::vector a = {1, 2, 3}; +std::vector b = {4, 5, 6}; +int dot = std::inner_product(a.begin(), a.end(), b.begin(), 0); // 32 + +// Sumy częściowe +std::vector prefix(vec.size()); +std::partial_sum(vec.begin(), vec.end(), prefix.begin()); // {1,3,6,10,15} +``` + +--- + +## 4. Funktory (Function Objects / Functors) + +### Definicja +**Funktory** to obiekty, które można wywołać jak funkcje (mają operator `()`). Służą do parametryzacji algorytmów. + +### Rodzaje funktorów + +#### 4.1 Predefiniowane funktory (``) + +```cpp +#include +#include + +std::vector vec = {3, 1, 4, 1, 5}; + +// Funktory arytmetyczne +std::plus add; +int result = add(2, 3); // 5 + +// Funktory porównania +std::sort(vec.begin(), vec.end(), std::greater()); // malejąco +std::sort(vec.begin(), vec.end(), std::less()); // rosnąco + +// Funktory logiczne +std::logical_and land; +bool b = land(true, false); // false +``` + +#### 4.2 Wyrażenia lambda (C++11) + +```cpp +std::vector vec = {3, 1, 4, 1, 5, 9, 2, 6}; + +// Lambda jako predykat +auto it = std::find_if(vec.begin(), vec.end(), + [](int x) { return x > 5; }); + +// Lambda z przechwytywaniem +int threshold = 4; +int count = std::count_if(vec.begin(), vec.end(), + [threshold](int x) { return x > threshold; }); + +// Lambda modyfikująca (mutable) +int counter = 0; +std::for_each(vec.begin(), vec.end(), + [&counter](int x) { counter += x; }); + +// Generic lambda (C++14) +auto generic = [](auto x, auto y) { return x + y; }; +``` + +#### 4.3 std::function i std::bind + +```cpp +#include + +// std::function - uniwersalny wrapper na callable +std::function func = [](int a, int b) { return a + b; }; +func = std::plus(); +func = &free_function; + +// std::bind - częściowa aplikacja funkcji +auto add5 = std::bind(std::plus(), std::placeholders::_1, 5); +int result = add5(10); // 15 + +// std::bind z referencją +void modify(int& x) { x *= 2; } +int n = 5; +auto bound = std::bind(modify, std::ref(n)); +bound(); // n == 10 +``` + +--- + +## 📊 Wzajemne powiązania + +``` +┌───────────────────────────────────────────────────────────────────┐ +│ │ +│ KONTENERY ←──── ITERATORY ────→ ALGORYTMY ←──── FUNKTORY │ +│ │ │ │ │ │ +│ przechowują abstrakcja operują na parametryzują │ +│ dane dostępu zakresach algorytmy │ +│ │ │ │ │ │ +│ vector begin()/end() sort() less │ +│ map ++, *, == find() lambdy │ +│ set random/bidir transform() std::function │ +│ │ +└───────────────────────────────────────────────────────────────────┘ +``` + +### Kluczowa zasada: Ortogonalność + +**M kontenerów × N algorytmów = M + N implementacji** (nie M × N!) + +Dzięki iteratorom: +- Algorytm `sort` działa z `vector`, `deque`, `array` +- Każdy nowy kontener automatycznie współpracuje z istniejącymi algorytmami +- Każdy nowy algorytm automatycznie współpracuje z istniejącymi kontenerami + +--- + +## 🧠 Mnemoniki + +### "KIAF" dla kategorii STL: +- **K**ontenery - CO przechowujemy +- **I**teratory - JAK się poruszamy +- **A**lgorytmy - CO robimy z danymi +- **F**unktory - JAK parametryzujemy operacje + +### "VLDA" dla kontenerów sekwencyjnych: +- **V**ector - domyślny wybór, tablica dynamiczna +- **L**ist - szybkie wstawianie w środku +- **D**eque - szybki dostęp do obu końców +- **A**rray - stały rozmiar, na stosie + +### "SM-UM" dla asocjacyjnych: +- **S**et/**M**ap - posortowane (drzewo), O(log n) +- **U**nordered_**M**ap/set - hash, O(1) + +### "SQP" dla adapterów: +- **S**tack - LIFO (stos talerzy) +- **Q**ueue - FIFO (kolejka do kasy) +- **P**riority_queue - VIP (najważniejsi pierwsi) + +### "IOFBRC" dla iteratorów (od najsłabszego): +- **I**nput - tylko czytanie, jedno przejście +- **O**utput - tylko pisanie, jedno przejście +- **F**orward - wielokrotne przejście do przodu +- **B**idirectional - do przodu i do tyłu +- **R**andom - skok do dowolnego miejsca +- **C**ontiguous - ciągła pamięć + +--- + +## ❓ Możliwe pytania dodatkowe (follow-up) + +### Q1: "Kiedy użyć vector, a kiedy list?" + +**Odpowiedź:** + +| Kryterium | vector | list | +|-----------|--------|------| +| Dostęp losowy | O(1) ✓ | O(n) ✗ | +| Wstawianie na końcu | O(1) ✓ | O(1) ✓ | +| Wstawianie w środku | O(n) ✗ | O(1) ✓* | +| Cache-friendly | TAK ✓ | NIE ✗ | +| Pamięć | Mniej | Więcej (wskaźniki) | + +*po znalezieniu pozycji + +**Praktyczna zasada:** Używaj `vector` domyślnie. `list` tylko gdy: +- Bardzo częste wstawianie/usuwanie w środku +- Iteratory muszą pozostać ważne po modyfikacji +- Nigdy nie potrzebujesz dostępu losowego + +--- + +### Q2: "Czym się różni map od unordered_map?" + +**Odpowiedź:** + +| Cecha | map | unordered_map | +|-------|-----|---------------| +| Struktura | Drzewo RB | Hash table | +| Złożoność | O(log n) | O(1) średnio | +| Najgorszy przypadek | O(log n) | O(n) | +| Wymagania dla klucza | `operator<` | `hash`, `operator==` | +| Kolejność iteracji | Posortowana | Nieokreślona | +| Stabilność | Iteratory stabilne | Rehashing może unieważnić | + +**Kiedy co:** +- `map`: Potrzebujesz kolejności, mały zbiór, klucze trudne do hashowania +- `unordered_map`: Duży zbiór, najważniejsza szybkość, kolejność nieistotna + +--- + +### Q3: "Co to jest iterator invalidation?" + +**Odpowiedź:** + +**Iterator invalidation** = iterator przestaje wskazywać na ważny element po modyfikacji kontenera. + +| Kontener | push_back | insert | erase | +|----------|-----------|--------|-------| +| vector | Może (realloc) | Tak | Tak (od miejsca) | +| deque | Tak | Tak | Tak | +| list | Nie | Nie | Tylko usunięty | +| map/set | Nie | Nie | Tylko usunięty | +| unordered_* | Może (rehash) | Może (rehash) | Tylko usunięty | + +```cpp +std::vector vec = {1, 2, 3, 4, 5}; +auto it = vec.begin() + 2; + +vec.push_back(6); // it może być INVALID! +vec.insert(vec.begin(), 0); // it jest INVALID! + +// Bezpieczny sposób usuwania +for (auto it = vec.begin(); it != vec.end(); ) { + if (*it % 2 == 0) + it = vec.erase(it); // erase zwraca następny ważny iterator + else + ++it; +} +``` + +--- + +### Q4: "Jak działa erase-remove idiom?" + +**Odpowiedź:** + +`std::remove` **nie usuwa** elementów - tylko przesuwa "dobre" na początek i zwraca iterator do "końca" dobrych. + +```cpp +std::vector vec = {1, 2, 3, 2, 4, 2, 5}; + +// BEZ idiomu +// std::remove zwraca iterator do nowego "końca" +auto new_end = std::remove(vec.begin(), vec.end(), 2); +// vec = {1, 3, 4, 5, ?, ?, ?} - stary rozmiar! +// ^new_end + +// Z idiomem +vec.erase(new_end, vec.end()); // usuń "śmieci" +// vec = {1, 3, 4, 5} + +// Jednolinijkowo +vec.erase(std::remove(vec.begin(), vec.end(), 2), vec.end()); + +// C++20: std::erase (wreszcie!) +std::erase(vec, 2); +``` + +--- + +### Q5: "Co to są zakresy (ranges) w C++20?" + +**Odpowiedź:** + +**Ranges** to ewolucja STL - algorytmy przyjmują kontener zamiast pary iteratorów. + +```cpp +#include +#include +#include + +std::vector vec = {5, 3, 1, 4, 2}; + +// C++17 (klasyczne) +std::sort(vec.begin(), vec.end()); + +// C++20 (ranges) +std::ranges::sort(vec); + +// Widoki (views) - leniwe, kompozowalne +auto result = vec + | std::views::filter([](int x) { return x % 2 == 0; }) + | std::views::transform([](int x) { return x * 2; }) + | std::views::take(3); + +// Pipeline - nie kopiuje, leniwe obliczenia +for (int x : result) { + std::cout << x << " "; +} +``` + +--- + +### Q6: "Jaka jest złożoność pamięciowa kontenerów?" + +**Odpowiedź:** + +| Kontener | Pamięć na element | Narzut całkowity | +|----------|-------------------|------------------| +| `array` | sizeof(T) | 0 | +| `vector` | sizeof(T) | 3 wskaźniki + capacity | +| `list` | sizeof(T) + 2 wskaźniki | 1 wskaźnik (head) | +| `forward_list` | sizeof(T) + 1 wskaźnik | 1 wskaźnik | +| `deque` | sizeof(T) | Mapa bloków | +| `set` | sizeof(T) + 3 wsk. + kolor | Root + size | +| `unordered_set` | sizeof(T) + wskaźnik | Bucket array | + +**Praktyka:** `vector` jest najbardziej cache-friendly (ciągła pamięć). + +--- + +## 🎯 Kluczowe punkty do zapamiętania + +1. **4 kategorie:** Kontenery, Iteratory, Algorytmy, Funktory +2. **Ortogonalność:** M kontenerów + N algorytmów = M + N implementacji +3. **vector domyślnie:** Najlepszy cache, wystarczający dla 90% przypadków +4. **Iteratory łączą:** Abstrakcja między kontenerami a algorytmami +5. **Lambda > funktory:** Czytelniejsze, nowocześniejsze +6. **Ranges (C++20):** Przyszłość STL - leniwe, kompozowalne + +--- + +## 📖 Źródła do pogłębienia + +1. Josuttis - "The C++ Standard Library" +2. Meyers - "Effective STL" +3. cppreference.com - dokumentacja STL +4. Stepanov - "Elements of Programming" diff --git a/pytania/odpowiedzi/06-reużywalność-kodu-oop.md b/pytania/odpowiedzi/06-reużywalność-kodu-oop.md new file mode 100644 index 0000000..850cea8 --- /dev/null +++ b/pytania/odpowiedzi/06-reużywalność-kodu-oop.md @@ -0,0 +1,777 @@ +# Pytanie 6: Metody reużywalności kodu w językach obiektowych + +## Pytanie +**"Omówić metody reużywalności kodu i struktur danych w obiektowych językach programowania."** + +Przedmiot: PROI (Programowanie Obiektowe) + +--- + +## 📚 Odpowiedź główna + +### Wprowadzenie + +**Reużywalność kodu (code reuse)** to fundamentalna zasada inżynierii oprogramowania - "nie wynajduj koła na nowo". W programowaniu obiektowym mamy kilka mechanizmów umożliwiających wielokrotne wykorzystanie kodu. + +### Główne metody reużywalności + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ METODY REUŻYWALNOŚCI │ +├─────────────────┬─────────────────┬─────────────────────────────┤ +│ DZIEDZICZENIE │ KOMPOZYCJA │ PROGRAMOWANIE │ +│ (Inheritance) │ (Composition) │ GENERYCZNE │ +├─────────────────┼─────────────────┼─────────────────────────────┤ +│ INTERFEJSY │ DELEGACJA │ BIBLIOTEKI │ +│ (Interfaces) │ (Delegation) │ (Libraries) │ +├─────────────────┼─────────────────┼─────────────────────────────┤ +│ MIXINY │ TRAITY │ WZORCE PROJEKTOWE │ +│ (Mixins) │ (Traits) │ (Design Patterns) │ +└─────────────────┴─────────────────┴─────────────────────────────┘ +``` + +--- + +## 1. Dziedziczenie (Inheritance) + +### Definicja +**Dziedziczenie** to mechanizm, w którym klasa pochodna (child) przejmuje atrybuty i metody klasy bazowej (parent). + +### Typy dziedziczenia + +| Typ | Opis | Języki | +|-----|------|--------| +| **Pojedyncze** | Jedna klasa bazowa | Java, C# | +| **Wielokrotne** | Wiele klas bazowych | C++, Python | +| **Wielopoziomowe** | A → B → C | Wszystkie | +| **Hierarchiczne** | A → B, A → C | Wszystkie | + +### Przykład (C++) + +```cpp +// Klasa bazowa +class Pojazd { +protected: + std::string marka; + int predkosc; + +public: + Pojazd(const std::string& m) : marka(m), predkosc(0) {} + + virtual void jedz() { + std::cout << marka << " jedzie " << predkosc << " km/h\n"; + } + + virtual ~Pojazd() = default; +}; + +// Klasa pochodna - dziedziczy i rozszerza +class Samochod : public Pojazd { +private: + int liczbaDrzwi; + +public: + Samochod(const std::string& m, int drzwi) + : Pojazd(m), liczbaDrzwi(drzwi) {} + + void jedz() override { + predkosc = 120; + Pojazd::jedz(); // wywołanie metody bazowej + std::cout << "Drzwi: " << liczbaDrzwi << "\n"; + } + + void parkuj() { /* nowa metoda */ } +}; + +// Użycie +Samochod auto1("BMW", 4); +auto1.jedz(); // Polimorfizm - wywołuje Samochod::jedz() +``` + +### Zalety i wady dziedziczenia + +| Zalety | Wady | +|--------|------| +| Naturalne modelowanie hierarchii | Silne wiązanie (tight coupling) | +| Polimorfizm | Problem kruchej klasy bazowej | +| Łatwe rozszerzanie | Problemy z wielodziedziczeniem (diamond) | +| Współdzielenie implementacji | Narusza enkapsulację | + +### Problem diamentu (Diamond Problem) + +``` + A + / \ + B C + \ / + D +``` + +```cpp +class A { public: void metoda() {} }; +class B : public A {}; +class C : public A {}; +class D : public B, public C {}; // Która A::metoda()? + +D d; +// d.metoda(); // BŁĄD: niejednoznaczne! +d.B::metoda(); // OK - jawne wskazanie +``` + +**Rozwiązanie w C++:** Dziedziczenie wirtualne +```cpp +class B : virtual public A {}; +class C : virtual public A {}; +class D : public B, public C {}; // Jedna kopia A +``` + +--- + +## 2. Kompozycja (Composition) + +### Definicja +**Kompozycja** to budowanie złożonych obiektów z prostszych komponentów. Relacja "zawiera" (has-a) zamiast "jest" (is-a). + +### Zasada: "Favor composition over inheritance" + +```cpp +// ZŁE - dziedziczenie +class Stack : public std::vector { + // Stack NIE JEST wektorem! + // Użytkownik może wywołać insert(), erase()... +}; + +// DOBRE - kompozycja +class Stack { +private: + std::vector elements; // Stack ZAWIERA wektor + +public: + void push(int x) { elements.push_back(x); } + int pop() { + int top = elements.back(); + elements.pop_back(); + return top; + } + bool empty() const { return elements.empty(); } + // Tylko te metody, które mają sens dla stosu +}; +``` + +### Typy relacji obiektowych + +| Relacja | Siła | Cykl życia | Przykład | +|---------|------|------------|----------| +| **Kompozycja** | Silna | Zależny (owns) | Samochód → Silnik | +| **Agregacja** | Słaba | Niezależny (uses) | Uniwersytet → Student | +| **Asocjacja** | Luźna | Niezależny | Klient ↔ Zamówienie | + +```cpp +// Kompozycja - silnik "umiera" z samochodem +class Samochod { +private: + Silnik silnik; // Obiekt wewnętrzny +public: + Samochod() : silnik() {} // Tworzy silnik + // ~Samochod() niszczy silnik automatycznie +}; + +// Agregacja - student istnieje niezależnie od uniwersytetu +class Uniwersytet { +private: + std::vector studenci; // Wskaźniki/referencje +public: + void dodajStudenta(Student* s) { studenci.push_back(s); } + // ~Uniwersytet() NIE niszczy studentów +}; +``` + +--- + +## 3. Programowanie generyczne (Generic Programming) + +### Definicja +**Programowanie generyczne** to pisanie kodu niezależnego od konkretnych typów danych, używając szablonów (templates) lub generyków. + +### Szablony w C++ + +```cpp +// Szablon funkcji +template +T maximum(T a, T b) { + return (a > b) ? a : b; +} + +// Użycie - kompilator generuje wersje dla każdego typu +int m1 = maximum(3, 5); // int +double m2 = maximum(3.14, 2.71); // double +std::string m3 = maximum("abc", "xyz"); // string + +// Szablon klasy +template +class Array { +private: + T data[N]; +public: + T& operator[](size_t i) { return data[i]; } + constexpr size_t size() const { return N; } +}; + +Array arr; // Tablica 10 intów +Array darr; // Tablica 5 double'i +``` + +### Generyki w Java/C# + +```java +// Java +public class Box { + private T value; + + public void set(T value) { this.value = value; } + public T get() { return value; } +} + +// Ograniczenia typów (bounded type parameters) +public > T max(T a, T b) { + return a.compareTo(b) > 0 ? a : b; +} +``` + +```csharp +// C# +public class Repository where T : class, IEntity, new() { + public T Create() => new T(); + public void Save(T entity) { /* ... */ } +} +``` + +### Zalety programowania generycznego + +| Zaleta | Opis | +|--------|------| +| **Type safety** | Błędy wykrywane w czasie kompilacji | +| **Brak duplikacji** | Jeden kod dla wielu typów | +| **Wydajność** | C++: specjalizacja w kompilacji, brak rzutowania | +| **Czytelność** | Jawne wymagania typów | + +--- + +## 4. Interfejsy (Interfaces) + +### Definicja +**Interfejs** definiuje kontrakt (zestaw metod), który klasa musi zaimplementować. Oddziela "co" od "jak". + +### Przykład + +```java +// Java - interfejs +public interface Drawable { + void draw(); + default void clear() { /* domyślna implementacja */ } +} + +public interface Resizable { + void resize(int width, int height); +} + +// Klasa implementuje wiele interfejsów +public class Rectangle implements Drawable, Resizable { + @Override + public void draw() { /* implementacja */ } + + @Override + public void resize(int w, int h) { /* implementacja */ } +} +``` + +```cpp +// C++ - klasa abstrakcyjna jako interfejs +class IDrawable { +public: + virtual void draw() = 0; // Pure virtual + virtual ~IDrawable() = default; +}; + +class IResizable { +public: + virtual void resize(int w, int h) = 0; + virtual ~IResizable() = default; +}; + +class Rectangle : public IDrawable, public IResizable { +public: + void draw() override { /* ... */ } + void resize(int w, int h) override { /* ... */ } +}; +``` + +### Interfejsy vs Klasy abstrakcyjne + +| Cecha | Interfejs | Klasa abstrakcyjna | +|-------|-----------|-------------------| +| Wielodziedziczenie | TAK | NIE (Java/C#) | +| Pola | NIE (do Java 8) | TAK | +| Konstruktor | NIE | TAK | +| Implementacja metod | default (Java 8+) | TAK | +| Cel | Definiuje kontrakt | Współdzieli implementację | + +--- + +## 5. Delegacja (Delegation) + +### Definicja +**Delegacja** to przekazywanie odpowiedzialności za wykonanie operacji do innego obiektu. + +```cpp +// Bez delegacji - dziedziczenie +class LoggingList : public std::list { +public: + void push_back(int x) { + log("Adding: " + std::to_string(x)); + std::list::push_back(x); + } +}; + +// Z delegacją - kompozycja +class LoggingList { +private: + std::list delegate; // Delegat + +public: + void push_back(int x) { + log("Adding: " + std::to_string(x)); + delegate.push_back(x); // Delegacja + } + + size_t size() const { + return delegate.size(); // Delegacja + } +}; +``` + +### Wzorzec strategii (Strategy Pattern) + +```cpp +// Interfejs strategii +class SortStrategy { +public: + virtual void sort(std::vector& data) = 0; + virtual ~SortStrategy() = default; +}; + +class QuickSort : public SortStrategy { +public: + void sort(std::vector& data) override { /* quicksort */ } +}; + +class MergeSort : public SortStrategy { +public: + void sort(std::vector& data) override { /* mergesort */ } +}; + +// Kontekst deleguje sortowanie do strategii +class Sorter { +private: + std::unique_ptr strategy; + +public: + void setStrategy(std::unique_ptr s) { + strategy = std::move(s); + } + + void performSort(std::vector& data) { + strategy->sort(data); // Delegacja + } +}; +``` + +--- + +## 6. Mixiny i Traity + +### Mixiny (Mixins) +Klasy dostarczające funkcjonalność do "wmieszania" do innych klas. + +```python +# Python - mixiny przez wielodziedziczenie +class JSONSerializableMixin: + def to_json(self): + import json + return json.dumps(self.__dict__) + +class XMLSerializableMixin: + def to_xml(self): + # implementacja... + pass + +class User(JSONSerializableMixin, XMLSerializableMixin): + def __init__(self, name, email): + self.name = name + self.email = email + +user = User("Jan", "jan@example.com") +print(user.to_json()) # {"name": "Jan", "email": "jan@example.com"} +``` + +### Traity (Traits) + +```rust +// Rust - traits +trait Drawable { + fn draw(&self); +} + +trait Movable { + fn move_to(&mut self, x: i32, y: i32); +} + +struct Circle { + x: i32, + y: i32, + radius: i32, +} + +impl Drawable for Circle { + fn draw(&self) { /* ... */ } +} + +impl Movable for Circle { + fn move_to(&mut self, x: i32, y: i32) { + self.x = x; + self.y = y; + } +} +``` + +```php +// PHP - traits +trait Timestampable { + public $createdAt; + public $updatedAt; + + public function touch() { + $this->updatedAt = new DateTime(); + } +} + +trait SoftDeletable { + public $deletedAt; + + public function softDelete() { + $this->deletedAt = new DateTime(); + } +} + +class Article { + use Timestampable, SoftDeletable; + + public $title; +} +``` + +--- + +## 7. Biblioteki i frameworki + +### Poziomy reużywalności + +``` +┌─────────────────────────────────────────────────────┐ +│ FRAMEWORK │ +│ (IoC, definiuje architekturę aplikacji) │ +├─────────────────────────────────────────────────────┤ +│ BIBLIOTEKA │ +│ (kolekcja klas/funkcji, wywołujesz Ty) │ +├─────────────────────────────────────────────────────┤ +│ MODUŁ/PAKIET │ +│ (logicznie powiązane klasy) │ +├─────────────────────────────────────────────────────┤ +│ KLASA │ +│ (jednostka enkapsulacji) │ +├─────────────────────────────────────────────────────┤ +│ FUNKCJA │ +│ (najmniejsza jednostka reużywalna) │ +└─────────────────────────────────────────────────────┘ +``` + +### Przykłady + +| Poziom | Przykłady | +|--------|-----------| +| Framework | Spring, .NET, Unity, Django | +| Biblioteka | STL, Boost, jQuery, NumPy | +| Moduł | java.util, System.IO | +| Klasa | ArrayList, HttpClient | + +--- + +## 8. Wzorce projektowe (Design Patterns) + +### Wzorce wspierające reużywalność + +| Wzorzec | Typ | Cel | +|---------|-----|-----| +| **Factory Method** | Kreacyjny | Delegacja tworzenia obiektów | +| **Abstract Factory** | Kreacyjny | Rodziny powiązanych obiektów | +| **Prototype** | Kreacyjny | Klonowanie obiektów | +| **Adapter** | Strukturalny | Dopasowanie interfejsów | +| **Decorator** | Strukturalny | Dynamiczne rozszerzanie | +| **Strategy** | Behawioralny | Wymienne algorytmy | +| **Template Method** | Behawioralny | Szkielet algorytmu z krokami | + +### Przykład: Template Method + +```cpp +// Szkielet algorytmu w klasie bazowej +class DataParser { +public: + // Template method - definiuje szkielet + void parse(const std::string& data) { + openFile(); + readHeader(); + processData(data); // Krok abstrakcyjny + closeFile(); + } + +protected: + virtual void openFile() { /* domyślna impl */ } + virtual void readHeader() { /* domyślna impl */ } + virtual void processData(const std::string& data) = 0; // PURE + virtual void closeFile() { /* domyślna impl */ } +}; + +// Konkretne implementacje +class JSONParser : public DataParser { +protected: + void processData(const std::string& data) override { + // Parsowanie JSON + } +}; + +class XMLParser : public DataParser { +protected: + void processData(const std::string& data) override { + // Parsowanie XML + } +}; +``` + +--- + +## 📊 Porównanie metod reużywalności + +| Metoda | Wiązanie | Elastyczność | Złożoność | +|--------|----------|--------------|-----------| +| Dziedziczenie | Statyczne | Niska | Średnia | +| Kompozycja | Dynamiczne | Wysoka | Niska | +| Interfejsy | Statyczne* | Wysoka | Niska | +| Generyki | Statyczne | Wysoka | Średnia | +| Delegacja | Dynamiczne | Wysoka | Średnia | +| Mixiny/Traity | Statyczne | Średnia | Średnia | + +*ale implementacja może być dynamiczna (polimorfizm) + +--- + +## 🧠 Mnemoniki + +### "SOLID" - zasady dobrego OOP: +- **S**ingle Responsibility - jedna odpowiedzialność +- **O**pen/Closed - otwarte na rozszerzenia, zamknięte na modyfikacje +- **L**iskov Substitution - podtyp zastępuje typ bazowy +- **I**nterface Segregation - wiele małych interfejsów > jeden duży +- **D**ependency Inversion - zależność od abstrakcji, nie konkretu + +### "HAS-A przed IS-A": +- **HAS-A** = kompozycja (Samochód HAS-A Silnik) +- **IS-A** = dziedziczenie (Samochód IS-A Pojazd) +- Preferuj HAS-A! + +### "DRIED" dla reużywalności: +- **D**on't **R**epeat - nie powtarzaj kodu +- **I**nterfaces - definiuj kontrakty +- **E**ncapsulate - ukrywaj szczegóły +- **D**elegate - przekazuj odpowiedzialność + +### "GIT" dla generyków: +- **G**eneric - niezależne od typu +- **I**nvariant - sprawdzane w kompilacji +- **T**ype-safe - bezpieczne typowanie + +--- + +## ❓ Możliwe pytania dodatkowe (follow-up) + +### Q1: "Kiedy dziedziczenie, a kiedy kompozycja?" + +**Odpowiedź:** + +| Użyj dziedziczenia gdy: | Użyj kompozycji gdy: | +|------------------------|---------------------| +| Relacja "jest" (is-a) | Relacja "zawiera" (has-a) | +| Potrzebujesz polimorfizmu | Potrzebujesz elastyczności | +| Klasa pochodna JEST typem bazowym | Chcesz zmieniać zachowanie w runtime | +| Zasada Liskov jest spełniona | Chcesz uniknąć problemów z hierarchią | + +**Przykład decyzji:** +- Ptak IS-A Zwierzę → dziedziczenie OK +- Samochód HAS-A Silnik → kompozycja! +- Stack IS-A Vector? → NIE! Kompozycja. + +--- + +### Q2: "Co to jest zasada substytucji Liskov?" + +**Odpowiedź:** + +> "Obiekty klasy bazowej powinny być zastępowalne obiektami klas pochodnych bez zmiany poprawności programu." + +**Naruszenie LSP:** +```cpp +class Rectangle { +public: + virtual void setWidth(int w) { width = w; } + virtual void setHeight(int h) { height = h; } + int area() { return width * height; } +protected: + int width, height; +}; + +class Square : public Rectangle { // PROBLEM! +public: + void setWidth(int w) override { width = height = w; } + void setHeight(int h) override { width = height = h; } +}; + +// Kod klienta +void resize(Rectangle& r) { + r.setWidth(5); + r.setHeight(10); + assert(r.area() == 50); // FAIL dla Square! +} +``` + +**Rozwiązanie:** Kwadrat nie powinien dziedziczyć po prostokącie (matematycznie IS-A, programistycznie NIE). + +--- + +### Q3: "Czym różnią się szablony C++ od generyków Java?" + +**Odpowiedź:** + +| Cecha | C++ Templates | Java Generics | +|-------|---------------|---------------| +| Implementacja | Kompilacja (code generation) | Type erasure (runtime) | +| Specjalizacja | TAK | NIE | +| Prymitywy | TAK (int, double...) | NIE (tylko obiekty) | +| Sprawdzanie typu | W czasie instancjacji | W czasie kompilacji | +| Ograniczenia | Concepts (C++20) | Bounded types | +| Wydajność | Optymalna | Rzutowanie w runtime | + +```cpp +// C++ - specjalizacja szablonu +template +class Container { /* ogólna implementacja */ }; + +template<> +class Container { /* specjalna dla bool - bitset */ }; +``` + +--- + +### Q4: "Co to jest Dependency Injection?" + +**Odpowiedź:** + +**Dependency Injection (DI)** = wzorzec przekazywania zależności z zewnątrz zamiast tworzenia ich wewnątrz. + +```cpp +// BEZ DI - silne wiązanie +class OrderService { +private: + MySQLDatabase db; // Zależność "zahardkodowana" +public: + OrderService() : db() {} +}; + +// Z DI - luźne wiązanie +class OrderService { +private: + IDatabase& db; // Zależność od abstrakcji +public: + OrderService(IDatabase& database) : db(database) {} // Injection +}; + +// Użycie +MySQLDatabase mysql; +PostgresDatabase postgres; + +OrderService service1(mysql); // Możemy łatwo zmienić +OrderService service2(postgres); // implementację +``` + +**Typy DI:** +1. Constructor Injection (preferowany) +2. Setter Injection +3. Interface Injection + +--- + +### Q5: "Jak wzorce projektowe wspierają reużywalność?" + +**Odpowiedź:** + +| Wzorzec | Mechanizm reużywalności | +|---------|------------------------| +| **Factory** | Oddziela tworzenie od użycia | +| **Strategy** | Wymienna rodzina algorytmów | +| **Decorator** | Dynamiczne dodawanie funkcji | +| **Adapter** | Reużycie niekompatybilnych klas | +| **Template Method** | Reużycie szkieletu algorytmu | +| **Composite** | Jednolite traktowanie obiektów i kolekcji | + +--- + +### Q6: "Wyjaśnij różnicę między agregacją a kompozycją" + +**Odpowiedź:** + +| Cecha | Kompozycja | Agregacja | +|-------|------------|-----------| +| Siła związku | Silna ("owns") | Słaba ("uses") | +| Cykl życia | Zależny | Niezależny | +| UML | Wypełniony romb ◆ | Pusty romb ◇ | +| Przykład | Samochód → Silnik | Firma → Pracownik | + +```cpp +// Kompozycja - silnik jest częścią samochodu +class Car { + Engine engine; // Engine tworzony z Car, niszczony z Car +}; + +// Agregacja - pracownik może istnieć bez firmy +class Company { + std::vector employees; // Wskaźniki - nie "posiada" +}; +``` + +--- + +## 🎯 Kluczowe punkty do zapamiętania + +1. **Kompozycja > Dziedziczenie** - elastyczność, luźne wiązanie +2. **Interfejsy oddzielają** kontrakt od implementacji +3. **Generyki eliminują** duplikację kodu dla różnych typów +4. **SOLID** - 5 zasad dobrego OOP +5. **Delegacja** - przekazuj odpowiedzialność +6. **Wzorce projektowe** - sprawdzone rozwiązania typowych problemów + +--- + +## 📖 Źródła do pogłębienia + +1. Gamma et al. - "Design Patterns: Elements of Reusable OO Software" (GoF) +2. Martin, R. - "Clean Code" i "Clean Architecture" +3. Meyers, S. - "Effective C++" +4. Bloch, J. - "Effective Java" diff --git a/pytania/odpowiedzi/07-dns-serwery-caching.md b/pytania/odpowiedzi/07-dns-serwery-caching.md new file mode 100644 index 0000000..176d217 --- /dev/null +++ b/pytania/odpowiedzi/07-dns-serwery-caching.md @@ -0,0 +1,426 @@ +# Pytanie 7: Serwery DNS i buforowanie zapytań + +## Pytanie +**"Które serwery DNS najwięcej zyskują dzięki buforowaniu zapytań (caching) w serwerach rekursywnych? Jakie znasz rodzaje serwerów DNS?"** + +Przedmiot: SKM (Sieci Komputerowe) + +--- + +## 📚 Odpowiedź główna + +### Wprowadzenie do DNS + +**DNS (Domain Name System)** to hierarchiczny, rozproszony system tłumaczenia nazw domenowych na adresy IP (i odwrotnie). + +``` +www.example.com → 93.184.216.34 +``` + +### Hierarchia DNS + +``` + . (root) + /|\ + / | \ + com org pl + /|\ | + / | \ | + google amazon pw + | | + www elka +``` + +--- + +## 1. Rodzaje serwerów DNS + +### 1.1 Serwery autorytatywne (Authoritative) + +**Definicja:** Przechowują oryginalne rekordy DNS dla danej domeny. Są "źródłem prawdy". + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ SERWERY AUTORYTATYWNE │ +├─────────────────────────────────────────────────────────────────┤ +│ ROOT SERVERS (.) - 13 klastrów (a.root-servers.net ... m.) │ +│ ↓ │ +│ TLD SERVERS (.com, .org, .pl) - zarządzane przez rejestry │ +│ ↓ │ +│ AUTHORITATIVE NS - serwery konkretnych domen (ns1.example.com)│ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### Root Servers (Serwery główne) +- **13 logicznych serwerów:** a.root-servers.net do m.root-servers.net +- **Fizycznie:** Setki serwerów (anycast) +- **Funkcja:** Wskazują serwery TLD + +#### TLD Servers (Top-Level Domain) +- **gTLD:** .com, .org, .net (generic) +- **ccTLD:** .pl, .de, .uk (country code) +- **Nowe gTLD:** .shop, .app, .xyz +- **Funkcja:** Wskazują autoryzacyjne NS domen + +#### Authoritative Name Servers +- **Primary (Master):** Oryginalne rekordy, edytowalne +- **Secondary (Slave):** Kopie przez transfer stref (AXFR/IXFR) +- **Funkcja:** Odpowiadają na zapytania o konkretną domenę + +### 1.2 Serwery rekursywne (Recursive Resolvers) + +**Definicja:** Wykonują pełne rozwiązywanie nazw w imieniu klienta, pytając kolejno serwery autorytatywne. + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ SERWERY REKURSYWNE │ +├─────────────────────────────────────────────────────────────────┤ +│ ISP Resolvers - dostarczane przez dostawcę Internetu │ +│ Public Resolvers - Google (8.8.8.8), Cloudflare (1.1.1.1) │ +│ Enterprise Resolvers - wewnętrzne serwery firmowe │ +│ Local Resolvers - np. router domowy, Pi-hole │ +└─────────────────────────────────────────────────────────────────┘ +``` + +### 1.3 Stub Resolvers (Resolwery klienckie) + +**Definicja:** Prosty klient DNS w systemie operacyjnym. Wysyła zapytanie do rekursywnego resolvera i czeka na odpowiedź. + +- Windows: usługa DNS Client +- Linux: libc resolver (nsswitch.conf, resolv.conf) +- Nie wykonuje rekurencji sam + +### 1.4 Forwarding Servers (Przekazujące) + +**Definicja:** Przyjmują zapytania i przekazują je do innego resolvera zamiast samodzielnie rozwiązywać. + +``` +Klient → Forwarder → Recursive Resolver → Authoritative +``` + +--- + +## 2. Proces rozwiązywania DNS (Resolution) + +### Zapytanie rekursywne vs iteracyjne + +``` +ZAPYTANIE REKURSYWNE (klient → resolver): +"Daj mi odpowiedź na www.example.com" +→ Resolver musi zwrócić ostateczną odpowiedź lub błąd + +ZAPYTANIE ITERACYJNE (resolver → authoritative): +"Co wiesz o www.example.com?" +→ Serwer zwraca odpowiedź lub odesłanie (referral) +``` + +### Pełny proces rozwiązywania + +``` +Klient Recursive Root .com TLD example.com + │ Resolver │ │ │ + │──(1) www.example.com?──→│ │ │ │ + │ │──(2) query?───→│ │ │ + │ │←─(3) refer .com┘ │ │ + │ │──(4) query?────────────────→│ │ + │ │←─(5) refer example.com─────┘ │ + │ │──(6) query?─────────────────────────────→│ + │ │←─(7) 93.184.216.34──────────────────────┘ + │←─(8) 93.184.216.34─────┘ + │ │ + │ [CACHE zapisuje wszystkie odpowiedzi] +``` + +--- + +## 3. Buforowanie (Caching) w DNS + +### Jak działa caching? + +1. **Resolver otrzymuje odpowiedź** z serwera autorytatywnego +2. **Zapisuje w cache** wraz z TTL (Time To Live) +3. **Przy kolejnym zapytaniu** o tę samą nazwę - zwraca z cache +4. **Po wygaśnięciu TTL** - pyta ponownie serwer autorytatywny + +### TTL (Time To Live) + +``` +; Fragment strefy DNS +www.example.com. 300 IN A 93.184.216.34 + ↑ + TTL = 300 sekund (5 minut) +``` + +| Typowe TTL | Zastosowanie | +|------------|--------------| +| 60-300 s | Dynamiczne usługi, failover | +| 3600 s (1h) | Standardowe strony | +| 86400 s (24h) | Stabilne serwisy | +| 604800 s (7d) | Rzadko zmieniane | + +--- + +## 4. Które serwery zyskują najwięcej na cachingu? + +### 🏆 Odpowiedź: **ROOT SERVERS i TLD SERVERS** + +### Dlaczego root servers zyskują najwięcej? + +``` +BEZ CACHINGU: +┌────────────────────────────────────────────────────────────────┐ +│ Każde zapytanie DNS → najpierw pytanie do root server │ +│ Miliardy zapytań dziennie → root servers byłyby przeciążone! │ +└────────────────────────────────────────────────────────────────┘ + +Z CACHINGIEM: +┌────────────────────────────────────────────────────────────────┐ +│ Resolver pyta root server RAZ o serwery .com │ +│ Cache przechowuje referral przez długi czas (np. 48h) │ +│ Kolejne tysiące zapytań o .com → z cache, bez root │ +└────────────────────────────────────────────────────────────────┘ +``` + +### Analiza ilościowa + +| Poziom | Liczba domen | Zapytania bez cache | Z cache | +|--------|--------------|---------------------|---------| +| **Root** | 1 (.) | ~100% zapytań | ~0.01% | +| **TLD** | ~1500 | ~100% zapytań | ~0.1% | +| **Authoritative** | Miliony | Proporcjonalnie | Zależne od TTL | + +### Dlaczego ROOT i TLD zyskują więcej niż authoritative? + +1. **Mniejsza liczba = więcej zapytań na serwer:** + - 13 root servers vs miliony domen + - Każde zapytanie o DOWOLNĄ domenę musi przejść przez root i TLD + +2. **Długie TTL referrali:** + - Root NS referrals: TTL 48h - 7 dni + - TLD NS referrals: TTL 24h - 48h + - Authoritative records: często krótsze (minuty-godziny) + +3. **Hierarchiczna struktura:** + ``` + Zapytanie o www.google.com: + - Root: "Oto serwery .com" → cached + - TLD: "Oto serwery google.com" → cached + - Auth: "Oto IP www.google.com" → cached (ale krótszy TTL) + + Zapytanie o www.facebook.com: + - Root: z cache! ✓ + - TLD: z cache! ✓ (ten sam .com) + - Auth: trzeba pytać (inna domena) + ``` + +### Podsumowanie zysków z cachingu + +``` +REDUKCJA RUCHU DZIĘKI CACHINGOWI: + +Root Servers: ████████████████████████████░░ ~99.9% redukcja +TLD Servers: ██████████████████████████░░░░ ~99% redukcja +Authoritative: ████████████░░░░░░░░░░░░░░░░░░ ~50-90% redukcja* + +*zależy od TTL i popularności domeny +``` + +--- + +## 5. Typy rekordów DNS + +| Rekord | Przeznaczenie | Przykład | +|--------|---------------|----------| +| **A** | IPv4 address | www → 93.184.216.34 | +| **AAAA** | IPv6 address | www → 2606:2800:220:1:... | +| **CNAME** | Alias (canonical name) | blog → www.example.com | +| **MX** | Mail server | @ → 10 mail.example.com | +| **NS** | Name server | @ → ns1.example.com | +| **TXT** | Tekst (SPF, DKIM) | @ → "v=spf1 ..." | +| **SOA** | Start of Authority | Metadata strefy | +| **PTR** | Reverse DNS | IP → nazwa | +| **SRV** | Service location | _sip._tcp → server:5060 | + +--- + +## 📊 Tabela porównawcza serwerów DNS + +| Typ serwera | Funkcja | Cache | Autorytatywny | +|-------------|---------|-------|---------------| +| **Root** | Wskazuje TLD | Nie | Tak (dla .) | +| **TLD** | Wskazuje NS domen | Nie | Tak (dla TLD) | +| **Authoritative** | Przechowuje rekordy | Nie | Tak | +| **Recursive** | Rozwiązuje dla klientów | **TAK** | Nie | +| **Forwarder** | Przekazuje zapytania | Może | Nie | +| **Stub** | Klient systemu | Minimalny | Nie | + +--- + +## 🧠 Mnemoniki + +### "RATS" dla hierarchii DNS: +- **R**oot - korzeń drzewa +- **A**uthoritative TLD - .com, .pl... +- **T**arget NS - ns1.example.com +- **S**tub resolver - klient + +### "ROOT COOL" dla zysków z cache: +- **ROOT** = **C**ache **O**ffers **O**verwhelming **L**oad reduction +- Root servers byłyby przeciążone bez cache w resolverach + +### "TRIP" dla procesu rozwiązywania: +- **T**ranslate - tłumaczenie nazwy na IP +- **R**ecursive - resolver robi pracę +- **I**terative - serwery autorytatywne odpowiadają lub odsyłają +- **P**ersist - cache przechowuje wynik + +### "A-QUAD" dla popularnych rekordów: +- **A** - Address (IPv4) +- **AAAA** - Address (IPv6) - 4×A +- **D**NS - NS record + +--- + +## ❓ Możliwe pytania dodatkowe (follow-up) + +### Q1: "Jak działa anycast w kontekście root servers?" + +**Odpowiedź:** + +**Anycast** = ten sam adres IP na wielu serwerach geograficznie rozproszonych. + +``` +Użytkownik w Polsce → najbliższy serwer a.root-servers.net (Frankfurt) +Użytkownik w USA → najbliższy serwer a.root-servers.net (Virginia) +Użytkownik w Japonii → najbliższy serwer a.root-servers.net (Tokyo) + +Wszystkie mają ten sam adres IP! +Routing BGP kieruje do najbliższego. +``` + +**Korzyści:** +- Niższe opóźnienia (latency) +- Odporność na DDoS +- Load balancing geograficzny + +--- + +### Q2: "Co to jest DNS poisoning/spoofing?" + +**Odpowiedź:** + +**DNS Cache Poisoning** = atak polegający na wstrzyknięciu fałszywych rekordów do cache resolvera. + +``` +Atakujący → fałszywa odpowiedź "google.com = 1.2.3.4" + ↓ +Resolver zapisuje w cache + ↓ +Użytkownicy kierowani na serwer atakującego +``` + +**Zabezpieczenia:** +- **DNSSEC** - podpisy kryptograficzne rekordów +- **Randomizacja portów źródłowych** +- **0x20 encoding** - randomizacja wielkości liter +- **DNS over HTTPS (DoH)** / **DNS over TLS (DoT)** + +--- + +### Q3: "Co to jest DNSSEC?" + +**Odpowiedź:** + +**DNSSEC (DNS Security Extensions)** = rozszerzenie dodające kryptograficzne podpisy do rekordów DNS. + +**Nowe typy rekordów:** +- **RRSIG** - podpis rekordu +- **DNSKEY** - klucz publiczny +- **DS** - delegacja bezpieczeństwa (u rodzica) +- **NSEC/NSEC3** - dowód nieistnienia + +**Łańcuch zaufania:** +``` +Root (.) → podpisuje DS dla .com +.com → podpisuje DS dla example.com +example.com → podpisuje A dla www +``` + +--- + +### Q4: "Czym różni się DNS over HTTPS od DNS over TLS?" + +**Odpowiedź:** + +| Cecha | DoT (DNS over TLS) | DoH (DNS over HTTPS) | +|-------|-------------------|---------------------| +| Port | 853 (dedykowany) | 443 (jak HTTPS) | +| Protokół | TLS | HTTPS | +| Widoczność | Łatwy do zablokowania | Trudny do odróżnienia | +| Format | Wire format DNS | Wire lub JSON | +| Klient | Systemowy resolver | Przeglądarka/aplikacja | + +**DoH** jest trudniejszy do blokowania/monitorowania - wygląda jak normalny ruch HTTPS. + +--- + +### Q5: "Co się stanie, jeśli wszystkie root servers przestaną działać?" + +**Odpowiedź:** + +**Krótkoterminowo (godziny):** Większość działa dzięki cache +- Resolwery mają w cache adresy TLD servers +- TTL root referrals: ~48h + +**Średnioterminowo (dni):** Stopniowa degradacja +- Cache wygasa +- Nowe domeny nierozwiązywalne +- Istniejące z długim TTL jeszcze działają + +**W praktyce:** Niemożliwe do osiągnięcia +- 13 klastrów anycast +- Setki fizycznych serwerów +- Geograficzne rozproszenie +- Różni operatorzy + +--- + +### Q6: "Jak działa Negative Caching?" + +**Odpowiedź:** + +**Negative caching** = cache'owanie odpowiedzi "nie istnieje" (NXDOMAIN). + +``` +Zapytanie: nieistniejaca.example.com +Odpowiedź: NXDOMAIN (SOA z TTL dla negative cache) +Cache: "nieistniejaca.example.com = NXDOMAIN" przez TTL +``` + +**Korzyści:** +- Redukcja ruchu przy literówkach +- Szybsza odpowiedź dla nieistniejących domen +- Ochrona przed niektórymi atakami + +**RFC 2308** definiuje negative caching. + +--- + +## 🎯 Kluczowe punkty do zapamiętania + +1. **ROOT i TLD zyskują NAJWIĘCEJ** na cachingu w resolverach +2. **Recursive resolver** = wykonuje pełne rozwiązywanie + cache +3. **Authoritative** = źródło prawdy, nie cache'uje +4. **Hierarchia:** Root → TLD → Authoritative NS +5. **TTL** określa czas życia rekordu w cache +6. **Anycast** pozwala 13 root serwerom obsługiwać cały Internet + +--- + +## 📖 Źródła do pogłębienia + +1. RFC 1034, 1035 - DNS specification +2. RFC 2308 - Negative caching +3. RFC 4033-4035 - DNSSEC +4. Cricket Liu - "DNS and BIND" +5. root-servers.org - informacje o root servers diff --git a/pytania/odpowiedzi/08-tcp-three-way-handshake.md b/pytania/odpowiedzi/08-tcp-three-way-handshake.md new file mode 100644 index 0000000..1ef2fd2 --- /dev/null +++ b/pytania/odpowiedzi/08-tcp-three-way-handshake.md @@ -0,0 +1,433 @@ +# Pytanie 8: TCP Three-Way Handshake + +## Pytanie +**"Jaki jest cel uzgadniania trójetapowego (three way handshake) w protokole TCP? Jaka jest interpretacja numerów sekwencyjnych i potwierdzenia? Jaka jest wartość początkowa numeru sekwencyjnego?"** + +Przedmiot: SKM (Sieci Komputerowe) + +--- + +## 📚 Odpowiedź główna + +### Wprowadzenie do TCP + +**TCP (Transmission Control Protocol)** to protokół warstwy transportowej zapewniający: +- Niezawodne dostarczanie danych +- Kontrolę przepływu +- Kontrolę przeciążenia +- Połączeniowość (connection-oriented) + +--- + +## 1. Three-Way Handshake - cel i przebieg + +### Cele uzgadniania trójetapowego + +1. **Nawiązanie połączenia** - obie strony zgadzają się na komunikację +2. **Synchronizacja numerów sekwencyjnych** - ISN (Initial Sequence Number) +3. **Uzgodnienie parametrów** - MSS, Window Scale, SACK, Timestamps +4. **Weryfikacja dostępności** - obie strony są aktywne i gotowe + +### Przebieg (diagram) + +``` + Klient Serwer + │ │ + │ (1) SYN, seq=x │ + │──────────────────────────────────────────→│ + │ │ + │ (2) SYN+ACK, seq=y, ack=x+1 │ + │←──────────────────────────────────────────│ + │ │ + │ (3) ACK, seq=x+1, ack=y+1 │ + │──────────────────────────────────────────→│ + │ │ + │ [POŁĄCZENIE NAWIĄZANE] │ + │ │ +``` + +### Szczegółowy opis kroków + +#### Krok 1: SYN (Synchronize) +``` +Klient → Serwer: +┌────────────────────────────────────────┐ +│ Flaga: SYN = 1 │ +│ Sequence Number: x (ISN klienta) │ +│ Acknowledgment Number: 0 (nieistotny) │ +│ Opcje: MSS, Window Scale, SACK, etc. │ +└────────────────────────────────────────┘ +``` +- Klient inicjuje połączenie +- Wysyła swój ISN (Initial Sequence Number) +- Stan klienta: SYN_SENT + +#### Krok 2: SYN-ACK (Synchronize-Acknowledge) +``` +Serwer → Klient: +┌────────────────────────────────────────┐ +│ Flagi: SYN = 1, ACK = 1 │ +│ Sequence Number: y (ISN serwera) │ +│ Acknowledgment Number: x + 1 │ +│ Opcje: MSS, Window Scale, etc. │ +└────────────────────────────────────────┘ +``` +- Serwer potwierdza otrzymanie SYN (ACK = x+1) +- Serwer wysyła swój ISN +- Stan serwera: SYN_RECEIVED + +#### Krok 3: ACK (Acknowledge) +``` +Klient → Serwer: +┌────────────────────────────────────────┐ +│ Flaga: ACK = 1 │ +│ Sequence Number: x + 1 │ +│ Acknowledgment Number: y + 1 │ +└────────────────────────────────────────┘ +``` +- Klient potwierdza otrzymanie SYN serwera +- Połączenie nawiązane (ESTABLISHED) +- Może zawierać już dane (TCP Fast Open) + +--- + +## 2. Numery sekwencyjne (Sequence Numbers) + +### Interpretacja + +**Sequence Number (SEQ)** = numer pierwszego bajtu danych w segmencie + +``` +Strumień danych: +Bajty: [0][1][2][3][4][5][6][7][8][9][10][11][12]... + +Segment 1: SEQ=0, dane = bajty 0-4 (5 bajtów) +Segment 2: SEQ=5, dane = bajty 5-9 (5 bajtów) +Segment 3: SEQ=10, dane = bajty 10-12 (3 bajty) +``` + +### Funkcje numerów sekwencyjnych + +| Funkcja | Opis | +|---------|------| +| **Kolejność** | Odbiorca składa segmenty we właściwej kolejności | +| **Wykrywanie duplikatów** | Ten sam SEQ = duplikat | +| **Wykrywanie braków** | Luka w SEQ = brakujący segment | +| **Potwierdzanie** | ACK wskazuje oczekiwany następny SEQ | + +### Przykład transmisji + +``` +Klient (ISN=1000) Serwer (ISN=5000) + │ │ + │ SEQ=1000, "Hello" (5 bytes) │ + │────────────────────────────────────→│ + │ │ + │ SEQ=5000, ACK=1005, "Hi" (2 bytes) │ + │←────────────────────────────────────│ + │ │ + │ SEQ=1005, ACK=5002, "World" (5 b) │ + │────────────────────────────────────→│ + │ │ +``` + +--- + +## 3. Numery potwierdzenia (Acknowledgment Numbers) + +### Interpretacja + +**Acknowledgment Number (ACK)** = numer **następnego oczekiwanego** bajtu + +``` +ACK = ostatni_otrzymany_SEQ + liczba_otrzymanych_bajtów +``` + +### Kumulatywne potwierdzenia + +TCP używa **cumulative ACK** - potwierdza wszystkie bajty do danego numeru: + +``` +Otrzymano: SEQ=100 (10 bajtów), SEQ=110 (10 bajtów) +ACK = 120 (potwierdza bajty 100-119) + +Otrzymano: SEQ=100 (10 bajtów), BRAK SEQ=110, SEQ=120 (10 bajtów) +ACK = 110 (nie można potwierdzić 120, bo brakuje 110-119!) +``` + +### Selective ACK (SACK) + +Opcja TCP pozwalająca potwierdzać niesąsiednie bloki: + +``` +Otrzymano: SEQ=100, BRAK SEQ=110, SEQ=120 +ACK = 110 +SACK: [120-130] ← "mam też te bajty" +``` + +--- + +## 4. Wartość początkowa numeru sekwencyjnego (ISN) + +### Dlaczego ISN nie zaczyna od 0? + +1. **Bezpieczeństwo** - przewidywalny ISN umożliwia ataki (TCP hijacking) +2. **Unikanie kolizji** - stare segmenty z poprzednich połączeń nie będą mylone z nowymi + +### Generowanie ISN + +#### Historycznie (RFC 793): +``` +ISN = (4 mikrosekundy timer) mod 2^32 +``` +Zwiększany o 1 co 4μs → pełny cykl co ~4.55 godziny + +#### Współcześnie (RFC 6528): +``` +ISN = M + F(localhost, localport, remotehost, remoteport, secretkey) +``` +Gdzie: +- **M** = timer (jak wyżej) +- **F** = funkcja kryptograficzna (MD5/SHA) +- **secretkey** = tajny klucz serwera + +### Właściwości dobrego ISN + +| Właściwość | Powód | +|------------|-------| +| **Losowy** | Utrudnia ataki typu sequence prediction | +| **Unikalny** | Różny dla każdego połączenia | +| **Monotonicznie rosnący** | Unikanie kolizji z poprzednimi połączeniami | + +### Zakres numerów sekwencyjnych + +``` +SEQ: 32 bity → zakres 0 do 4,294,967,295 (2^32 - 1) + +Przy szybkości 1 Gbps: +- 125 MB/s danych +- Przepełnienie (wrap-around) co ~34 sekundy! + +Rozwiązanie: PAWS (Protection Against Wrapped Sequences) +- Używa opcji Timestamp do rozróżniania "starych" i "nowych" numerów +``` + +--- + +## 5. Stany połączenia TCP + +``` + ┌─────────────┐ + ┌────────→│ CLOSED │←────────┐ + │ └─────────────┘ │ + │ │ │ + (timeout) (passive open) (active open) + │ ↓ │ + │ ┌─────────────┐ │ + │ │ LISTEN │ │ + │ └─────────────┘ │ + │ │ │ + │ (recv SYN) (send SYN) + │ ↓ ↓ + ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ + │ TIME_WAIT │ │ SYN_RECEIVED│ │ SYN_SENT │ + └─────────────┘ └─────────────┘ └─────────────┘ + ↑ │ │ + (recv FIN+ACK) (send SYN+ACK) (recv SYN+ACK) + │ ↓ ↓ + ┌─────────────┐ ┌─────────────────────────────┐ + │ FIN_WAIT_2 │ │ ESTABLISHED │ + └─────────────┘ └─────────────────────────────┘ +``` + +--- + +## 6. Zamykanie połączenia (Four-Way Handshake) + +``` + Klient Serwer + │ │ + │ (1) FIN, seq=u │ + │──────────────────────────────────────────→│ + │ │ + │ (2) ACK, ack=u+1 │ + │←──────────────────────────────────────────│ + │ │ + │ (serwer może jeszcze wysyłać dane) │ + │ │ + │ (3) FIN, seq=v │ + │←──────────────────────────────────────────│ + │ │ + │ (4) ACK, ack=v+1 │ + │──────────────────────────────────────────→│ + │ │ + │ [TIME_WAIT: 2×MSL] │ + │ │ +``` + +**MSL (Maximum Segment Lifetime)** = maksymalny czas życia segmentu (~2 minuty) +**TIME_WAIT = 2×MSL** = ~4 minuty (oczekiwanie na zagubione segmenty) + +--- + +## 📊 Podsumowanie Three-Way Handshake + +| Krok | Kierunek | Flagi | SEQ | ACK | Cel | +|------|----------|-------|-----|-----|-----| +| 1 | C→S | SYN | x | - | Inicjacja, ISN klienta | +| 2 | S→C | SYN+ACK | y | x+1 | Akceptacja, ISN serwera | +| 3 | C→S | ACK | x+1 | y+1 | Potwierdzenie, połączenie gotowe | + +--- + +## 🧠 Mnemoniki + +### "SYN-SYN/ACK-ACK" - trzy kroki: +- **SYN** - "Chcę rozmawiać" (klient) +- **SYN/ACK** - "OK, ja też" (serwer) +- **ACK** - "Super, zaczynamy" (klient) + +### "SEQ = Sent, ACK = Expected": +- **SEQ**uence = numer wysyłanego bajtu +- **ACK**nowledgment = numer oczekiwanego bajtu + +### "ISN = Initial Secret Number": +- **I**nitial - początkowy +- **S**ecret - losowy dla bezpieczeństwa +- **N**umber - 32-bitowa liczba + +### "ESTABLISHED po trzech krokach": +- 1: SYN_SENT +- 2: SYN_RECEIVED +- 3: **ESTABLISHED** (obie strony) + +--- + +## ❓ Możliwe pytania dodatkowe (follow-up) + +### Q1: "Dlaczego trzy kroki, nie dwa?" + +**Odpowiedź:** + +Dwa kroki nie wystarczą do synchronizacji **obu** ISN: + +``` +Dwa kroki (hipotetycznie): +Klient: SYN, seq=x → Serwer zna ISN klienta +Serwer: SYN+ACK, seq=y → Klient zna ISN serwera + → Ale serwer NIE WIE, czy klient otrzymał y! + +Trzy kroki: +Klient: SYN, seq=x → Serwer zna ISN klienta +Serwer: SYN+ACK, seq=y → Klient zna ISN serwera +Klient: ACK, ack=y+1 → Serwer WIE, że klient otrzymał y ✓ +``` + +--- + +### Q2: "Co to jest SYN flood attack?" + +**Odpowiedź:** + +**SYN flood** = atak DoS wysyłający masę SYN bez dokończenia handshake'a. + +``` +Atakujący: SYN, SYN, SYN, SYN... (tysiące) +Serwer: SYN+ACK, SYN+ACK... (czeka na ACK) + → Kolejka half-open connections pełna + → Serwer nie może przyjąć nowych połączeń +``` + +**Obrona:** +- **SYN cookies** - serwer nie przechowuje stanu, koduje go w ISN +- **Zwiększenie kolejki SYN** +- **Zmniejszenie timeout SYN_RECEIVED** +- **Firewall/IDS** + +--- + +### Q3: "Co to jest TCP Fast Open (TFO)?" + +**Odpowiedź:** + +**TFO** pozwala wysyłać dane już w pierwszym SYN (0-RTT): + +``` +Standardowo: TFO: +SYN → SYN + dane → + ← SYN+ACK ← SYN+ACK + dane +ACK + dane → ACK → + +3 RTT do danych 1 RTT do danych! +``` + +**Wymaga:** Cookie TFO z poprzedniego połączenia (uzyskany przy pierwszym handshake). + +--- + +### Q4: "Jak działa retransmisja w TCP?" + +**Odpowiedź:** + +1. **Timeout (RTO):** Brak ACK w określonym czasie → retransmisja +2. **Fast Retransmit:** 3 duplikaty ACK → retransmisja bez czekania na timeout + +``` +Wysłano: SEQ=100, SEQ=200, SEQ=300 +Zgubiono: SEQ=200 + +Odbiorca: ACK=200, ACK=200, ACK=200 (3× duplikat) +Nadawca: "Ah, brakuje 200!" → retransmisja SEQ=200 +``` + +--- + +### Q5: "Co oznacza flaga RST?" + +**Odpowiedź:** + +**RST (Reset)** = natychmiastowe przerwanie połączenia. + +**Kiedy wysyłane:** +- Segment do zamkniętego portu +- Segment do nieistniejącego połączenia +- Połączenie w nieprawidłowym stanie +- Aplikacja chce natychmiast zamknąć (bez FIN handshake) + +``` +RST nie wymaga potwierdzenia - połączenie natychmiast zamknięte. +``` + +--- + +### Q6: "Wyjaśnij opcje negocjowane podczas handshake" + +**Odpowiedź:** + +| Opcja | Opis | Wartość typowa | +|-------|------|----------------| +| **MSS** | Maximum Segment Size | 1460 (Ethernet) | +| **Window Scale** | Mnożnik okna (>65535) | 0-14 (×2^n) | +| **SACK Permitted** | Selective ACK dozwolone | tak/nie | +| **Timestamp** | Pomiar RTT, PAWS | 32-bit timer | +| **NOP** | Padding | - | + +--- + +## 🎯 Kluczowe punkty do zapamiętania + +1. **3 kroki:** SYN → SYN+ACK → ACK +2. **SEQ** = numer pierwszego bajtu w segmencie +3. **ACK** = numer **następnego oczekiwanego** bajtu +4. **ISN** = losowy, dla bezpieczeństwa i unikania kolizji +5. **Zamknięcie:** 4 kroki (FIN → ACK → FIN → ACK) + TIME_WAIT +6. **SYN flood** - atak DoS, obrona: SYN cookies + +--- + +## 📖 Źródła do pogłębienia + +1. RFC 793 - TCP Specification +2. RFC 6528 - Defending Against Sequence Number Attacks +3. RFC 7413 - TCP Fast Open +4. Stevens - "TCP/IP Illustrated, Volume 1" diff --git a/pytania/odpowiedzi/09-procesy-watki.md b/pytania/odpowiedzi/09-procesy-watki.md new file mode 100644 index 0000000..a842c60 --- /dev/null +++ b/pytania/odpowiedzi/09-procesy-watki.md @@ -0,0 +1,673 @@ +# Pytanie 9: Procesy i wątki w systemie operacyjnym + +## Pytanie +**"Procesy i wątki w systemie operacyjnym. Omówić budowę, szybkość działania i zakres zastosowania. Przedstawić problemy i możliwości komunikacji i synchronizacji."** + +Przedmiot: SOI (Systemy Operacyjne) + +--- + +## 📚 Odpowiedź główna + +### Wprowadzenie + +**Proces** i **wątek** to podstawowe jednostki wykonania w systemach operacyjnych. Różnią się poziomem izolacji i kosztami przełączania. + +--- + +## 1. Proces (Process) + +### Definicja +**Proces** = program w trakcie wykonania + jego kontekst (zasoby, stan). + +### Budowa procesu + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ PRZESTRZEŃ ADRESOWA PROCESU │ +├─────────────────────────────────────────────────────────────────┤ +│ ┌─────────────────┐ │ +│ │ STOS │ ← zmienne lokalne, adresy powrotu │ +│ │ (Stack) │ rośnie w dół ↓ │ +│ ├─────────────────┤ │ +│ │ ↓ │ │ +│ │ │ ← wolna przestrzeń │ +│ │ ↑ │ │ +│ ├─────────────────┤ │ +│ │ STERTA │ ← pamięć dynamiczna (malloc/new) │ +│ │ (Heap) │ rośnie w górę ↑ │ +│ ├─────────────────┤ │ +│ │ BSS │ ← zmienne globalne niezainicjowane │ +│ ├─────────────────┤ │ +│ │ DATA │ ← zmienne globalne zainicjowane │ +│ ├─────────────────┤ │ +│ │ TEXT │ ← kod programu (read-only) │ +│ │ (Code) │ │ +│ └─────────────────┘ │ +└─────────────────────────────────────────────────────────────────┘ +``` + +### PCB (Process Control Block) + +Struktura w jądrze przechowująca informacje o procesie: + +| Pole | Opis | +|------|------| +| **PID** | Identyfikator procesu | +| **Stan** | Running, Ready, Blocked, etc. | +| **Rejestry CPU** | PC, SP, flagi, rejestry ogólne | +| **Informacje o pamięci** | Tablice stron, limity | +| **Informacje I/O** | Otwarte pliki, urządzenia | +| **Informacje rozliczeniowe** | Czas CPU, limity | +| **Priorytet** | Szeregowanie | +| **Wskaźniki** | Rodzic, dzieci, kolejki | + +### Stany procesu + +``` + ┌──────────────────┐ + (utworzenie) │ │ (zakończenie) + ↓ │ │ ↓ + ┌─────────┐ │ ┌──────────┐ │ ┌──────────┐ + │ NEW │───┼──→│ READY │←──┼──│TERMINATED│ + └─────────┘ │ └──────────┘ │ └──────────┘ + │ ↑↓ │ + │ (scheduler) │ + │ ↓↑ │ + │ ┌──────────┐ │ + │ │ RUNNING │ │ + │ └──────────┘ │ + │ │ │ + │ (I/O, wait) │ + │ ↓ │ + │ ┌──────────┐ │ + └───│ BLOCKED │───┘ + └──────────┘ +``` + +--- + +## 2. Wątek (Thread) + +### Definicja +**Wątek** = lekka jednostka wykonania współdzieląca przestrzeń adresową procesu. + +### Budowa wątku + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ PROCES │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ WSPÓŁDZIELONE: PRYWATNE (per wątek): │ +│ ┌─────────────────┐ ┌───────┐ ┌───────┐ ┌───────┐ │ +│ │ Przestrzeń │ │ Stos │ │ Stos │ │ Stos │ │ +│ │ adresowa │ │ W1 │ │ W2 │ │ W3 │ │ +│ ├─────────────────┤ ├───────┤ ├───────┤ ├───────┤ │ +│ │ Kod (TEXT) │ │Rejestry│ │Rejestry│ │Rejestry│ │ +│ ├─────────────────┤ │ CPU │ │ CPU │ │ CPU │ │ +│ │ Dane globalne │ ├───────┤ ├───────┤ ├───────┤ │ +│ ├─────────────────┤ │ PC │ │ PC │ │ PC │ │ +│ │ Sterta (Heap) │ ├───────┤ ├───────┤ ├───────┤ │ +│ ├─────────────────┤ │ TID │ │ TID │ │ TID │ │ +│ │ Otwarte pliki │ └───────┘ └───────┘ └───────┘ │ +│ │ Sygnały │ Wątek 1 Wątek 2 Wątek 3 │ +│ └─────────────────┘ │ +│ │ +└─────────────────────────────────────────────────────────────────┘ +``` + +### TCB (Thread Control Block) + +| Pole | Opis | +|------|------| +| **TID** | Identyfikator wątku | +| **Stan** | Running, Ready, Blocked | +| **Rejestry** | PC, SP, rejestry ogólne | +| **Stos** | Wskaźnik do prywatnego stosu | +| **Priorytet** | Szeregowanie | +| **Wskaźnik do PCB** | Proces macierzysty | + +--- + +## 3. Porównanie: Proces vs Wątek + +### Tabela porównawcza + +| Cecha | Proces | Wątek | +|-------|--------|-------| +| **Przestrzeń adresowa** | Własna, izolowana | Współdzielona z procesem | +| **Tworzenie** | Wolne (~ms) | Szybkie (~μs) | +| **Przełączanie kontekstu** | Wolne (TLB flush) | Szybkie (tylko rejestry) | +| **Komunikacja** | IPC (pipe, socket, shm) | Bezpośrednia (współdzielona pamięć) | +| **Izolacja** | Pełna | Brak (awaria = awaria procesu) | +| **Zasoby** | Własne | Współdzielone | +| **Wieloprocesorowość** | Naturalna | Wymaga synchronizacji | + +### Koszty czasowe (typowe) + +| Operacja | Czas | +|----------|------| +| Tworzenie procesu | 1-10 ms | +| Tworzenie wątku | 10-100 μs | +| Przełączanie procesu | 1-10 μs | +| Przełączanie wątku | 0.1-1 μs | +| Komunikacja IPC | 1-100 μs | +| Współdzielona pamięć | 10-100 ns | + +--- + +## 4. Typy wątków + +### Wątki użytkownika (User-level Threads) + +``` +┌─────────────────────────────────────────┐ +│ PRZESTRZEŃ UŻYTKOWNIKA │ +│ ┌─────────────────────────────────┐ │ +│ │ Biblioteka wątków (pthread) │ │ +│ │ ┌─────┐ ┌─────┐ ┌─────┐ │ │ +│ │ │ W1 │ │ W2 │ │ W3 │ │ │ +│ │ └─────┘ └─────┘ └─────┘ │ │ +│ └─────────────────────────────────┘ │ +├─────────────────────────────────────────┤ +│ JĄDRO │ +│ Widzi tylko JEDEN wątek (proces) │ +└─────────────────────────────────────────┘ +``` + +**Zalety:** Szybkie przełączanie, przenośność +**Wady:** Blokujące wywołanie blokuje wszystkie wątki, brak prawdziwej równoległości + +### Wątki jądra (Kernel-level Threads) + +``` +┌─────────────────────────────────────────┐ +│ PRZESTRZEŃ UŻYTKOWNIKA │ +│ ┌─────┐ ┌─────┐ ┌─────┐ │ +│ │ W1 │ │ W2 │ │ W3 │ │ +│ └──┬──┘ └──┬──┘ └──┬──┘ │ +├─────────┼───────┼───────┼───────────────┤ +│ ↓ ↓ ↓ │ +│ ┌─────────────────────────────┐ │ +│ │ JĄDRO (scheduler) │ │ +│ │ Zarządza wszystkimi wątkami│ │ +│ └─────────────────────────────┘ │ +└─────────────────────────────────────────┘ +``` + +**Zalety:** Prawdziwa równoległość, blokada jednego nie blokuje innych +**Wady:** Wolniejsze operacje (wywołanie systemowe) + +### Modele mapowania + +| Model | Opis | Przykłady | +|-------|------|-----------| +| **1:1** | 1 wątek user = 1 wątek kernel | Linux, Windows | +| **N:1** | N wątków user = 1 wątek kernel | Green threads | +| **M:N** | M wątków user = N wątków kernel | Solaris, Go goroutines | + +--- + +## 5. Komunikacja między procesami (IPC) + +### Mechanizmy IPC + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ MECHANIZMY IPC │ +├─────────────────┬─────────────────┬─────────────────────────────┤ +│ SYGNAŁY │ POTOKI │ PAMIĘĆ WSPÓŁDZIELONA │ +│ (Signals) │ (Pipes) │ (Shared Memory) │ +├─────────────────┼─────────────────┼─────────────────────────────┤ +│ KOLEJKI │ GNIAZDA │ PLIKI MAPOWANE │ +│ KOMUNIKATÓW │ (Sockets) │ (Memory-mapped) │ +│ (Msg Queues) │ │ │ +└─────────────────┴─────────────────┴─────────────────────────────┘ +``` + +### Szczegóły mechanizmów + +#### Potoki (Pipes) + +```c +// Potok nienazwany (anonimowy) +int fd[2]; +pipe(fd); +// fd[0] - odczyt, fd[1] - zapis + +// Potok nazwany (FIFO) +mkfifo("/tmp/myfifo", 0666); +``` + +**Cechy:** Jednokierunkowe, FIFO, między powiązanymi procesami (anonimowe) + +#### Pamięć współdzielona (Shared Memory) + +```c +// POSIX shared memory +int fd = shm_open("/my_shm", O_CREAT | O_RDWR, 0666); +ftruncate(fd, SIZE); +void* ptr = mmap(NULL, SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); + +// Użycie +strcpy(ptr, "Hello from process A"); +// Proces B może odczytać przez ten sam shm_open +``` + +**Cechy:** Najszybszy IPC, wymaga synchronizacji! + +#### Gniazda (Sockets) + +```c +// Unix domain socket (lokalne) +int sock = socket(AF_UNIX, SOCK_STREAM, 0); + +// Network socket (sieciowe) +int sock = socket(AF_INET, SOCK_STREAM, 0); +``` + +**Cechy:** Uniwersalne, lokalne i sieciowe, dwukierunkowe + +#### Kolejki komunikatów (Message Queues) + +```c +// POSIX message queue +mqd_t mq = mq_open("/my_queue", O_CREAT | O_RDWR, 0666, &attr); +mq_send(mq, message, strlen(message), priority); +mq_receive(mq, buffer, MAX_SIZE, &priority); +``` + +**Cechy:** Asynchroniczne, z priorytetami, zachowują granice wiadomości + +--- + +## 6. Synchronizacja + +### Problemy współbieżności + +#### 1. Wyścig (Race Condition) + +```c +// Dwa wątki wykonują: +counter++; // NIE ATOMOWE! + +// W asemblerze: +// LOAD counter → reg +// ADD 1 → reg +// STORE reg → counter + +// Możliwy przebieg: +// Wątek A: LOAD (counter=5) +// Wątek B: LOAD (counter=5) +// Wątek A: ADD (reg=6) +// Wątek B: ADD (reg=6) +// Wątek A: STORE (counter=6) +// Wątek B: STORE (counter=6) +// Wynik: 6 zamiast 7! +``` + +#### 2. Zakleszczenie (Deadlock) + +``` +Wątek A: lock(mutex1) → czeka na mutex2 +Wątek B: lock(mutex2) → czeka na mutex1 + +→ DEADLOCK! (wzajemne oczekiwanie) +``` + +**Warunki Coffmana (wszystkie muszą być spełnione):** +1. **Mutual exclusion** - zasób może mieć tylko jeden właściciel +2. **Hold and wait** - trzymaj i czekaj na więcej +3. **No preemption** - nie można odebrać zasobu +4. **Circular wait** - cykliczne oczekiwanie + +#### 3. Głodzenie (Starvation) + +Proces nigdy nie dostaje zasobu, bo inni mają wyższy priorytet. + +#### 4. Inwersja priorytetów (Priority Inversion) + +Proces o niskim priorytecie blokuje proces o wysokim priorytecie (przez mutex). + +--- + +### Mechanizmy synchronizacji + +#### Mutex (Mutual Exclusion) + +```c +pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; + +pthread_mutex_lock(&mutex); +// Sekcja krytyczna +counter++; +pthread_mutex_unlock(&mutex); +``` + +#### Semafor (Semaphore) + +```c +sem_t sem; +sem_init(&sem, 0, 3); // Wartość początkowa 3 + +sem_wait(&sem); // P() - dekrementuj, blokuj jeśli 0 +// Sekcja krytyczna +sem_post(&sem); // V() - inkrementuj +``` + +**Typy:** +- **Binarny** (0/1) - jak mutex +- **Licznikowy** - ogranicza liczbę wątków (np. pula połączeń) + +#### Zmienna warunkowa (Condition Variable) + +```c +pthread_mutex_t mutex; +pthread_cond_t cond; + +// Producent +pthread_mutex_lock(&mutex); +buffer[in] = item; +pthread_cond_signal(&cond); // Obudź czekającego +pthread_mutex_unlock(&mutex); + +// Konsument +pthread_mutex_lock(&mutex); +while (buffer_empty) { + pthread_cond_wait(&cond, &mutex); // Zwalnia mutex i czeka +} +item = buffer[out]; +pthread_mutex_unlock(&mutex); +``` + +#### Bariera (Barrier) + +```c +pthread_barrier_t barrier; +pthread_barrier_init(&barrier, NULL, NUM_THREADS); + +// W każdym wątku: +// ... obliczenia ... +pthread_barrier_wait(&barrier); // Czekaj na wszystkich +// ... dalsze obliczenia ... +``` + +#### Read-Write Lock + +```c +pthread_rwlock_t rwlock; + +// Czytelnik +pthread_rwlock_rdlock(&rwlock); // Wielu może czytać +// ... czytanie ... +pthread_rwlock_unlock(&rwlock); + +// Pisarz +pthread_rwlock_wrlock(&rwlock); // Wyłączny dostęp +// ... pisanie ... +pthread_rwlock_unlock(&rwlock); +``` + +--- + +## 📊 Porównanie mechanizmów synchronizacji + +| Mechanizm | Blokujący | Użycie | Koszt | +|-----------|-----------|--------|-------| +| **Mutex** | Tak | Sekcja krytyczna | Niski | +| **Spinlock** | Tak (aktywne) | Krótkie sekcje, SMP | Bardzo niski* | +| **Semafor** | Tak | Ograniczanie zasobów | Niski | +| **Cond. var.** | Tak | Oczekiwanie na warunek | Niski | +| **Bariera** | Tak | Synchronizacja fazowa | Średni | +| **RW Lock** | Tak | Wielu czytelników | Średni | +| **Atomics** | Nie | Proste operacje | Najniższy | + +*jeśli sekcja krytyczna krótka + +--- + +## 7. Zastosowania + +### Kiedy procesy? + +- **Izolacja** - awaria jednego nie wpływa na inne +- **Bezpieczeństwo** - różne uprawnienia +- **Różne języki/technologie** - mikrousługi +- **Niezawodność** - restart bez wpływu na system + +**Przykłady:** Serwery WWW (fork), przeglądarki (proces per tab), bazy danych + +### Kiedy wątki? + +- **Współdzielenie danych** - bez kopiowania +- **Responsywność** - UI thread + worker threads +- **Równoległość CPU** - obliczenia na wielu rdzeniach +- **I/O asynchroniczne** - czekanie nie blokuje wszystkiego + +**Przykłady:** Gry, serwery aplikacji, przetwarzanie obrazu/wideo + +--- + +## 🧠 Mnemoniki + +### "PEST" dla różnic Proces-wątek: +- **P**amięć - proces ma własną, wątek współdzieli +- **E**fektywność - wątek szybszy +- **S**ynchronizacja - wątki wymagają więcej +- **T**worzenie - proces wolniejsze + +### "SPIN WAIT SLEEP" dla oczekiwania: +- **Spinlock** - aktywne czekanie (pętla) +- **Mutex** - uśpienie, wybudzenie przez scheduler + +### "COFFMAN" dla warunków deadlocka: +- **C**ircular wait - cykliczne oczekiwanie +- **O**nly one - mutual exclusion +- **F**orever hold - hold and wait +- **F**orced release - no preemption (brak) + +### "PV" dla semafora: +- **P** = Proberen (testuj) = wait = down = dekrementuj +- **V** = Verhogen (zwiększ) = signal = up = inkrementuj + +--- + +## ❓ Możliwe pytania dodatkowe (follow-up) + +### Q1: "Jak unikać deadlocka?" + +**Odpowiedź:** + +1. **Zapobieganie** - złam jeden z warunków Coffmana: + - Zamawianie zasobów (zawsze lock A przed B) + - Żądaj wszystkich zasobów naraz + - Timeout na blokady + +2. **Unikanie** - algorytm bankiera (sprawdź czy bezpieczne) + +3. **Wykrywanie i naprawianie** - graf oczekiwania, zabij proces + +```c +// Zapobieganie przez porządek +// Zawsze: mutex1 przed mutex2 +pthread_mutex_lock(&mutex1); +pthread_mutex_lock(&mutex2); +// ... +pthread_mutex_unlock(&mutex2); +pthread_mutex_unlock(&mutex1); +``` + +--- + +### Q2: "Czym różni się fork() od pthread_create()?" + +**Odpowiedź:** + +| fork() | pthread_create() | +|--------|------------------| +| Tworzy nowy proces | Tworzy nowy wątek | +| Kopiuje przestrzeń adresową (COW) | Współdzieli przestrzeń | +| Nowy PID | Ten sam PID, nowy TID | +| Komunikacja przez IPC | Komunikacja przez pamięć | +| Wolne (~ms) | Szybkie (~μs) | + +```c +// fork() +pid_t pid = fork(); +if (pid == 0) { + // Proces potomny +} else { + // Proces rodzic +} + +// pthread_create() +pthread_t thread; +pthread_create(&thread, NULL, thread_function, arg); +pthread_join(thread, NULL); +``` + +--- + +### Q3: "Co to jest Copy-on-Write (COW)?" + +**Odpowiedź:** + +**COW** = optymalizacja fork() - strony pamięci są współdzielone dopóki nie zostaną zmodyfikowane. + +``` +Przed fork(): +Proces A: [strona 1] [strona 2] [strona 3] + +Po fork() (bez COW): +Proces A: [strona 1] [strona 2] [strona 3] ← kopia +Proces B: [strona 1] [strona 2] [strona 3] ← kopia + (kopiowanie całej pamięci - WOLNE!) + +Po fork() (z COW): +Proces A: [strona 1 (shared, RO)] + ↑ +Proces B: [strona 1 (shared, RO)] + (współdzielenie - SZYBKIE!) + +Po modyfikacji przez A: +Proces A: [strona 1 (kopia, RW)] ← kopia dopiero teraz! +Proces B: [strona 1 (shared, RO)] +``` + +--- + +### Q4: "Wyjaśnij problem producent-konsument" + +**Odpowiedź:** + +**Problem:** Producent wytwarza dane, konsument je pobiera. Bufor ograniczony. + +```c +#define BUFFER_SIZE 10 +int buffer[BUFFER_SIZE]; +int count = 0; + +sem_t empty, full; +pthread_mutex_t mutex; + +// Inicjalizacja +sem_init(&empty, 0, BUFFER_SIZE); // Wolne miejsca +sem_init(&full, 0, 0); // Zajęte miejsca + +void* producer(void* arg) { + while (1) { + int item = produce(); + + sem_wait(&empty); // Czekaj na wolne miejsce + pthread_mutex_lock(&mutex); + buffer[in] = item; + in = (in + 1) % BUFFER_SIZE; + pthread_mutex_unlock(&mutex); + sem_post(&full); // Sygnalizuj dane + } +} + +void* consumer(void* arg) { + while (1) { + sem_wait(&full); // Czekaj na dane + pthread_mutex_lock(&mutex); + int item = buffer[out]; + out = (out + 1) % BUFFER_SIZE; + pthread_mutex_unlock(&mutex); + sem_post(&empty); // Sygnalizuj wolne miejsce + + consume(item); + } +} +``` + +--- + +### Q5: "Co to są coroutines/goroutines?" + +**Odpowiedź:** + +**Coroutines** = współprogramy - lekkie "wątki" zarządzane w przestrzeni użytkownika. + +| Cecha | Wątki | Coroutines | +|-------|-------|------------| +| Scheduling | Preemptive (OS) | Cooperative (yield) | +| Stos | ~1-8 MB | ~2-8 KB | +| Tworzenie | ~10-100 μs | ~100 ns | +| Liczba | Setki-tysiące | Miliony | + +**Goroutines (Go):** +```go +go func() { + fmt.Println("Hello from goroutine") +}() +``` + +**Async/await (Python, C#, JavaScript):** +```python +async def fetch_data(): + data = await http_client.get(url) + return data +``` + +--- + +### Q6: "Jak działa scheduler wątków?" + +**Odpowiedź:** + +**Algorytmy schedulingu:** + +| Algorytm | Opis | Użycie | +|----------|------|--------| +| **FIFO** | Pierwszy przyszedł, pierwszy obsłużony | Prosty, batch | +| **Round Robin** | Kwant czasu, rotacja | Interaktywne | +| **Priority** | Wyższy priorytet pierwszy | Real-time | +| **CFS** | Completely Fair Scheduler | Linux | +| **Multi-level Feedback** | Priorytety + promocja/degradacja | Windows | + +**CFS (Linux):** +- Wirtualny czas wykonania (vruntime) +- Czerwono-czarne drzewo +- Sprawiedliwy podział CPU + +--- + +## 🎯 Kluczowe punkty do zapamiętania + +1. **Proces** = izolacja, własna pamięć, wolne tworzenie +2. **Wątek** = współdzielenie, szybkie, wymaga synchronizacji +3. **IPC:** Pipes, shared memory, sockets, message queues +4. **Synchronizacja:** Mutex, semafor, cond var, bariera +5. **Deadlock:** 4 warunki Coffmana, zapobiegaj przez porządek +6. **Race condition:** Atomowe operacje lub blokady + +--- + +## 📖 Źródła do pogłębienia + +1. Silberschatz, Galvin - "Operating System Concepts" +2. Tanenbaum - "Modern Operating Systems" +3. Love, R. - "Linux Kernel Development" +4. Butenhof - "Programming with POSIX Threads" diff --git a/pytania/odpowiedzi/10-zarzadzanie-pamiecia.md b/pytania/odpowiedzi/10-zarzadzanie-pamiecia.md new file mode 100644 index 0000000..48f4846 --- /dev/null +++ b/pytania/odpowiedzi/10-zarzadzanie-pamiecia.md @@ -0,0 +1,600 @@ +# Pytanie 10: Zarządzanie pamięcią - stronicowanie i segmentacja + +## Pytanie +**"Scharakteryzować problemy i mechanizmy zarządzania pamięcią. Porównać cechy i przeznaczenie mechanizmów stronicowania i segmentacji."** + +Przedmiot: SOI (Systemy Operacyjne) + +--- + +## 📚 Odpowiedź główna + +### Wprowadzenie + +**Zarządzanie pamięcią** to jeden z kluczowych zadań systemu operacyjnego: +- Przydzielanie pamięci procesom +- Ochrona pamięci między procesami +- Efektywne wykorzystanie ograniczonego zasobu +- Abstrakcja (programista nie musi znać fizycznych adresów) + +--- + +## 1. Problemy zarządzania pamięcią + +### 1.1 Fragmentacja + +#### Fragmentacja zewnętrzna (External Fragmentation) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ Pamięć fizyczna: │ +│ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ │ +│ │PROC│ │FREE│ │PROC│ │FREE│ │PROC│ │FREE│ │PROC│ │ +│ │ A │ │ 2K │ │ B │ │ 3K │ │ C │ │ 1K │ │ D │ │ +│ └────┘ └────┘ └────┘ └────┘ └────┘ └────┘ └────┘ │ +│ │ +│ Suma wolnej pamięci: 6K │ +│ Ale nie można przydzielić bloku 5K! (fragmentacja) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +**Problem:** Wolna pamięć jest rozproszona w małych, nieciągłych blokach. + +#### Fragmentacja wewnętrzna (Internal Fragmentation) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ Przydzielono blok 4KB, proces potrzebuje 3.5KB: │ +│ ┌────────────────────────────────────────┐ │ +│ │ WYKORZYSTANE (3.5KB) │ ZMARNOWANE (0.5KB) │ │ +│ └────────────────────────────────────────┘ │ +│ ↑ │ +│ Fragmentacja wewnętrzna │ +└─────────────────────────────────────────────────────────────────┘ +``` + +**Problem:** Przydzielony blok jest większy niż potrzeba. + +### 1.2 Ochrona pamięci + +- Proces A nie może czytać/pisać pamięci procesu B +- Jądro chronione przed aplikacjami użytkownika +- Mechanizmy: rejestry bazowy/graniczny, bity ochrony, ringi + +### 1.3 Relokacja + +**Problem:** Program kompilowany z założeniem konkretnych adresów musi działać pod różnymi adresami. + +**Rozwiązania:** +- Relokacja statyczna (loader) +- Relokacja dynamiczna (MMU - Memory Management Unit) + +### 1.4 Współdzielenie + +- Biblioteki współdzielone (DLL, .so) +- Pamięć współdzielona między procesami +- Copy-on-Write (COW) + +### 1.5 Ograniczona pamięć fizyczna + +- Więcej procesów niż RAM +- Rozwiązanie: pamięć wirtualna + swap + +--- + +## 2. Mechanizmy zarządzania pamięcią + +### 2.1 Partycjonowanie stałe (Fixed Partitioning) + +``` +┌────────────────────────────────────────────────────────────────┐ +│ Pamięć podzielona na stałe partycje: │ +│ ┌──────────┬──────────┬──────────┬──────────┐ │ +│ │ Partycja │ Partycja │ Partycja │ Partycja │ │ +│ │ 1MB │ 2MB │ 4MB │ 8MB │ │ +│ └──────────┴──────────┴──────────┴──────────┘ │ +│ │ +│ Zalety: Proste, brak fragmentacji zewnętrznej │ +│ Wady: Fragmentacja wewnętrzna, maks. rozmiar procesu ograniczony│ +└────────────────────────────────────────────────────────────────┘ +``` + +### 2.2 Partycjonowanie dynamiczne (Dynamic Partitioning) + +``` +┌────────────────────────────────────────────────────────────────┐ +│ Partycje tworzone według potrzeb: │ +│ ┌─────┬───────────┬────────┬─────────────────────────────┐ │ +│ │ P1 │ P2 │ P3 │ WOLNA │ │ +│ │ 3MB │ 5MB │ 2MB │ 10MB │ │ +│ └─────┴───────────┴────────┴─────────────────────────────┘ │ +│ │ +│ Zalety: Brak fragmentacji wewnętrznej, elastyczność │ +│ Wady: Fragmentacja zewnętrzna! │ +└────────────────────────────────────────────────────────────────┘ +``` + +**Algorytmy przydziału:** + +| Algorytm | Opis | Zalety | Wady | +|----------|------|--------|------| +| **First Fit** | Pierwszy wystarczający blok | Szybki | Fragmentacja na początku | +| **Best Fit** | Najmniejszy wystarczający | Oszczędza duże bloki | Wiele małych fragmentów | +| **Worst Fit** | Największy blok | Pozostawia użyteczne resztki | Niszczy duże bloki | +| **Next Fit** | First Fit od ostatniego miejsca | Rozproszenie | Fragmentacja | + +--- + +## 3. Stronicowanie (Paging) + +### Idea + +Dzielimy pamięć na **równe bloki** (strony/ramki): +- **Strona (Page)** - blok pamięci wirtualnej (4KB typowo) +- **Ramka (Frame)** - blok pamięci fizycznej (ten sam rozmiar) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ PAMIĘĆ WIRTUALNA PAMIĘĆ FIZYCZNA │ +│ (przestrzeń adresowa) (RAM) │ +│ │ +│ ┌─────────┐ ┌─────────┐ │ +│ │ Strona 0│─────────────────────────│ Ramka 5 │ │ +│ ├─────────┤ ├─────────┤ │ +│ │ Strona 1│──────────┐ │ Ramka 1 │ │ +│ ├─────────┤ │ ├─────────┤ │ +│ │ Strona 2│────┐ │ │ Ramka 2 │←──────────┐ │ +│ ├─────────┤ │ │ ├─────────┤ │ │ +│ │ Strona 3│ │ └─────────────→│ Ramka 3 │ │ │ +│ └─────────┘ │ ├─────────┤ │ │ +│ │ │ Ramka 4 │ │ │ +│ │ ├─────────┤ │ │ +│ └───────────────────→│ Ramka 7 │ │ │ +│ └─────────┘ │ │ +│ │ │ +│ TABLICA STRON (Page Table) Strona 2 → Ramka 7────┘ │ +│ ┌──────────────────────┐ │ +│ │ Strona │ Ramka │Flagi│ │ +│ │ 0 │ 5 │ RW │ │ +│ │ 1 │ 3 │ R │ │ +│ │ 2 │ 7 │ RW │ │ +│ │ 3 │ - │ INV │ ← Strona nie w pamięci (page fault) │ +│ └──────────────────────┘ │ +└─────────────────────────────────────────────────────────────────┘ +``` + +### Translacja adresu + +``` +Adres wirtualny (32-bit, strony 4KB): +┌────────────────────────┬──────────────┐ +│ Numer strony (20b) │ Offset (12b) │ +└────────────────────────┴──────────────┘ + │ │ + ↓ │ + Tablica stron │ + │ │ + ↓ │ +┌────────────────────────┬──────────────┐ +│ Numer ramki (20b) │ Offset (12b) │ +└────────────────────────┴──────────────┘ + Adres fizyczny +``` + +### Wielopoziomowe tablice stron + +**Problem:** Tablica stron dla 32-bit przestrzeni z 4KB stronami = 2²⁰ wpisów × 4B = **4MB per proces!** + +**Rozwiązanie:** Hierarchiczna tablica stron + +``` +Adres wirtualny (32-bit, 2 poziomy): +┌────────────┬────────────┬──────────────┐ +│ Katalog(10)│ Tabela(10) │ Offset (12) │ +└────────────┴────────────┴──────────────┘ + │ │ │ + ↓ ↓ │ +┌──────────┐ ┌──────────┐ │ +│ Page │ │ Page │ │ +│Directory │→ │ Table │→ Ramka + Offset +└──────────┘ └──────────┘ +``` + +**64-bit (x86-64):** 4 poziomy (PML4 → PDPT → PD → PT) + +### TLB (Translation Lookaside Buffer) + +**Problem:** Każdy dostęp do pamięci wymaga 2+ odczytów (tablica + dane). + +**Rozwiązanie:** Cache translacji adresów + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ TLB │ +│ ┌───────────────────────────────────────────────────────────┐ │ +│ │ Strona wirtualna │ Ramka fizyczna │ Flagi │ ASID │ │ +│ │ 0x12345 │ 0x789AB │ RW │ 42 │ │ +│ │ 0x12346 │ 0x789AC │ R │ 42 │ │ +│ │ ... │ ... │ ... │ ... │ │ +│ └───────────────────────────────────────────────────────────┘ │ +│ │ +│ TLB hit: ~1 cykl │ +│ TLB miss: ~100+ cykli (page walk) │ +│ Hit rate: >99% typowo │ +└─────────────────────────────────────────────────────────────────┘ +``` + +### Zalety i wady stronicowania + +| Zalety | Wady | +|--------|------| +| Brak fragmentacji zewnętrznej | Fragmentacja wewnętrzna (ostatnia strona) | +| Prosta alokacja (bitmapa ramek) | Narzut tablicy stron | +| Łatwe współdzielenie (COW) | TLB miss kosztowny | +| Pamięć wirtualna naturalna | Nie odpowiada strukturze programu | + +--- + +## 4. Segmentacja (Segmentation) + +### Idea + +Dzielimy pamięć na **logiczne segmenty** odpowiadające strukturze programu: +- Segment kodu +- Segment danych +- Segment stosu +- Segment bibliotek + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ PRZESTRZEŃ LOGICZNA PAMIĘĆ FIZYCZNA │ +│ │ +│ ┌─────────────────┐ ┌─────────────────────┐ │ +│ │ Segment 0 │ │ │ │ +│ │ (Kod) │─────────────────│→ 0x1000 - 0x3FFF │ │ +│ │ Rozmiar: 12KB │ │ │ │ +│ └─────────────────┘ ├─────────────────────┤ │ +│ ┌─────────────────┐ │ │ │ +│ │ Segment 1 │─────────────────│→ 0x8000 - 0xBFFF │ │ +│ │ (Dane) │ │ │ │ +│ │ Rozmiar: 16KB │ ├─────────────────────┤ │ +│ └─────────────────┘ │ │ │ +│ ┌─────────────────┐ │ │ │ +│ │ Segment 2 │─────────────────│→ 0xF000 - 0xF7FF │ │ +│ │ (Stos) │ │ │ │ +│ │ Rozmiar: 2KB │ └─────────────────────┘ │ +│ └─────────────────┘ │ +│ │ +│ TABLICA SEGMENTÓW │ +│ ┌───────────────────────────────────────────────────────────┐ │ +│ │ Segment │ Baza │ Limit │ Prawa │ │ │ +│ │ 0 │ 0x1000 │ 12KB │ RX │ (kod - execute) │ │ +│ │ 1 │ 0x8000 │ 16KB │ RW │ (dane - read/write) │ │ +│ │ 2 │ 0xF000 │ 2KB │ RW │ (stos) │ │ +│ └───────────────────────────────────────────────────────────┘ │ +└─────────────────────────────────────────────────────────────────┘ +``` + +### Translacja adresu + +``` +Adres logiczny: +┌────────────────────┬──────────────────────┐ +│ Numer segmentu (s) │ Offset (d) │ +└────────────────────┴──────────────────────┘ + │ │ + ↓ │ + Tablica segmentów │ + ┌──────┬───────┐ │ + │ Baza │ Limit │ │ + └──────┴───────┘ │ + │ │ │ + │ Sprawdź: d < Limit? + │ │ │ + ↓ ↓ │ + Adres fizyczny = Baza + Offset +``` + +### Ochrona w segmentacji + +Każdy segment ma **prawa dostępu:** +- **R** (Read) - odczyt dozwolony +- **W** (Write) - zapis dozwolony +- **X** (Execute) - wykonanie dozwolone + +``` +Segment kodu: RX (wykonaj, nie modyfikuj) +Segment danych: RW (czytaj/pisz, nie wykonuj) +Segment stosu: RW (bez wykonywania - ochrona przed exploitami) +``` + +### Zalety i wady segmentacji + +| Zalety | Wady | +|--------|------| +| Odpowiada strukturze programu | Fragmentacja zewnętrzna | +| Naturalna ochrona (per segment) | Segmenty o zmiennej wielkości | +| Łatwe współdzielenie (cały segment) | Kompaktowanie potrzebne | +| Dynamiczny wzrost segmentów | Skomplikowana alokacja | + +--- + +## 5. Porównanie: Stronicowanie vs Segmentacja + +| Cecha | Stronicowanie | Segmentacja | +|-------|---------------|-------------| +| **Jednostka** | Strona (stały rozmiar) | Segment (zmienny rozmiar) | +| **Widoczność dla programisty** | Niewidoczna | Widoczna (logiczne jednostki) | +| **Fragmentacja zewnętrzna** | ❌ Brak | ✅ Występuje | +| **Fragmentacja wewnętrzna** | ✅ Występuje | ❌ Brak | +| **Tablica** | Tablica stron (duża) | Tablica segmentów (mała) | +| **Ochrona** | Per strona (mniej naturalna) | Per segment (naturalna) | +| **Współdzielenie** | Per strona | Per segment (całe moduły) | +| **Pamięć wirtualna** | Łatwa (strony na dysk) | Trudniejsza | + +--- + +## 6. Segmentacja ze stronicowaniem (Hybrid) + +### Intel x86 (tryb chroniony) + +Kombinacja obu mechanizmów: + +``` +Adres logiczny (Selector:Offset) + │ + ↓ + SEGMENTACJA + (Segment → Adres liniowy) + │ + ↓ + Adres liniowy + │ + ↓ + STRONICOWANIE + (Strona → Ramka) + │ + ↓ + Adres fizyczny +``` + +**Praktyka:** Współczesne OS (Linux, Windows) używają **flat memory model** - wszystkie segmenty pokrywają całą przestrzeń adresową, efektywnie wyłączając segmentację. + +### Zalety hybrydowego podejścia + +1. **Ochrona** z segmentacji (kod vs dane vs stos) +2. **Brak fragmentacji zewnętrznej** ze stronicowania +3. **Pamięć wirtualna** ze stronicowania + +--- + +## 7. Pamięć wirtualna (Virtual Memory) + +### Idea + +Nie wszystkie strony muszą być w RAM - część może być na dysku (swap). + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ │ +│ PAMIĘĆ WIRTUALNA RAM DYSK (Swap) │ +│ ┌─────────────┐ ┌──────────┐ ┌──────────────┐ │ +│ │ Strona 0 │ ────→│ Ramka 2 │ │ │ │ +│ │ Strona 1 │ │ │ │ Strona 3 │ │ +│ │ Strona 2 │ ────→│ Ramka 5 │ │ Strona 5 │ │ +│ │ Strona 3 │ ─────────────────────→ │ │ │ +│ │ Strona 4 │ ────→│ Ramka 1 │ │ │ │ +│ │ Strona 5 │ ─────────────────────→ │ │ │ +│ └─────────────┘ └──────────┘ └──────────────┘ │ +│ │ +│ Page fault: Strona 3 → załaduj z dysku do RAM │ +└─────────────────────────────────────────────────────────────────┘ +``` + +### Algorytmy zastępowania stron + +| Algorytm | Opis | Właściwości | +|----------|------|-------------| +| **FIFO** | Najstarsza strona | Prosty, anomalia Bélády'ego | +| **LRU** | Najdawniej używana | Optymalny offline, kosztowny | +| **LRU Approximation** | Clock, Second Chance | Praktyczny kompromis | +| **LFU** | Najrzadziej używana | Dobre dla hot data | +| **OPT** | Najdalej używana | Teoretycznie optymalny, niemożliwy | + +### Algorytm Clock (Second Chance) + +``` + ┌───┐ + ┌──→│ 1 │──┐ Bit referencji: + │ └───┘ │ 1 = używana ostatnio + │ ↓ 0 = kandydat do usunięcia +┌───┐ ┌───┐ +│ 0 │ │ 1 │ Wskazówka zegara: +└───┘ └───┘ - Jeśli bit=1: zeruj, idź dalej + ↑ │ - Jeśli bit=0: zastąp tę stronę + │ ┌───┐ │ + └───│ 0 │←─┘ + └───┘ + ↑ + wskazówka +``` + +--- + +## 🧠 Mnemoniki + +### "STRONY RÓWNE, SEGMENTY LOGICZNE": +- **Strony** = wszystkie takie same (4KB) +- **Segmenty** = różne rozmiary, logiczny podział + +### "PAGE = Physical Allocation Generates Equality": +- Fizyczne ramki równej wielkości +- Brak fragmentacji zewnętrznej + +### "SEGMENT = Software Entity with Guarded Memory, ENforcing Type safety": +- Logiczne jednostki programu +- Ochrona per segment + +### "TLB = Translation Lightning-fast Buffer": +- Cache dla translacji adresów +- Hit = 1 cykl, Miss = 100+ cykli + +### "LRU = Last Recently Used → pierwszy do usunięcia": +- Najdawniej używana = najlepsza do wyrzucenia + +--- + +## ❓ Możliwe pytania dodatkowe (follow-up) + +### Q1: "Co to jest Page Fault i jak jest obsługiwany?" + +**Odpowiedź:** + +**Page Fault** = wyjątek gdy strona nie jest w RAM (bit valid=0 w tablicy stron). + +``` +1. Proces odwołuje się do adresu w stronie 5 +2. MMU sprawdza tablicę stron: strona 5 invalid +3. Page Fault exception +4. OS: + a) Znajdź stronę na dysku (swap) + b) Znajdź wolną ramkę (lub zwolnij przez algorytm zastępowania) + c) Załaduj stronę z dysku do RAM + d) Zaktualizuj tablicę stron (valid=1, ramka=X) + e) Wznów instrukcję +5. Proces kontynuuje (nie wie, że był page fault) +``` + +--- + +### Q2: "Wyjaśnij anomalię Bélády'ego" + +**Odpowiedź:** + +**Anomalia Bélády'ego** = więcej ramek → więcej page faults (dla FIFO)! + +``` +Sekwencja odwołań: 1, 2, 3, 4, 1, 2, 5, 1, 2, 3, 4, 5 + +3 ramki (FIFO): 9 page faults +4 ramki (FIFO): 10 page faults (!!) + +Wniosek: FIFO nie jest "stack algorithm" - nie ma tej właściwości: +"Strony w pamięci z N ramkami ⊆ strony z N+1 ramkami" + +LRU nie ma tej anomalii (jest stack algorithm). +``` + +--- + +### Q3: "Co to jest thrashing?" + +**Odpowiedź:** + +**Thrashing** = system spędza więcej czasu na page faults niż na wykonywaniu kodu. + +``` +Przyczyna: Zbyt mało RAM dla working set procesów + +Working set = zbiór stron aktywnie używanych przez proces + +Symptomy: +- CPU utilization spada +- Dysk ciągle pracuje (swap in/out) +- System "zamiera" + +Rozwiązania: +- Zwiększ RAM +- Zmniejsz multiprogramming +- Working set model (przydziel RAM proporcjonalnie) +- Swap na SSD +``` + +--- + +### Q4: "Jak działa Copy-on-Write?" + +**Odpowiedź:** + +**COW** = odroczenie kopiowania do momentu modyfikacji. + +``` +fork() bez COW: +Rodzic: [Strona A] [Strona B] [Strona C] + ↓ kopiowanie +Dziecko: [Strona A'] [Strona B'] [Strona C'] +→ Kosztowne! + +fork() z COW: +Rodzic: [Strona A (RO)] [Strona B (RO)] [Strona C (RO)] + ↓ shared ↓ shared ↓ shared +Dziecko: [Strona A (RO)] [Strona B (RO)] [Strona C (RO)] +→ Szybkie! (tylko tablice stron) + +Dziecko pisze do Strony B: +1. Page fault (strona RO) +2. OS kopiuje Stronę B → B' +3. Dziecko dostaje B' (RW), rodzic zachowuje B (RW) +``` + +--- + +### Q5: "Jaki jest typowy rozmiar strony i dlaczego?" + +**Odpowiedź:** + +| Rozmiar | Zalety | Wady | +|---------|--------|------| +| **Mały (1KB)** | Mała fragmentacja wewnętrzna | Duża tablica stron | +| **Duży (64KB)** | Mała tablica stron | Duża fragmentacja wewnętrzna | +| **4KB (typowy)** | Kompromis | Kompromis | + +**Dlaczego 4KB?** +- Rozmiar bloku dysku (sektor 512B × 8 lub 4K native) +- Rozsądna fragmentacja (~2KB średnio) +- Rozsądna tablica stron +- Historyczne (VAX, Unix) + +**Huge Pages (2MB, 1GB):** +- Dla dużych aplikacji (bazy danych) +- Mniej wpisów TLB +- Mniej page faults + +--- + +### Q6: "Jak segmentacja jest używana w x86-64?" + +**Odpowiedź:** + +**x86-64 praktycznie nie używa segmentacji:** + +``` +CS, DS, ES, SS → Baza = 0, Limit = maksymalny + → Efektywnie "flat model" + +Wyjątki: +- FS, GS → używane dla Thread Local Storage (TLS) +- CS → poziom uprzywilejowania (ring 0/3) +``` + +**Powód:** Segmentacja komplikuje pamięć wirtualną i nie jest potrzebna z ochroną per-strona (NX bit, SMEP, SMAP). + +--- + +## 🎯 Kluczowe punkty do zapamiętania + +1. **Stronicowanie** = równe strony/ramki, brak fragmentacji zewnętrznej +2. **Segmentacja** = logiczne jednostki, fragmentacja zewnętrzna +3. **Współczesne OS** = stronicowanie (segmentacja wyłączona) +4. **TLB** = cache translacji, kluczowy dla wydajności +5. **Page fault** = strona nie w RAM, załaduj z dysku +6. **Thrashing** = za mało RAM, ciągłe page faults + +--- + +## 📖 Źródła do pogłębienia + +1. Silberschatz, Galvin - "Operating System Concepts" +2. Tanenbaum - "Modern Operating Systems" +3. Intel Manual Vol. 3 - System Programming Guide +4. Linux kernel documentation - Memory Management diff --git a/pytania/odpowiedzi/11-modelowanie-procesow-biznesowych.md b/pytania/odpowiedzi/11-modelowanie-procesow-biznesowych.md new file mode 100644 index 0000000..360e08e --- /dev/null +++ b/pytania/odpowiedzi/11-modelowanie-procesow-biznesowych.md @@ -0,0 +1,575 @@ +# Pytanie 11: Standardy i narzędzia do modelowania procesów biznesowych + +## Pytanie +**"Scharakteryzować standardy i narzędzia do modelowania procesów biznesowych."** + +Przedmiot: WSYZ (Wstęp do Systemów Zarządzania) + +--- + +## 📚 Odpowiedź główna + +### Wprowadzenie + +**Modelowanie procesów biznesowych** to graficzne przedstawienie przepływu pracy, działań i decyzji w organizacji. Służy do: +- Dokumentowania procesów +- Analizy i optymalizacji +- Automatyzacji (workflow, BPM) +- Komunikacji między działami + +--- + +## 1. Główne standardy modelowania + +### Przegląd standardów + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ STANDARDY MODELOWANIA PROCESÓW │ +├─────────────────┬─────────────────┬─────────────────────────────┤ +│ BPMN │ UML │ EPC │ +│ Business │ Activity │ Event-driven │ +│ Process Model │ Diagrams │ Process Chain │ +│ and Notation │ │ │ +├─────────────────┼─────────────────┼─────────────────────────────┤ +│ IDEF0 │ Flowcharts │ Value Stream Map │ +│ Function │ (Schematy │ (Lean Manufacturing) │ +│ Modeling │ blokowe) │ │ +└─────────────────┴─────────────────┴─────────────────────────────┘ +``` + +--- + +## 2. BPMN (Business Process Model and Notation) + +### Charakterystyka + +- **Standard:** OMG (Object Management Group) +- **Wersja aktualna:** BPMN 2.0 (2011) +- **Cel:** Uniwersalny język dla analityków, architektów i programistów +- **Format:** Graficzny + XML (dla automatyzacji) + +### Podstawowe elementy BPMN + +#### Flow Objects (Obiekty przepływu) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ ZDARZENIA (Events) │ +│ │ +│ ○ Zdarzenie startowe (Start Event) │ +│ │ +│ ◎ Zdarzenie pośrednie (Intermediate Event) │ +│ │ +│ ◉ Zdarzenie końcowe (End Event) │ +│ │ +│ Modyfikatory: Timer ⏱, Message ✉, Error ⚡, Signal 📶 │ +└─────────────────────────────────────────────────────────────────┘ + +┌─────────────────────────────────────────────────────────────────┐ +│ CZYNNOŚCI (Activities) │ +│ │ +│ ┌─────────┐ │ +│ │ │ Zadanie (Task) - atomowa czynność │ +│ └─────────┘ │ +│ │ +│ ┌─────────┐ │ +│ │ [+] │ Podproces (Sub-Process) - zagnieżdżony │ +│ └─────────┘ │ +│ │ +│ Typy zadań: User, Service, Script, Manual, Send, Receive │ +└─────────────────────────────────────────────────────────────────┘ + +┌─────────────────────────────────────────────────────────────────┐ +│ BRAMKI (Gateways) │ +│ │ +│ ◇ Exclusive (XOR) - jeden z wielu ścieżek │ +│ │ +│ ◆ Parallel (AND) - wszystkie ścieżki równolegle │ +│ │ +│ ○◇ Inclusive (OR) - jedna lub więcej ścieżek │ +│ │ +│ ⊕ Event-based - wybór na podstawie zdarzenia │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### Connecting Objects (Łączniki) + +| Symbol | Nazwa | Użycie | +|--------|-------|--------| +| ────→ | Sequence Flow | Kolejność czynności | +| - - -→ | Message Flow | Komunikacja między uczestnikami | +| · · ·→ | Association | Powiązanie z artefaktem | + +#### Swimlanes (Tory) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ Pool: Firma XYZ │ +├─────────────────────────────────────────────────────────────────┤ +│ Lane: Dział Sprzedaży │ +│ ○────→[Przyjmij zamówienie]────→◇────→[Potwierdź] │ +├─────────────────────────────────────────────────────────────────┤ +│ Lane: Magazyn │ +│ └──→[Skompletuj]────→◉ │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### Artefakty + +| Symbol | Nazwa | Użycie | +|--------|-------|--------| +| 📄 | Data Object | Dane wejściowe/wyjściowe | +| 📁 | Data Store | Baza danych, repozytorium | +| 📝 | Annotation | Komentarz | +| [ ] | Group | Grupowanie elementów | + +### Przykład procesu BPMN + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ Proces: Obsługa reklamacji │ +│ │ +│ ○────→[Przyjmij ]────→◇────→[Weryfikuj ]────→◇ │ +│ [reklamację ] │ [produkt ] │ │ +│ │ │ │ +│ [Brak danych] [OK] │[NOK] │ +│ │ │ │ │ +│ ↓ │ ↓ │ +│ [Poproś o ] │ [Odrzuć ]│ +│ [uzupełnienie] │ [reklamację]│ +│ │ │ │ │ +│ └─────────────────→◆←────┘ │ +│ │ │ +│ ↓ │ +│ [Wyślij ] │ +│ [odpowiedź ] │ +│ │ │ +│ ↓ │ +│ ◉ │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +## 3. UML Activity Diagrams + +### Charakterystyka + +- **Standard:** OMG (część UML 2.x) +- **Cel:** Modelowanie przepływu sterowania i danych +- **Pochodzenie:** Rozszerzenie flowcharts + Petri nets + +### Elementy Activity Diagrams + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ WĘZŁY AKCJI │ +│ │ +│ ╭─────────╮ │ +│ │ Akcja │ Action Node - pojedyncza czynność │ +│ ╰─────────╯ │ +│ │ +│ ╭──[warunek]──╮ │ +│ │ Akcja │ z Guard - akcja warunkowa │ +│ ╰─────────────╯ │ +└─────────────────────────────────────────────────────────────────┘ + +┌─────────────────────────────────────────────────────────────────┐ +│ WĘZŁY STERUJĄCE │ +│ │ +│ ● Initial Node (początek) │ +│ ◉ Activity Final (koniec całości) │ +│ ⊗ Flow Final (koniec przepływu) │ +│ │ +│ ◇ Decision/Merge Node │ +│ ▬ Fork/Join Node (równoległość) │ +└─────────────────────────────────────────────────────────────────┘ + +┌─────────────────────────────────────────────────────────────────┐ +│ PRZEPŁYW OBIEKTÓW │ +│ │ +│ [Zamówienie] Object Node │ +│ │ +│ ▭▭▭▭▭▭▭▭▭▭ Datastore │ +└─────────────────────────────────────────────────────────────────┘ +``` + +### Porównanie BPMN vs UML Activity + +| Cecha | BPMN | UML Activity | +|-------|------|--------------| +| **Cel** | Procesy biznesowe | Logika oprogramowania | +| **Odbiorcy** | Analitycy, biznes | Programiści, architekci | +| **Swimlanes** | Pool/Lane | Partition | +| **Zdarzenia** | Bogate (timer, message...) | Ograniczone | +| **Automatyzacja** | BPEL, silniki BPM | Generowanie kodu | + +--- + +## 4. EPC (Event-driven Process Chain) + +### Charakterystyka + +- **Pochodzenie:** ARIS (Architecture of Integrated Information Systems) +- **Twórca:** Prof. August-Wilhelm Scheer (1992) +- **Zastosowanie:** SAP, modelowanie procesów ERP + +### Elementy EPC + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ │ +│ ⬡ Zdarzenie (Event) - pasywne, opisuje stan │ +│ np. "Zamówienie otrzymane" │ +│ │ +│ ▭ Funkcja (Function) - aktywna, opisuje działanie │ +│ np. "Sprawdź dostępność" │ +│ │ +│ ∧ AND - wszystkie ścieżki │ +│ ∨ OR - jedna lub więcej │ +│ XOR XOR - dokładnie jedna │ +│ │ +│ ○ Organizational Unit │ +│ □ Information Object │ +│ ◇ IT System │ +└─────────────────────────────────────────────────────────────────┘ +``` + +### Reguły EPC + +1. **Start i koniec:** Zdarzenie +2. **Naprzemienność:** Zdarzenie → Funkcja → Zdarzenie +3. **Łączniki:** Między zdarzeniami a funkcjami + +``` +EPC: Proces zamówienia + + ⬡ Zamówienie otrzymane + │ + ↓ + ▭ Sprawdź dostępność + │ + ↓ + XOR + / \ + ↓ ↓ +⬡ Produkt ⬡ Produkt + dostępny niedostępny + │ │ + ↓ ↓ +▭ Przygotuj ▭ Złóż + wysyłkę zamówienie + │ u dostawcy + ↓ │ +⬡ Wysyłka ↓ + gotowa ⬡ Zamówienie + złożone +``` + +--- + +## 5. IDEF (Integration DEFinition) + +### Rodzina IDEF + +| Standard | Nazwa | Zastosowanie | +|----------|-------|--------------| +| **IDEF0** | Function Modeling | Hierarchia funkcji | +| **IDEF1** | Information Modeling | Struktura danych | +| **IDEF1X** | Data Modeling | Bazy danych (ERD) | +| **IDEF3** | Process Description | Przepływ procesów | +| **IDEF4** | Object-Oriented Design | Projektowanie OO | +| **IDEF5** | Ontology Description | Ontologie | + +### IDEF0 - Modelowanie funkcji + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ KONTROLA (C) │ +│ │ │ +│ ↓ │ +│ WEJŚCIE (I) ────→ ┌───────────┐ ────→ WYJŚCIE (O) │ +│ │ FUNKCJA │ │ +│ └───────────┘ │ +│ ↑ │ +│ │ │ +│ MECHANIZM (M) │ +│ │ +│ I = Input (co jest przetwarzane) │ +│ C = Control (reguły, ograniczenia) │ +│ O = Output (rezultat) │ +│ M = Mechanism (kto/co wykonuje) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +### Dekompozycja IDEF0 + +``` +Poziom 0: A0 - Całość procesu + │ + ├── A1 - Podfunkcja 1 + │ ├── A11 + │ ├── A12 + │ └── A13 + │ + ├── A2 - Podfunkcja 2 + │ + └── A3 - Podfunkcja 3 +``` + +--- + +## 6. Inne notacje i podejścia + +### Flowcharts (Schematy blokowe) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ Symbole: │ +│ │ +│ ⬭ Terminal (Start/End) │ +│ ▭ Process (Operacja) │ +│ ◇ Decision (Decyzja) │ +│ ▱ I/O (Wejście/Wyjście) │ +│ ─→ Flow (Przepływ) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +**Zalety:** Proste, uniwersalne, znane +**Wady:** Brak standaryzacji, niewystarczające dla złożonych procesów + +### Value Stream Map (VSM) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ Lean Manufacturing │ +│ │ +│ Supplier ──→ [Magazyn] ──→ [Produkcja] ──→ [QC] ──→ Customer │ +│ Inv: 5d PT: 2h PT: 30min │ +│ CT: 45s │ +│ │ +│ PT = Processing Time (czas przetwarzania) │ +│ CT = Cycle Time (czas cyklu) │ +│ Inv = Inventory (zapas) │ +│ │ +│ Cel: Identyfikacja MUDA (marnotrawstwo) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +### Petri Nets (Sieci Petriego) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ Formalizm matematyczny dla współbieżności │ +│ │ +│ ○ Place (Miejsce) - stan │ +│ ▭ Transition (Przejście) - akcja │ +│ ● Token (Żeton) - znacznik │ +│ │ +│ ●○────→▭────→○ │ +│ │ +│ Zastosowanie: Analiza deadlocków, weryfikacja formalna │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +## 7. Narzędzia do modelowania + +### Przegląd narzędzi + +| Narzędzie | Standardy | Typ | Cena | +|-----------|-----------|-----|------| +| **Bizagi Modeler** | BPMN | Dedykowane | Free/Paid | +| **Camunda Modeler** | BPMN, DMN | Open Source | Free | +| **Signavio** | BPMN, EPC | Cloud | Paid | +| **ARIS** | EPC, BPMN | Enterprise | Paid | +| **Enterprise Architect** | UML, BPMN | Uniwersalne | Paid | +| **Lucidchart** | Wszystkie | Cloud | Free/Paid | +| **draw.io** | Wszystkie | Free | Free | +| **Visio** | Flowcharts, BPMN | Desktop | Paid | +| **ProcessMaker** | BPMN | BPM Suite | Paid | +| **Bonita** | BPMN | Open Source | Free/Paid | + +### Funkcjonalności narzędzi + +| Funkcja | Podstawowe | Zaawansowane | +|---------|------------|--------------| +| Modelowanie graficzne | ✓ | ✓ | +| Walidacja modelu | ✗ | ✓ | +| Symulacja | ✗ | ✓ | +| Wykonywanie (engine) | ✗ | ✓ | +| Eksport (XML, PDF) | ✓ | ✓ | +| Współpraca | ✗/Cloud | ✓ | +| Integracja z IT | ✗ | ✓ | + +--- + +## 📊 Porównanie standardów + +| Cecha | BPMN | UML Activity | EPC | IDEF0 | +|-------|------|--------------|-----|-------| +| **Cel główny** | Procesy biznesowe | Logika systemu | Procesy ERP | Funkcje | +| **Złożoność** | Średnia-wysoka | Średnia | Średnia | Niska | +| **Automatyzacja** | Tak (BPEL) | Częściowo | Tak (SAP) | Nie | +| **Popularność** | Bardzo wysoka | Wysoka | Średnia (SAP) | Niska | +| **Krzywa uczenia** | Stroma | Średnia | Płaska | Płaska | +| **Standaryzacja** | OMG (ISO) | OMG | ARIS | NIST | + +--- + +## 🧠 Mnemoniki + +### "BPMN = Business Process Modeling Notation": +- **B**iznesowe procesy +- **P**ule i tory (swimlanes) +- **M**odele graficzne + XML +- **N**otacja standardowa (OMG) + +### "EPC = Event → Process → Control": +- **E**vent startuje i kończy +- **P**roces (funkcja) działa +- **C**ontrol przez XOR/AND/OR + +### "ICOM" dla IDEF0: +- **I**nput - co wchodzi +- **C**ontrol - co kontroluje +- **O**utput - co wychodzi +- **M**echanism - kto/co wykonuje + +### "Bramki BPMN - X AND OR": +- **X** (XOR) - wyłącznie jedna ścieżka +- **AND** (+) - wszystkie ścieżki +- **OR** (○) - jedna lub więcej + +--- + +## ❓ Możliwe pytania dodatkowe (follow-up) + +### Q1: "Jakie są poziomy dojrzałości modelowania procesów?" + +**Odpowiedź:** + +**CMMI-like dla BPM:** + +| Poziom | Nazwa | Charakterystyka | +|--------|-------|-----------------| +| 1 | **Initial** | Ad-hoc, brak dokumentacji | +| 2 | **Repeatable** | Podstawowa dokumentacja | +| 3 | **Defined** | Procesy zdefiniowane, BPMN | +| 4 | **Managed** | Mierzone KPI, optymalizacja | +| 5 | **Optimizing** | Ciągłe doskonalenie, automatyzacja | + +--- + +### Q2: "Co to jest BPEL i jak się ma do BPMN?" + +**Odpowiedź:** + +**BPEL (Business Process Execution Language)** = język XML do wykonywania procesów przez silniki workflow. + +``` +BPMN (graficzny) → eksport → BPEL (XML) → silnik BPM → wykonanie +``` + +| Cecha | BPMN | BPEL | +|-------|------|------| +| Format | Graficzny | XML | +| Cel | Modelowanie | Wykonanie | +| Odbiorcy | Analitycy | Systemy IT | +| Czytelność | Wysoka | Niska | + +--- + +### Q3: "Jakie metryki procesów można monitorować?" + +**Odpowiedź:** + +**KPI procesów biznesowych:** + +| Metryka | Opis | Przykład | +|---------|------|----------| +| **Cycle Time** | Czas od początku do końca | 5 dni na zamówienie | +| **Throughput** | Liczba zakończonych instancji | 100 zamówień/dzień | +| **Cost per Transaction** | Koszt pojedynczej instancji | 50 PLN/zamówienie | +| **Error Rate** | Procent błędów/odrzuceń | 2% reklamacji | +| **SLA Compliance** | Zgodność z umową | 95% w terminie | +| **Resource Utilization** | Wykorzystanie zasobów | 80% czasu pracy | + +--- + +### Q4: "Czym różni się proces od procedury?" + +**Odpowiedź:** + +| Aspekt | Proces | Procedura | +|--------|--------|-----------| +| **Definicja** | CO robimy (flow) | JAK robimy (instrukcja) | +| **Zakres** | End-to-end | Pojedyncza czynność | +| **Format** | Diagram (BPMN) | Tekst, checklist | +| **Cel** | Optymalizacja, automatyzacja | Standaryzacja, jakość | +| **Przykład** | Proces reklamacji | Procedura weryfikacji produktu | + +--- + +### Q5: "Co to jest DMN i jak współpracuje z BPMN?" + +**Odpowiedź:** + +**DMN (Decision Model and Notation)** = standard OMG do modelowania decyzji. + +``` +BPMN: [Oceń ryzyko kredytowe] ←── połączenie ──→ DMN: Tabela decyzyjna + ┌─────────────┐ + │Dochód │Wynik│ + │>10k │ OK │ + │<10k │ NOK │ + └─────────────┘ +``` + +**Zalety:** +- Oddzielenie logiki decyzji od przepływu +- Łatwiejsze utrzymanie reguł biznesowych +- Zrozumiałe dla biznesu (tabele decyzyjne) + +--- + +### Q6: "Jakie są zasady poprawnego modelowania BPMN?" + +**Odpowiedź:** + +**Dobre praktyki:** + +1. **Jeden start, jeden koniec** (per proces) +2. **Nazwy = czasownik + rzeczownik** ("Sprawdź zamówienie") +3. **Bramki w parach** (split → merge) +4. **Unikaj krzyżowania linii** +5. **Swimlanes = role, nie osoby** +6. **Poziom szczegółowości = cel modelu** +7. **Happy path główny, wyjątki osobno** + +**Błędy częste:** +- Brak bramki po decyzji +- Mieszanie XOR i AND bez merge +- Zbyt szczegółowe lub zbyt ogólne + +--- + +## 🎯 Kluczowe punkty do zapamiętania + +1. **BPMN** = standard przemysłowy, OMG, automatyzacja +2. **UML Activity** = dla programistów, część UML +3. **EPC** = SAP, zdarzenia-funkcje-łączniki +4. **IDEF0** = hierarchia funkcji, ICOM +5. **Narzędzia:** Bizagi, Camunda, draw.io, Visio +6. **Cel:** Dokumentacja → Analiza → Optymalizacja → Automatyzacja + +--- + +## 📖 Źródła do pogłębienia + +1. OMG - "Business Process Model and Notation (BPMN) 2.0" +2. Weske, M. - "Business Process Management" +3. Dumas, M. et al. - "Fundamentals of Business Process Management" +4. Scheer, A.-W. - "ARIS - Business Process Modeling" diff --git a/pytania/odpowiedzi/12-sieciowe-modele-optymalizacji.md b/pytania/odpowiedzi/12-sieciowe-modele-optymalizacji.md new file mode 100644 index 0000000..1157cab --- /dev/null +++ b/pytania/odpowiedzi/12-sieciowe-modele-optymalizacji.md @@ -0,0 +1,281 @@ +# Pytanie 12: Sieciowe modele optymalizacji w systemach zarządzania + +## Pytanie +**"Przedstawić sieciowe modele optymalizacji stosowane w systemach zarządzania. Omówić ich właściwości."** + +Przedmiot: WSYZ (Wstęp do Systemów Zarządzania) + +--- + +## 📚 Odpowiedź główna + +### Wprowadzenie + +**Sieciowe modele optymalizacji** to matematyczne reprezentacje problemów decyzyjnych w postaci grafów (sieci), gdzie: +- **Węzły** = punkty decyzyjne, lokalizacje, zdarzenia +- **Krawędzie** = połączenia, przepływy, zależności +- **Wagi** = koszty, czasy, przepustowości + +--- + +## 1. Problem najkrótszej ścieżki (Shortest Path) + +### Definicja +Znaleźć ścieżkę o minimalnej sumie wag między węzłem źródłowym a docelowym. + +``` + 2 + A ────→ B + │ │ + 1 │ │ 3 + ↓ ↓ + C ────→ D + 1 + +Najkrótsza ścieżka A→D: A→C→D (koszt: 2) +``` + +### Algorytmy +| Algorytm | Złożoność | Wagi ujemne | Zastosowanie | +|----------|-----------|-------------|--------------| +| **Dijkstra** | O(V² lub E log V) | ❌ | GPS, routing | +| **Bellman-Ford** | O(VE) | ✅ | Finanse, arbitraż | +| **A*** | O(E) średnio | ❌ | Gry, nawigacja | + +### Zastosowania w zarządzaniu +- Optymalizacja tras dostaw +- Planowanie logistyki +- Routing w sieciach telekomunikacyjnych + +--- + +## 2. Problem maksymalnego przepływu (Max Flow) + +### Definicja +Znaleźć maksymalny przepływ ze źródła (s) do ujścia (t) przy ograniczeniach przepustowości. + +``` + 10 10 + s ────→ A ────→ t + │ ↑ ↑ + 5 │ 5 │ │ 10 + ↓ │ │ + B ──────┴───────┘ + 15 + +Max flow = 15 (przez A: 10, przez B: 5) +``` + +### Algorytmy +| Algorytm | Złożoność | Uwagi | +|----------|-----------|-------| +| **Ford-Fulkerson** | O(E × max_flow) | Metoda ścieżek powiększających | +| **Edmonds-Karp** | O(VE²) | BFS dla ścieżek | +| **Dinic** | O(V²E) | Przepływy blokujące | + +### Zastosowania +- Planowanie produkcji (przepustowość linii) +- Zarządzanie siecią dystrybucji +- Przydział zasobów + +--- + +## 3. Problem minimalnego kosztu przepływu (Min Cost Flow) + +### Definicja +Przepływ o zadanej wielkości przy minimalnym koszcie (każda krawędź ma przepustowość i koszt jednostkowy). + +``` + (cap=10, cost=2) + s ─────────────────→ A + │ │ + │(cap=5, cost=1) │(cap=10, cost=3) + ↓ ↓ + B ─────────────────→ t + (cap=15, cost=1) + +Wymagany przepływ: 10 +Min koszt = ? +``` + +### Zastosowania +- Transport towarów (minimalizacja kosztów) +- Przydział zadań pracownikom +- Optymalizacja łańcucha dostaw + +--- + +## 4. Problem przydziału (Assignment Problem) + +### Definicja +Przypisanie n zadań do n wykonawców przy minimalnym koszcie (jeden do jednego). + +``` + Zadanie 1 Zadanie 2 Zadanie 3 +Prac. A 8 4 7 +Prac. B 5 2 3 +Prac. C 9 6 4 + +Optymalny przydział: A→Z2, B→Z1, C→Z3 (koszt: 4+5+4=13) +``` + +### Algorytm węgierski (Hungarian) +- Złożoność: O(n³) +- Gwarantuje optimum + +### Zastosowania +- Planowanie grafików pracy +- Przydział maszyn do zleceń +- Matching w HR (rekrutacja) + +--- + +## 5. Problem komiwojażera (TSP - Travelling Salesman) + +### Definicja +Odwiedzić wszystkie węzły dokładnie raz i wrócić do startu przy minimalnym koszcie. + +``` + A ──5── B + │╲ ╱│ + 4│ ╲3╱ │6 + │ ╳ │ + 2│ ╱ ╲ │7 + │╱ ╲│ + C ──8── D + +Optymalna trasa: A→C→D→B→A (koszt: 2+8+6+5=21) +``` + +### Właściwości +- **NP-trudny** - brak algorytmu wielomianowego +- Dokładne: Branch & Bound, programowanie dynamiczne +- Heurystyki: Nearest Neighbor, 2-opt, symulowane wyżarzanie + +### Zastosowania +- Planowanie tras kurierów +- Optymalizacja wizyt serwisowych +- Sekwencjonowanie produkcji + +--- + +## 6. CPM/PERT - Harmonogramowanie projektów + +### CPM (Critical Path Method) + +``` + ┌──B(3)──┐ + ╱ ╲ +A(2)──┤ ├──E(2)──F(1) + ╲ ╱ + └──C(4)──D(1) + +Ścieżka krytyczna: A→C→D→E→F (czas: 2+4+1+2+1=10) +``` + +### Właściwości +| Cecha | CPM | PERT | +|-------|-----|------| +| Czasy | Deterministyczne | Probabilistyczne (a,m,b) | +| Zastosowanie | Projekty powtarzalne | Projekty R&D | +| Wynik | Ścieżka krytyczna | Rozkład prawdopodobieństwa | + +### Zastosowania +- Zarządzanie projektami budowlanymi +- Planowanie wdrożeń IT +- Koordynacja produkcji + +--- + +## 7. Drzewo rozpinające (MST - Minimum Spanning Tree) + +### Definicja +Połączyć wszystkie węzły przy minimalnym koszcie (bez cykli). + +``` +Przed: Po (MST): + 2 2 +A──────B A──────B +│╲ ╱│ │ +│3╲1╱ │4 │3 +│ C │ → │ C +│ ╱╲ │ │ ╱ +│╱5 ╲6│ │╱5 +D──────E D E + 7 + +Koszt MST: 2+3+1+5=11 +``` + +### Algorytmy +| Algorytm | Złożoność | Strategia | +|----------|-----------|-----------| +| **Kruskal** | O(E log E) | Sortuj krawędzie, Union-Find | +| **Prim** | O(E log V) | Rozbudowa od węzła | + +### Zastosowania +- Projektowanie sieci (elektrycznych, telekomunikacyjnych) +- Klasteryzacja danych +- Minimalizacja okablowania + +--- + +## 📊 Porównanie modeli + +| Model | Typ problemu | Złożoność | Przykład zastosowania | +|-------|--------------|-----------|----------------------| +| Shortest Path | P | O(E log V) | Nawigacja GPS | +| Max Flow | P | O(V²E) | Planowanie produkcji | +| Min Cost Flow | P | O(V³) | Transport towarów | +| Assignment | P | O(n³) | Grafiki pracy | +| TSP | NP-hard | Wykładnicza | Trasy kurierów | +| CPM/PERT | P | O(V+E) | Projekty | +| MST | P | O(E log V) | Sieci infrastruktury | + +--- + +## 🧠 Mnemoniki + +### "SPAM-CT" - modele sieciowe: +- **S**hortest Path +- **P**rzepływ (Max Flow) +- **A**ssignment +- **M**ST +- **C**PM/PERT +- **T**SP + +### "Graf = Węzły + Krawędzie + Wagi": +- Węzły = lokalizacje/decyzje +- Krawędzie = połączenia +- Wagi = koszty/czasy/przepustowości + +--- + +## ❓ Możliwe pytania dodatkowe + +### Q1: "Jaka jest różnica między CPM a PERT?" +**Odpowiedź:** CPM używa deterministycznych czasów (znanych), PERT używa trzech estymacji (optymistyczna, najbardziej prawdopodobna, pesymistyczna) i rozkładu beta. CPM dla projektów powtarzalnych, PERT dla R&D z niepewnością. + +### Q2: "Kiedy stosować heurystyki zamiast algorytmów dokładnych?" +**Odpowiedź:** Gdy problem jest NP-trudny (TSP) lub dane wejściowe bardzo duże. Heurystyki dają "dość dobre" rozwiązanie w rozsądnym czasie. Przykład: 2-opt dla TSP daje rozwiązanie ~5% od optimum w O(n²). + +### Q3: "Co to jest slack/float w CPM?" +**Odpowiedź:** Zapas czasu zadania = najpóźniejszy start − najwcześniejszy start. Zadania na ścieżce krytycznej mają slack=0 (opóźnienie opóźni cały projekt). + +--- + +## 🎯 Kluczowe punkty + +1. **Sieciowe modele** = problemy jako grafy (węzły, krawędzie, wagi) +2. **Shortest Path, Max Flow, MST** = rozwiązywalne w czasie wielomianowym +3. **TSP** = NP-trudny, wymaga heurystyk +4. **CPM/PERT** = harmonogramowanie, ścieżka krytyczna +5. **Assignment** = optymalne dopasowanie 1:1 + +--- + +## 📖 Źródła + +1. Hillier, Lieberman - "Introduction to Operations Research" +2. Cormen et al. - "Introduction to Algorithms" +3. Winston - "Operations Research: Applications and Algorithms" diff --git a/pytania/odpowiedzi/13-systemy-agentowe-aktorowe.md b/pytania/odpowiedzi/13-systemy-agentowe-aktorowe.md new file mode 100644 index 0000000..61af693 --- /dev/null +++ b/pytania/odpowiedzi/13-systemy-agentowe-aktorowe.md @@ -0,0 +1,248 @@ +# Pytanie 13: Systemy agentowe i aktorowe - teorie, standardy, narzędzia + +## Pytanie +**"Omówić szczegółowo teorie, definicje, standardy i narzędzia wykorzystywane przy projektowaniu i implementacji systemów opartych na koncepcji agenta i aktora."** + +Przedmiot: AASD (Agentowe i Aktorowe Systemy Decyzyjne) + +--- + +## 📚 Odpowiedź główna + +### 1. Definicje fundamentalne + +#### Agent (wg Wooldridge & Jennings) +**Agent** = system komputerowy umieszczony w środowisku, zdolny do **autonomicznego działania** w celu realizacji celów. + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ ŚRODOWISKO │ +│ ┌─────────────────────────────────────────────────────────┐ │ +│ │ │ │ +│ │ Percepcja ┌─────────┐ Akcja │ │ +│ │ ─────────────────→ │ AGENT │ ─────────────────→ │ │ +│ │ (sensory) │ │ (effectors) │ │ +│ │ │ Cele │ │ │ +│ │ │ Wiedza │ │ │ +│ │ │ Plany │ │ │ +│ │ └─────────┘ │ │ +│ └─────────────────────────────────────────────────────────┘ │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### Właściwości agenta (AARC) + +| Właściwość | Opis | +|------------|------| +| **Autonomiczność** | Działa bez bezpośredniej interwencji | +| **Reaktywność** | Reaguje na zmiany środowiska | +| **Proaktywność** | Inicjuje działania do realizacji celów | +| **Społeczność** | Komunikuje się z innymi agentami | + +#### Aktor (model Hewitta, 1973) +**Aktor** = fundamentalna jednostka obliczeń, która: +- Ma **prywatny stan** +- Komunikuje się wyłącznie przez **wiadomości** +- Może tworzyć nowych aktorów +- Przetwarza jedną wiadomość naraz + +``` +┌────────────────────────────────────────────────────────────────┐ +│ AKTOR │ +│ ┌──────────────────┐ │ +│ │ Mailbox │ ← wiadomości (kolejka) │ +│ │ ┌─┬─┬─┬─┐ │ │ +│ │ │m│m│m│m│ │ │ +│ │ └─┴─┴─┴─┘ │ │ +│ │ ↓ │ │ +│ │ Behavior │ → przetwarzanie sekwencyjne │ +│ │ (zachowanie) │ │ +│ │ ↓ │ │ +│ │ Stan prywatny │ → izolowany, niemutowalny z zewnątrz │ +│ └──────────────────┘ │ +│ │ +│ Reakcje na wiadomość: │ +│ 1. Wyślij wiadomości do innych aktorów │ +│ 2. Utwórz nowych aktorów │ +│ 3. Zmień własne zachowanie (become) │ +└────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 2. Agent vs Aktor + +| Cecha | Agent | Aktor | +|-------|-------|-------| +| **Cel** | Inteligentne zachowanie | Współbieżność | +| **Stan** | Beliefs, Goals, Intentions | Prywatny, izolowany | +| **Komunikacja** | ACL (semantyka) | Wiadomości (asynchroniczne) | +| **Autonomia** | Wysoka (decyzje) | Średnia (reaktywność) | +| **Pochodzenie** | AI, systemy rozproszone | Teoria obliczeń | + +--- + +### 3. Architektury agentów + +#### BDI (Belief-Desire-Intention) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ ARCHITEKTURA BDI │ +│ │ +│ Percepcja → BELIEFS (przekonania o świecie) │ +│ ↓ │ +│ DESIRES (cele do osiągnięcia) │ +│ ↓ │ +│ INTENTIONS (wybrane plany) │ +│ ↓ │ +│ Akcja │ +│ │ +│ Przykład: │ +│ B: "Jest czerwone światło" │ +│ D: "Chcę dojechać do celu" │ +│ I: "Zatrzymam się i poczekam" │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### Subsumption Architecture (Brooks) + +``` +Warstwa 3: [Eksploruj] → najwyższy priorytet + ↓ suppress +Warstwa 2: [Unikaj przeszkód] + ↓ suppress +Warstwa 1: [Idź przed siebie] + ↓ + Effektory + +Zachowania niskopoziomowe mogą być "nadpisane" przez wyższe. +``` + +--- + +### 4. Standardy komunikacji agentów + +#### FIPA (Foundation for Intelligent Physical Agents) + +**FIPA-ACL** (Agent Communication Language): + +``` +(inform + :sender agent1 + :receiver agent2 + :content (price item1 100) + :language FIPA-SL + :ontology trading-ontology +) +``` + +**Performatywy FIPA:** + +| Performatyw | Znaczenie | +|-------------|-----------| +| `inform` | Informuje o fakcie | +| `request` | Prosi o wykonanie akcji | +| `query-if` | Pyta czy coś jest prawdą | +| `propose` | Proponuje transakcję | +| `accept-proposal` | Akceptuje propozycję | +| `reject-proposal` | Odrzuca propozycję | +| `cfp` | Call for Proposals | + +#### KQML (Knowledge Query and Manipulation Language) +Starszy standard, podobny do FIPA-ACL. + +--- + +### 5. Narzędzia i frameworki + +#### Systemy agentowe + +| Narzędzie | Język | Opis | +|-----------|-------|------| +| **JADE** | Java | FIPA-compliant, najpopularniejszy | +| **Jason** | AgentSpeak | BDI, deklaratywny | +| **SPADE** | Python | Asynchroniczny, XMPP | +| **NetLogo** | Logo | Symulacje, edukacja | +| **MASON** | Java | Symulacje wieloagentowe | + +#### Systemy aktorowe + +| Narzędzie | Język | Opis | +|-----------|-------|------| +| **Akka** | Scala/Java | Produkcyjny, dojrzały | +| **Erlang/OTP** | Erlang | Telekomunikacja, fault-tolerant | +| **Orleans** | C# | Microsoft, Virtual Actors | +| **Pony** | Pony | Capabilities, bezpieczny | +| **Ray** | Python | ML, distributed computing | + +--- + +### 6. Protokoły interakcji + +#### Contract Net Protocol + +``` +┌─────────┐ cfp ┌─────────┐ +│ Manager │───────────────────→│ Bidder1 │ +│ │←──────propose──────│ │ +│ │ cfp ├─────────┤ +│ │───────────────────→│ Bidder2 │ +│ │←──────propose──────│ │ +│ │ ├─────────┤ +│ │───accept-proposal─→│ Winner │ +│ │←─────inform────────│ │ +└─────────┘ └─────────┘ +``` + +--- + +## 🧠 Mnemoniki + +### "BDI = Believe, Desire, Intend": +- **B**eliefs = co wiem o świecie +- **D**esires = czego chcę +- **I**ntentions = co zamierzam zrobić + +### "ARPS" - właściwości agenta: +- **A**utonomiczność +- **R**eaktywność +- **P**roaktywność +- **S**połeczność + +### "Aktor = Mailbox + Behavior + State": +- Kolejka wiadomości +- Logika przetwarzania +- Izolowany stan + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Czym różni się JADE od Akka?" +**Odpowiedź:** JADE to framework agentowy (FIPA, ACL, inteligentne zachowania), Akka to framework aktorowy (współbieżność, fault-tolerance, reactive streams). JADE dla AI/MAS, Akka dla systemów rozproszonych. + +### Q2: "Co to jest Yellow Pages w systemach agentowych?" +**Odpowiedź:** Usługa katalogowa (Directory Facilitator w FIPA) gdzie agenty rejestrują swoje usługi. Inne agenty mogą wyszukiwać agenty oferujące konkretne usługi. Analogia do książki telefonicznej. + +### Q3: "Jak Akka zapewnia fault-tolerance?" +**Odpowiedź:** Supervision trees - każdy aktor ma supervisora, który decyduje o reakcji na błąd (restart, stop, eskaluj). "Let it crash" philosophy - izolacja błędów. + +--- + +## 🎯 Kluczowe punkty + +1. **Agent** = autonomiczny, reaktywny, proaktywny, społeczny +2. **Aktor** = mailbox + behavior + isolated state +3. **BDI** = Beliefs-Desires-Intentions (architektura) +4. **FIPA-ACL** = standard komunikacji agentów +5. **JADE** = agenty (Java), **Akka** = aktorzy (Scala) + +--- + +## 📖 Źródła + +1. Wooldridge - "An Introduction to MultiAgent Systems" +2. Hewitt - "A Universal Modular Actor Formalism for AI" +3. FIPA Specifications - fipa.org +4. Akka Documentation - akka.io diff --git a/pytania/odpowiedzi/14-algorytmy-wieloagentowe.md b/pytania/odpowiedzi/14-algorytmy-wieloagentowe.md new file mode 100644 index 0000000..64ad3b4 --- /dev/null +++ b/pytania/odpowiedzi/14-algorytmy-wieloagentowe.md @@ -0,0 +1,302 @@ +# Pytanie 14: Algorytmy i metody w systemach wieloagentowych i aktorowych + +## Pytanie +**"Wymienić i szczegółowo opisać wybrane algorytmy i metody wykorzystywane w systemach wieloagentowych i aktorowych."** + +Przedmiot: AASD (Agentowe i Aktorowe Systemy Decyzyjne) + +--- + +## 📚 Odpowiedź główna + +### 1. Algorytmy negocjacji i aukcji + +#### Contract Net Protocol (CNP) + +``` +Fazy: +1. ANNOUNCEMENT - Manager ogłasza zadanie (cfp) +2. BIDDING - Wykonawcy składają oferty (propose) +3. AWARDING - Manager wybiera najlepszą (accept/reject) +4. EXECUTION - Wybrany wykonuje zadanie (inform) + + Manager Contractors + │ ┌───┬───┬───┐ + │────── cfp ──────────→│ A │ B │ C │ + │ └───┴───┴───┘ + │←───── propose ─────── │ │ + │←───── propose ──────────── │ + │←───── propose ───────────────── + │ + │── accept-proposal ──→ B (winner) + │── reject-proposal ──→ A, C + │ + │←───── inform ─────── B (result) +``` + +**Zastosowania:** Przydział zadań, zarządzanie zasobami, e-commerce + +#### Aukcje wieloagentowe + +| Typ aukcji | Mechanizm | Właściwości | +|------------|-----------|-------------| +| **English** | Rosnące stawki | Otwarta, winner's curse | +| **Dutch** | Malejące stawki | Szybka, ryzykowna | +| **First-price sealed** | Zapieczętowane | Strategiczne zaniżanie | +| **Vickrey** | Second-price sealed | Truthful (incentive compatible) | + +--- + +### 2. Algorytmy konsensusu + +#### Raft (dla systemów aktorowych) + +``` +Stany węzłów: FOLLOWER → CANDIDATE → LEADER + +Leader Election: +1. Follower timeout → staje się Candidate +2. Candidate wysyła RequestVote do wszystkich +3. Większość głosów → nowy Leader +4. Leader wysyła heartbeats + +Log Replication: +1. Client → Leader (command) +2. Leader → Followers (AppendEntries) +3. Większość potwierdza → commit +4. Leader → Client (success) +``` + +#### PBFT (Practical Byzantine Fault Tolerance) + +``` +Toleruje f błędnych węzłów przy n ≥ 3f + 1 + +Fazy: +PRE-PREPARE → PREPARE → COMMIT → REPLY + +Client ──request──→ Primary + │ + ┌──────────┼──────────┐ + ↓ ↓ ↓ + Replica1 Replica2 Replica3 + └──────────┼──────────┘ + ↓ + Reply +``` + +--- + +### 3. Algorytmy koordynacji + +#### Distributed Mutual Exclusion + +**Algorytm Ricarta-Agrawali:** +``` +Wejście do sekcji krytycznej: +1. Wyślij REQUEST(timestamp) do wszystkich +2. Czekaj na REPLY od wszystkich +3. Wejdź do sekcji krytycznej + +Odbiór REQUEST: +- Jeśli nie chcę CS lub mój timestamp > nadawcy → wyślij REPLY +- W przeciwnym razie → kolejkuj REQUEST +``` + +**Złożoność:** 2(N-1) wiadomości na wejście do CS + +#### Token Ring +``` + ┌───→ A ───→ B ───┐ + │ ↓ + │ [TOKEN] │ + │ │ + └─── D ←─── C ←───┘ + +Kto ma token → może wejść do CS +Złożoność: 0 do N-1 wiadomości (średnio N/2) +``` + +--- + +### 4. Algorytmy uczenia wieloagentowego + +#### Q-Learning (Independent Learners) + +``` +Każdy agent uczy się niezależnie: + +Q(s,a) ← Q(s,a) + α[r + γ max Q(s',a') - Q(s,a)] + +Problem: Środowisko niestacjonarne (inni agenci się zmieniają) +``` + +#### Nash Q-Learning + +``` +Uwzględnia akcje innych agentów: + +Q_i(s, a₁, a₂, ..., aₙ) - wartość dla agenta i + +Aktualizacja używa równowagi Nasha: +Q_i ← Q_i + α[r_i + γ Nash(Q_i(s')) - Q_i] +``` + +#### Fictitious Play +``` +1. Obserwuj akcje przeciwników +2. Buduj rozkład empiryczny ich strategii +3. Graj best response wobec tego rozkładu +4. Powtarzaj + +Zbieżność do Nasha w grach z właściwością FP +``` + +--- + +### 5. Algorytmy dla aktorów + +#### Supervision Strategies (Akka) + +```scala +// One-for-One: restart tylko tego aktora +override val supervisorStrategy = + OneForOneStrategy() { + case _: ArithmeticException => Resume + case _: NullPointerException => Restart + case _: Exception => Stop + } + +// All-for-One: restart wszystkich dzieci +override val supervisorStrategy = + AllForOneStrategy() { + case _: Exception => Restart + } +``` + +#### Routing Strategies + +| Strategia | Opis | +|-----------|------| +| **Round Robin** | Po kolei do każdego | +| **Random** | Losowo | +| **Smallest Mailbox** | Do najmniej obciążonego | +| **Broadcast** | Do wszystkich | +| **Consistent Hashing** | Wg klucza (locality) | + +--- + +### 6. Algorytmy planowania (BDI) + +#### Means-Ends Reasoning + +``` +Goal: be_at(destination) + +Plans: + plan1: walk(X,Y) :- distance(X,Y) < 1km + plan2: drive(X,Y) :- have(car), distance(X,Y) >= 1km + plan3: take_bus(X,Y) :- bus_available(X,Y) + +Wybór planu na podstawie: +- Kontekstu (beliefs) +- Preferencji +- Kosztu +``` + +#### Partial Order Planning (POP) + +``` +Cel: have(coffee) ∧ have(report) + + Start + │ + ┌────┴────┐ + ↓ ↓ + buy(coffee) write(report) + │ │ + └────┬────┘ + ↓ + Goal + +Ordering constraints: flexible (równoległość gdy możliwa) +``` + +--- + +### 7. Algorytmy formowania koalicji + +#### Shapley Value + +``` +Sprawiedliwy podział zysków w koalicji: + +φᵢ = Σ [|S|!(n-|S|-1)!/n!] × [v(S∪{i}) - v(S)] + +Gdzie: +- S = podzbiór agentów bez i +- v(S) = wartość koalicji S +- n = liczba agentów + +Właściwości: efektywność, symetria, addytywność +``` + +--- + +## 📊 Podsumowanie algorytmów + +| Kategoria | Algorytm | Zastosowanie | +|-----------|----------|--------------| +| Negocjacje | Contract Net | Przydział zadań | +| Aukcje | Vickrey | Truthful bidding | +| Konsensus | Raft, PBFT | Systemy rozproszone | +| Koordynacja | Ricart-Agrawala | Mutual exclusion | +| Uczenie | Nash Q-Learning | Gry wieloagentowe | +| Aktorzy | Supervision | Fault tolerance | +| Planowanie | Means-Ends | BDI agenty | +| Koalicje | Shapley Value | Podział zysków | + +--- + +## 🧠 Mnemoniki + +### "CNP = Call, Propose, Award, Execute": +Fazy Contract Net Protocol + +### "RAFT = Replicated And Fault Tolerant": +Leader election + log replication + +### "Vickrey = Second price = Truthful": +Płacisz drugą cenę → opłaca się licytować prawdziwie + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Dlaczego aukcja Vickreya jest truthful?" +**Odpowiedź:** Płacisz drugą najwyższą cenę, nie swoją. Licytowanie poniżej wartości = ryzyko przegranej. Licytowanie powyżej = ryzyko przepłacenia. Optymalna strategia = licytuj prawdziwą wartość. + +### Q2: "Jak Raft radzi sobie z partycją sieci?" +**Odpowiedź:** Tylko partycja z większością węzłów może wybrać lidera i commitować. Mniejszość jest zablokowana (read-only lub niedostępna). Po naprawie partycji - synchronizacja logów. + +### Q3: "Czym różni się One-for-One od All-for-One supervision?" +**Odpowiedź:** One-for-One: restart tylko wadliwego aktora (izolacja błędu). All-for-One: restart wszystkich dzieci (gdy stan jest współdzielony/zależny). Wybór zależy od zależności między aktorami. + +--- + +## 🎯 Kluczowe punkty + +1. **Contract Net** = aukcja zadań między agentami +2. **Raft/PBFT** = konsensus w systemach rozproszonych +3. **Nash Q-Learning** = uczenie z uwzględnieniem innych +4. **Supervision** = "let it crash" + automatic recovery +5. **Shapley Value** = sprawiedliwy podział koalicji + +--- + +## 📖 Źródła + +1. Shoham, Leyton-Brown - "Multiagent Systems" +2. Ongaro, Ousterhout - "In Search of an Understandable Consensus Algorithm" (Raft) +3. Akka Documentation - Supervision +4. Sandholm - "Distributed Rational Decision Making" diff --git a/pytania/odpowiedzi/15-modelowanie-architektury.md b/pytania/odpowiedzi/15-modelowanie-architektury.md new file mode 100644 index 0000000..e353e73 --- /dev/null +++ b/pytania/odpowiedzi/15-modelowanie-architektury.md @@ -0,0 +1,219 @@ +# Pytanie 15: Metody modelowania architektury systemów informatycznych + +## Pytanie +**"Omówić metody modelowania architektury systemów informatycznych. Przedstawić cele i metody modelowania architektury."** + +Przedmiot: AIS (Architektura i Integracja Systemów) + +--- + +## 📚 Odpowiedź główna + +### 1. Cele modelowania architektury + +| Cel | Opis | +|-----|------| +| **Komunikacja** | Wspólny język dla stakeholderów | +| **Dokumentacja** | Zapis decyzji architektonicznych | +| **Analiza** | Weryfikacja atrybutów jakościowych | +| **Planowanie** | Roadmapa rozwoju systemu | +| **Zarządzanie złożonością** | Abstrakcja, dekompozycja | + +--- + +### 2. Frameworki architektoniczne + +#### TOGAF (The Open Group Architecture Framework) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ ADM (Architecture Development Method) │ +│ │ +│ Preliminary │ +│ ↓ │ +│ ┌─── A. Architecture Vision ───┐ │ +│ ↓ ↓ │ +│ H. Architecture ←───────────→ B. Business │ +│ Change Mgmt Architecture │ +│ ↑ ↓ │ +│ G. Implementation ←── Requirements ── C. Information │ +│ Governance Management Systems Arch │ +│ ↑ ↓ │ +│ F. Migration ←───────────→ D. Technology │ +│ Planning Architecture │ +│ ↑ ↓ │ +│ └─── E. Opportunities & Solutions ───┘ │ +└─────────────────────────────────────────────────────────────────┘ +``` + +**Domeny TOGAF:** +- Business Architecture +- Data Architecture +- Application Architecture +- Technology Architecture + +#### Zachman Framework + +``` + │ What │ How │ Where │ Who │ When │ Why +─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼───────── +Planner │ Data │ Function│ Network │ People │ Time │ Motivation +Owner │ Entity │ Process │ Location│ Org │ Schedule│ Goals +Designer │ Model │ System │ Distrib │ Role │ Workflow│ Rules +Builder │ Schema │ Program │ Infra │ UI │ Control │ Logic + │ │ │ │ │ │ +``` + +#### 4+1 View Model (Kruchten) + +``` + ┌─────────────────┐ + │ Scenarios │ + │ (Use Cases) │ + └────────┬────────┘ + │ + ┌────────────────────┼────────────────────┐ + ↓ ↓ ↓ +┌───────────────┐ ┌───────────────┐ ┌───────────────┐ +│ Logical │ │ Process │ │ Development │ +│ View │ │ View │ │ View │ +│ (funkcjonalna)│ │ (współbieżn.) │ │ (organizacja) │ +└───────────────┘ └───────────────┘ └───────────────┘ + │ + ┌────────┴────────┐ + │ Physical │ + │ View │ + │ (wdrożenie) │ + └─────────────────┘ +``` + +--- + +### 3. Notacje i języki modelowania + +#### UML (Unified Modeling Language) + +| Diagram | Zastosowanie | +|---------|--------------| +| **Component** | Struktura modułów | +| **Deployment** | Fizyczne rozmieszczenie | +| **Package** | Organizacja logiczna | +| **Sequence** | Interakcje czasowe | + +#### ArchiMate + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ Warstwy ArchiMate: │ +│ │ +│ ┌─────────────────────────────────────────────────────────────┐│ +│ │ Business Layer │ Actor, Role, Process, Service, Event ││ +│ ├─────────────────────────────────────────────────────────────┤│ +│ │ Application Layer │ Component, Interface, Function, Service ││ +│ ├─────────────────────────────────────────────────────────────┤│ +│ │ Technology Layer │ Node, Device, Network, Artifact ││ +│ └─────────────────────────────────────────────────────────────┘│ +│ │ +│ Aspekty: Passive (data), Behavior (process), Active (actor) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### C4 Model (Simon Brown) + +``` +Level 1: System Context - System w kontekście użytkowników +Level 2: Container - Aplikacje, bazy, serwisy +Level 3: Component - Wewnętrzna struktura kontenera +Level 4: Code - Klasy, interfejsy (opcjonalnie) + +Zasada: Zoom in/out między poziomami +``` + +--- + +### 4. ADR (Architecture Decision Records) + +```markdown +# ADR-001: Wybór bazy danych + +## Status: Accepted + +## Context +System wymaga przechowywania danych użytkowników... + +## Decision +Wybieramy PostgreSQL + +## Consequences ++ Dojrzały, stabilny ++ Wsparcie JSON +- Wymaga DBA +``` + +--- + +### 5. Metody analizy architektury + +#### ATAM (Architecture Tradeoff Analysis Method) + +``` +Fazy: +1. Present architecture +2. Identify quality attribute scenarios +3. Generate quality attribute utility tree +4. Analyze architectural approaches +5. Identify sensitivity & tradeoff points +6. Generate risks & non-risks +``` + +#### Quality Attributes (ISO 25010) + +| Atrybut | Opis | +|---------|------| +| **Performance** | Czas odpowiedzi, throughput | +| **Security** | CIA (Confidentiality, Integrity, Availability) | +| **Scalability** | Horizontal/Vertical scaling | +| **Maintainability** | Modyfikowalność, testowalność | +| **Reliability** | MTBF, MTTR | + +--- + +## 🧠 Mnemoniki + +### "TOGAF ADM = A-H cycle": +A-Vision, B-Business, C-IS, D-Tech, E-Opportunities, F-Migration, G-Governance, H-Change + +### "C4 = Context, Container, Component, Code": +4 poziomy zoomu architektury + +### "4+1 = LDPP + Scenarios": +Logical, Development, Process, Physical + Scenarios + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Jaka jest różnica między TOGAF a Zachman?" +**Odpowiedź:** TOGAF to metodyka (proces ADM), Zachman to taksonomia (klasyfikacja artefaktów). TOGAF mówi JAK tworzyć architekturę, Zachman CO dokumentować. + +### Q2: "Kiedy używać C4 vs ArchiMate?" +**Odpowiedź:** C4 dla programistów (proste, 4 poziomy), ArchiMate dla enterprise architects (formalne, warstwy biznes-aplikacja-technologia). + +--- + +## 🎯 Kluczowe punkty + +1. **TOGAF** = metodyka ADM + 4 domeny +2. **4+1** = 5 widoków (Logical, Process, Development, Physical, Scenarios) +3. **C4** = 4 poziomy zoomu +4. **ArchiMate** = 3 warstwy (Business, Application, Technology) +5. **ADR** = dokumentacja decyzji + +--- + +## 📖 Źródła + +1. TOGAF 9.2 Standard - The Open Group +2. Kruchten - "4+1 View Model" +3. Simon Brown - "C4 Model" (c4model.com) +4. ArchiMate 3.1 Specification diff --git a/pytania/odpowiedzi/16-wzorce-architektoniczne.md b/pytania/odpowiedzi/16-wzorce-architektoniczne.md new file mode 100644 index 0000000..10bbc76 --- /dev/null +++ b/pytania/odpowiedzi/16-wzorce-architektoniczne.md @@ -0,0 +1,234 @@ +# Pytanie 16: Wzorce architektoniczne + +## Pytanie +**"Czemu służą wzorce architektoniczne? Jak powstają? Jak są katalogowane? Omówić przykładowe wzorce architektoniczne."** + +Przedmiot: AIS (Architektura i Integracja Systemów) + +--- + +## 📚 Odpowiedź główna + +### 1. Cel wzorców architektonicznych + +| Cel | Opis | +|-----|------| +| **Reużywalność** | Sprawdzone rozwiązania typowych problemów | +| **Komunikacja** | Wspólne słownictwo ("używamy MVC") | +| **Dokumentacja** | Zapis wiedzy architektonicznej | +| **Jakość** | Adresowanie atrybutów jakościowych | +| **Edukacja** | Nauka z doświadczeń innych | + +--- + +### 2. Jak powstają wzorce + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ 1. PROBLEM pojawia się wielokrotnie │ +│ ↓ │ +│ 2. Różni architekci znajdują PODOBNE ROZWIĄZANIA │ +│ ↓ │ +│ 3. UOGÓLNIENIE - wyodrębnienie wspólnych elementów │ +│ ↓ │ +│ 4. DOKUMENTACJA w formie wzorca │ +│ ↓ │ +│ 5. WALIDACJA przez społeczność (peer review) │ +│ ↓ │ +│ 6. KATALOGOWANIE w książkach/repozytoriach │ +└─────────────────────────────────────────────────────────────────┘ +``` + +**Format opisu wzorca:** +- **Nazwa** - identyfikator +- **Kontekst** - kiedy stosować +- **Problem** - co rozwiązuje +- **Rozwiązanie** - struktura i zachowanie +- **Konsekwencje** - trade-offs +- **Znane zastosowania** - przykłady + +--- + +### 3. Katalogowanie wzorców + +| Katalog | Zakres | Przykłady | +|---------|--------|-----------| +| **POSA** (Pattern-Oriented Software Architecture) | Architektura | Layers, Pipes&Filters | +| **GoF** (Gang of Four) | Projektowe | Factory, Observer | +| **EIP** (Enterprise Integration Patterns) | Integracja | Message Router, Aggregator | +| **PoEAA** (Fowler) | Enterprise | Repository, Unit of Work | +| **Cloud Patterns** | Chmura | Circuit Breaker, Sidecar | + +--- + +### 4. Przykładowe wzorce architektoniczne + +#### Layered Architecture (Warstwy) + +``` +┌─────────────────────────────────────────┐ +│ Presentation Layer │ UI, Controllers +├─────────────────────────────────────────┤ +│ Business Logic Layer │ Services, Domain +├─────────────────────────────────────────┤ +│ Data Access Layer │ Repositories, ORM +├─────────────────────────────────────────┤ +│ Database │ SQL, NoSQL +└─────────────────────────────────────────┘ + +Zasada: Warstwa zna tylko warstwę bezpośrednio niższą ++ Separacja odpowiedzialności +- Sztywność, boilerplate +``` + +#### Microservices + +``` +┌─────┐ ┌─────┐ ┌─────┐ +│User │ │Order│ │Inv- │ +│Svc │ │Svc │ │entory│ +└──┬──┘ └──┬──┘ └──┬──┘ + │ │ │ + └────┬────┴────┬────┘ + │ │ + ┌────┴────┐ │ + │API Gate │────┘ + │ way │ + └─────────┘ + ++ Niezależne wdrożenia, skalowalność +- Złożoność operacyjna, komunikacja +``` + +#### Event-Driven Architecture (EDA) + +``` +┌──────────┐ event ┌──────────┐ +│ Producer │ ───────────→ │ Event │ +└──────────┘ │ Broker │ + │(Kafka) │ +┌──────────┐ event └────┬─────┘ +│ Consumer │ ←─────────────────┘ +│ A │ +└──────────┘ +┌──────────┐ event +│ Consumer │ ←─────────────────┘ +│ B │ +└──────────┘ + ++ Loose coupling, skalowalność +- Eventual consistency, debugging +``` + +#### CQRS (Command Query Responsibility Segregation) + +``` + Commands Queries + │ │ + ↓ ↓ + ┌──────────┐ ┌──────────┐ + │ Write │ │ Read │ + │ Model │ │ Model │ + └────┬─────┘ └────┬─────┘ + │ │ + ↓ ↓ + ┌──────────┐ sync ┌──────────┐ + │ Write │ ─────────→ │ Read │ + │ DB │ │ DB │ + └──────────┘ └──────────┘ + ++ Optymalizacja read/write osobno +- Złożoność, eventual consistency +``` + +#### Hexagonal Architecture (Ports & Adapters) + +``` + ┌─────────────────────────────────────┐ + │ Application Core │ + │ ┌───────────────────────────────┐ │ + Adapter │ │ │ │ Adapter + (REST) ──┼──│► Port Domain Port ◄├──┼── (DB) + │ │ (in) Logic (out) │ │ + │ └───────────────────────────────┘ │ + └─────────────────────────────────────┘ + ++ Testowalność, niezależność od frameworków +- Więcej kodu (adaptery) +``` + +#### Saga Pattern (dla transakcji rozproszonych) + +``` +Orchestration: +┌─────────┐ cmd ┌─────────┐ cmd ┌─────────┐ +│ Saga │ ───────→ │ Service │ ───────→ │ Service │ +│Orchestr.│ ←─reply── │ A │ ←─reply── │ B │ +└─────────┘ └─────────┘ └─────────┘ + │ + │ compensation (rollback) jeśli błąd + ↓ + +Choreography: +Service A ──event──→ Service B ──event──→ Service C + ↑ │ + └────────── compensation event ──────────┘ +``` + +--- + +### 5. Porównanie wzorców + +| Wzorzec | Skalowalność | Złożoność | Use Case | +|---------|--------------|-----------|----------| +| **Monolith** | Niska | Niska | MVP, małe zespoły | +| **Layered** | Średnia | Niska | Enterprise CRUD | +| **Microservices** | Wysoka | Wysoka | Duże systemy | +| **Event-Driven** | Wysoka | Średnia | Real-time, IoT | +| **CQRS** | Wysoka | Wysoka | Read-heavy systems | + +--- + +## 🧠 Mnemoniki + +### "LAMP = Layers, API Gateway, Microservices, Pub/Sub": +Ewolucja architektur + +### "CQRS = Commands mutate, Queries read": +Rozdzielenie zapisu od odczytu + +### "Hexagonal = Inside-Out testing": +Core nie zna zewnętrznych szczegółów + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Kiedy wybrać monolith zamiast microservices?" +**Odpowiedź:** Mały zespół (<10), MVP, niejasne granice domen, brak DevOps maturity. "Monolith first" - rozdzielaj gdy wiesz gdzie granice. + +### Q2: "Jak CQRS współpracuje z Event Sourcing?" +**Odpowiedź:** Event Sourcing zapisuje zdarzenia (nie stan), CQRS buduje read model z eventów. Razem: audit trail, time-travel, ale złożoność. + +### Q3: "Co to jest Strangler Fig Pattern?" +**Odpowiedź:** Migracja z monolitu do microservices. Nowe funkcje jako mikroserwisy, stare stopniowo zastępowane. Routing przez facade. Nazwa od figi dusiciela. + +--- + +## 🎯 Kluczowe punkty + +1. **Wzorce** = sprawdzone rozwiązania typowych problemów +2. **Katalogi:** POSA, GoF, EIP, PoEAA +3. **Layered** = separacja, proste, sztywne +4. **Microservices** = niezależność, złożoność ops +5. **Event-Driven** = loose coupling, eventual consistency +6. **CQRS** = osobne modele read/write + +--- + +## 📖 Źródła + +1. Buschmann et al. - "POSA Vol. 1" +2. Fowler - "Patterns of Enterprise Application Architecture" +3. Hohpe, Woolf - "Enterprise Integration Patterns" +4. Richardson - "Microservices Patterns" diff --git a/pytania/odpowiedzi/17-optymalizacja-nieliniowa.md b/pytania/odpowiedzi/17-optymalizacja-nieliniowa.md new file mode 100644 index 0000000..285ab83 --- /dev/null +++ b/pytania/odpowiedzi/17-optymalizacja-nieliniowa.md @@ -0,0 +1,208 @@ +# Pytanie 17: Optymalizacja nieliniowa - warunki optymalności + +## Pytanie +**"Przedstawić warunki konieczne i dostateczne optymalności różniczkowalnych zadań optymalizacji bez ograniczeń i z ograniczeniami oraz warunki regularności i omówić metody poszukiwania rozwiązań zadań optymalizacji nieliniowej."** + +Przedmiot: AMO (Analiza i Metody Optymalizacji) + +--- + +## 📚 Odpowiedź główna + +### 1. Optymalizacja bez ograniczeń + +#### Problem +$$\min_{x \in \mathbb{R}^n} f(x)$$ + +#### Warunki konieczne (I rzędu) +Jeśli $x^*$ jest minimum lokalnym i $f$ jest różniczkowalna: +$$\nabla f(x^*) = 0$$ + +(Gradient zerowy - punkt stacjonarny) + +#### Warunki dostateczne (II rzędu) +Jeśli $\nabla f(x^*) = 0$ oraz hesjan $H(x^*) = \nabla^2 f(x^*)$: + +| Hesjan | Wniosek | +|--------|---------| +| $H \succ 0$ (dodatnio określony) | **Minimum lokalne** | +| $H \prec 0$ (ujemnie określony) | Maximum lokalne | +| $H$ nieokreślony | Punkt siodłowy | +| $H \succeq 0$ (półdodatni) | Brak wniosku | + +**Sprawdzenie:** Wszystkie wartości własne $\lambda_i > 0 \Rightarrow H \succ 0$ + +--- + +### 2. Optymalizacja z ograniczeniami + +#### Problem ogólny +$$\min_{x} f(x)$$ +$$\text{s.t. } g_i(x) \leq 0, \quad i = 1, \ldots, m$$ +$$\quad\quad h_j(x) = 0, \quad j = 1, \ldots, p$$ + +#### Lagrangian +$$L(x, \lambda, \mu) = f(x) + \sum_{i=1}^{m} \lambda_i g_i(x) + \sum_{j=1}^{p} \mu_j h_j(x)$$ + +--- + +### 3. Warunki KKT (Karush-Kuhn-Tucker) + +#### Warunki konieczne I rzędu + +Jeśli $x^*$ jest minimum i spełnione są warunki regularności: + +1. **Stacjonarność:** +$$\nabla_x L(x^*, \lambda^*, \mu^*) = 0$$ + +2. **Dopuszczalność pierwotna:** +$$g_i(x^*) \leq 0, \quad h_j(x^*) = 0$$ + +3. **Dopuszczalność dualna:** +$$\lambda_i^* \geq 0$$ + +4. **Komplementarność:** +$$\lambda_i^* g_i(x^*) = 0 \quad \forall i$$ + +``` +KKT interpretacja geometryczna: + + ∇f(x*) + ↑ + │ ∇g₁(x*) + │ ↗ + ─────●───── (granica ograniczenia) + x* + +W optimum: ∇f = -λ∇g (przeciwne kierunki, λ≥0) +``` + +--- + +### 4. Warunki regularności (Constraint Qualification) + +Warunki zapewniające, że KKT są konieczne: + +| Warunek | Definicja | +|---------|-----------| +| **LICQ** (Linear Independence CQ) | Gradienty aktywnych ograniczeń liniowo niezależne | +| **MFCQ** (Mangasarian-Fromovitz CQ) | Słabsza wersja LICQ | +| **Slater** | Istnieje punkt ściśle wewnątrz (dla wypukłych) | + +**LICQ:** $\{\nabla g_i(x^*) : g_i(x^*) = 0\} \cup \{\nabla h_j(x^*)\}$ są liniowo niezależne + +--- + +### 5. Warunki dostateczne II rzędu + +Jeśli spełnione KKT i dla hesjanu Lagrangianu: +$$d^T \nabla_{xx}^2 L(x^*, \lambda^*, \mu^*) d > 0$$ + +dla wszystkich $d \neq 0$ spełniających: +- $\nabla g_i(x^*)^T d = 0$ dla aktywnych $g_i$ +- $\nabla h_j(x^*)^T d = 0$ dla wszystkich $h_j$ + +To $x^*$ jest **ścisłym minimum lokalnym**. + +--- + +### 6. Metody optymalizacji nieliniowej + +#### Metody gradientowe (bez ograniczeń) + +| Metoda | Kierunek | Zbieżność | +|--------|----------|-----------| +| **Gradient Descent** | $d = -\nabla f$ | Liniowa | +| **Newton** | $d = -H^{-1}\nabla f$ | Kwadratowa | +| **BFGS** | Quasi-Newton | Superlinearna | +| **Conjugate Gradient** | Sprzężone kierunki | Superlinearna | + +``` +Gradient Descent: +x_{k+1} = x_k - α_k ∇f(x_k) + +Newton: +x_{k+1} = x_k - [∇²f(x_k)]^{-1} ∇f(x_k) +``` + +#### Metody z ograniczeniami + +| Metoda | Idea | +|--------|------| +| **Kary zewnętrznej** | $\min f(x) + \rho \sum \max(0, g_i)^2$ | +| **Kary wewnętrznej (Barrier)** | $\min f(x) - \mu \sum \log(-g_i)$ | +| **SQP** (Sequential Quadratic Programming) | Iteracyjne rozwiązywanie QP | +| **Interior Point** | Barrier + Newton | +| **Augmented Lagrangian** | Lagrangian + kara | + +#### SQP - Algorytm + +``` +Repeat: +1. Rozwiąż podproblem QP: + min ∇f(x_k)^T d + ½ d^T H_k d + s.t. g_i(x_k) + ∇g_i(x_k)^T d ≤ 0 + h_j(x_k) + ∇h_j(x_k)^T d = 0 + +2. x_{k+1} = x_k + α_k d_k + +3. Aktualizuj H_k (BFGS) +``` + +--- + +### 7. Porównanie metod + +| Metoda | Ograniczenia | Złożoność iter. | Zbieżność | +|--------|--------------|-----------------|-----------| +| **Gradient** | Bez | O(n) | Liniowa | +| **Newton** | Bez | O(n³) | Kwadratowa | +| **BFGS** | Bez | O(n²) | Superlinearna | +| **SQP** | Z | O(n³) per QP | Superlinearna | +| **Interior Point** | Z | O(n³) | Polinomialna | + +--- + +## 🧠 Mnemoniki + +### "KKT = Keep Killing Troubles": +- **K**ondycja stacjonarności (∇L = 0) +- **K**onieczność dopuszczalności (g ≤ 0, h = 0, λ ≥ 0) +- **T**rick komplementarności (λg = 0) + +### "Hesjan dodatni = Minimum": +$H \succ 0$ → punkt jest minimum (jak miska) + +### "LICQ = Linear Independence": +Gradienty aktywnych ograniczeń muszą być liniowo niezależne + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Co oznacza warunek komplementarności λᵢgᵢ = 0?" +**Odpowiedź:** Albo ograniczenie nieaktywne ($g_i < 0$, wtedy $\lambda_i = 0$), albo aktywne ($g_i = 0$, wtedy $\lambda_i \geq 0$). Mnożnik niezerowy tylko dla "ciasnych" ograniczeń. + +### Q2: "Kiedy KKT są warunkami dostatecznymi?" +**Odpowiedź:** Dla problemów wypukłych (f wypukła, g wypukłe, h liniowe). Wtedy każdy punkt KKT jest globalnym minimum. + +### Q3: "Jaka jest przewaga BFGS nad Newtonem?" +**Odpowiedź:** BFGS nie wymaga obliczania hesjanu (tylko gradienty), przybliża hesjan iteracyjnie. O(n²) zamiast O(n³) per iteracja. Bardziej odporny na nieścisłości. + +--- + +## 🎯 Kluczowe punkty + +1. **Bez ograniczeń:** $\nabla f = 0$ (konieczny), $H \succ 0$ (dostateczny) +2. **Z ograniczeniami:** KKT = stacjonarność + dopuszczalność + komplementarność +3. **Regularność:** LICQ, Slater - warunki na poprawność KKT +4. **Metody:** Gradient, Newton, BFGS (bez), SQP, Interior Point (z) +5. **Wypukłość:** KKT konieczne i dostateczne + +--- + +## 📖 Źródła + +1. Boyd, Vandenberghe - "Convex Optimization" +2. Nocedal, Wright - "Numerical Optimization" +3. Bazaraa et al. - "Nonlinear Programming" diff --git a/pytania/odpowiedzi/18-optymalizacja-liniowa-kwadratowa.md b/pytania/odpowiedzi/18-optymalizacja-liniowa-kwadratowa.md new file mode 100644 index 0000000..3ea955f --- /dev/null +++ b/pytania/odpowiedzi/18-optymalizacja-liniowa-kwadratowa.md @@ -0,0 +1,209 @@ +# Pytanie 18: Optymalizacja liniowa i kwadratowa + +## Pytanie +**"Omówić metody rozwiązywania zadań liniowych i kwadratowych optymalizacji."** + +Przedmiot: AMO (Analiza i Metody Optymalizacji) + +--- + +## 📚 Odpowiedź główna + +### 1. Programowanie liniowe (LP) + +#### Postać standardowa +$$\min c^T x$$ +$$\text{s.t. } Ax = b, \quad x \geq 0$$ + +#### Metoda Simplex + +``` +Idea: Przechodzenie po wierzchołkach wielościanu dopuszczalnego + + c^T x = const + ↘ + ●───────● + /│ /│ + / │ / │ Wielościan dopuszczalny + ●──┼────● │ + │ ●────┼──● + │ / │ / + │/ │/ + ●───────● ← optimum (wierzchołek) +``` + +**Algorytm:** +1. Znajdź bazowe rozwiązanie dopuszczalne (BFS) +2. Sprawdź optymalność (reduced costs ≥ 0) +3. Wybierz zmienną wchodzącą (pivot column) +4. Wybierz zmienną wychodzącą (ratio test) +5. Wykonaj pivot, powtórz + +**Złożoność:** O(2^n) worst-case, ale praktycznie bardzo szybki + +#### Metoda punktu wewnętrznego (Interior Point) + +``` +Start wewnątrz wielościanu, zbieżność do optimum przez wnętrze: + + ●───────────● + /│ /│ + / │ ●→●→● / │ Ścieżka centralna + ●──┼───────● │ + │ ●───────┼──● + │ / │ / + │/ │/ + ●──────────● ← optimum +``` + +**Algorytm Barrier:** +$$\min c^T x - \mu \sum_{i} \ln(x_i)$$ + +Zmniejszaj μ → 0, rozwiązuj układy Newtona + +**Złożoność:** O(n^3.5 L) - wielomianowa + +#### Porównanie LP + +| Cecha | Simplex | Interior Point | +|-------|---------|----------------| +| Złożoność teoretyczna | Wykładnicza | Wielomianowa | +| Praktyczna wydajność | Bardzo dobra | Dobra dla dużych | +| Warm start | Tak | Nie | +| Rozwiązanie bazowe | Tak | Nie (wewnętrzne) | + +--- + +### 2. Programowanie kwadratowe (QP) + +#### Postać ogólna +$$\min \frac{1}{2} x^T Q x + c^T x$$ +$$\text{s.t. } Ax \leq b, \quad Ex = d$$ + +Gdzie Q jest macierzą symetryczną. + +#### Klasyfikacja + +| Q | Typ | Rozwiązywalność | +|---|-----|-----------------| +| Q ≻ 0 (dodatnio określona) | Wypukły QP | Globalnie jednoznaczne | +| Q ⪰ 0 (półdodatnia) | Wypukły QP | Może wiele rozwiązań | +| Q nieokreślona | Niewypukły QP | NP-trudny | + +--- + +### 3. Metody rozwiązywania QP + +#### Active Set Method + +``` +Idea: Traktuj aktywne ograniczenia jako równości + +1. Zgadnij zbiór aktywnych ograniczeń W +2. Rozwiąż QP z ograniczeniami W jako równości +3. Sprawdź: + - Czy rozwiązanie dopuszczalne? (jeśli nie: usuń z W) + - Czy mnożniki ≥ 0? (jeśli nie: dodaj do W) +4. Powtarzaj do zbieżności +``` + +**Zalety:** Dokładne rozwiązanie, warm start +**Wady:** Liczba iteracji zależy od kombinatoryki + +#### Metody punktu wewnętrznego dla QP + +``` +Barrier problem: +min ½x^TQx + c^Tx - μ Σ ln(s_i) +s.t. Ax + s = b + +KKT system → rozwiązuj Newton +Zmniejszaj μ → 0 +``` + +**Złożoność:** O(n^3) per iteracja, O(√n) iteracji + +#### Gradient Projection Method + +``` +Dla QP z prostymi ograniczeniami (x ∈ [l, u]): + +1. Kierunek: d = -∇f(x) = -(Qx + c) +2. Krok: x_{k+1} = P[x_k + α_k d_k] + +Gdzie P[·] = projekcja na [l, u] +``` + +--- + +### 4. Przypadki szczególne + +#### Least Squares (najmniejsze kwadraty) +$$\min \|Ax - b\|_2^2 = \min x^T A^T A x - 2b^T A x + b^T b$$ + +**Rozwiązanie:** $(A^T A)x = A^T b$ (równanie normalne) + +#### Support Vector Machine (SVM) +$$\min \frac{1}{2}\|w\|^2$$ +$$\text{s.t. } y_i(w^T x_i + b) \geq 1$$ + +→ QP z dodatnio określoną macierzą + +#### Portfolio Optimization (Markowitz) +$$\min \frac{1}{2} x^T \Sigma x \quad \text{(ryzyko)}$$ +$$\text{s.t. } \mu^T x \geq r, \quad \sum x_i = 1, \quad x \geq 0$$ + +--- + +### 5. Narzędzia + +| Narzędzie | Typ | Metody | +|-----------|-----|--------| +| **CPLEX** | Komercyjny | Simplex, Barrier, QP | +| **Gurobi** | Komercyjny | Simplex, Barrier, QP | +| **GLPK** | Open source | Simplex | +| **OSQP** | Open source | ADMM dla QP | +| **CVXPY** | Python | Interfejs do solverów | + +--- + +## 🧠 Mnemoniki + +### "Simplex = Surface walking": +Chodzi po wierzchołkach (powierzchni) wielościanu + +### "Interior Point = Inside path": +Idzie przez wnętrze do optimum + +### "Q dodatnia = QP wypukły = łatwy": +Macierz Q określa trudność problemu + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Kiedy Simplex jest lepszy od Interior Point?" +**Odpowiedź:** Małe/średnie problemy, warm start (sekwencja podobnych LP), potrzeba rozwiązania bazowego. Interior Point lepszy dla bardzo dużych, rzadkich problemów. + +### Q2: "Co to jest dualność w LP?" +**Odpowiedź:** Każdy LP (primal) ma dual. Silna dualność: opt(primal) = opt(dual). Mnożniki Lagrange'a = zmienne dualne. Complementary slackness: x_i > 0 ⟹ ograniczenie dualne aktywne. + +### Q3: "Jak rozwiązać niewypukły QP?" +**Odpowiedź:** NP-trudny, metody: Branch & Bound, SDP relaxation, lokalne metody (wiele startów). Brak gwarancji globalnego optimum w czasie wielomianowym. + +--- + +## 🎯 Kluczowe punkty + +1. **LP:** Simplex (wierzchołki), Interior Point (wnętrze) +2. **QP wypukły:** Q ⪰ 0, Active Set lub Interior Point +3. **QP niewypukły:** NP-trudny +4. **Narzędzia:** CPLEX, Gurobi, GLPK, OSQP + +--- + +## 📖 Źródła + +1. Nocedal, Wright - "Numerical Optimization" +2. Boyd, Vandenberghe - "Convex Optimization" +3. Bertsimas, Tsitsiklis - "Introduction to Linear Optimization" diff --git a/pytania/odpowiedzi/19-mfcc-lpc-parametryzacja.md b/pytania/odpowiedzi/19-mfcc-lpc-parametryzacja.md new file mode 100644 index 0000000..62ce555 --- /dev/null +++ b/pytania/odpowiedzi/19-mfcc-lpc-parametryzacja.md @@ -0,0 +1,204 @@ +# Pytanie 19: MFCC i LPC - parametryzacja sygnału mowy + +## Pytanie +**"Przedstawić metody wyznaczania cech (parametryzacji) sygnału mowy: MFCC (cechy mel-cepstralne) i LPC (cechy według liniowej predykcji)."** + +Przedmiot: EASAR (Elementy Automatycznego Sterowania i Rozpoznawania) + +--- + +## 📚 Odpowiedź główna + +### 1. Cel parametryzacji mowy + +- **Redukcja wymiarowości:** 16kHz × 16bit → ~13-40 cech/ramkę +- **Ekstrakcja informacji fonetycznej** +- **Usunięcie informacji mówcy** (częściowo) +- **Reprezentacja kompaktowa** dla modeli (HMM, DNN) + +--- + +### 2. MFCC (Mel-Frequency Cepstral Coefficients) + +#### Pipeline MFCC + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ Sygnał mowy │ +│ ↓ │ +│ [Pre-emphasis] ──→ y[n] = x[n] - α·x[n-1], α ≈ 0.97 │ +│ ↓ │ +│ [Ramkowanie] ──→ 20-30ms ramki, 10ms przesunięcie │ +│ ↓ │ +│ [Okienkowanie] ──→ Hamming: w[n] = 0.54 - 0.46cos(2πn/N) │ +│ ↓ │ +│ [FFT] ──→ Widmo mocy |X(k)|² │ +│ ↓ │ +│ [Filtracja Mel] ──→ Bank filtrów trójkątnych (26-40) │ +│ ↓ │ +│ [Log] ──→ log(energia w pasmach) │ +│ ↓ │ +│ [DCT] ──→ Discrete Cosine Transform │ +│ ↓ │ +│ MFCC (12-13 współczynników) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### Skala Mel + +``` +Percepcja częstotliwości przez człowieka jest nieliniowa: + +mel(f) = 2595 · log₁₀(1 + f/700) + +Hz: 0 500 1000 2000 4000 8000 +Mel: 0 607 1000 1500 2146 2840 + + Bank filtrów Mel: + ╱╲ ╱╲ ╱╲ ╱╲ ╱╲ ╱╲ + ╱ ╲ ╱ ╲ ╱ ╲ ╱ ╲ ╱ ╲ ╱ ╲ + ╱ ╳ ╳ ╳ ╳ ╳ ╲ + ──────────────────────────────────→ f + 0 8000 Hz + + Filtry gęściej w niskich częstotliwościach +``` + +#### Cechy dynamiczne (Delta, Delta-Delta) + +``` +Δ MFCC (velocity): +Δc[t] = Σ_{n=1}^{N} n·(c[t+n] - c[t-n]) / (2·Σ n²) + +ΔΔ MFCC (acceleration): +ΔΔc[t] = Δ(Δc[t]) + +Typowy wektor: 13 MFCC + 13 Δ + 13 ΔΔ = 39 cech +``` + +--- + +### 3. LPC (Linear Predictive Coding) + +#### Idea + +Model mowy jako filtr pobudzany: +- **Dźwięczne:** pobudzenie okresowe (struny głosowe) +- **Bezdźwięczne:** pobudzenie szumowe + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ │ +│ Pobudzenie e[n] Filtr H(z) Sygnał mowy s[n] │ +│ ┌───┐ ┌─────────┐ │ +│ ──→ │ G │ ──────→ │ 1/A(z) │ ──────→ │ +│ └───┘ └─────────┘ │ +│ │ +│ gdzie A(z) = 1 - Σ_{k=1}^{p} a_k z^{-k} │ +│ │ +│ Predykcja: ŝ[n] = Σ_{k=1}^{p} a_k s[n-k] │ +│ Błąd: e[n] = s[n] - ŝ[n] │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### Wyznaczanie współczynników LPC + +**Metoda autokorelacji (Levinson-Durbin):** + +``` +1. Oblicz autokorelację: R[k] = Σ s[n]·s[n+k] + +2. Algorytm Levinsona-Durbina: + E₀ = R[0] + for i = 1 to p: + k_i = (R[i] - Σ_{j=1}^{i-1} a_{i-1,j}·R[i-j]) / E_{i-1} + a_{i,i} = k_i + for j = 1 to i-1: + a_{i,j} = a_{i-1,j} - k_i·a_{i-1,i-j} + E_i = (1 - k_i²)·E_{i-1} + +3. Wynik: współczynniki a₁, a₂, ..., a_p +``` + +**Typowo:** p = 10-16 dla mowy (8kHz), p = 16-20 (16kHz) + +#### Parametry pochodne LPC + +| Parametr | Opis | +|----------|------| +| **Współczynniki LPC** | a₁, ..., a_p | +| **PARCOR (k)** | Współczynniki odbicia | +| **LSF/LSP** | Line Spectral Frequencies | +| **Cepstrum LPC** | Transformacja współczynników | + +--- + +### 4. Porównanie MFCC vs LPC + +| Cecha | MFCC | LPC | +|-------|------|-----| +| **Podstawa** | Percepcja słuchowa | Model produkcji mowy | +| **Filtracja** | Bank filtrów Mel | Model all-pole | +| **Wymiarowość** | 12-13 + delty | 10-20 | +| **Zastosowanie** | Rozpoznawanie mowy | Kodowanie, synteza | +| **Korelacja** | Niska (DCT dekoreluje) | Wysoka | +| **Interpolacja** | Trudna | Łatwa (LSF) | + +--- + +### 5. Rozszerzenia + +#### PLP (Perceptual Linear Prediction) +Łączy LPC z percepcją słuchową: +- Filtracja w skali Bark +- Krzywa równej głośności +- Kompresja intensity-loudness + +#### Filter Banks (dla DNN) +Nowoczesne podejście: +- Log Mel filterbanks (bez DCT) +- 40-80 filtrów +- DNN uczy się własnych cech + +--- + +## 🧠 Mnemoniki + +### "MFCC = Mel + FFT + Cepstrum": +Skala Mel → FFT → Log → DCT + +### "LPC = Linear Prediction Coefficients": +Przewiduj próbkę z p poprzednich + +### "39 = 13 + 13 + 13": +MFCC + Delta + Delta-Delta + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Dlaczego używamy skali Mel?" +**Odpowiedź:** Percepcja częstotliwości przez człowieka jest logarytmiczna. Różnica 100-200Hz jest bardziej słyszalna niż 4000-4100Hz. Mel modeluje tę nieliniowość. + +### Q2: "Co to jest cepstrum?" +**Odpowiedź:** "Widmo widma" - IFFT(log(|FFT(x)|)). Rozdziela pobudzenie (pitch) od filtra (formantów). MFCC używa DCT zamiast IFFT dla lepszych właściwości. + +### Q3: "Dlaczego LPC jest używane w kodowaniu mowy (CELP)?" +**Odpowiedź:** Kompaktowa reprezentacja (~10 współczynników). Łatwa interpolacja (LSF). Efektywna synteza (filtr IIR). Standard w GSM, VoIP. + +--- + +## 🎯 Kluczowe punkty + +1. **MFCC:** Pre-emphasis → Ramki → FFT → Mel → Log → DCT +2. **LPC:** Model all-pole, predykcja liniowa, Levinson-Durbin +3. **Wymiary:** MFCC ~39, LPC ~10-20 +4. **MFCC** dla rozpoznawania, **LPC** dla kodowania/syntezy + +--- + +## 📖 Źródła + +1. Rabiner, Schafer - "Digital Processing of Speech Signals" +2. Huang et al. - "Spoken Language Processing" +3. HTK Book - Feature extraction diff --git a/pytania/odpowiedzi/20-hmm-vs-deep-learning-mowa.md b/pytania/odpowiedzi/20-hmm-vs-deep-learning-mowa.md new file mode 100644 index 0000000..b5dbe88 --- /dev/null +++ b/pytania/odpowiedzi/20-hmm-vs-deep-learning-mowa.md @@ -0,0 +1,221 @@ +# Pytanie 20: Rozpoznawanie mowy - HMM vs Deep Learning + +## Pytanie +**"Przedstawić klasyczną metodę rozpoznawania mowy opartą o HMM (Ukryte Modele Markowa). Porównać ją z metodami korzystającymi z głębokich sieci neuronowych."** + +Przedmiot: EASAR (Elementy Automatycznego Sterowania i Rozpoznawania) + +--- + +## 📚 Odpowiedź główna + +### 1. System rozpoznawania mowy - architektura + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ Sygnał audio │ +│ ↓ │ +│ [Ekstrakcja cech] ──→ MFCC/Filterbanks │ +│ ↓ │ +│ [Model akustyczny] ──→ HMM / DNN / Hybrid │ +│ ↓ │ +│ [Model językowy] ──→ N-gram / RNN-LM │ +│ ↓ │ +│ [Dekoder] ──→ Wyszukiwanie najlepszej hipotezy │ +│ ↓ │ +│ Tekst │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 2. HMM (Hidden Markov Model) - klasyczne podejście + +#### Struktura HMM dla fonemu + +``` + a₁₂ a₂₃ a₃₄ + ┌────────→ ┌────────→ ┌────────→ + │ │ │ +┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌───┐ +│ 1 │ │ 2 │ │ 3 │ │ 4 │ +│ │ │ │ │ │ │END│ +└─┬─┘ └─┬─┘ └─┬─┘ └───┘ + │ │ │ + └──────────┴──────────┘ + a₁₁ a₂₂ a₃₃ (self-loops) + +Każdy stan emituje obserwacje (MFCC) według rozkładu GMM: +b_j(o) = Σ_m c_{jm} N(o; μ_{jm}, Σ_{jm}) +``` + +#### Parametry HMM + +| Symbol | Opis | +|--------|------| +| **A** | Macierz przejść (a_ij) | +| **B** | Rozkłady emisji (GMM) | +| **π** | Rozkład początkowy | + +#### Trzy problemy HMM + +| Problem | Algorytm | Zastosowanie | +|---------|----------|--------------| +| **Ewaluacja:** P(O\|λ) | Forward-Backward | Scoring | +| **Dekodowanie:** argmax P(Q\|O) | Viterbi | Rozpoznawanie | +| **Uczenie:** argmax P(O\|λ) | Baum-Welch (EM) | Trening | + +#### Algorytm Viterbi + +``` +Znajdź najbardziej prawdopodobną sekwencję stanów: + +α_t(j) = max_{i} [α_{t-1}(i) · a_{ij}] · b_j(o_t) + +Backtrace: ψ_t(j) = argmax_{i} [α_{t-1}(i) · a_{ij}] + + t=1 t=2 t=3 t=4 +s=1 ●──────●──────●──────● + │╲ │╲ │╲ │ +s=2 ●──────●──────●──────● + │╲ │╲ │╲ │ +s=3 ●──────●──────●──────● + Viterbi trellis +``` + +--- + +### 3. Deep Learning w rozpoznawaniu mowy + +#### DNN-HMM Hybrid (2012+) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ Klasyczne GMM-HMM: │ +│ Cechy MFCC → GMM → P(o|stan) → HMM → dekodowanie │ +│ │ +│ Hybrid DNN-HMM: │ +│ Cechy → DNN → P(stan|o) → P(o|stan) = P(stan|o)/P(stan) │ +│ ↓ │ +│ HMM → dekodowanie │ +│ │ +│ DNN zastępuje GMM jako model emisji! │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### End-to-End Models (2014+) + +``` +CTC (Connectionist Temporal Classification): +┌──────────────────────────────────────────────────────────────┐ +│ Audio → [LSTM/Transformer] → P(y_t|x) → CTC Loss → Tekst │ +│ │ +│ CTC pozwala na różne wyrównania: │ +│ "h-e-l-l-o" = "hh-ee-ll-lo" = "-h-e-l-l-o-" │ +│ (blank = '-') │ +└──────────────────────────────────────────────────────────────┘ + +Attention-based (Seq2Seq): +┌──────────────────────────────────────────────────────────────┐ +│ Audio → [Encoder] → [Attention] → [Decoder] → Tekst │ +│ ↓ │ +│ Wyrównanie uczone │ +│ │ +│ Modele: LAS (Listen Attend Spell), Transformer ASR │ +└──────────────────────────────────────────────────────────────┘ +``` + +#### Transformer ASR (2020+) + +``` +Whisper, Wav2Vec 2.0, Conformer: + +Audio waveform + ↓ +[CNN Feature Encoder] + ↓ +[Transformer Encoder] × N + ↓ +[CTC / Attention Decoder] + ↓ +Tekst + +Pre-training: Self-supervised na dużych danych +Fine-tuning: Supervised na labeled data +``` + +--- + +### 4. Porównanie HMM vs DNN + +| Aspekt | GMM-HMM | DNN-HMM | End-to-End | +|--------|---------|---------|------------| +| **Model akustyczny** | GMM | DNN | DNN | +| **Model czasowy** | HMM | HMM | CTC/Attention | +| **Wyrównanie** | Viterbi | Viterbi | Uczone/CTC | +| **Trening** | EM (Baum-Welch) | Backprop | Backprop | +| **Interpretowalność** | Wysoka | Średnia | Niska | +| **Dane treningowe** | Małe | Średnie | Duże | +| **WER (Word Error Rate)** | ~15-20% | ~8-12% | ~3-5% | +| **Latencja** | Niska | Średnia | Zmienna | + +--- + +### 5. Ewolucja wydajności + +``` +WER na Switchboard (telefon): + +Rok Model WER +2010 GMM-HMM ~18% +2012 DNN-HMM ~12% +2015 LSTM-HMM ~8% +2017 LAS (Seq2Seq) ~6% +2020 Conformer ~4% +2023 Whisper Large ~3% + Poziom ludzki ~4% +``` + +--- + +## 🧠 Mnemoniki + +### "HMM = Hidden states + Markov + Model": +Ukryte stany, przejścia markowskie, emisje obserwacji + +### "Viterbi = Find best path": +Dynamiczne programowanie dla najlepszej ścieżki + +### "CTC = Collapse The Characters": +Usuwa powtórzenia i blanki → tekst + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Co to jest forced alignment?" +**Odpowiedź:** Viterbi z ograniczeniem do znanej transkrypcji. Wyznacza granice czasowe fonemów/słów. Używane do tworzenia danych treningowych i TTS. + +### Q2: "Dlaczego DNN jest lepszy od GMM?" +**Odpowiedź:** DNN może modelować złożone, nieliniowe zależności. GMM zakłada mieszaninę Gaussianów (często niewystarczające). DNN korzysta z kontekstu (wiele ramek na wejściu). + +### Q3: "Co to jest language model fusion?" +**Odpowiedź:** Łączenie modelu akustycznego z językowym: P(W|O) ∝ P(O|W)·P(W)^α. Shallow fusion (podczas dekodowania) lub deep fusion (wspólny trening). + +--- + +## 🎯 Kluczowe punkty + +1. **HMM:** Stany ukryte, GMM emisje, Viterbi dekodowanie +2. **DNN-HMM Hybrid:** DNN zastępuje GMM, HMM dla czasu +3. **End-to-End:** CTC lub Attention, bez HMM +4. **Trend:** Większe modele, więcej danych, mniej inżynierii cech + +--- + +## 📖 Źródła + +1. Rabiner - "A Tutorial on HMM" +2. Hinton et al. - "Deep Neural Networks for Acoustic Modeling" (2012) +3. Graves et al. - "CTC" (2006) +4. Chan et al. - "LAS" (2016) diff --git a/pytania/odpowiedzi/21-agent-upostaciowiony-roboty.md b/pytania/odpowiedzi/21-agent-upostaciowiony-roboty.md new file mode 100644 index 0000000..ae81914 --- /dev/null +++ b/pytania/odpowiedzi/21-agent-upostaciowiony-roboty.md @@ -0,0 +1,247 @@ +# Pytanie 21: Agent upostaciowiony w specyfikacji sterowników robotów + +## Pytanie +**"Jak wykorzystuje się agenta upostaciowionego do specyfikacji sterowników robotów?"** + +Przedmiot: ERPM (Elementy Robotyki i Projektowania Mechatronicznego) + +--- + +## 📚 Odpowiedź główna + +### 1. Agent upostaciowiony (Embodied Agent) + +#### Definicja + +**Agent upostaciowiony** = agent posiadający fizyczne ciało, osadzony w rzeczywistym środowisku, zdolny do: +- **Percepcji** poprzez sensory +- **Działania** poprzez efektory +- **Interakcji** ze środowiskiem + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ ŚRODOWISKO FIZYCZNE │ +│ │ +│ ┌───────────────────────────────────────────────┐ │ +│ │ ROBOT (Agent upostaciowiony) │ │ +│ │ │ │ +│ │ Sensory Sterownik Efektory │ │ +│ │ ┌─────┐ ┌─────────┐ ┌─────┐ │ │ +│ │ │Kamera│───────→│ Agent │─────→│Motor│ │ │ +│ │ │LIDAR │ │ Logic │ │Grip │ │ │ +│ │ │IMU │ │ (BDI) │ │Servo│ │ │ +│ │ └─────┘ └─────────┘ └─────┘ │ │ +│ │ ↑ ↓ │ │ +│ │ └────────────────────────────────┘ │ │ +│ │ Sprzężenie zwrotne │ │ +│ └───────────────────────────────────────────────┘ │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 2. Specyfikacja sterownika robota + +#### Architektura agentowa sterownika + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ WARSTWA DELIBERACYJNA (Agent BDI) │ +│ ┌─────────────────────────────────────────────────────────┐ │ +│ │ Beliefs: mapa, pozycja, stan zadania │ │ +│ │ Desires: cel nawigacji, zadanie manipulacji │ │ +│ │ Intentions: aktualny plan działania │ │ +│ └─────────────────────────────────────────────────────────┘ │ +│ ↓ │ +│ WARSTWA WYKONAWCZA (Reactive behaviors) │ +│ ┌─────────────────────────────────────────────────────────┐ │ +│ │ Unikanie kolizji, śledzenie ścieżki, chwytanie │ │ +│ └─────────────────────────────────────────────────────────┘ │ +│ ↓ │ +│ WARSTWA SPRZĘTOWA (HAL) │ +│ ┌─────────────────────────────────────────────────────────┐ │ +│ │ Sterowniki silników, protokoły sensorów │ │ +│ └─────────────────────────────────────────────────────────┘ │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 3. Formalny model agenta + +#### Cykl percepcja-akcja + +``` +Agent: Environment → Action +Agent: Percept* → Action (historia percepcji) + +Formalnie: + see: E → P (funkcja percepcji) + action: P* → A (funkcja decyzyjna) + next: E × A → E (funkcja przejścia środowiska) +``` + +#### Specyfikacja w logice temporalnej + +``` +Przykład specyfikacji bezpieczeństwa: +□(obstacle_detected → ¬move_forward) +"Zawsze gdy wykryto przeszkodę, nie jedź do przodu" + +Specyfikacja żywotności: +◇(at_goal) +"Kiedyś robot dotrze do celu" + +Specyfikacja reaktywności: +□(request_pickup → ◇holding_object) +"Zawsze gdy jest żądanie podniesienia, kiedyś obiekt będzie trzymany" +``` + +--- + +### 4. Zastosowanie w ROS (Robot Operating System) + +#### Agent jako węzeł ROS + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ ROS Architecture │ +│ │ +│ /sensor_node ──topic──→ /agent_node ──topic──→ /motor_node │ +│ ↓ ↓ ↓ │ +│ [Publikuje] [Subskrybuje & [Wykonuje] │ +│ /scan Publikuje] /cmd_vel │ +│ /camera /plan │ +│ /odom /status │ +│ │ +│ Agent node implementuje: │ +│ - Pętlę kontrolną (control loop) │ +│ - Stan wewnętrzny (beliefs) │ +│ - Planowanie (intentions) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### Behavior Trees (BT) + +``` +Nowoczesna specyfikacja zachowań robota: + + [Selector ?] + / | \ + / | \ + [Seq→] [Seq→] [Idle] + / \ | + / \ | +[Check] [Pick] [Navigate] + +Węzły: +- Sequence (→): wykonaj wszystkie po kolei +- Selector (?): wykonaj pierwszy sukces +- Action: atomowa akcja +- Condition: sprawdzenie warunku +``` + +--- + +### 5. Hybrydowa architektura 3T + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ THREE-TIER (3T) Architecture │ +│ │ +│ ┌─────────────────────────────────────────────────────────┐ │ +│ │ PLANNER (deliberation) │ │ +│ │ - Długoterminowe planowanie │ │ +│ │ - Rozumowanie symboliczne │ │ +│ │ Czas: sekundy - minuty │ │ +│ └─────────────────────────────────────────────────────────┘ │ +│ ↓↑ │ +│ ┌─────────────────────────────────────────────────────────┐ │ +│ │ SEQUENCER (executive) │ │ +│ │ - Wybór zachowań, nadzór wykonania │ │ +│ │ - Finite State Machine / Behavior Tree │ │ +│ │ Czas: 100ms - sekundy │ │ +│ └─────────────────────────────────────────────────────────┘ │ +│ ↓↑ │ +│ ┌─────────────────────────────────────────────────────────┐ │ +│ │ CONTROLLER (reactive) │ │ +│ │ - Pętle PID, unikanie kolizji │ │ +│ │ - Bezpośrednia reakcja sensor → motor │ │ +│ │ Czas: ms │ │ +│ └─────────────────────────────────────────────────────────┘ │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 6. Korzyści podejścia agentowego + +| Korzyść | Opis | +|---------|------| +| **Modularność** | Rozdzielenie percepcji, decyzji, akcji | +| **Abstrakcja** | Ukrycie szczegółów sprzętu | +| **Autonomia** | Robot sam decyduje o działaniach | +| **Reużywalność** | Zachowania przenośne między platformami | +| **Weryfikowalność** | Formalna specyfikacja → model checking | + +--- + +## 🧠 Mnemoniki + +### "Agent = See-Think-Act": +Percepcja → Deliberacja → Akcja + +### "3T = Plan-Sequence-Control": +Trzy warstwy od abstrakcji do sprzętu + +### "BDI w robocie": +- **B**eliefs = mapa, pozycja +- **D**esires = cel nawigacji +- **I**ntentions = plan ruchu + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Czym różni się agent reaktywny od deliberatywnego?" +**Odpowiedź:** Reaktywny: bezpośrednia reakcja sensor→akcja (np. unikanie kolizji), bez planowania. Deliberatywny: model świata, planowanie, cel. Hybryda łączy oba. + +### Q2: "Co to jest subsumption architecture?" +**Odpowiedź:** Architektura Brooksa - warstwy zachowań, wyższe mogą "nadpisać" niższe. Bez centralnego modelu świata. Skuteczna dla prostych robotów mobilnych. + +### Q3: "Jak weryfikować poprawność sterownika agentowego?" +**Odpowiedź:** Model checking (SPIN, NuSMV), symulacja (Gazebo), formalna specyfikacja (LTL, CTL), testy jednostkowe zachowań, testy integracyjne w symulacji przed wdrożeniem na sprzęt. + +--- + +## 🎯 Kluczowe punkty + +1. **Agent upostaciowiony** = ciało + sensory + efektory + środowisko +2. **BDI** dla deliberacji, reaktywność dla bezpieczeństwa +3. **3T Architecture:** Planner → Sequencer → Controller +4. **Behavior Trees** nowoczesna specyfikacja zachowań➜ utils (main) ✗ git commit -m "feat: more aggressive android script" +Running auto-fixers and shell_check before committing... +Auto-fixing 3 shell file(s)... + → Running shfmt... + ✓ Auto-fixes applied and staged +Running shell_check validation... + +In scripts/utils/android_guardian/post-fs-data.sh line 5: +MODULE_DIR="/data/adb/modules/android_guardian" +^--------^ SC2034 (warning): MODULE_DIR appears unused. Verify use (or export if used externally). + +For more information: + https://www.shellcheck.net/wiki/SC2034 -- MODULE_DIR appears unused. Verify... + +Commit aborted: shellcheck found issues. +Fix the remaining problems and retry the commit. +5. **Korzyści:** modularność, abstrakcja, weryfikowalność + +--- + +## 📖 Źródła + +1. Wooldridge - "Introduction to MultiAgent Systems" +2. Siciliano, Khatib - "Springer Handbook of Robotics" +3. Gat - "Three-Layer Architectures" +4. ROS Documentation - ros.org diff --git a/pytania/odpowiedzi/22-jezyki-programowania-robotow.md b/pytania/odpowiedzi/22-jezyki-programowania-robotow.md new file mode 100644 index 0000000..8dac6f9 --- /dev/null +++ b/pytania/odpowiedzi/22-jezyki-programowania-robotow.md @@ -0,0 +1,254 @@ +# Pytanie 22: Języki programowania robotów + +## Pytanie +**"Omówić specjalizowane języki programowania robotów. Uwypuklić ich klasyfikację."** + +Przedmiot: ERPM (Elementy Robotyki i Projektowania Mechatronicznego) + +--- + +## 📚 Odpowiedź główna + +### 1. Klasyfikacja języków programowania robotów + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ JĘZYKI PROGRAMOWANIA ROBOTÓW │ +├─────────────────────────────────────────────────────────────────┤ +│ POZIOM ABSTRAKCJI: │ +│ │ +│ ┌─────────────────────────────────────────────────────────┐ │ +│ │ TASK-LEVEL (Zadaniowy) │ │ +│ │ "Podnieś obiekt A i połóż na B" │ │ +│ └─────────────────────────────────────────────────────────┘ │ +│ ↓ │ +│ ┌─────────────────────────────────────────────────────────┐ │ +│ │ ROBOT-LEVEL (Obiektowy) │ │ +│ │ move_to(position), grasp(), release() │ │ +│ └─────────────────────────────────────────────────────────┘ │ +│ ↓ │ +│ ┌─────────────────────────────────────────────────────────┐ │ +│ │ MOTION-LEVEL (Ruchowy) │ │ +│ │ Trajektorie, interpolacja, kinematyka │ │ +│ └─────────────────────────────────────────────────────────┘ │ +│ ↓ │ +│ ┌─────────────────────────────────────────────────────────┐ │ +│ │ SERVO-LEVEL (Napędowy) │ │ +│ │ Sterowanie silnikami, PID, momenty │ │ +│ └─────────────────────────────────────────────────────────┘ │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 2. Klasyfikacja wg metody programowania + +| Metoda | Opis | Przykłady | +|--------|------|-----------| +| **Online (Teach-in)** | Programowanie przez demonstrację | Pendant, prowadzenie ręczne | +| **Offline** | Programowanie bez robota | Symulacja, CAD/CAM | +| **Tekstowe** | Kod źródłowy | RAPID, KRL, Karel | +| **Graficzne** | Bloki, flowcharty | Blockly, ROBOGUIDE | + +--- + +### 3. Języki producentów robotów przemysłowych + +#### RAPID (ABB) + +```rapid +MODULE MainModule + PROC main() + MoveJ pHome, v1000, z50, tool1; + MoveL pPick, v500, fine, tool1; + GripClose; + MoveL pPlace, v500, fine, tool1; + GripOpen; + ENDPROC +ENDMODULE + +! MoveJ = ruch w przestrzeni złączy (Joint) +! MoveL = ruch liniowy (Linear) +! v500 = prędkość 500 mm/s +! fine/z50 = dokładność (fine = dokładnie) +``` + +#### KRL - KUKA Robot Language + +```krl +DEF Pick_and_Place() + PTP HOME + LIN pPick + GripperClose() + LIN pPlace + GripperOpen() + PTP HOME +END + +; PTP = Point-to-Point (ruch złączowy) +; LIN = ruch liniowy +; CIRC = ruch kołowy +``` + +#### Karel (FANUC) + +```karel +PROGRAM pick_place +BEGIN + MOVE TO home_pos + MOVE TO pick_pos + CLOSE HAND 1 + MOVE TO place_pos + OPEN HAND 1 +END pick_place +``` + +#### PDL2 (Comau) +```pdl2 +PROGRAM main +BEGIN + MOVE TO home_jnt + MOVE LINEAR TO pick_point + $DOUT[1] := ON -- gripper + MOVE LINEAR TO place_point + $DOUT[1] := OFF +END main +``` + +--- + +### 4. Porównanie języków producentów + +| Cecha | RAPID (ABB) | KRL (KUKA) | Karel (FANUC) | +|-------|-------------|------------|---------------| +| **Paradygmat** | Proceduralny | Proceduralny | Proceduralny | +| **Typy ruchów** | MoveJ, MoveL, MoveC | PTP, LIN, CIRC | MOVE TO | +| **Zmienne** | VAR, PERS, CONST | DECL | VAR | +| **I/O** | SetDO, WaitDI | $OUT[], $IN[] | DOUT[], DIN[] | +| **Wielozadaniowość** | Tak (TASK) | Tak (SUBMIT) | Tak (TASK) | + +--- + +### 5. Języki uniwersalne i frameworki + +#### ROS (Robot Operating System) + +```python +# Python + rospy +import rospy +from geometry_msgs.msg import Twist + +rospy.init_node('robot_controller') +pub = rospy.Publisher('/cmd_vel', Twist, queue_size=10) + +twist = Twist() +twist.linear.x = 0.5 +twist.angular.z = 0.1 +pub.publish(twist) +``` + +#### MoveIt (ROS) + +```python +# Planowanie ruchu manipulatora +import moveit_commander + +move_group = moveit_commander.MoveGroupCommander("arm") +move_group.set_pose_target(target_pose) +plan = move_group.go(wait=True) +``` + +#### Orocos / RTT + +```cpp +// Real-Time Toolkit - C++ +class MyComponent : public RTT::TaskContext { + void updateHook() { + // Pętla sterowania (deterministyczna) + } +}; +``` + +--- + +### 6. Języki graficzne + +| Narzędzie | Producent | Opis | +|-----------|-----------|------| +| **RobotStudio** | ABB | RAPID + symulacja 3D | +| **KUKA.Sim** | KUKA | KRL + symulacja | +| **ROBOGUIDE** | FANUC | Karel + symulacja | +| **Blockly** | Google | Programowanie wizualne (edukacja) | +| **Scratch for Robots** | MIT | Edukacja, LEGO, mBot | + +--- + +### 7. Klasyfikacja wg poziomu abstrakcji + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ Task-Level: │ +│ "Złóż produkt X z części A, B, C" │ +│ → Planowanie automatyczne, AI │ +│ Przykłady: STRIPS, PDDL, Behavior Trees │ +├─────────────────────────────────────────────────────────────────┤ +│ Robot-Level: │ +│ move_to(), pick(), place(), wait() │ +│ → RAPID, KRL, Karel, Python+ROS │ +├─────────────────────────────────────────────────────────────────┤ +│ Motion-Level: │ +│ Trajektorie, splajny, kinematyka odwrotna │ +│ → MoveIt, OMPL, IKFast │ +├─────────────────────────────────────────────────────────────────┤ +│ Servo-Level: │ +│ PID, sterowanie momentem, prądem │ +│ → C/C++, FPGA, PLC (Ladder, ST) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +## 🧠 Mnemoniki + +### "RAPID = Robot Application Programming in Data": +Język ABB - MoveJ, MoveL, MoveC + +### "KRL = KUKA Robot Language": +PTP, LIN, CIRC + +### "ROS = Robot Operating System": +Middleware - topics, services, actions + +### "Od zadania do serwa: T-R-M-S": +Task → Robot → Motion → Servo + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Czym różni się ruch PTP od LIN?" +**Odpowiedź:** PTP (Point-to-Point) = ruch w przestrzeni złączy, najszybszy ale trajektoria TCP nieprzewidywalna. LIN (Linear) = ruch liniowy TCP, wolniejszy ale precyzyjna ścieżka. LIN wymaga rozwiązania kinematyki odwrotnej w każdym punkcie. + +### Q2: "Dlaczego każdy producent ma własny język?" +**Odpowiedź:** Historyczne (lata 80-90), integracja ze sterownikiem, optymalizacja dla konkretnego sprzętu, vendor lock-in. ROS próbuje to ujednolicić, ale nie dla real-time. + +### Q3: "Co to jest Teach Pendant?" +**Odpowiedź:** Przenośny panel do programowania online. Przyciski ruchu (jog), zapis punktów, edycja programu. Tryb manualny (bezpieczny) vs automatyczny. + +--- + +## 🎯 Kluczowe punkty + +1. **Klasyfikacja:** Online/Offline, Task/Robot/Motion/Servo level +2. **Producenci:** RAPID (ABB), KRL (KUKA), Karel (FANUC) +3. **Uniwersalne:** ROS + Python/C++, MoveIt +4. **Graficzne:** RobotStudio, ROBOGUIDE, Blockly + +--- + +## 📖 Źródła + +1. Siciliano, Khatib - "Springer Handbook of Robotics" +2. ABB RAPID Reference Manual +3. KUKA KRL Documentation +4. ROS Wiki - ros.org diff --git a/pytania/odpowiedzi/23-zegary-logiczne-wektory.md b/pytania/odpowiedzi/23-zegary-logiczne-wektory.md new file mode 100644 index 0000000..263d475 --- /dev/null +++ b/pytania/odpowiedzi/23-zegary-logiczne-wektory.md @@ -0,0 +1,248 @@ +# Pytanie 23: Zegary logiczne i wektory stempli czasowych + +## Pytanie +**"Przedstawić koncepcję i przeznaczenie zegarów logicznych i wektorów stempli czasowych."** + +Przedmiot: ERSMS (Elementy Rozproszonych Systemów i Middleware'u Sieciowego) + +--- + +## 📚 Odpowiedź główna + +### 1. Problem czasu w systemach rozproszonych + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ Brak globalnego zegara: │ +│ │ +│ Node A: ──●────────●────────●──→ czas lokalny A │ +│ e1 e2 e3 │ +│ │↘ │ +│ │ ↘ msg │ +│ │ ↘ │ +│ Node B: ────●─────────────●───→ czas lokalny B │ +│ e4 e5 │ +│ │ +│ Pytanie: Czy e2 było przed e5, czy po? │ +│ Zegary fizyczne: drift, synchronizacja niedokładna │ +└─────────────────────────────────────────────────────────────────┘ +``` + +**Problem:** Nie możemy polegać na zegarach fizycznych - drift, opóźnienia sieciowe, brak atomowej synchronizacji. + +--- + +### 2. Relacja "happened-before" (Lamport) + +#### Definicja (→) + +Zdarzenie **a** happened-before **b** (a → b) jeśli: +1. **a** i **b** są w tym samym procesie i **a** występuje przed **b** +2. **a** to wysłanie wiadomości, **b** to jej odbiór +3. Przechodniość: a → c ∧ c → b ⟹ a → b + +``` +P1: ─●─────●─────────●───→ + a b d + │↘ + │ ↘ m1 + │ ↘ +P2: ───────────●─────●───→ + c e + +a → b (ten sam proces) +b → c (wysłanie → odbiór) +a → c (przechodniość) +c → e (ten sam proces) +``` + +#### Zdarzenia współbieżne + +Jeśli ¬(a → b) ∧ ¬(b → a), to **a || b** (współbieżne). + +--- + +### 3. Zegar Lamporta (Scalar Clock) + +#### Algorytm + +``` +Każdy proces P_i ma licznik C_i: + +1. Przed każdym zdarzeniem lokalnym: + C_i := C_i + 1 + +2. Wysyłając wiadomość m: + C_i := C_i + 1 + Dołącz timestamp(m) = C_i + +3. Odbierając wiadomość m z timestamp t: + C_i := max(C_i, t) + 1 +``` + +#### Przykład + +``` +P1: C=0 ──●(1)────●(2)─────────●(5)──→ + a b d + │↘ + │ ↘ m(2) + │ ↘ +P2: C=0 ────●(1)───────●(3)────●(4)──→ + x c e + +Zdarzenia: a=1, b=2, x=1, c=3, e=4, d=5 +``` + +#### Właściwości + +| Właściwość | Zegar Lamporta | +|------------|----------------| +| a → b ⟹ C(a) < C(b) | ✅ TAK | +| C(a) < C(b) ⟹ a → b | ❌ NIE | + +**Ograniczenie:** C(a) < C(b) nie oznacza, że a → b (mogą być współbieżne). + +--- + +### 4. Zegary wektorowe (Vector Clocks) + +#### Algorytm + +``` +Każdy z N procesów ma wektor V[1..N]: + +1. Przed każdym zdarzeniem lokalnym: + V_i[i] := V_i[i] + 1 + +2. Wysyłając wiadomość m: + V_i[i] := V_i[i] + 1 + Dołącz timestamp(m) = V_i + +3. Odbierając wiadomość m z timestamp T: + V_i[j] := max(V_i[j], T[j]) dla każdego j + V_i[i] := V_i[i] + 1 +``` + +#### Przykład + +``` +P1: [0,0,0] ──●[1,0,0]────●[2,0,0]─────────●[3,2,0]──→ + a b d + │↘ + │ ↘ m[2,0,0] + │ ↘ +P2: [0,0,0] ────●[0,1,0]─────────●[2,2,0]────●[2,3,0]──→ + x c e +``` + +#### Porównanie wektorów + +``` +V ≤ W ⟺ ∀i: V[i] ≤ W[i] +V < W ⟺ V ≤ W ∧ V ≠ W +V || W ⟺ ¬(V ≤ W) ∧ ¬(W ≤ V) + +Przykład: +[2,3,1] < [2,4,1] (happened-before) +[2,3,1] || [1,4,2] (współbieżne) +``` + +#### Właściwości + +| Właściwość | Zegar wektorowy | +|------------|-----------------| +| a → b ⟺ V(a) < V(b) | ✅ TAK | +| Wykrycie współbieżności | ✅ TAK | + +**Zegary wektorowe charakteryzują dokładnie relację happened-before!** + +--- + +### 5. Porównanie + +| Cecha | Lamport | Vector Clock | +|-------|---------|--------------| +| **Rozmiar** | O(1) | O(N) | +| **a → b ⟹ C(a) < C(b)** | ✅ | ✅ | +| **C(a) < C(b) ⟹ a → b** | ❌ | ✅ | +| **Wykrycie współbieżności** | ❌ | ✅ | +| **Zastosowanie** | Uporządkowanie | Wykrywanie konfliktów | + +--- + +### 6. Zastosowania + +| Zastosowanie | Typ zegara | Cel | +|--------------|------------|-----| +| **Mutual exclusion** | Lamport | Uporządkowanie żądań | +| **Causal broadcast** | Vector | Dostarczanie w kolejności przyczynowej | +| **Conflict detection** | Vector | Wykrycie współbieżnych zapisów | +| **Distributed debugging** | Vector | Odtworzenie kolejności zdarzeń | +| **Version vectors (Dynamo)** | Vector | Wykrycie konfliktów w replikacji | + +#### Przykład: Dynamo/Riak + +``` +Put(key, value) z vector clock: + +Client → Server A: put("x", "v1", [A:1]) +Client → Server B: put("x", "v2", [B:1]) + +Konflikt wykryty: [A:1] || [B:1] +Oba wartości przechowane, klient rozwiązuje +``` + +--- + +### 7. Warianty i rozszerzenia + +| Wariant | Opis | +|---------|------| +| **Interval Tree Clocks** | Dynamiczna liczba procesów | +| **Bloom Clocks** | Probabilistyczne, kompaktowe | +| **Hybrid Logical Clocks** | Lamport + czas fizyczny | +| **Matrix Clocks** | Wiedza o wiedzy innych | + +--- + +## 🧠 Mnemoniki + +### "Lamport = Licznik skalarny": +Jedna liczba, nie wykrywa współbieżności + +### "Vector = Każdy wie o każdym": +V[i] = ile zdarzeń widział proces i + +### "< oznacza →, || oznacza współbieżność": +Porównanie wektorów = relacja przyczynowa + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Dlaczego nie używać NTP zamiast zegarów logicznych?" +**Odpowiedź:** NTP ma błąd ~ms (LAN) do ~100ms (WAN). Dla zdarzeń szybszych niż błąd synchronizacji, kolejność fizyczna jest nieznana. Zegary logiczne dają gwarancje przyczynowe bez względu na drift. + +### Q2: "Co to jest causal consistency?" +**Odpowiedź:** Model spójności gdzie zapisy przyczynowo zależne są widziane w tej samej kolejności przez wszystkich. Wymaga vector clocks. Słabszy niż sequential consistency, silniejszy niż eventual. + +### Q3: "Problem skalowalności vector clocks?" +**Odpowiedź:** O(N) rozmiar dla N procesów. Rozwiązania: przycinanie (Dynamo), Interval Tree Clocks (dynamiczne ID), Bloom clocks (probabilistyczne). + +--- + +## 🎯 Kluczowe punkty + +1. **Problem:** Brak globalnego zegara w systemach rozproszonych +2. **Lamport:** Skalarny, a → b ⟹ C(a) < C(b), nie odwrotnie +3. **Vector:** a → b ⟺ V(a) < V(b), wykrywa współbieżność +4. **Zastosowania:** Replikacja, debugging, causal broadcast + +--- + +## 📖 Źródła + +1. Lamport - "Time, Clocks, and the Ordering of Events" (1978) +2. Fidge, Mattern - "Vector Clocks" (1988) +3. DeCandia et al. - "Dynamo" (Amazon, 2007) diff --git a/pytania/odpowiedzi/24-modele-spojnosci-rozproszone.md b/pytania/odpowiedzi/24-modele-spojnosci-rozproszone.md new file mode 100644 index 0000000..31ee8af --- /dev/null +++ b/pytania/odpowiedzi/24-modele-spojnosci-rozproszone.md @@ -0,0 +1,271 @@ +# Pytanie 24: Modele spójności danych w systemach rozproszonych + +## Pytanie +**"Omówić silne i słabe modele spójności danych w środowisku rozproszonym."** + +Przedmiot: ERSMS (Elementy Rozproszonych Systemów i Middleware'u Sieciowego) + +--- + +## 📚 Odpowiedź główna + +### 1. Problem spójności w systemach rozproszonych + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ Repliki danych: │ +│ │ +│ Client A Client B │ +│ │ write(x=1) │ read(x)=? │ +│ ↓ ↓ │ +│ ┌───────┐ ┌───────┐ │ +│ │Replica│──sync?──→│Replica│ │ +│ │ 1 │ │ 2 │ │ +│ │ x=1 │ │ x=0? │ │ +│ └───────┘ └───────┘ │ +│ │ +│ Pytanie: Co zwróci read(x)? │ +│ Odpowiedź zależy od modelu spójności! │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 2. Spektrum modeli spójności + +``` +Silne ←─────────────────────────────────────────→ Słabe + +Linearizability Eventual + │ Consistency + ↓ ↑ +Sequential Causal +Consistency Consistency + │ ↑ + ↓ Session +Causal+ Guarantees + │ + ↓ +PRAM +``` + +--- + +### 3. Silne modele spójności + +#### Linearizability (Linearyzacja) + +``` +Definicja: Każda operacja wygląda jakby wykonała się atomowo +w pewnym momencie między wywołaniem a odpowiedzią. + +Timeline: +Client A: ─────[write(x=1)]─────────────────────→ +Client B: ───────────[read(x)]──────────────────→ + ↓ + Musi zwrócić 1! + +Właściwości: +- Najsilniejsza gwarancja +- "Globalny porządek rzeczywisty" +- Kosztowna (wymaga koordynacji) +``` + +**Implementacja:** Consensus (Paxos, Raft), single leader + +#### Sequential Consistency + +``` +Definicja: Istnieje globalny porządek operacji zgodny +z porządkiem programu każdego procesu. + +Client A: write(x=1) ──────────────────→ +Client B: ──────────── write(x=2) ─────→ +Client C: read(x)=? ── read(x)=? ──────→ + +Dozwolone: C widzi [1,2] lub [2,1] + (byle konsystentnie z innymi) + +Różnica od linearyzacji: +- Nie wymaga zgodności z czasem rzeczywistym +- Wystarczy spójny porządek +``` + +--- + +### 4. Słabe modele spójności + +#### Eventual Consistency + +``` +Definicja: Jeśli nie ma nowych zapisów, ostatecznie +wszystkie odczyty zwrócą tę samą wartość. + +Timeline: +write(x=1) @ Replica A + ↓ (propagacja) + ↓ + ↓ ... czas ... + ↓ +read(x)=1 @ Replica B (eventually) + +Gwarancje: +✅ Dostępność (AP w CAP) +✅ Niska latencja +❌ Stare dane przez jakiś czas +❌ Możliwe konflikty +``` + +**Implementacja:** DNS, Dynamo, Cassandra + +#### Causal Consistency + +``` +Definicja: Operacje przyczynowo zależne widziane +w tej samej kolejności przez wszystkich. + +P1: write(x=1) ─────────────────────────→ + ↓ (read x) +P2: ──────────── write(y=2) ────────────→ + +P3 widzi: x=1 przed y=2 (zawsze!) + (bo y=2 zależy przyczynowo od x=1) + +Niezależne zapisy mogą być widziane w różnej kolejności. +``` + +**Implementacja:** Vector clocks, COPS + +#### Session Guarantees + +| Gwarancja | Opis | +|-----------|------| +| **Read Your Writes** | Odczyt widzi własne wcześniejsze zapisy | +| **Monotonic Reads** | Raz widziana wartość nie "cofa się" | +| **Monotonic Writes** | Zapisy aplikowane w kolejności sesji | +| **Writes Follow Reads** | Zapis po odczycie widzi ten odczyt | + +``` +Read Your Writes: +Session: write(x=5) ──── read(x)=? ────→ + Musi być 5! + +Monotonic Reads: +Session: read(x)=5 ──── read(x)=? ────→ + Musi być ≥ 5! +``` + +--- + +### 5. CAP Theorem + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ CAP Theorem │ +│ │ +│ Consistency (C) │ +│ /\ │ +│ / \ │ +│ / \ │ +│ / CA \ │ +│ / \ │ +│ / CP \ │ +│ Availability (A) ──────────── Partition Tolerance (P) │ +│ AP │ +│ │ +│ W obecności partycji sieci (P): wybierz C lub A │ +│ │ +│ CP: Spójne, ale niedostępne (Zookeeper, etcd) │ +│ AP: Dostępne, ale niespójne (Dynamo, Cassandra) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 6. Porównanie modeli + +| Model | Gwarancje | Wydajność | Przykłady | +|-------|-----------|-----------|-----------| +| **Linearizable** | Najsilniejsze | Niska | Spanner, CockroachDB | +| **Sequential** | Silne | Średnia | Zookeeper | +| **Causal** | Przyczynowe | Dobra | COPS, MongoDB | +| **Session** | Per-sesja | Dobra | Dynamo sessions | +| **Eventual** | Najsłabsze | Najwyższa | DNS, Cassandra | + +--- + +### 7. Strategie rozwiązywania konfliktów + +#### Last-Writer-Wins (LWW) +``` +Konflikt: write(x=1) || write(x=2) +Rozwiązanie: Większy timestamp wygrywa +Problem: Utrata danych! +``` + +#### Multi-Value (Siblings) +``` +Konflikt: write(x=1) || write(x=2) +Rozwiązanie: Przechowaj oba: x=[1,2] +Klient rozwiązuje przy odczycie (Riak) +``` + +#### CRDTs (Conflict-free Replicated Data Types) +``` +Struktury automatycznie łączące się: +- G-Counter (grow-only counter) +- OR-Set (observed-remove set) +- LWW-Register + +Merge jest łączny, przemienny, idempotentny +→ Zawsze zbieżność! +``` + +--- + +## 🧠 Mnemoniki + +### "Linearizable = Real-time + Atomic": +Widoczne natychmiast, atomowo + +### "Eventual = Eventually, trust me": +Kiedyś będzie spójne (bez gwarancji kiedy) + +### "CAP = Choose 2 of 3": +Partition → wybierz Consistency lub Availability + +### "CRDT = Conflict-free": +Matematyczna gwarancja zbieżności + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Czym różni się linearizability od serializability?" +**Odpowiedź:** Linearizability = dla pojedynczych operacji, real-time ordering. Serializability = dla transakcji, jakiś serial order. Strict serializability = oba razem. + +### Q2: "Kiedy wybrać eventual consistency?" +**Odpowiedź:** Wysoka dostępność ważniejsza niż spójność, tolerancja na stale reads, możliwość rozwiązania konfliktów (shopping cart, likes counter, DNS). + +### Q3: "Co to jest Quorum?" +**Odpowiedź:** W = write quorum, R = read quorum, N = repliki. W + R > N gwarantuje odczyt najnowszej wartości. Dynamo: N=3, W=2, R=2. + +--- + +## 🎯 Kluczowe punkty + +1. **Linearizable:** Najsilniejszy, atomowy, kosztowny +2. **Sequential:** Globalny porządek, bez real-time +3. **Causal:** Przyczynowo zależne w kolejności +4. **Eventual:** Ostatecznie spójne, najszybszy +5. **CAP:** Partition → C xor A +6. **CRDTs:** Automatyczne rozwiązywanie konfliktów + +--- + +## 📖 Źródła + +1. Herlihy, Wing - "Linearizability" (1990) +2. Vogels - "Eventually Consistent" (Amazon CTO) +3. Gilbert, Lynch - "CAP Theorem" (2002) +4. Shapiro et al. - "CRDTs" (2011) diff --git a/pytania/odpowiedzi/25-programowanie-calkowitoliczbowe.md b/pytania/odpowiedzi/25-programowanie-calkowitoliczbowe.md new file mode 100644 index 0000000..006d2bb --- /dev/null +++ b/pytania/odpowiedzi/25-programowanie-calkowitoliczbowe.md @@ -0,0 +1,269 @@ +# Pytanie 25: Programowanie całkowitoliczbowe (MIP) + +## Pytanie +**"Gdzie znajdują zastosowania zadania programowania matematycznego całkowitoliczbowego i jak można je rozwiązywać? Omówić wybraną metodę dokładną, wyjaśnić dla jakich praktycznych problemów ma ona zastosowanie i co może wpływać na jej efektywność."** + +Przedmiot: MOD (Metody Optymalizacji Dyskretnej) + +--- + +## 📚 Odpowiedź główna + +### 1. Definicja MIP (Mixed Integer Programming) + +``` +Programowanie całkowitoliczbowe: + +min c^T x +s.t. Ax ≤ b + x_i ∈ Z dla i ∈ I (zmienne całkowite) + x_j ∈ R dla j ∈ J (zmienne ciągłe) + x ≥ 0 + +Przypadki szczególne: +- IP (Integer Programming): wszystkie zmienne całkowite +- BIP (Binary IP): x_i ∈ {0,1} +- MIP (Mixed IP): część całkowite, część ciągłe +``` + +--- + +### 2. Zastosowania + +| Dziedzina | Problem | Zmienne binarne | +|-----------|---------|-----------------| +| **Logistyka** | Vehicle Routing (VRP) | x_ij = czy trasa i→j | +| **Produkcja** | Scheduling, Lot sizing | y_t = czy produkować w t | +| **Transport** | Facility Location | y_i = czy otworzyć magazyn i | +| **Telekomunikacja** | Network Design | x_e = czy użyć krawędzi e | +| **Finanse** | Portfolio (min transakcji) | y_i = czy inwestować w i | +| **Energia** | Unit Commitment | y_t = czy uruchomić generator | + +### Przykład: Problem plecakowy (Knapsack) + +``` +max Σ v_i x_i (wartość) +s.t. Σ w_i x_i ≤ C (pojemność) + x_i ∈ {0,1} (brać lub nie) + +Przedmioty: (wartość, waga) +Item 1: (60, 10) +Item 2: (100, 20) +Item 3: (120, 30) +Pojemność: C = 50 + +Optymalne: x = [1,1,1] niemożliwe (waga=60) + x = [1,0,1] wartość=180, waga=40 ✓ +``` + +--- + +### 3. Metody rozwiązywania + +| Metoda | Typ | Gwarancja optimum | +|--------|-----|-------------------| +| **Branch and Bound** | Dokładna | ✅ | +| **Branch and Cut** | Dokładna | ✅ | +| **Branch and Price** | Dokładna | ✅ | +| **Cutting Planes** | Dokładna | ✅ | +| **Heurystyki** | Przybliżona | ❌ | +| **Metaheurystyki** | Przybliżona | ❌ | + +--- + +### 4. Branch and Bound (B&B) - metoda dokładna + +#### Idea + +``` +1. Relaksacja LP: rozwiąż bez ograniczeń całkowitoliczbowych +2. Jeśli rozwiązanie całkowite → gotowe +3. Jeśli nie → rozgałęź (branch) na zmiennej niecałkowitej +4. Przycinaj (bound) gdy dolne ograniczenie ≥ najlepsze znane + + LP relaxation + x* = 2.7 + /\ + / \ + x ≤ 2 x ≥ 3 + / \ + LP: z=10 LP: z=8 + / \ + (dalej) (przycinaj jeśli + najlepsze ≥ 8) +``` + +#### Algorytm szczegółowy + +``` +BranchAndBound(P): + Q = {P} // kolejka podproblemów + best = -∞ // najlepsze rozwiązanie + best_x = null + + while Q not empty: + P' = select(Q) // wybierz podproblem + z, x = LP_relax(P') // rozwiąż relaksację + + if z ≤ best: // BOUND: przycięcie + continue + + if x is integer: // rozwiązanie całkowite + if z > best: + best = z + best_x = x + else: // BRANCH: rozgałęzienie + i = fractional_var(x) // wybierz zmienną + P1 = P' + {x_i ≤ floor(x_i)} + P2 = P' + {x_i ≥ ceil(x_i)} + Q.add(P1, P2) + + return best_x +``` + +#### Przykład: Max 3x + 2y, x + y ≤ 4, x,y ∈ Z+ + +``` + Root: LP opt + x=4, y=0, z=12 + (całkowite!) → DONE + +Bardziej interesujący przykład: +max 5x + 8y + x + y ≤ 6 + 5x + 9y ≤ 45 + x, y ≥ 0, integer + +LP: x=2.25, y=3.75, z=41.25 + │ + ┌───────┴───────┐ + y ≤ 3 y ≥ 4 + │ │ + x=3, y=3 x=1.8, y=4 + z=39 (int!) z=41 + │ │ + incumbent=39 ┌───┴───┐ + x≤1 x≥2 + │ │ + z=40 infeas. + x=1,y=4 + (int!) + +Optimum: x=1, y=4, z=40 +``` + +--- + +### 5. Czynniki wpływające na efektywność B&B + +| Czynnik | Wpływ | Strategie | +|---------|-------|-----------| +| **Jakość relaksacji** | Lepsza → mniej węzłów | Silne formulacje, cutting planes | +| **Wybór zmiennej do branch** | Balans drzewa | Most fractional, strong branching | +| **Wybór węzła** | DFS vs BFS | Best-first (best bound) | +| **Przerywanie** | Jakość incumbent | Heurystyki, warm start | +| **Symetria** | Wiele równoważnych rozw. | Symmetry breaking constraints | + +#### Strategie wyboru zmiennej (branching) + +| Strategia | Opis | +|-----------|------| +| **Most fractional** | x_i najbliżej 0.5 | +| **First fractional** | Pierwsza niecałkowita | +| **Strong branching** | Testuj kandydatów przez LP | +| **Pseudocost** | Historia wpływu na bound | + +#### Strategie wyboru węzła + +| Strategia | Właściwości | +|-----------|-------------| +| **Best-first** | Najlepszy bound → mniej węzłów | +| **Depth-first** | Szybko znajduje rozwiązania | +| **Best-estimate** | Kombinacja bound + estimate | + +--- + +### 6. Ulepszenia: Branch and Cut + +``` +Branch and Bound + Cutting Planes: + +W każdym węźle: +1. Rozwiąż LP relaksację +2. Jeśli rozwiązanie niecałkowite: + - Generuj cięcia (Gomory, Cover, Clique...) + - Dodaj cięcia do LP + - Powtórz do limitu +3. Jeśli nadal niecałkowite → branch + +Cięcia zacieśniają relaksację LP bez odcinania +rozwiązań całkowitoliczbowych! + + ┌─────────────────────┐ + │ Politop LP │ + │ ╱─────╲ │ + │ ╱ ╲ cięcie │ + │ ●─────────● │ + │ │ ● ● │ │ + │ │ ● ● │ rozw. │ + │ │ ● ● │ całk. │ + │ ●─────────● │ + └─────────────────────┘ +``` + +--- + +### 7. Narzędzia + +| Solver | Typ | Licencja | +|--------|-----|----------| +| **CPLEX** | Komercyjny | IBM | +| **Gurobi** | Komercyjny | Academic free | +| **SCIP** | Open source | ZIB | +| **CBC** | Open source | COIN-OR | +| **OR-Tools** | Open source | Google | + +--- + +## 🧠 Mnemoniki + +### "B&B = Branch by variable, Bound by LP": +Rozgałęziaj na zmiennej, przycinaj przez relaksację + +### "MIP = Mix of Integer and continuous": +Część zmiennych całkowita, część ciągła + +### "Tight LP = Fast B&B": +Lepsza relaksacja → mniej węzłów do sprawdzenia + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Co to jest integrality gap?" +**Odpowiedź:** Różnica między optimum LP (relaksacja) a optimum IP. Mała luka = silna formulacja = szybki B&B. Gap = (LP_opt - IP_opt) / IP_opt. + +### Q2: "Kiedy B&B jest nieefektywny?" +**Odpowiedź:** Słaba relaksacja (duży gap), dużo symetrii, wiele prawie równoważnych rozwiązań. Wtedy: miliony węzłów, długi czas. Rozwiązanie: silniejsze formulacje, symmetry breaking, heurystyki. + +### Q3: "Co to jest cięcie Gomory'ego?" +**Odpowiedź:** Automatycznie generowane cięcie z tablicy simplex. Odcina aktualne rozwiązanie LP bez odcinania punktów całkowitych. Słabe dla dużych problemów, lepsze: cover cuts, clique cuts dla konkretnych struktur. + +--- + +## 🎯 Kluczowe punkty + +1. **MIP:** Optymalizacja ze zmiennymi całkowitymi (NP-trudna) +2. **Zastosowania:** Scheduling, routing, facility location +3. **B&B:** Relaksacja LP + branching + bounding +4. **Efektywność:** Jakość relaksacji, strategia branching, cięcia +5. **Narzędzia:** CPLEX, Gurobi, SCIP, CBC + +--- + +## 📖 Źródła + +1. Wolsey - "Integer Programming" +2. Nemhauser, Wolsey - "Integer and Combinatorial Optimization" +3. CPLEX User Manual +4. Achterberg - "SCIP: Solving Constraint Integer Programs" diff --git a/pytania/odpowiedzi/26-narzedzia-optymalizacji-dyskretnej.md b/pytania/odpowiedzi/26-narzedzia-optymalizacji-dyskretnej.md new file mode 100644 index 0000000..c89e495 --- /dev/null +++ b/pytania/odpowiedzi/26-narzedzia-optymalizacji-dyskretnej.md @@ -0,0 +1,272 @@ +# Pytanie 26: Narzędzia optymalizacji dyskretnej + +## Pytanie +**"Scharakteryzować informatyczne narzędzia optymalizacji dyskretnej. Jakie są warunki i wymagania, jakie możliwości oraz trudności wiążą się ze stosowaniem gotowych narzędzi."** + +Przedmiot: MOD (Metody Optymalizacji Dyskretnej) + +--- + +## 📚 Odpowiedź główna + +### 1. Kategorie narzędzi + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ NARZĘDZIA OPTYMALIZACJI DYSKRETNEJ │ +├─────────────────────────────────────────────────────────────────┤ +│ SOLVERY MIP │ SOLVERY CP │ METAHEURYSTYKI │ +│ (Mixed Integer │ (Constraint │ │ +│ Programming) │ Programming) │ │ +│ ───────────────── │ ────────────── │ ────────────── │ +│ CPLEX, Gurobi │ CP-SAT (Google) │ LocalSolver │ +│ SCIP, CBC │ Chuffed, Gecode │ OptaPlanner │ +│ │ MiniZinc │ OR-Tools │ +├─────────────────────────────────────────────────────────────────┤ +│ JĘZYKI MODELOWANIA │ SAT/SMT SOLVERY │ FRAMEWORKI │ +│ ───────────────── │ ────────────── │ ────────────── │ +│ AMPL, GAMS │ Z3, CVC5 │ PuLP (Python) │ +│ Pyomo, JuMP │ MiniSat, Glucose │ CVXPY │ +│ MiniZinc │ │ OR-Tools │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 2. Solvery MIP + +| Solver | Licencja | Cechy | +|--------|----------|-------| +| **CPLEX** | Komercyjny (IBM) | Najszybszy dla dużych MIP | +| **Gurobi** | Komercyjny (academic free) | Bardzo szybki, dobry API | +| **SCIP** | Open source (ZIB) | Framework extensible | +| **CBC** | Open source (COIN-OR) | Dobry darmowy solver | +| **HiGHS** | Open source | Nowoczesny, szybki LP/MIP | +| **GLPK** | Open source | Prosty, portable | + +### Porównanie wydajności (benchmark) + +``` +Typowe czasy dla problemów MIPLIB (średnie): + +CPLEX ████████████████████████████ 100% +Gurobi ███████████████████████████ 98% +SCIP ████████████████ 60% +CBC ████████████ 45% +GLPK ████████ 30% +``` + +--- + +### 3. Solvery Constraint Programming + +| Solver | Język | Cechy | +|--------|-------|-------| +| **CP-SAT** | Python/C++ | Google, bardzo szybki | +| **Gecode** | C++ | Akademicki, elastyczny | +| **Chuffed** | MiniZinc | Lazy clause generation | +| **OR-Tools** | Multi | Google, CP + routing + MIP | + +### Kiedy CP vs MIP? + +| Aspekt | MIP | CP | +|--------|-----|-----| +| **Ograniczenia globalne** | Słabo | Świetnie (alldiff, cumulative) | +| **Relaksacja** | LP (silna) | Słabsza | +| **Scheduling** | Średnio | Świetnie | +| **Kombinatoryczne** | Dobrze | Bardzo dobrze | + +--- + +### 4. Języki modelowania + +#### AMPL +```ampl +set PRODUCTS; +param profit{PRODUCTS}; +param capacity; + +var produce{PRODUCTS} >= 0 integer; + +maximize total_profit: + sum{p in PRODUCTS} profit[p] * produce[p]; + +subject to capacity_limit: + sum{p in PRODUCTS} produce[p] <= capacity; +``` + +#### Pyomo (Python) +```python +from pyomo.environ import * + +model = ConcreteModel() +model.x = Var([1,2,3], domain=NonNegativeIntegers) +model.obj = Objective(expr=sum(model.x[i] for i in [1,2,3]), + sense=maximize) +model.con = Constraint(expr=model.x[1] + model.x[2] <= 10) + +solver = SolverFactory('gurobi') +solver.solve(model) +``` + +#### OR-Tools (Python) +```python +from ortools.linear_solver import pywraplp + +solver = pywraplp.Solver.CreateSolver('SCIP') +x = solver.IntVar(0, 10, 'x') +y = solver.IntVar(0, 10, 'y') +solver.Add(x + y <= 15) +solver.Maximize(3*x + 4*y) +solver.Solve() +``` + +--- + +### 5. Warunki i wymagania + +| Wymaganie | Opis | +|-----------|------| +| **Licencja** | Komercyjne (CPLEX, Gurobi) vs Open source | +| **API/Język** | Python, C++, Java, Julia | +| **Format modelu** | MPS, LP, AMPL, własny | +| **Pamięć** | Duże modele = duże wymagania RAM | +| **Wielowątkowość** | Parallel B&B, concurrent LP | + +### Typowe wymagania sprzętowe + +``` +Mały problem (< 1000 zmiennych): + - RAM: 4 GB + - CPU: dowolny + - Czas: sekundy + +Średni problem (1000-100k zmiennych): + - RAM: 16-32 GB + - CPU: multi-core + - Czas: minuty-godziny + +Duży problem (> 100k zmiennych): + - RAM: 64+ GB + - CPU: wiele rdzeni + - Czas: godziny-dni + - Czasem: cluster computing +``` + +--- + +### 6. Możliwości + +| Możliwość | Opis | +|-----------|------| +| **Gwarancja optimum** | Metody dokładne (B&B, B&C) | +| **Gap tracking** | Śledzenie jakości rozwiązania | +| **Callbacks** | Własne cięcia, heurystyki, lazy constraints | +| **Warm start** | Start od znanego rozwiązania | +| **Tuning** | Automatyczne dostrajanie parametrów | +| **Solution pool** | Wiele rozwiązań (k-best) | + +--- + +### 7. Trudności + +| Trudność | Opis | Rozwiązanie | +|----------|------|-------------| +| **Czas obliczeń** | NP-trudność | Heurystyki, time limit | +| **Słaba formulacja** | Duży integrality gap | Silniejsze modele, cięcia | +| **Symetria** | Wiele równoważnych rozw. | Symmetry breaking | +| **Numeryka** | Błędy zaokrągleń | Tolerancje, scaling | +| **Pamięć** | Duże drzewa B&B | Limity węzłów, DFS | +| **Debugowanie** | Infeasible/unbounded | IIS (Irreducible Infeasible Set) | + +### Diagnostyka problemów + +``` +Problem: Model INFEASIBLE + +Diagnoza: +1. solver.computeIIS() # znajdź konflikt +2. Sprawdź constraints +3. Poluzuj ograniczenia + +Problem: Zbyt długi czas + +Diagnoza: +1. Gap się nie zmniejsza → słaba formulacja +2. Dużo węzłów B&B → symetria +3. LP wolne → presolve, scaling +``` + +--- + +### 8. Best practices + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ 1. FORMULACJA │ +│ - Unikaj big-M (słaba relaksacja) │ +│ - Używaj wskaźnikowych (indicator constraints) │ +│ - Tight bounds na zmienne │ +│ │ +│ 2. PREPROCESSING │ +│ - Presolve (solver robi automatycznie) │ +│ - Agregacja zmiennych │ +│ - Eliminacja redundancji │ +│ │ +│ 3. PARAMETRY SOLVERA │ +│ - MIPGap: akceptowalny gap (np. 1%) │ +│ - TimeLimit: maksymalny czas │ +│ - Threads: liczba wątków │ +│ - Emphasis: feasibility vs optimality │ +│ │ +│ 4. DEBUGGING │ +│ - Zacznij od małej instancji │ +│ - Sprawdź relaxację LP │ +│ - Użyj IIS dla infeasible │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +## 🧠 Mnemoniki + +### "CPLEX/Gurobi = Commercial Power": +Najszybsze, ale płatne (academic free) + +### "SCIP = Swiss army knife": +Open source, extensible, framework + +### "CP for Scheduling, MIP for Planning": +CP świetny dla harmonogramowania + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Kiedy używać metaheurystyk zamiast solverów?" +**Odpowiedź:** Bardzo duże instancje (miliony zmiennych), brak dobrej formulacji MIP, potrzeba szybkiego "dobrego" rozwiązania bez gwarancji, problemy z wieloma celami, problemy dynamiczne. + +### Q2: "Co to jest callback w solverze MIP?" +**Odpowiedź:** Funkcja wywoływana przez solver w trakcie B&B. Typy: lazy constraints (dodaj ograniczenie gdy naruszone), user cuts (wzmocnij relaksację), heuristic (znajdź rozwiązanie), branching (własna strategia). + +### Q3: "Jak poprawić słabą formulację?" +**Odpowiedź:** Dodaj valid inequalities (cięcia), zastąp big-M przez indicator constraints, wprowadź dodatkowe zmienne (extended formulation), użyj disaggregation. + +--- + +## 🎯 Kluczowe punkty + +1. **MIP solvery:** CPLEX, Gurobi (komercyjne), SCIP, CBC (open source) +2. **CP solvery:** CP-SAT, Gecode - dobre dla scheduling +3. **Języki:** AMPL, Pyomo, OR-Tools +4. **Trudności:** Czas, słaba formulacja, symetria +5. **Best practice:** Tight formulation, callbacks, proper tuning + +--- + +## 📖 Źródła + +1. CPLEX User Manual +2. Gurobi Reference Manual +3. Williams - "Model Building in Mathematical Programming" +4. OR-Tools documentation - developers.google.com/optimization diff --git a/pytania/odpowiedzi/27-jakosc-modelu-danych.md b/pytania/odpowiedzi/27-jakosc-modelu-danych.md new file mode 100644 index 0000000..e9ff17d --- /dev/null +++ b/pytania/odpowiedzi/27-jakosc-modelu-danych.md @@ -0,0 +1,236 @@ +# Pytanie 27: Jakość modelu danych w projekcie informatycznym + +## Pytanie +**"Dlaczego jakość modelu danych jest krytycznie ważnym czynnikiem jakości projektu informatycznego?"** + +Przedmiot: MODA (Modelowanie Danych) + +--- + +## 📚 Odpowiedź główna + +### 1. Model danych jako fundament systemu + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ ARCHITEKTURA SYSTEMU │ +│ │ +│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ +│ │ UI │ │ Logika │ │ Integracje │ │ +│ │ │ │ biznesowa │ │ │ │ +│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ +│ │ │ │ │ +│ └────────────┬────┴────────────────┘ │ +│ │ │ +│ ↓ │ +│ ╔════════════════════════════════╗ │ +│ ║ MODEL DANYCH ║ ← FUNDAMENT │ +│ ║ (schemat bazy, encje, ║ │ +│ ║ relacje, ograniczenia) ║ │ +│ ╚════════════════════════════════╝ │ +│ │ +│ Zmiana modelu danych → kaskadowe zmiany w całym systemie! │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 2. Konsekwencje złego modelu danych + +| Problem | Konsekwencje | +|---------|--------------| +| **Redundancja** | Anomalie (insert, update, delete), niespójność | +| **Brak normalizacji** | Duplikacja, trudna aktualizacja | +| **Nadmierna normalizacja** | Wolne zapytania (wiele JOIN) | +| **Złe typy danych** | Błędy konwersji, utrata precyzji | +| **Brak ograniczeń** | Nieprawidłowe dane w bazie | +| **Słaba dokumentacja** | Niezrozumiały schemat | + +### Przykład: Anomalie przy braku normalizacji + +``` +Tabela nienormalizowana (zamówienia): +┌────────┬─────────┬─────────────┬───────────┬─────────┐ +│OrderID │Customer │CustomerAddr │ Product │ Price │ +├────────┼─────────┼─────────────┼───────────┼─────────┤ +│ 1 │ Jan │ Warszawa │ Laptop │ 3000 │ +│ 2 │ Jan │ Warszawa │ Mysz │ 50 │ +│ 3 │ Anna │ Kraków │ Laptop │ 3000 │ +└────────┴─────────┴─────────────┴───────────┴─────────┘ + +Problemy: +❌ UPDATE: Jan zmienia adres → aktualizuj wiele wierszy +❌ DELETE: Usunięcie zamówienia 3 → tracimy info o Annie +❌ INSERT: Nowy klient bez zamówienia → nie można dodać +``` + +--- + +### 3. Wpływ na różne aspekty projektu + +#### Wydajność + +``` +Zły model: +SELECT * FROM orders +JOIN customers ON orders.customer_name = customers.name -- string comparison! +JOIN products ON orders.product_name = products.name +WHERE customers.city = 'Warszawa'; +→ Full table scans, wolne JOIN na stringach + +Dobry model: +SELECT * FROM orders o +JOIN customers c ON o.customer_id = c.id -- integer FK +JOIN products p ON o.product_id = p.id +WHERE c.city_id = 1; -- indexed lookup +→ Index scans, szybkie JOIN na integer PK/FK +``` + +#### Skalowalność + +| Model | Skalowalność | +|-------|--------------| +| **Denormalizowany (złe)** | Ogromne tabele, trudne sharding | +| **Nadmiernie znormalizowany** | Wiele JOIN, complex queries | +| **Zbalansowany** | Optymalne partycjonowanie, cache-friendly | + +#### Utrzymywalność + +``` +Zły model: +- Pole "data" typu VARCHAR przechowuje JSON, XML, CSV... +- Brak dokumentacji co oznaczają kody (status=1,2,3?) +- Nazwy kolumn: col1, col2, temp_field, test123 + +Dobry model: +- Dedykowane tabele i kolumny z opisowymi nazwami +- ENUM lub tabela słownikowa dla statusów +- Komentarze w schemacie, dokumentacja ERD +``` + +--- + +### 4. Koszty naprawy złego modelu + +``` +Koszt zmiany modelu danych w czasie: + +Koszt + ↑ + │ ████ + │ ████████████ + │ ████████████████████ + │ ████████████████████████████ + │ ████████████████████████████████████ + │ ████████████████████████████████████████████ + │████████████████████████████████████████████████████ + └────────────────────────────────────────────────────→ Czas + Projekt Dev Test Prod 2 lata 5 lat + +Migracja w produkcji: downtime, ryzyko utraty danych, +koordynacja z aplikacjami, rollback plan +``` + +**Reguła 1:10:100:** +- Naprawa w fazie projektowania: 1x +- Naprawa w fazie developmentu: 10x +- Naprawa w produkcji: 100x + +--- + +### 5. Cechy dobrego modelu danych + +| Cecha | Opis | +|-------|------| +| **Poprawność** | Odzwierciedla dziedzinę biznesową | +| **Kompletność** | Wszystkie wymagane dane | +| **Spójność** | Brak sprzeczności, integralność | +| **Minimalizm** | Brak zbędnej redundancji | +| **Elastyczność** | Możliwość rozszerzenia | +| **Wydajność** | Odpowiednia denormalizacja gdzie potrzeba | +| **Dokumentacja** | ERD, słownik danych | + +--- + +### 6. Wpływ na jakość danych (GIGO) + +``` +Garbage In, Garbage Out: + +┌──────────────────┐ +│ Złe dane wejść. │ → Zły model → Złe decyzje biznesowe +│ (brak walidacji) │ +└──────────────────┘ + +Dobry model wymusza jakość: +- NOT NULL gdzie wymagane +- CHECK constraints (age > 0) +- FOREIGN KEY (referential integrity) +- UNIQUE (brak duplikatów) +- Trigger dla złożonej walidacji +``` + +--- + +### 7. Model danych a architektura aplikacji + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ Model danych wpływa na: │ +│ │ +│ • ORM mapping (Entity classes) │ +│ • API endpoints (REST resources) │ +│ • UI forms (pola formularzy) │ +│ • Validation rules │ +│ • Business logic │ +│ • Reports & Analytics │ +│ • Data warehouse schema │ +│ • Integration contracts │ +│ │ +│ Zmiana w modelu → propagacja do WSZYSTKICH warstw! │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +## 🧠 Mnemoniki + +### "Model = Fundament domu": +Zły fundament → dom się zawali (kosztowna przebudowa) + +### "GIGO = Garbage In, Garbage Out": +Zły model → złe dane → złe decyzje + +### "1:10:100 = Koszt naprawy rośnie": +Im później naprawa, tym drożej + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Jak mierzyć jakość modelu danych?" +**Odpowiedź:** Metryki: liczba anomalii, poziom normalizacji, pokrycie constraints, liczba orphan records, czas wykonania typowych zapytań, coupling między tabelami, dokumentacja coverage. + +### Q2: "Kiedy denormalizacja jest uzasadniona?" +**Odpowiedź:** Read-heavy systemy (raportowanie), krytyczne zapytania wymagające wielu JOIN, cache/materialized views, data warehouse (star schema), gdy koszt UPDATE < koszt JOIN. + +### Q3: "Jak ewoluować model w produkcji?" +**Odpowiedź:** Migracje (Flyway, Liquibase), blue-green deployment, feature flags, backward compatible changes (add column, nie remove), expand-contract pattern. + +--- + +## 🎯 Kluczowe punkty + +1. **Fundament:** Model danych = podstawa całego systemu +2. **Kaskada:** Zmiana modelu → zmiany wszędzie +3. **Koszt:** 1:10:100 - wczesne poprawki tańsze +4. **Jakość:** Constraints wymuszają poprawność danych +5. **Dokumentacja:** ERD, słownik danych niezbędne + +--- + +## 📖 Źródła + +1. Date - "An Introduction to Database Systems" +2. Fowler - "Patterns of Enterprise Application Architecture" +3. Ambler - "Agile Database Techniques" diff --git a/pytania/odpowiedzi/28-fazy-ewolucji-modelu-danych.md b/pytania/odpowiedzi/28-fazy-ewolucji-modelu-danych.md new file mode 100644 index 0000000..5f934a7 --- /dev/null +++ b/pytania/odpowiedzi/28-fazy-ewolucji-modelu-danych.md @@ -0,0 +1,296 @@ +# Pytanie 28: Fazy ewolucji modelu danych + +## Pytanie +**"Omówić typowe fazy ewolucji modelu danych i pożądane cechy modelu w każdej z faz."** + +Przedmiot: MODA (Modelowanie Danych) + +--- + +## 📚 Odpowiedź główna + +### 1. Przegląd faz ewolucji + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ FAZY EWOLUCJI MODELU DANYCH │ +│ │ +│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ +│ │ KONCEPTUALNY │ → │ LOGICZNY │ → │ FIZYCZNY │ │ +│ │ (CDM) │ │ (LDM) │ │ (PDM) │ │ +│ └──────────────┘ └──────────────┘ └──────────────┘ │ +│ │ │ │ │ +│ ↓ ↓ ↓ │ +│ CO przechowujemy JAK strukturyzujemy JAK implementujemy │ +│ (biznes) (logika) (technologia) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 2. Model konceptualny (Conceptual Data Model) + +#### Cel +- Zrozumienie dziedziny biznesowej +- Komunikacja z interesariuszami (nietechnicznymi) +- Identyfikacja głównych encji i relacji + +#### Cechy pożądane + +| Cecha | Opis | +|-------|------| +| **Prostota** | Zrozumiały dla biznesu | +| **Abstrakcja** | Brak szczegółów technicznych | +| **Kompletność** | Wszystkie koncepcje biznesowe | +| **Poprawność** | Zgodność z rzeczywistością biznesową | + +#### Notacja i narzędzia + +``` +Diagram ERD (Entity-Relationship) - uproszczony: + + ┌──────────┐ ┌──────────┐ + │ KLIENT │ składa │ZAMÓWIENIE│ + │ │ 1────M │ │ + └──────────┘ └──────────┘ + │ + │ zawiera + │ M + │ + ┌──────────┐ + │ PRODUKT │ + │ │ + └──────────┘ + +Brak typów danych, kluczy, atrybutów szczegółowych! +Tylko encje i relacje (z krotnością). +``` + +#### Przykład + +``` +Model konceptualny dla e-commerce: + +Encje: Klient, Zamówienie, Produkt, Kategoria, Dostawca, Płatność + +Relacje: +- Klient składa Zamówienia (1:N) +- Zamówienie zawiera Produkty (M:N) +- Produkt należy do Kategorii (N:1) +- Dostawca dostarcza Produkty (M:N) +- Zamówienie ma Płatność (1:1) +``` + +--- + +### 3. Model logiczny (Logical Data Model) + +#### Cel +- Szczegółowa struktura danych +- Normalizacja +- Definicja atrybutów i kluczy +- Niezależność od DBMS + +#### Cechy pożądane + +| Cecha | Opis | +|-------|------| +| **Normalizacja** | Minimum 3NF, często BCNF | +| **Integralność** | PK, FK, constraints | +| **Kompletność atrybutów** | Wszystkie pola z typami logicznymi | +| **Dokumentacja** | Słownik danych | +| **Niezależność** | Bez szczegółów implementacji | + +#### Notacja + +``` +ERD szczegółowy (np. Crow's Foot): + +┌────────────────────────┐ ┌────────────────────────┐ +│ KLIENT │ │ ZAMÓWIENIE │ +├────────────────────────┤ ├────────────────────────┤ +│ PK klient_id │───┐ │ PK zamowienie_id │ +│ imie │ │ │ FK klient_id │──┐ +│ nazwisko │ └──<│ data_zamowienia │ │ +│ email (UNIQUE) │ │ status │ │ +│ data_rejestracji │ │ suma │ │ +└────────────────────────┘ └────────────────────────┘ │ + │ │ + │ 1 │ + │ │ + ┌────────────────────────┐ │ + │ POZYCJA_ZAMOWIENIA │ │ + ├────────────────────────┤ │ + │ PK pozycja_id │ │ + │ FK zamowienie_id │──┘ + │ FK produkt_id │ + │ ilosc │ + │ cena_jednostkowa │ + └────────────────────────┘ +``` + +#### Normalizacja + +``` +1NF: Atomowe wartości, brak powtarzających się grup +2NF: 1NF + brak częściowych zależności od PK +3NF: 2NF + brak zależności przechodnich +BCNF: Każdy determinant jest kluczem kandydującym +``` + +--- + +### 4. Model fizyczny (Physical Data Model) + +#### Cel +- Implementacja w konkretnym DBMS +- Optymalizacja wydajności +- Definicja indeksów, partycji, storage + +#### Cechy pożądane + +| Cecha | Opis | +|-------|------| +| **Wydajność** | Indeksy, denormalizacja gdzie potrzeba | +| **Specyfika DBMS** | Typy danych, funkcje specyficzne | +| **Skalowalność** | Partycjonowanie, sharding | +| **Bezpieczeństwo** | Uprawnienia, szyfrowanie | +| **Backup/Recovery** | Strategia archiwizacji | + +#### Przykład DDL (PostgreSQL) + +```sql +CREATE TABLE klient ( + klient_id SERIAL PRIMARY KEY, + imie VARCHAR(50) NOT NULL, + nazwisko VARCHAR(50) NOT NULL, + email VARCHAR(100) UNIQUE NOT NULL, + data_rejestracji TIMESTAMP DEFAULT CURRENT_TIMESTAMP, + status klient_status DEFAULT 'aktywny' +); + +CREATE INDEX idx_klient_email ON klient(email); +CREATE INDEX idx_klient_nazwisko ON klient(nazwisko); + +CREATE TABLE zamowienie ( + zamowienie_id SERIAL PRIMARY KEY, + klient_id INTEGER NOT NULL REFERENCES klient(klient_id), + data_zamowienia TIMESTAMP DEFAULT CURRENT_TIMESTAMP, + status zamowienie_status DEFAULT 'nowe', + suma DECIMAL(10,2) NOT NULL CHECK (suma >= 0) +) PARTITION BY RANGE (data_zamowienia); + +CREATE TABLE zamowienie_2024 PARTITION OF zamowienie + FOR VALUES FROM ('2024-01-01') TO ('2025-01-01'); +``` + +#### Optymalizacje fizyczne + +| Technika | Zastosowanie | +|----------|--------------| +| **Indeksy** | B-tree, Hash, GIN, GiST | +| **Partycjonowanie** | Range, List, Hash | +| **Denormalizacja** | Materialized views, redundancja | +| **Kompresja** | Kolumnowe storage | +| **Clustering** | Fizyczne uporządkowanie | + +--- + +### 5. Porównanie faz + +| Aspekt | Konceptualny | Logiczny | Fizyczny | +|--------|--------------|----------|----------| +| **Odbiorcy** | Biznes | Analitycy, projektanci | DBA, developerzy | +| **Abstrakcja** | Wysoka | Średnia | Niska | +| **DBMS** | Niezależny | Niezależny | Specyficzny | +| **Typy danych** | Brak | Logiczne | Natywne DBMS | +| **Indeksy** | Brak | Brak | Tak | +| **Normalizacja** | Nie | Tak (3NF+) | Może być denorm. | + +--- + +### 6. Transformacje między fazami + +``` +┌──────────────────────────────────────────────────────────────────┐ +│ Konceptualny → Logiczny: │ +│ • Encje → Tabele │ +│ • Atrybuty → Kolumny │ +│ • Relacje M:N → Tabele asocjacyjne │ +│ • Generalizacja → Opcje: single table, class table, concrete │ +│ • Normalizacja do 3NF/BCNF │ +├──────────────────────────────────────────────────────────────────┤ +│ Logiczny → Fizyczny: │ +│ • Typy logiczne → Typy DBMS (VARCHAR, INTEGER, TIMESTAMP...) │ +│ • Dodanie indeksów (na FK, WHERE, ORDER BY) │ +│ • Partycjonowanie dużych tabel │ +│ • Kontrolowana denormalizacja (wydajność) │ +│ • Tablespace, storage parameters │ +└──────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 7. Ewolucja w czasie (produkcja) + +``` +Wersja 1.0 → 1.1 → 2.0 → ... + +Narzędzia migracji: +- Flyway +- Liquibase +- Django migrations +- Alembic (SQLAlchemy) + +Zasady: +✓ Backward compatible (add, nie remove) +✓ Expand-Contract pattern +✓ Zero-downtime migrations +✓ Rollback plan +``` + +--- + +## 🧠 Mnemoniki + +### "C-L-F = Concept, Logic, Physical": +Trzy fazy ewolucji modelu + +### "Konceptualny = CO, Logiczny = JAK, Fizyczny = GDZIE": +- CO przechowujemy (biznes) +- JAK strukturyzujemy (normalizacja) +- GDZIE i jak wydajnie (DBMS) + +### "3NF w logicznym, denorm w fizycznym": +Normalizuj w logicznym, optymalizuj w fizycznym + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Kiedy pominąć fazę konceptualną?" +**Odpowiedź:** Małe projekty, proste dziedziny, doświadczony zespół znający domenę. Ale ryzyko: brak wspólnego zrozumienia z biznesem, pominięte wymagania. + +### Q2: "Jak dokumentować model danych?" +**Odpowiedź:** ERD (draw.io, Lucidchart, dbdiagram.io), słownik danych (Data Dictionary), komentarze w DDL, wiki z opisem biznesowym, generowana dokumentacja (SchemaSpy). + +### Q3: "Co to jest reverse engineering modelu?" +**Odpowiedź:** Generowanie modelu logicznego/konceptualnego z istniejącej bazy (fizycznej). Narzędzia: ERwin, PowerDesigner, DBeaver. Przydatne dla legacy systems. + +--- + +## 🎯 Kluczowe punkty + +1. **Konceptualny:** Biznes, encje, relacje, bez technologii +2. **Logiczny:** Normalizacja, PK/FK, typy logiczne +3. **Fizyczny:** DBMS-specific, indeksy, partycje +4. **Transformacja:** Konceptualny → Logiczny → Fizyczny +5. **Ewolucja:** Migracje, backward compatibility + +--- + +## 📖 Źródła + +1. Teorey et al. - "Database Modeling and Design" +2. Silberschatz - "Database System Concepts" +3. Ambler - "Agile Database Techniques" diff --git a/pytania/odpowiedzi/29-prawo-amdahla.md b/pytania/odpowiedzi/29-prawo-amdahla.md new file mode 100644 index 0000000..2f7693d --- /dev/null +++ b/pytania/odpowiedzi/29-prawo-amdahla.md @@ -0,0 +1,268 @@ +# Pytanie 29: Prawo Amdahla - przyśpieszenie programów równoległych + +## Pytanie +**"Oszacować ilościowo przyśpieszenie wykonania programu sekwencyjnego z fragmentami równoległymi na maszynie wielordzeniowej. Co osłabia to ograniczenie?"** + +Przedmiot: PORR (Programowanie Równoległe i Rozproszone) + +--- + +## 📚 Odpowiedź główna + +### 1. Prawo Amdahla + +#### Formuła + +$$S(n) = \frac{1}{(1-p) + \frac{p}{n}}$$ + +Gdzie: +- $S(n)$ = przyśpieszenie (speedup) +- $p$ = część programu, która może być zrównoleglona (0 ≤ p ≤ 1) +- $n$ = liczba procesorów/rdzeni +- $(1-p)$ = część sekwencyjna + +#### Interpretacja graficzna + +``` +Czas wykonania: + +Sekwencyjny (1 procesor): +├────────────────────────────────────────────────────────────────┤ +│ Sekwencyjna (1-p) │ Równoległa (p) │ +│ 20% │ 80% │ +├────────────────────────────┴────────────────────────────────────┤ + T₁ = 100% + +Równoległy (4 procesory): +├────────────────────────────┬────────────────────┤ +│ Sekwencyjna (1-p) │ Równoległa (p/n) │ +│ 20% │ 80%/4 = 20% │ +├────────────────────────────┴────────────────────┤ + T₄ = 40% + +Speedup = T₁/T₄ = 100/40 = 2.5x +``` + +#### Przykłady liczbowe + +| p (równoległa) | n=2 | n=4 | n=8 | n=∞ | +|----------------|-----|-----|-----|-----| +| 50% | 1.33 | 1.60 | 1.78 | 2.00 | +| 75% | 1.60 | 2.29 | 3.20 | 4.00 | +| 90% | 1.82 | 3.08 | 4.71 | 10.00 | +| 95% | 1.90 | 3.48 | 5.93 | 20.00 | +| 99% | 1.98 | 3.88 | 7.48 | 100.00 | + +#### Maksymalne przyśpieszenie (n → ∞) + +$$S_{max} = \lim_{n \to \infty} S(n) = \frac{1}{1-p}$$ + +``` +Dla p = 90% (10% sekwencyjnej): +S_max = 1/0.1 = 10x + +Nawet z nieskończoną liczbą procesorów, +10% kodu sekwencyjnego limituje speedup do 10x! +``` + +--- + +### 2. Wizualizacja ograniczenia + +``` +Speedup + ↑ +20 ┤ ........... p=99% + │ ...... + │ ...... +15 ┤ ..... + │ ..... + │ .... ______ p=95% +10 ┤ .... _____/ + │ ... _____/ + │ .. ______/ _____ p=90% + 5 ┤ . _____/ _____/ + │. _____/ _____/ + │ ____/ _____/ ____ p=75% + 2 ┼/ ________/_______________/____ + 1 ┼────────────────────────────────────────────→ Procesory (n) + 1 4 8 16 32 64 128 256 +``` + +**Obserwacja:** Krzywe szybko się spłaszczają - dodawanie procesorów daje coraz mniejszy zysk. + +--- + +### 3. Co osłabia ograniczenie Amdahla? + +#### 3.1 Prawo Gustafsona-Barsisa (Scaled Speedup) + +``` +Amdahl: Stały problem, więcej procesorów +Gustafson: Większy problem, stały czas + +S_scaled(n) = n - (1-p)(n-1) = 1 - p + p·n + +Dla p = 90%, n = 100: +S_scaled = 1 - 0.9 + 0.9·100 = 90.1x (vs Amdahl: ~10x) + +Zastosowanie: Symulacje, rendering, ML training +- Większy dataset +- Więcej iteracji +- Wyższa rozdzielczość +``` + +#### 3.2 Techniki zmniejszania części sekwencyjnej + +| Technika | Opis | +|----------|------| +| **Algorytmy równoległe** | Zamiana algorytmu sekwencyjnego na równoległy | +| **Lock-free structures** | Unikanie synchronizacji blokującej | +| **Pipelining** | Nakładanie faz obliczeń | +| **Speculative execution** | Równoległe wykonanie alternatyw | +| **Data parallelism** | Podział danych zamiast zadań | + +#### 3.3 Ukrywanie latencji + +``` +Sekwencyjne I/O: +CPU: ────compute────│wait│────compute────│wait│──── + ↑ I/O ↑ I/O + +Overlapping (prefetching, async I/O): +CPU: ────compute────────compute────────compute──── +I/O: └──fetch──┘ └──fetch──┘ └──fetch──┘ + +Efektywnie zmniejsza (1-p)! +``` + +--- + +### 4. Czynniki zmniejszające rzeczywiste przyśpieszenie + +``` +S_real < S_Amdahl ze względu na: + +┌─────────────────────────────────────────────────────────────────┐ +│ 1. OVERHEAD SYNCHRONIZACJI │ +│ - Mutex, semaphore contention │ +│ - Barrier wait time │ +│ - Lock granularity (coarse vs fine) │ +├─────────────────────────────────────────────────────────────────┤ +│ 2. KOMUNIKACJA │ +│ - Przesyłanie danych między wątkami/procesami │ +│ - Bandwidth limitations │ +│ - Latency (szczególnie distributed) │ +├─────────────────────────────────────────────────────────────────┤ +│ 3. LOAD IMBALANCE │ +│ - Nierówny podział pracy │ +│ - Różne czasy wykonania task'ów │ +├─────────────────────────────────────────────────────────────────┤ +│ 4. CACHE EFFECTS │ +│ - False sharing │ +│ - Cache coherency traffic │ +│ - NUMA effects │ +├─────────────────────────────────────────────────────────────────┤ +│ 5. THREAD MANAGEMENT │ +│ - Tworzenie/niszczenie wątków │ +│ - Context switching │ +│ - Thread pool overhead │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### False Sharing + +```c +// Zły kod - false sharing +struct Counter { + int count; // Te pola są w tej samej linii cache! +} counters[NUM_THREADS]; + +// Thread i: +counters[i].count++; // Invaliduje cache innych wątków! + +// Dobry kod - padding +struct Counter { + int count; + char padding[60]; // Separacja na osobne linie cache +} counters[NUM_THREADS]; +``` + +--- + +### 5. Efektywność równoległa + +$$E(n) = \frac{S(n)}{n} = \frac{1}{n \cdot (1-p) + p}$$ + +| p | n=4 | n=16 | n=64 | +|---|-----|------|------| +| 90% | 77% | 36% | 13% | +| 95% | 87% | 55% | 24% | +| 99% | 97% | 86% | 61% | + +**Wniosek:** Efektywność spada z liczbą procesorów. Trzeba zwiększać problem (Gustafson) lub zmniejszać (1-p). + +--- + +### 6. Rozszerzone prawo Amdahla (z overhead) + +$$S(n) = \frac{1}{(1-p) + \frac{p}{n} + O(n)}$$ + +Gdzie $O(n)$ = overhead zależny od n (komunikacja, synchronizacja). + +``` +Przykład: O(n) = 0.001·n (liniowy overhead) + +n=10: S = 1/(0.1 + 0.09 + 0.01) = 5.0 +n=100: S = 1/(0.1 + 0.009 + 0.1) = 4.8 +n=1000: S = 1/(0.1 + 0.0009 + 1) = 0.9 (slowdown!) + +Punkt optymalny: istnieje n* maksymalizujące S! +``` + +--- + +## 🧠 Mnemoniki + +### "Amdahl = Sequential is the limit": +Część sekwencyjna limituje maksymalne przyśpieszenie + +### "S_max = 1/(1-p)": +10% sekwencyjnej → max 10x speedup + +### "Gustafson = Scale the problem": +Większy problem → lepsze wykorzystanie procesorów + +### "FLOP = False sharing, Load imbalance, Overhead, Poor locality": +Główne przyczyny sublinearnego speedup + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Kiedy Gustafson jest lepszy od Amdahla?" +**Odpowiedź:** Gdy problem można skalować (więcej danych, iteracji). Symulacje fizyczne, rendering, ML training. Amdahl zakłada stały problem - pesymistyczny dla HPC. + +### Q2: "Jak zmierzyć rzeczywiste p?" +**Odpowiedź:** Profilowanie (perf, VTune). Zmierz czas sekwencyjny vs równoległy. p ≈ 1 - T_seq/T_total. Uwaga: p może zależeć od danych wejściowych. + +### Q3: "Co to jest strong vs weak scaling?" +**Odpowiedź:** Strong: stały problem, więcej proc. (Amdahl). Weak: problem rośnie proporcjonalnie do proc. (Gustafson). Weak scaling łatwiejsze do osiągnięcia. + +--- + +## 🎯 Kluczowe punkty + +1. **Amdahl:** $S = 1/((1-p) + p/n)$, max = $1/(1-p)$ +2. **Sekwencyjna część limituje** - 10% seq → max 10x +3. **Gustafson:** Skaluj problem, nie procesory +4. **Overhead:** Sync, komunikacja, cache, load imbalance +5. **Efektywność spada** z liczbą procesorów + +--- + +## 📖 Źródła + +1. Amdahl - "Validity of the Single Processor Approach" (1967) +2. Gustafson - "Reevaluating Amdahl's Law" (1988) +3. Hennessy, Patterson - "Computer Architecture" diff --git a/pytania/odpowiedzi/30-modelowanie-matematyczne-decyzje.md b/pytania/odpowiedzi/30-modelowanie-matematyczne-decyzje.md new file mode 100644 index 0000000..1685921 --- /dev/null +++ b/pytania/odpowiedzi/30-modelowanie-matematyczne-decyzje.md @@ -0,0 +1,282 @@ +# Pytanie 30: Modelowanie matematyczne dla problemów decyzyjnych + +## Pytanie +**"Omówić metody oraz typowe problemy w modelowaniu matematycznym dla problemów decyzyjnych i optymalizacyjnych."** + +Przedmiot: MOM (Metody Optymalizacji Matematycznej) + +--- + +## 📚 Odpowiedź główna + +### 1. Struktura modelu matematycznego + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ MODEL OPTYMALIZACYJNY │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ min/max f(x) ← Funkcja celu │ +│ │ +│ subject to: │ +│ g_i(x) ≤ 0 ← Ograniczenia nierównościowe │ +│ h_j(x) = 0 ← Ograniczenia równościowe │ +│ x ∈ X ← Dziedzina zmiennych │ +│ │ +│ gdzie x = (x₁, x₂, ..., xₙ) ∈ ℝⁿ (lub ℤⁿ, {0,1}ⁿ) │ +│ │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 2. Metody modelowania + +#### 2.1 Etapy tworzenia modelu + +``` +┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ +│ PROBLEM │ → │ MODEL │ → │ ROZWIĄZANIE│ → │ WALIDACJA │ +│ RZECZYWISTY│ │ MATEMATYCZNY│ │ OPTYMALNE │ │ I WDROŻENIE│ +└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ + │ │ │ │ + ↓ ↓ ↓ ↓ + Analiza Zmienne, Solver, Interpretacja, + wymagań funkcja celu, algorytm analiza wrażliwości + ograniczenia +``` + +#### 2.2 Typy modeli + +| Typ | Charakterystyka | Przykład | +|-----|-----------------|----------| +| **LP** (Linear Programming) | Liniowa f(x), liniowe g, h | Transport, alokacja | +| **QP** (Quadratic) | Kwadratowa f(x), liniowe ograniczenia | Portfolio | +| **NLP** (Nonlinear) | Nieliniowe f, g lub h | Engineering design | +| **MIP** (Mixed Integer) | Zmienne ciągłe + całkowite | Scheduling, routing | +| **MINLP** | Całkowitoliczbowe + nieliniowe | Najtrudniejsze | + +--- + +### 3. Typowe problemy w modelowaniu + +#### 3.1 Wybór zmiennych decyzyjnych + +``` +Problem: Ile zmiennych? Jakie typy? + +Przykład - planowanie produkcji: + +Źle: x = "plan produkcji" (zbyt ogólne) + +Dobrze: +x_it = ilość produktu i w okresie t (ciągła) +y_it = czy produkujemy i w t (binarna) +z_ijt = transport z i do j w t (całkowita) + +Zasady: +✓ Zmienne muszą być mierzalne +✓ Zmienne muszą być kontrolowalne +✓ Minimalna liczba dla pełnego opisu +``` + +#### 3.2 Problem Big-M + +``` +Modelowanie implikacji: y=1 → x ≤ 5 + +Zła formulacja (słaba relaksacja): +x ≤ 5 + M(1-y), gdzie M = 10^6 + +Lepsza formulacja: +x ≤ 5 + (UB_x - 5)(1-y), gdzie UB_x = upper bound na x + +Indicator constraints (jeśli solver wspiera): +y = 1 → x ≤ 5 (bezpośrednio) + +Problem: Duże M → słaba LP relaxation → wolny B&B +``` + +#### 3.3 Symetria + +``` +Problem: Wiele równoważnych rozwiązań optymalnych + +Przykład - bin packing: + Bin 1: {A, B}, Bin 2: {C} + Bin 1: {C}, Bin 2: {A, B} ← ta sama wartość! + +Rozwiązanie - symmetry breaking: + x[i][1] ≥ x[i][2] ≥ x[i][3] ... (lexicographic ordering) + +Lub: użyj indeksu pierwszego użycia pojemnika +``` + +#### 3.4 Walidacja modelu + +| Test | Opis | +|------|------| +| **Extreme cases** | Czy model działa dla skrajnych danych? | +| **Known solutions** | Czy odtwarza znane rozwiązania? | +| **Dimensional analysis** | Czy jednostki się zgadzają? | +| **Sensitivity analysis** | Jak rozwiązanie reaguje na zmiany? | +| **Infeasibility** | Czy model ma rozwiązanie dopuszczalne? | + +--- + +### 4. Techniki modelowania + +#### 4.1 Linearyzacja + +``` +Problem: xy (iloczyn zmiennych ciągłych) + +McCormick envelopes: +w ≥ x·LB_y + y·LB_x - LB_x·LB_y +w ≥ x·UB_y + y·UB_x - UB_x·UB_y +w ≤ x·LB_y + y·UB_x - LB_y·UB_x +w ≤ x·UB_y + y·LB_x - UB_y·LB_x + +Problem: |x| (wartość bezwzględna) + +Modelowanie: +min z +z ≥ x +z ≥ -x +``` + +#### 4.2 Modelowanie warunków logicznych + +``` +Alternatywa (OR): x ≤ 5 ∨ y ≤ 3 + +x ≤ 5 + M(1-z) +y ≤ 3 + Mz +z ∈ {0,1} + +Koniunkcja (AND): x ≤ 5 ∧ y ≤ 3 + +x ≤ 5 +y ≤ 3 (po prostu oba ograniczenia) +``` + +#### 4.3 Piece-wise linear functions + +``` +f(x) = różne liniowe segmenty + + f(x) + ↑ + │ / + │ / + │ / + │ /____ + │/ + └────────→ x + +Modelowanie SOS2 (Special Ordered Set type 2): +f(x) = Σ λ_i · f(breakpoint_i) +x = Σ λ_i · breakpoint_i +Σ λ_i = 1 +λ ≥ 0, max 2 sąsiednie λ_i > 0 +``` + +--- + +### 5. Wielokryterialne podejmowanie decyzji + +``` +min f₁(x), f₂(x), ..., f_k(x) ← konfliktujące cele + +Metody: + +1. WEIGHTED SUM: + min Σ w_i · f_i(x) + Problem: nie znajduje wszystkich Pareto-optymalnych + +2. ε-CONSTRAINT: + min f₁(x) + s.t. f_i(x) ≤ ε_i, i=2..k + +3. GOAL PROGRAMMING: + min Σ |f_i(x) - target_i| + +4. PARETO FRONT: + Znajdź wszystkie niezdominowane rozwiązania +``` + +--- + +### 6. Analiza wrażliwości + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ Co się zmieni gdy zmienią się dane wejściowe? │ +├─────────────────────────────────────────────────────────────────┤ +│ Shadow price (dual variable): │ +│ - Ile warta jest jednostka zasobu? │ +│ - Δf = λ · Δb (dla małych zmian RHS) │ +│ │ +│ Reduced cost: │ +│ - O ile musi się zmienić c_j żeby x_j wszedł do bazy? │ +│ │ +│ Range analysis: │ +│ - Przedział zmian parametrów bez zmiany optymalnej bazy │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 7. Częste błędy + +| Błąd | Konsekwencja | Rozwiązanie | +|------|--------------|-------------| +| **Brak bounds** | Unbounded lub słaba relaxation | Zawsze definiuj LB, UB | +| **Za duże M** | Numerical issues, wolne | Tight big-M | +| **Redundantne ograniczenia** | Wolniejsze, confusion | Minimalizuj | +| **Zła skala** | Numerical instability | Scaling, rescaling | +| **Over-modeling** | Za złożone, wolne | Simplify, aggregate | + +--- + +## 🧠 Mnemoniki + +### "VCO = Variables, Constraints, Objective": +Trzy elementy modelu matematycznego + +### "Big-M = Big Mistake (jeśli źle użyte)": +Unikaj dużych M, tight bounds + +### "PASS = Pareto, Analysis, Sensitivity, Symmetry": +Kluczowe zagadnienia zaawansowane + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Jak sprawdzić czy model jest poprawny?" +**Odpowiedź:** Testy na znanych instancjach, extreme cases, dimensional analysis, sprawdzenie czy relaksacja LP daje sensowne wyniki, analiza IIS dla infeasible. + +### Q2: "Kiedy linearyzować a kiedy użyć NLP?" +**Odpowiedź:** Linearyzuj gdy: nieliniowość jest "miękka", solver MIP szybszy niż NLP, potrzebujesz gwarancji optimum. NLP gdy: silna nieliniowość, ciągłe zmienne, akceptowalny local optimum. + +### Q3: "Jak obsłużyć niepewność w modelu?" +**Odpowiedź:** Stochastic programming (scenariusze), robust optimization (worst-case), chance constraints, sensitivity analysis. Wybór zależy od charakteru niepewności. + +--- + +## 🎯 Kluczowe punkty + +1. **Model:** Zmienne + funkcja celu + ograniczenia +2. **Big-M:** Unikaj dużych M, tight formulation +3. **Symetria:** Symmetry breaking constraints +4. **Walidacja:** Extreme cases, known solutions +5. **Wrażliwość:** Shadow prices, reduced costs + +--- + +## 📖 Źródła + +1. Williams - "Model Building in Mathematical Programming" +2. Wolsey - "Integer Programming" +3. Nemhauser, Wolsey - "Integer and Combinatorial Optimization" diff --git a/pytania/odpowiedzi/31-wypuklosc-nieliniowosc.md b/pytania/odpowiedzi/31-wypuklosc-nieliniowosc.md new file mode 100644 index 0000000..0b70df4 --- /dev/null +++ b/pytania/odpowiedzi/31-wypuklosc-nieliniowosc.md @@ -0,0 +1,317 @@ +# Pytanie 31: Wypukłość i nieliniowość w systemach decyzyjnych + +## Pytanie +**"Wyjaśnić główne zagadnienia modelowania matematycznego w systemach decyzyjnych z wykorzystaniem pojęć (nie)wypukłości i (nie)liniowości."** + +Przedmiot: MOM (Metody Optymalizacji Matematycznej) + +--- + +## 📚 Odpowiedź główna + +### 1. Klasyfikacja problemów optymalizacyjnych + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ KLASYFIKACJA PROBLEMÓW │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ LINIOWE NIELINIOWE │ +│ ┌─────────────┐ ┌─────────────┐ │ +│ │ LP │ │ NLP │ │ +│ │ Simplex, │ │ Gradient, │ │ +│ │ Interior │ │ Newton, │ │ +│ │ Point │ │ SQP │ │ +│ └─────────────┘ └──────┬──────┘ │ +│ │ │ +│ ┌───────────┴───────────┐ │ +│ │ │ │ +│ WYPUKŁE NIEWYPUKŁE │ +│ ┌─────────────┐ ┌─────────────┐ │ +│ │ Convex NLP │ │ Non-convex │ │ +│ │ Global opt │ │ Local opt │ │ +│ │ gwarantowane│ │ NP-trudne │ │ +│ └─────────────┘ └─────────────┘ │ +│ │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 2. Definicje kluczowe + +#### Zbiór wypukły + +$$S \text{ wypukły} \Leftrightarrow \forall x,y \in S, \forall \lambda \in [0,1]: \lambda x + (1-\lambda)y \in S$$ + +``` +WYPUKŁY: NIEWYPUKŁY: + ●───────● ●───────● + / \ / ↗ \ + / \ / / \ + / \ /___/ \ +● ● ● ● + Każdy odcinek Odcinek wychodzi + wewnątrz zbioru poza zbiór +``` + +#### Funkcja wypukła + +$$f \text{ wypukła} \Leftrightarrow f(\lambda x + (1-\lambda)y) \leq \lambda f(x) + (1-\lambda) f(y)$$ + +``` + f(x) + ↑ + │ Funkcja wypukła + │ /\ + │ / \ + │ / \ Cięciwa zawsze + │ /──────\ powyżej wykresu + │ / \ + │ / \ + └────────────────→ x + + f(x) + ↑ Funkcja wklęsła (concave) + │ ________ + │ / \ + │ / \ Cięciwa zawsze + │ /────────────\ poniżej wykresu + │/ \ + └────────────────→ x +``` + +--- + +### 3. Znaczenie wypukłości + +#### Własności problemów wypukłych + +| Własność | Opis | +|----------|------| +| **Global = Local** | Każde minimum lokalne jest globalne | +| **Jednoznaczność** | Zbiór optymalnych jest wypukły | +| **Efektywność** | Algorytmy wielomianowe (interior point) | +| **Dualność** | Silna dualność (zero duality gap) | +| **Warunki KKT** | Wystarczające dla optimum | + +#### Porównanie złożoności + +``` +Problem │ Złożoność │ Gwarancja +─────────────────┼────────────────┼────────────── +LP │ Wielomianowa │ Globalne opt. +Convex QP │ Wielomianowa │ Globalne opt. +Convex NLP │ Wielomianowa │ Globalne opt. +Non-convex NLP │ NP-trudna │ Lokalne opt. +MINLP │ NP-trudna │ (zależy) +``` + +--- + +### 4. Liniowość vs nieliniowość + +#### Programowanie liniowe (LP) + +$$\min c^T x \quad \text{s.t.} \quad Ax \leq b, \quad x \geq 0$$ + +``` +Cechy LP: +✓ Optimum w wierzchołku (jeśli istnieje) +✓ Simplex: pivotuje między wierzchołkami +✓ Interior Point: przez wnętrze +✓ Zawsze wypukłe +✓ Silna dualność +``` + +#### Programowanie nieliniowe (NLP) + +$$\min f(x) \quad \text{s.t.} \quad g_i(x) \leq 0, \quad h_j(x) = 0$$ + +``` +Typy nieliniowości: + +1. Kwadratowa (QP): + min x'Qx + c'x s.t. Ax ≤ b + + Q ≻ 0 (dodatnio określona) → wypukłe + Q ma ujemne eigenvalues → niewypukłe + +2. Ogólna nieliniowa: + min sin(x) + x²·y + s.t. x² + y² ≤ 1 + + Może być wypukła lub nie +``` + +--- + +### 5. Testowanie wypukłości + +#### Dla funkcji + +``` +f(x) jest wypukła jeśli: + +1. HESJAN: H = ∇²f(x) ≽ 0 (dodatnio półokreślony) dla wszystkich x + +2. Kompozycja: + - Suma wypukłych → wypukła + - max(f, g) gdzie f, g wypukłe → wypukła + - f(Ax+b) gdzie f wypukła → wypukła + +3. Znane funkcje wypukłe: + - x², eˣ, -log(x), |x|, max(x,0) + - Normy: ||x||₁, ||x||₂ +``` + +#### Dla zbiorów + +``` +Zbiór S jest wypukły jeśli: + +1. Przekrój wypukłych → wypukły +2. {x: Ax ≤ b} → wielościan (wypukły) +3. {x: ||x||₂ ≤ r} → kula (wypukła) +4. {x: f(x) ≤ α} gdzie f wypukła → sublevel set (wypukły) +``` + +--- + +### 6. Problemy niewypukłe + +#### Konsekwencje + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ PROBLEM NIEWYPUKŁY: │ +│ │ +│ f(x) │ +│ ↑ ● │ +│ │ / \ ● ← lokalne minimum │ +│ │ / \ /│\ │ +│ │ / \ / │ \ │ +│ │ / \/ │ \ │ +│ │ / ● │ \ ● ← globalne minimum │ +│ │ / local │ \ / │ +│ │ / min │ \/ │ +│ └────────────────────────→ x │ +│ │ +│ Algorytmy gradientowe znajdą LOKALNE minimum! │ +│ Nie ma gwarancji znalezienia globalnego. │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### Strategie dla niewypukłych + +| Strategia | Opis | +|-----------|------| +| **Multi-start** | Wiele punktów startowych | +| **Global solvers** | BARON, Couenne, SCIP | +| **Relaxation** | Convex relaxation + B&B | +| **Metaheurystyki** | GA, SA, PSO | +| **Reformulation** | Przeformułuj na wypukły | + +--- + +### 7. Przykłady praktyczne + +#### Wypukły - Portfolio optimization + +``` +Markowitz: +min x'Σx (wariancja, Q = Σ ≻ 0 → wypukłe!) +s.t. μ'x ≥ r (minimalny zwrot) + Σx_i = 1 (pełna inwestycja) + x ≥ 0 (brak short selling) + +Jest WYPUKŁY → globalne optimum gwarantowane +``` + +#### Niewypukły - Pooling problem + +``` +Mieszanie strumieni o różnych jakościach: + +q_out = Σ(q_i · flow_i) / Σ flow_i + +Zawiera ILOCZYN zmiennych (bilinear) → NIEWYPUKŁY +Tylko lokalne optimum gwarantowane (chyba że global solver) +``` + +#### Granica - SVM + +``` +Hard margin SVM (separowalne dane): +min ||w||² +s.t. y_i(w·x_i + b) ≥ 1 + +Jest WYPUKŁY (QP z liniowymi ograniczeniami) + +Kernel SVM - nadal wypukły w przestrzeni dualnej! +``` + +--- + +### 8. Dualność + +``` +Primal (P): Dual (D): +min f(x) max L(λ, μ) +s.t. g(x) ≤ 0 s.t. λ ≥ 0 + h(x) = 0 + +Lagrangian: L(x,λ,μ) = f(x) + λᵀg(x) + μᵀh(x) + +SŁABA DUALNOŚĆ (zawsze): + d* ≤ p* (dual ≤ primal) + +SILNA DUALNOŚĆ (dla wypukłych + constraint qualification): + d* = p* (zero duality gap) + +Duality gap dla niewypukłych może być > 0! +``` + +--- + +## 🧠 Mnemoniki + +### "Convex = Global Local": +Dla wypukłych: każde lokalne = globalne + +### "Hesjan ≻ 0 = wypukłe": +Dodatnio określona macierz drugich pochodnych + +### "LP ⊂ QP ⊂ Convex NLP": +Każdy LP jest QP, każdy QP (z Q≥0) jest Convex NLP + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Jak rozpoznać czy problem jest wypukły?" +**Odpowiedź:** Sprawdź: (1) czy f celu ma Hesjan ≥ 0, (2) czy ograniczenia nierównościowe g_i są wypukłe, (3) czy ograniczenia równościowe h_j są liniowe. Jeśli wszystkie TAK → wypukły. + +### Q2: "Co zrobić gdy problem jest niewypukły?" +**Odpowiedź:** Multi-start, global solvers (BARON), convex relaxation, reformulation (np. SDP relaxation dla QCQP), metaheurystyki, decomposition methods. + +### Q3: "Czy MILP jest wypukły?" +**Odpowiedź:** Nie w klasycznym sensie (zmienne dyskretne). Ale LP relaxation jest wypukła. Branch & Bound wykorzystuje wypukłość relaksacji do pruning. + +--- + +## 🎯 Kluczowe punkty + +1. **Wypukłość:** Global = Local, efektywne algorytmy +2. **Niewypukłość:** Wiele minimów lokalnych, NP-trudne +3. **Hesjan:** ∇²f ≥ 0 → funkcja wypukła +4. **LP zawsze wypukły**, QP zależy od Q +5. **Silna dualność** dla wypukłych + +--- + +## 📖 Źródła + +1. Boyd, Vandenberghe - "Convex Optimization" +2. Nocedal, Wright - "Numerical Optimization" +3. Bazaraa et al. - "Nonlinear Programming" diff --git a/pytania/odpowiedzi/32-komunikacja-synchroniczna-asynchroniczna.md b/pytania/odpowiedzi/32-komunikacja-synchroniczna-asynchroniczna.md new file mode 100644 index 0000000..44dd5e8 --- /dev/null +++ b/pytania/odpowiedzi/32-komunikacja-synchroniczna-asynchroniczna.md @@ -0,0 +1,309 @@ +# Pytanie 32: Komunikacja synchroniczna/asynchroniczna, blokująca/nieblokująca + +## Pytanie +**"Podać definicję komunikacji synchronicznej i asynchronicznej oraz blokującej i nieblokującej. Jak uniknąć zakleszczenia, gdy dwa symetryczne procesy (np. realizujące algorytm iteracyjny Jacobiego) mają w kodzie następujące po sobie wywołania funkcji wysyłającej komunikat do partnera i odbierającej komunikat wysłany przez niego?"** + +Przedmiot: PORR (Programowanie Równoległe i Rozproszone) + +--- + +## 📚 Odpowiedź główna + +### 1. Definicje podstawowe + +#### Synchroniczna vs Asynchroniczna + +``` +KOMUNIKACJA SYNCHRONICZNA: +┌─────────────────────────────────────────────────────────────────┐ +│ Nadawca i odbiorca synchronizują się w momencie przekazania │ +│ │ +│ Proces A Proces B │ +│ │ │ │ +│ │ send() ──────────────────> recv() │ +│ │ [czeka aż B odbierze] [odbiera] │ +│ │ [kontynuuje] │ │ +│ │ +│ Gwarancja: Po powrocie z send() wiadomość została odebrana │ +└─────────────────────────────────────────────────────────────────┘ + +KOMUNIKACJA ASYNCHRONICZNA: +┌─────────────────────────────────────────────────────────────────┐ +│ Nadawca nie czeka na odbiorcę │ +│ │ +│ Proces A Proces B │ +│ │ │ │ +│ │ send() ─────────> [bufor] ───> recv() │ +│ │ [kontynuuje │ (później) │ +│ │ natychmiast] │ │ +│ │ +│ Gwarancja: Wiadomość trafiła do bufora (nie do odbiorcy!) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### Blokująca vs Nieblokująca + +``` +OPERACJA BLOKUJĄCA: +┌─────────────────────────────────────────────────────────────────┐ +│ Wywołanie nie zwraca kontroli do wołającego dopóki operacja │ +│ nie zostanie zakończona (lub warunek spełniony) │ +│ │ +│ Proces: send() │ +│ ├─────────────────────┤ │ +│ │ BLOKADA │ │ +│ │ (czeka na coś) │ │ +│ └─────────────────────┘ │ +│ return │ +└─────────────────────────────────────────────────────────────────┘ + +OPERACJA NIEBLOKUJĄCA: +┌─────────────────────────────────────────────────────────────────┐ +│ Wywołanie zwraca natychmiast, operacja wykonuje się w tle │ +│ │ +│ Proces: isend() → return immediately │ +│ │ │ +│ │ (inne obliczenia) │ +│ │ │ +│ wait() lub test() ← sprawdź czy zakończone │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 2. Kombinacje w MPI + +| Funkcja MPI | Blokująca? | Synchroniczna? | Opis | +|-------------|------------|----------------|------| +| `MPI_Send` | Blokująca | Zależne od impl. | Standard send | +| `MPI_Ssend` | Blokująca | Synchroniczna | Czeka na recv | +| `MPI_Bsend` | Blokująca | Asynchroniczna | Buforowana | +| `MPI_Rsend` | Blokująca | - | Ready (recv musi czekać) | +| `MPI_Isend` | Nieblokująca | Asynchroniczna | Immediate | +| `MPI_Recv` | Blokująca | - | Standard recv | +| `MPI_Irecv` | Nieblokująca | - | Immediate recv | + +--- + +### 3. Problem zakleszczenia (Deadlock) + +#### Scenariusz: Algorytm Jacobiego + +```c +// DEADLOCK! - oba procesy czekają na siebie nawzajem + +// Proces 0: // Proces 1: +MPI_Send(to=1, data); MPI_Send(to=0, data); +MPI_Recv(from=1, data); MPI_Recv(from=0, data); + +Przebieg: +┌──────────────────┬──────────────────┐ +│ PROCES 0 │ PROCES 1 │ +├──────────────────┼──────────────────┤ +│ Send(to=1) │ Send(to=0) │ +│ [BLOKUJE - czeka │ [BLOKUJE - czeka │ +│ aż 1 odbierze] │ aż 0 odbierze] │ +│ ↓ │ ↓ │ +│ DEADLOCK! │ DEADLOCK! │ +│ (nikt nie robi │ (nikt nie robi │ +│ Recv) │ Recv) │ +└──────────────────┴──────────────────┘ +``` + +--- + +### 4. Rozwiązania problemu zakleszczenia + +#### 4.1 Zmiana kolejności operacji + +```c +// Proces 0: // Proces 1: +MPI_Send(to=1, data); MPI_Recv(from=0, data); // ← zmiana! +MPI_Recv(from=1, data); MPI_Send(to=0, data); + +Przebieg: +┌──────────────────┬──────────────────┐ +│ PROCES 0 │ PROCES 1 │ +├──────────────────┼──────────────────┤ +│ Send(to=1) ──────│──→ Recv(from=0) │ +│ [zakończone] │ [zakończone] │ +│ Recv(from=1) ←───│─── Send(to=0) │ +│ [zakończone] │ [zakończone] │ +└──────────────────┴──────────────────┘ +✓ Brak deadlocka! +``` + +#### 4.2 Nieblokujące operacje + +```c +// Oba procesy: +MPI_Request req_send, req_recv; + +MPI_Irecv(from=partner, data_in, &req_recv); // Nieblokujące recv +MPI_Isend(to=partner, data_out, &req_send); // Nieblokujące send +MPI_Wait(&req_recv, &status); // Czekaj na recv +MPI_Wait(&req_send, &status); // Czekaj na send + +Przebieg: +┌──────────────────┬──────────────────┐ +│ PROCES 0 │ PROCES 1 │ +├──────────────────┼──────────────────┤ +│ Irecv (posted) │ Irecv (posted) │ +│ Isend (posted) │ Isend (posted) │ +│ ↓ ↓ │ ↓ ↓ │ +│ [operacje w tle] │ [operacje w tle] │ +│ Wait (recv done) │ Wait (recv done) │ +│ Wait (send done) │ Wait (send done) │ +└──────────────────┴──────────────────┘ +✓ Brak deadlocka! +``` + +#### 4.3 MPI_Sendrecv + +```c +// Oba procesy (najczystsze rozwiązanie): +MPI_Sendrecv( + send_buf, send_count, type, dest, send_tag, + recv_buf, recv_count, type, source, recv_tag, + comm, &status +); + +// Wewnętrznie implementuje bezpieczną wymianę +// Unika deadlocka automatycznie +``` + +#### 4.4 Buforowane wysyłanie + +```c +// Attach buffer +char buffer[BUFFER_SIZE]; +MPI_Buffer_attach(buffer, BUFFER_SIZE); + +// Oba procesy: +MPI_Bsend(to=partner, data); // Kopiuje do bufora i wraca +MPI_Recv(from=partner, data); // Teraz może odebrać + +MPI_Buffer_detach(&buffer, &size); + +// Działa gdy bufor wystarczająco duży +``` + +--- + +### 5. Porównanie rozwiązań + +| Rozwiązanie | Zalety | Wady | +|-------------|--------|------| +| **Zmiana kolejności** | Proste, brak overhead | Wymaga asymetrii kodu | +| **Isend/Irecv** | Elastyczne, overlap | Złożoność kodu | +| **Sendrecv** | Proste, bezpieczne | Mniej elastyczne | +| **Bsend** | Podobne do standardowego | Wymaga bufora, memory | + +--- + +### 6. Algorytm Jacobiego - pełny przykład + +```c +// Iteracyjne rozwiązanie równania Laplace'a +// Grid podzielony między procesy + +for (int iter = 0; iter < MAX_ITER; iter++) { + // Wymiana granic z sąsiadami + + // Bezpieczna wymiana z lewym sąsiadem + if (rank > 0) { + MPI_Sendrecv( + &u[1], 1, MPI_DOUBLE, rank-1, 0, // wyślij lewą granicę + &u[0], 1, MPI_DOUBLE, rank-1, 0, // odbierz od lewego + MPI_COMM_WORLD, &status + ); + } + + // Bezpieczna wymiana z prawym sąsiadem + if (rank < size-1) { + MPI_Sendrecv( + &u[n-2], 1, MPI_DOUBLE, rank+1, 0, // wyślij prawą granicę + &u[n-1], 1, MPI_DOUBLE, rank+1, 0, // odbierz od prawego + MPI_COMM_WORLD, &status + ); + } + + // Obliczenia Jacobiego + for (int i = 1; i < n-1; i++) { + u_new[i] = 0.5 * (u[i-1] + u[i+1]); + } + + swap(&u, &u_new); +} +``` + +--- + +### 7. Wzorce komunikacji + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ RING (pierścień) - każdy z sąsiadami: │ +│ │ +│ ┌───→ P0 ───→ P1 ───→ P2 ───→ P3 ───┐ │ +│ └──────────────────────────────────────┘ │ +│ │ +│ Bezpieczne: Sendrecv w jednym kierunku │ +├─────────────────────────────────────────────────────────────────┤ +│ ALL-TO-ALL - każdy z każdym: │ +│ │ +│ P0 ←→ P1 │ +│ P0 ←→ P2 │ +│ P1 ←→ P2 │ +│ ... │ +│ │ +│ Rozwiązanie: MPI_Alltoall lub ordered pairwise exchange │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +## 🧠 Mnemoniki + +### "S-B Matrix": +| | Sync | Async | +|---|---|---| +| **Block** | Ssend | Send/Bsend | +| **Non-block** | - | Isend | + +### "I = Immediate = Non-blocking": +MPI_Isend, MPI_Irecv - nieblokujące (I na początku) + +### "Sendrecv = Safe exchange": +Jedna funkcja, zero deadlocków + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Czy MPI_Send jest synchroniczne?" +**Odpowiedź:** Zależy od implementacji i rozmiaru! Małe wiadomości często buforowane (async), duże mogą być sync. MPI_Ssend zawsze sync, MPI_Bsend zawsze async (buforowane). + +### Q2: "Jak wykryć potencjalny deadlock?" +**Odpowiedź:** Analiza statyczna grafu zależności send/recv. Narzędzia: MUST, Marmot. Runtime: timeouty, watchdog. Zasada: unikaj cykli w grafie oczekiwań. + +### Q3: "Co to jest eager vs rendezvous protocol?" +**Odpowiedź:** Eager: małe msg kopiowane do bufora natychmiast (async). Rendezvous: duże msg - handshake send/recv przed transferem (sync). Threshold zależy od implementacji MPI. + +--- + +## 🎯 Kluczowe punkty + +1. **Synchroniczna:** Nadawca czeka na odbiorcę +2. **Blokująca:** Funkcja nie wraca do zakończenia +3. **Deadlock:** Cykliczne oczekiwanie (Send-Send) +4. **Rozwiązania:** Sendrecv, Isend/Irecv, zmiana kolejności +5. **MPI_I*** = nieblokujące (Immediate) + +--- + +## 📖 Źródła + +1. MPI Standard (mpi-forum.org) +2. Gropp et al. - "Using MPI" +3. Pacheco - "Parallel Programming with MPI" diff --git a/pytania/odpowiedzi/33-publikuj-subskrybuj.md b/pytania/odpowiedzi/33-publikuj-subskrybuj.md new file mode 100644 index 0000000..5781a85 --- /dev/null +++ b/pytania/odpowiedzi/33-publikuj-subskrybuj.md @@ -0,0 +1,334 @@ +# Pytanie 33: Model publikuj-subskrybuj (Pub/Sub) + +## Pytanie +**"Scharakteryzować model przesyłania komunikatów publikuj-subskrybuj oraz przykładowe rozwiązania techniczne wykorzystujące ten model."** + +Przedmiot: PSD (Przetwarzanie Strumieniowe Danych) + +--- + +## 📚 Odpowiedź główna + +### 1. Definicja modelu Pub/Sub + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ MODEL PUBLISH-SUBSCRIBE │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ PUBLISHERS BROKER SUBSCRIBERS │ +│ (nadawcy) (pośrednik) (odbiorcy) │ +│ │ +│ ┌─────┐ ┌─────────┐ ┌─────┐ │ +│ │ P1 │ ──publish──→ │ │ ──────→ │ S1 │ │ +│ └─────┘ topic:A │ │ topic:A └─────┘ │ +│ │ MESSAGE │ │ +│ ┌─────┐ │ BROKER │ ┌─────┐ │ +│ │ P2 │ ──publish──→ │ │ ──────→ │ S2 │ │ +│ └─────┘ topic:B │ (router)│ topic:A └─────┘ │ +│ │ │ topic:B │ +│ ┌─────┐ │ │ ┌─────┐ │ +│ │ P3 │ ──publish──→ │ │ ──────→ │ S3 │ │ +│ └─────┘ topic:A └─────────┘ topic:B └─────┘ │ +│ │ +│ Cechy: │ +│ • Luźne powiązanie (publisher nie zna subscriberów) │ +│ • Asynchroniczność │ +│ • Skalowalność (1:N, N:M) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 2. Typy subskrypcji + +| Typ | Opis | Przykład | +|-----|------|----------| +| **Topic-based** | Subskrypcja na nazwany temat | `subscribe("orders")` | +| **Content-based** | Filtrowanie po zawartości | `price > 100 AND category = "electronics"` | +| **Type-based** | Na podstawie typu wiadomości | `subscribe(OrderEvent.class)` | +| **Hierarchical** | Tematy zagnieżdżone | `sport/football/+` (wildcard) | + +### Wildcardy (MQTT) + +``` +Hierarchia tematów: + home/living-room/temperature + home/living-room/humidity + home/bedroom/temperature + home/kitchen/temperature + +Subskrypcje: + home/living-room/# → wszystko z living-room + home/+/temperature → temperatura ze wszystkich pomieszczeń + home/# → wszystko z home +``` + +--- + +### 3. Gwarancje dostarczenia + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ QoS (Quality of Service) levels: │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ QoS 0: AT MOST ONCE (fire and forget) │ +│ Publisher ──msg──→ Broker ──msg──→ Subscriber │ +│ • Brak potwierdzenia │ +│ • Możliwa utrata │ +│ • Najszybsze │ +│ │ +│ QoS 1: AT LEAST ONCE │ +│ Publisher ──msg──→ Broker ──ack──→ Publisher │ +│ • Potwierdzenie dostarczenia │ +│ • Możliwe duplikaty │ +│ │ +│ QoS 2: EXACTLY ONCE │ +│ Publisher ←──handshake──→ Broker │ +│ • 4-way handshake │ +│ • Brak duplikatów, brak utraty │ +│ • Najwolniejsze │ +│ │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 4. Rozwiązania techniczne + +#### 4.1 Apache Kafka + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ APACHE KAFKA │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Topic: "orders" │ +│ ┌─────────────────────────────────────────────────┐ │ +│ │ Partition 0: [msg1][msg2][msg3][msg4]... │ │ +│ │ Partition 1: [msg5][msg6][msg7]... │ │ +│ │ Partition 2: [msg8][msg9]... │ │ +│ └─────────────────────────────────────────────────┘ │ +│ │ +│ Consumer Groups: │ +│ Group A: Consumer1 → Part0, Consumer2 → Part1,2 │ +│ Group B: Consumer3 → Part0,1,2 (wszystkie) │ +│ │ +│ Cechy: │ +│ • Distributed, fault-tolerant │ +│ • Persisted log (retention) │ +│ • High throughput (millions msg/s) │ +│ • Pull model (consumer kontroluje tempo) │ +│ • Exactly-once semantics (transactions) │ +└─────────────────────────────────────────────────────────────────┘ + +// Producer +producer.send(new ProducerRecord<>("orders", key, value)); + +// Consumer +consumer.subscribe(Arrays.asList("orders")); +while (true) { + ConsumerRecords records = consumer.poll(Duration.ofMillis(100)); + for (ConsumerRecord record : records) { + process(record); + } +} +``` + +#### 4.2 RabbitMQ + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ RABBITMQ │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Publisher → Exchange → Queue → Consumer │ +│ │ +│ Exchange types: │ +│ • Direct: routing_key exact match │ +│ • Topic: routing_key pattern (*.error, logs.#) │ +│ • Fanout: broadcast to all queues │ +│ • Headers: match on headers │ +│ │ +│ [P] ─→ [Exchange] ─┬─→ [Queue1] ─→ [C1] │ +│ (topic) │ │ +│ └─→ [Queue2] ─→ [C2] │ +│ │ +│ Cechy: │ +│ • AMQP protocol │ +│ • Flexible routing │ +│ • Push model (broker wysyła do consumera) │ +│ • Acknowledgments, dead letter queues │ +└─────────────────────────────────────────────────────────────────┘ + +// Python - pika +channel.exchange_declare(exchange='logs', exchange_type='fanout') +channel.basic_publish(exchange='logs', routing_key='', body=message) + +channel.queue_bind(exchange='logs', queue=queue_name) +channel.basic_consume(queue=queue_name, on_message_callback=callback) +``` + +#### 4.3 MQTT (Message Queuing Telemetry Transport) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ MQTT │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Lightweight protocol for IoT │ +│ │ +│ [Sensor] ──publish──→ [Broker] ──deliver──→ [Dashboard] │ +│ topic: (Mosquitto, │ +│ "home/temp" HiveMQ) │ +│ │ +│ Cechy: │ +│ • Minimal overhead (2 byte header) │ +│ • QoS 0, 1, 2 │ +│ • Retained messages │ +│ • Last Will and Testament (LWT) │ +│ • Ideal for constrained devices │ +│ │ +│ Brokers: Mosquitto, HiveMQ, EMQ X, AWS IoT Core │ +└─────────────────────────────────────────────────────────────────┘ + +// Python - paho-mqtt +client.publish("home/temperature", payload="22.5") +client.subscribe("home/#") +``` + +#### 4.4 Redis Pub/Sub + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ REDIS PUB/SUB │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Prosty pub/sub w Redis │ +│ │ +│ PUBLISH channel message │ +│ SUBSCRIBE channel │ +│ PSUBSCRIBE pattern (np. news.*) │ +│ │ +│ Cechy: │ +│ • Fire-and-forget (brak persistence) │ +│ • Very fast │ +│ • Brak consumer groups (podstawowy) │ +│ │ +│ Redis Streams (nowsze): │ +│ • Persistent log (jak Kafka) │ +│ • Consumer groups │ +│ • XADD, XREAD, XGROUP │ +└─────────────────────────────────────────────────────────────────┘ + +# Publisher +redis-cli PUBLISH news "Breaking: ..." + +# Subscriber +redis-cli SUBSCRIBE news +``` + +--- + +### 5. Porównanie rozwiązań + +| Cecha | Kafka | RabbitMQ | MQTT | Redis Pub/Sub | +|-------|-------|----------|------|---------------| +| **Model** | Pull (log) | Push (queue) | Push | Push | +| **Persistence** | Tak (log) | Opcjonalne | Retained only | Nie (Streams: tak) | +| **Throughput** | Bardzo wysoki | Wysoki | Niski-średni | Wysoki | +| **Routing** | Topic/partition | Flexible | Topic hierarchy | Channel/pattern | +| **Use case** | Event streaming | Task queues | IoT | Real-time simple | +| **Protocol** | Własny | AMQP | MQTT | RESP | + +--- + +### 6. Zalety i wady Pub/Sub + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ ZALETY: │ +│ ✓ Luźne powiązanie (decoupling) │ +│ ✓ Skalowalność (dodawanie subskrybentów bez zmian publishera) │ +│ ✓ Asynchroniczność (brak blokowania) │ +│ ✓ Broadcast (1:N) │ +│ ✓ Filtrowanie (content-based, topics) │ +├─────────────────────────────────────────────────────────────────┤ +│ WADY: │ +│ ✗ Brak gwarancji dostarczenia (zależy od QoS) │ +│ ✗ Ordering challenges (zwłaszcza z partycjami) │ +│ ✗ Debugging trudniejsze (brak bezpośredniego połączenia) │ +│ ✗ Broker = single point of failure (wymaga HA) │ +│ ✗ Message loss jeśli subscriber offline (bez persistence) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 7. Wzorce użycia + +``` +1. EVENT SOURCING: + [Service] ─publish─→ [Kafka] ←─consume─ [Projections] + Wszystkie zmiany jako events, rebuild state z log + +2. CQRS (Command Query Responsibility Segregation): + [Write Model] ─events─→ [Event Bus] ─→ [Read Model] + Oddzielne modele do zapisu i odczytu + +3. MICROSERVICES COMMUNICATION: + [Order Service] ─"OrderCreated"─→ [Message Broker] + │ + ┌────────────────────┼────────────────────┐ + ↓ ↓ ↓ + [Inventory] [Shipping] [Notification] + +4. IoT DATA COLLECTION: + [Sensors] ─MQTT─→ [Broker] ─→ [Data Pipeline] ─→ [Analytics] +``` + +--- + +## 🧠 Mnemoniki + +### "Pub/Sub = Radio broadcast": +Publisher nadaje, kto chce słucha (subscribe) + +### "Kafka = Log, RabbitMQ = Queue": +Kafka przechowuje log, RabbitMQ to klasyczna kolejka + +### "QoS 0-1-2 = Fire-AtLeast-Exactly": +0 = fire&forget, 1 = at least once, 2 = exactly once + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Kiedy Kafka a kiedy RabbitMQ?" +**Odpowiedź:** Kafka: event streaming, log retention, replay, high throughput, analytics. RabbitMQ: task queues, complex routing, request-reply, legacy AMQP integration. + +### Q2: "Co to jest consumer group w Kafce?" +**Odpowiedź:** Grupa consumerów gdzie każda partycja jest przypisana do jednego consumera w grupie. Umożliwia parallel processing i load balancing. Różne grupy otrzymują wszystkie wiadomości niezależnie. + +### Q3: "Jak zapewnić ordering w pub/sub?" +**Odpowiedź:** Kafka: ordering per partition (użyj tego samego klucza). RabbitMQ: single queue, single consumer. MQTT: QoS 2 dla pojedynczego topicu. Globalny ordering wymaga single partition/queue. + +--- + +## 🎯 Kluczowe punkty + +1. **Pub/Sub:** Luźne powiązanie, asynchroniczność, 1:N +2. **Kafka:** Distributed log, high throughput, persistence +3. **RabbitMQ:** AMQP, flexible routing, push model +4. **MQTT:** IoT, lightweight, QoS levels +5. **Gwarancje:** At most/least/exactly once + +--- + +## 📖 Źródła + +1. Kafka Documentation - kafka.apache.org +2. RabbitMQ Tutorials - rabbitmq.com +3. MQTT Specification - mqtt.org +4. Kleppmann - "Designing Data-Intensive Applications" diff --git a/pytania/odpowiedzi/34-analityka-strumieniowa.md b/pytania/odpowiedzi/34-analityka-strumieniowa.md new file mode 100644 index 0000000..25521bc --- /dev/null +++ b/pytania/odpowiedzi/34-analityka-strumieniowa.md @@ -0,0 +1,331 @@ +# Pytanie 34: Analityka danych strumieniowych + +## Pytanie +**"Scharakteryzować rozwiązania analityczne działające na danych o charakterze strumieniowym."** + +Przedmiot: PSD (Przetwarzanie Strumieniowe Danych) + +--- + +## 📚 Odpowiedź główna + +### 1. Charakterystyka danych strumieniowych + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ DANE STRUMIENIOWE vs BATCH │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ BATCH: │ +│ ┌─────────────────────────┐ │ +│ │ Dane statyczne │ → Przetwarzanie → Wynik │ +│ │ (cały zbiór) │ (jednorazowe) │ +│ └─────────────────────────┘ │ +│ │ +│ STREAMING: │ +│ ─────●────●──●─────●──●────●───────→ (nieskończony strumień) │ +│ │ │ │ │ │ │ │ +│ ↓ ↓ ↓ ↓ ↓ ↓ │ +│ [Przetwarzanie ciągłe] → Wyniki w czasie rzeczywistym │ +│ │ +│ Cechy strumieni: │ +│ • Nieograniczone (unbounded) │ +│ • Ciągłe napływanie │ +│ • Brak możliwości przechowania wszystkiego │ +│ • Wymagana niska latencja │ +│ • Dane mogą być nieuporządkowane (out-of-order) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 2. Modele przetwarzania + +#### Event Time vs Processing Time + +``` +Event Time: Kiedy zdarzenie faktycznie nastąpiło +Processing Time: Kiedy zdarzenie dotarło do systemu + +Timeline: +Event time: ─●─────●───●─────────●───→ + E1 E2 E3 E4 + +Processing: ───●───────●──●──●───────→ + E1 E3 E2 E4 (różna kolejność!) + +Watermark: znacznik postępu event time + "Wszystkie zdarzenia do czasu T już dotarły" +``` + +#### Windowing (okna czasowe) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ TUMBLING WINDOW (rozłączne): │ +│ ├────────┤├────────┤├────────┤├────────┤ │ +│ │ Window1││ Window2││ Window3││ Window4│ │ +│ │ +│ SLIDING WINDOW (nakładające się): │ +│ ├────────────┤ │ +│ ├────────────┤ │ +│ ├────────────┤ │ +│ ├────────────┤ │ +│ │ +│ SESSION WINDOW (oparte na aktywności): │ +│ ├────┤ ├──────────┤ ├───┤ ├─────┤ │ +│ session1 session2 s3 session4 │ +│ gap gap gap │ +│ │ +│ GLOBAL WINDOW: │ +│ ├─────────────────────────────────────────────────────→ │ +│ (jedno okno, trigger decyduje kiedy emitować) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 3. Platformy Stream Processing + +#### Apache Kafka Streams + +```java +StreamsBuilder builder = new StreamsBuilder(); + +KStream source = builder.stream("input-topic"); + +KTable, Long> counts = source + .groupByKey() + .windowedBy(TimeWindows.of(Duration.ofMinutes(5))) + .count(); + +counts.toStream().to("output-topic"); + +// Cechy: +// • Library (nie cluster) +// • Exactly-once semantics +// • Stateful processing z RocksDB +// • Integracja z Kafka ecosystem +``` + +#### Apache Flink + +```java +DataStream stream = env.addSource(new FlinkKafkaConsumer<>(...)); + +DataStream result = stream + .keyBy(event -> event.getKey()) + .window(TumblingEventTimeWindows.of(Time.minutes(5))) + .aggregate(new MyAggregateFunction()) + .process(new MyProcessFunction()); + +// Cechy: +// • True streaming (nie micro-batch) +// • Event time processing +// • Exactly-once state +// • Savepoints & checkpoints +// • Complex Event Processing (CEP) +``` + +#### Apache Spark Structured Streaming + +```python +df = spark.readStream \ + .format("kafka") \ + .option("subscribe", "events") \ + .load() + +result = df \ + .withWatermark("timestamp", "10 minutes") \ + .groupBy( + window("timestamp", "5 minutes"), + "userId" + ) \ + .count() + +query = result.writeStream \ + .outputMode("append") \ + .format("console") \ + .start() + +# Cechy: +# • Micro-batch (domyślnie) lub Continuous +# • Unified batch + streaming API +# • Catalyst optimizer +# • Integracja z Spark ecosystem +``` + +--- + +### 4. Porównanie platform + +| Cecha | Kafka Streams | Flink | Spark Streaming | +|-------|---------------|-------|-----------------| +| **Model** | True streaming | True streaming | Micro-batch | +| **Deployment** | Library | Cluster | Cluster | +| **Latency** | Niska | Bardzo niska | Średnia (~100ms) | +| **State** | RocksDB | RocksDB/heap | In-memory/external | +| **Exactly-once** | Tak | Tak | Tak | +| **SQL** | KSQL | Flink SQL | Spark SQL | +| **CEP** | Ograniczone | Tak (FlinkCEP) | Nie natywnie | + +--- + +### 5. Algorytmy strumieniowe + +#### Approximate counting - HyperLogLog + +``` +Problem: Zlicz unikalne elementy w strumieniu + (bez przechowywania wszystkich) + +HyperLogLog: +• O(1) space (kilka KB) +• ~2% error dla 12-bit registers +• Używa hash → trailing zeros + +Przykład: Redis PFADD, PFCOUNT +``` + +#### Frequency estimation - Count-Min Sketch + +``` +Problem: Estymuj częstość elementów + +Count-Min Sketch: +┌─────────────────────────────────┐ +│ h1: [3][0][2][5][1][0][4][2] │ +│ h2: [1][2][0][3][4][1][0][2] │ +│ h3: [2][1][3][0][2][1][3][0] │ +└─────────────────────────────────┘ + +Query(x): min(h1[hash1(x)], h2[hash2(x)], h3[hash3(x)]) + +• Overestimates (never underestimates) +• Tunable accuracy vs space +``` + +#### Sampling - Reservoir Sampling + +``` +Problem: Równomiernie próbkuj k elementów + ze strumienia o nieznanej długości + +Algorithm: +1. Zachowaj pierwsze k elementów +2. Dla i-tego elementu (i > k): + - Z prawdopodobieństwem k/i zamień + losowy element w reservoir + +Gwarancja: Każdy element ma szansę k/n +``` + +--- + +### 6. Obsługa opóźnień i Out-of-Order + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ WATERMARKS + LATE DATA │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Stream: ─●(t=1)──●(t=5)──●(t=3)──●(t=8)──●(t=2)───→ │ +│ ↑ ↑ │ +│ out-of-order late data │ +│ │ +│ Watermark: "Prawdopodobnie wszystkie events do t=X dotarły" │ +│ │ +│ Strategie dla late data: │ +│ 1. DROP: Ignoruj spóźnione (najprostsze) │ +│ 2. RECOMPUTE: Przelicz okno (kosztowne) │ +│ 3. SIDE OUTPUT: Zapisz do osobnego strumienia │ +│ 4. ALLOWED LATENESS: Czekaj dodatkowo N czasu │ +│ │ +│ Flink: │ +│ .allowedLateness(Time.minutes(5)) │ +│ .sideOutputLateData(lateOutputTag) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 7. Exactly-Once Semantics + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ GWARANCJE PRZETWARZANIA: │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ AT-MOST-ONCE: │ +│ Fire-and-forget, możliwa utrata danych │ +│ │ +│ AT-LEAST-ONCE: │ +│ Retry przy failure, możliwe duplikaty │ +│ │ +│ EXACTLY-ONCE: │ +│ Każde zdarzenie przetworzone dokładnie raz │ +│ │ +│ Implementacja (Flink/Kafka): │ +│ • Checkpointing (periodic snapshots) │ +│ • Transactional sinks (Kafka transactions) │ +│ • Barrier alignment │ +│ • Idempotent operations │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 8. Use Cases + +| Use Case | Technologia | Opis | +|----------|-------------|------| +| **Fraud detection** | Flink CEP | Pattern matching w czasie rzeczywistym | +| **IoT analytics** | Kafka Streams | Agregacja danych z sensorów | +| **Real-time dashboards** | Spark + Druid | Metryki biznesowe | +| **Log analysis** | ELK + Kafka | Centralizacja logów | +| **Recommendations** | Flink | Real-time personalizacja | + +--- + +## 🧠 Mnemoniki + +### "TWSS = Tumbling, Window, Sliding, Session": +Cztery typy okien czasowych + +### "Flink = Fast, Spark = Safe": +Flink najszybszy (true streaming), Spark bezpieczny (micro-batch) + +### "HLL = Hash, Leading zeros, Log": +HyperLogLog do zliczania unikalnych + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Kiedy micro-batch a kiedy true streaming?" +**Odpowiedź:** True streaming (Flink): ultra-low latency, CEP, event-time critical. Micro-batch (Spark): wyższa przepustowość, łatwiejsza integracja z batch, mniej wrażliwe na anomalie. + +### Q2: "Jak obsłużyć skoki danych (spikes)?" +**Odpowiedź:** Backpressure (Flink automatycznie), buffering, auto-scaling (Kubernetes), rate limiting na źródle, spillage to disk. + +### Q3: "Co to jest checkpointing?" +**Odpowiedź:** Periodic snapshots stanu (Flink). Przy failure - restart od ostatniego checkpoointu. Barrier synchronizuje snapshot między operatorami. Incremental checkpoints dla dużych stanów. + +--- + +## 🎯 Kluczowe punkty + +1. **Streaming:** Unbounded, continuous, low latency +2. **Windowing:** Tumbling, Sliding, Session, Global +3. **Event time vs Processing time:** Watermarks +4. **Platforms:** Flink (true), Spark (micro-batch), Kafka Streams (library) +5. **Exactly-once:** Checkpointing + transactions + +--- + +## 📖 Źródła + +1. Kleppmann - "Designing Data-Intensive Applications" +2. Apache Flink Documentation +3. Spark Structured Streaming Guide +4. Kafka Streams Documentation diff --git a/pytania/odpowiedzi/35-uklady-cyber-fizyczne.md b/pytania/odpowiedzi/35-uklady-cyber-fizyczne.md new file mode 100644 index 0000000..78c4a8b --- /dev/null +++ b/pytania/odpowiedzi/35-uklady-cyber-fizyczne.md @@ -0,0 +1,291 @@ +# Pytanie 35: Modelowanie układów cyber-fizycznych + +## Pytanie +**"Na czym polega specyfika modelowania matematycznego układów cyber-fizycznych? Podać przykłady współpracy agentów w sieci i problemów w osiąganiu pożądanego zachowania układu."** + +Przedmiot: SIU (Systemy Inteligentne i Uczące się) + +--- + +## 📚 Odpowiedź główna + +### 1. Definicja układów cyber-fizycznych (CPS) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ CYBER-PHYSICAL SYSTEM (CPS) │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ ┌──────────────────┐ ┌──────────────────┐ │ +│ │ CYBER │ ←────→ │ PHYSICAL │ │ +│ │ (computation, │ │ (dynamics, │ │ +│ │ communication, │ │ physics, │ │ +│ │ control) │ │ environment) │ │ +│ └──────────────────┘ └──────────────────┘ │ +│ ↑ ↑ │ +│ │ SENSORS │ │ +│ └────────────────────────────┘ │ +│ ACTUATORS │ +│ │ +│ Przykłady: Autonomiczne pojazdy, smart grid, robotyka, │ +│ drony, systemy medyczne, Industry 4.0 │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 2. Specyfika modelowania CPS + +#### Hybrid Systems (systemy hybrydowe) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ DYNAMIKA CIĄGŁA + DYSKRETNA │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Ciągła (fizyka): ẋ = f(x, u) (równania różniczkowe) │ +│ Dyskretna (logika): Automat stanów (przełączanie trybów) │ +│ │ +│ Przykład - termostat: │ +│ │ +│ Mode: OFF Mode: ON │ +│ ┌─────────────┐ ┌─────────────┐ │ +│ │ Ṫ = -α(T-Tₑ)│ ──TTₕ─── │ │ │ +│ └─────────────┘ └─────────────┘ │ +│ │ +│ T = temperatura, Tₑ = zewnętrzna, Tₗ/Tₕ = progi │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### Modelowanie matematyczne + +| Aspekt | Model | Opis | +|--------|-------|------| +| **Dynamika ciągła** | ODE/PDE | ẋ = f(x,u,t) | +| **Stany dyskretne** | Automaty hybrydowe | Przejścia między trybami | +| **Komunikacja** | Grafy, delay | Topologia sieci, opóźnienia | +| **Niepewność** | Stochastyczne ODE | Szum, zakłócenia | +| **Ograniczenia** | Nierówności | Fizyczne limity | + +--- + +### 3. Współpraca agentów w sieci + +#### Consensus (uzgadnianie) + +``` +Problem: Agenty mają osiągnąć wspólną wartość + +Protokół consensus: + ẋᵢ = Σⱼ∈Nᵢ aᵢⱼ(xⱼ - xᵢ) + +gdzie: +- xᵢ = stan agenta i +- Nᵢ = sąsiedzi agenta i +- aᵢⱼ = waga połączenia + +Forma macierzowa: + ẋ = -L·x + +L = Laplacian grafu komunikacji + +┌─────────────────────────────────────────────────────────────────┐ +│ Przykład: 4 agenty, różne wartości początkowe │ +│ │ +│ x(t) │ +│ ↑ │ +│ 5 │ ● │ +│ 4 │ ●───────────────────────────● consensus │ +│ 3 │ ●───────────────────────● value │ +│ 2 │ ●───────────────────● │ +│ 1 │ ●─────────────────────────────● │ +│ └─────────────────────────────────→ t │ +│ │ +│ Wszystkie wartości zbiegają do średniej │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### Formation Control (formacje) + +``` +Problem: Utrzymanie geometrycznej formacji + +Agent i: + ẋᵢ = Σⱼ∈Nᵢ aᵢⱼ[(xⱼ - xᵢ) - (dⱼ* - dᵢ*)] + +gdzie dᵢ* = pozycja docelowa agenta i w formacji + +Przykład - formacja trójkąta: + + Start: Cel: + ● ● ● + ● ● / \ + ● ●───● +``` + +#### Flocking (stado) + +``` +Trzy zasady Reynoldsa: + +1. SEPARATION: Unikaj kolizji z sąsiadami + Fₛₑₚ = -Σ (xⱼ - xᵢ)/||xⱼ - xᵢ||² + +2. ALIGNMENT: Dopasuj prędkość do sąsiadów + Fₐₗᵢₘ = Σ (vⱼ - vᵢ) + +3. COHESION: Dąż do centrum grupy + Fₖₒₕ = (x̄ - xᵢ) + +┌─────────────────────────────────────────────────────────────────┐ +│ ●→ │ +│ ●→ ●→ ●→ │ +│ ●→ ●→ │ +│ ●→ ●→ ●→ │ +│ ●→ ●→ │ +│ │ +│ Ptaki/ryby poruszają się jako zorganizowana grupa │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 4. Problemy w osiąganiu pożądanego zachowania + +#### 4.1 Problemy komunikacyjne + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ OPÓŹNIENIA (Delays): │ +│ │ +│ ẋᵢ(t) = Σⱼ aᵢⱼ[xⱼ(t - τᵢⱼ) - xᵢ(t)] │ +│ │ +│ Duże τ → niestabilność, oscylacje │ +│ │ +│ UTRATA PAKIETÓW: │ +│ │ +│ Agent nie otrzymuje informacji od sąsiada │ +│ → Stale dane, błędne decyzje │ +│ │ +│ OGRANICZONA PRZEPUSTOWOŚĆ: │ +│ │ +│ Kwantyzacja informacji │ +│ → Błędy zaokrągleń, limit cykli │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### 4.2 Problemy topologii + +| Problem | Opis | Skutek | +|---------|------|--------| +| **Słaba łączność** | Graf niespójny | Brak consensus | +| **Zmiana topologii** | Agenty się przemieszczają | Niestabilność | +| **Single point of failure** | Kluczowy węzeł pada | Rozpad sieci | +| **Partycjonowanie** | Sieć dzieli się | Lokalne consensus | + +``` +Graf spójny: Graf niespójny: + ●───● ●───● ●───● + │ │ │ │ + ●───● ● ● + +Consensus: TAK Consensus: NIE + (dwa osobne clustry) +``` + +#### 4.3 Problemy dynamiczne + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ HETEROGENICZNOŚĆ: │ +│ Agenty mają różne dynamiki (szybkie vs wolne) │ +│ → Różne szybkości zbieżności │ +│ │ +│ SATURACJA AKTUATORÓW: │ +│ |uᵢ| ≤ uₘₐₓ (fizyczne ograniczenia) │ +│ → Wolniejsza zbieżność, możliwy brak zbieżności │ +│ │ +│ ZAKŁÓCENIA: │ +│ ẋᵢ = f(x) + wᵢ(t) gdzie wᵢ = szum │ +│ → Błąd steady-state, oscylacje wokół celu │ +│ │ +│ ADVERSARIAL AGENTS: │ +│ Złośliwy agent wysyła fałszywe dane │ +│ → Consensus na błędnej wartości │ +│ Rozwiązanie: Byzantine fault tolerance │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 5. Warunki zbieżności consensus + +``` +Twierdzenie: Protokół consensus ẋ = -Lx zbiega do consensus ⟺ + Graf komunikacji jest (słabo) spójny + +Szybkość zbieżności ~ λ₂(L) (algebraic connectivity) + +Większe λ₂ → szybsza zbieżność + +Dla grafów skierowanych: +- Potrzebny spanning tree +- Wartość consensus = ważona średnia +``` + +--- + +### 6. Przykłady zastosowań + +| Zastosowanie | Agenty | Współpraca | +|--------------|--------|------------| +| **Swarm robotics** | Roboty | Eksploracja, transport | +| **Vehicular platoon** | Pojazdy | Jazda w kolumnie | +| **Smart grid** | Generatory | Balansowanie mocy | +| **Sensor networks** | Sensory | Distributed estimation | +| **UAV coordination** | Drony | Surveillance, delivery | + +--- + +## 🧠 Mnemoniki + +### "CPS = Cyber + Physical + Sensors": +Trzy elementy systemu cyber-fizycznego + +### "Consensus = Laplacian = -Lx": +Protokół consensus używa Laplacianu grafu + +### "SAC = Separation, Alignment, Cohesion": +Trzy zasady flockingu Reynoldsa + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Jak modelować opóźnienia w komunikacji?" +**Odpowiedź:** Delay differential equations (DDE): ẋ(t) = f(x(t), x(t-τ)). Analiza stabilności: metody Lyapunova-Krasovskiego, analiza wartości własnych z delay. Kompensacja: predyktory Smitha, robust control. + +### Q2: "Co to jest algebraic connectivity?" +**Odpowiedź:** Druga najmniejsza wartość własna Laplacianu grafu (λ₂). Mierzy jak dobrze graf jest połączony. λ₂ > 0 ⟺ graf spójny. Większe λ₂ = szybsza zbieżność consensus. + +### Q3: "Jak zapewnić odporność na złośliwe agenty?" +**Odpowiedź:** Byzantine fault tolerance: F-local / F-total model, W-MSR algorithm (Weighted Mean-Subsequence-Reduced), redundancja informacji, reputation systems. + +--- + +## 🎯 Kluczowe punkty + +1. **CPS:** Hybrid systems (ciągła + dyskretna dynamika) +2. **Consensus:** ẋ = -Lx, zbieżność do wspólnej wartości +3. **Flocking:** Separation, Alignment, Cohesion +4. **Problemy:** Delays, packet loss, topology changes +5. **Warunek:** Graf spójny dla consensus + +--- + +## 📖 Źródła + +1. Olfati-Saber, Murray - "Consensus Problems in Networks of Agents" +2. Mesbahi, Egerstedt - "Graph Theoretic Methods in Multiagent Networks" +3. Bullo - "Lectures on Network Systems" diff --git a/pytania/odpowiedzi/36-uczenie-ze-wzmocnieniem.md b/pytania/odpowiedzi/36-uczenie-ze-wzmocnieniem.md new file mode 100644 index 0000000..7ac4dbf --- /dev/null +++ b/pytania/odpowiedzi/36-uczenie-ze-wzmocnieniem.md @@ -0,0 +1,297 @@ +# Pytanie 36: Uczenie się ze wzmocnieniem (Reinforcement Learning) + +## Pytanie +**"Omówić ogólny algorytm, elementy składowe oraz własności uczenia się ze wzmocnieniem."** + +Przedmiot: SIU (Systemy Inteligentne i Uczące się) + +--- + +## 📚 Odpowiedź główna + +### 1. Model uczenia ze wzmocnieniem + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ REINFORCEMENT LEARNING LOOP │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ ┌─────────────┐ │ +│ action aₜ │ │ reward rₜ │ +│ ──────────→ │ ENVIRONMENT │ ──────────→ │ +│ │ │ │ │ │ +│ │ └─────────────┘ │ │ +│ │ │ │ │ +│ │ state sₜ₊₁ │ │ +│ │ │ │ │ +│ │ ↓ ↓ │ +│ │ ┌─────────────┐ │ +│ └────────── │ AGENT │ ←─────────┘ │ +│ │ (policy π) │ │ +│ └─────────────┘ │ +│ │ +│ Cel: Maksymalizacja skumulowanej nagrody E[Σ γᵗrₜ] │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 2. Elementy składowe + +| Element | Symbol | Opis | +|---------|--------|------| +| **State** | s ∈ S | Obserwacja środowiska | +| **Action** | a ∈ A | Decyzja agenta | +| **Reward** | r ∈ ℝ | Sygnał zwrotny | +| **Policy** | π(a\|s) | Strategia wyboru akcji | +| **Value function** | V(s), Q(s,a) | Oczekiwana nagroda | +| **Discount factor** | γ ∈ [0,1] | Ważność przyszłych nagród | +| **Transition** | P(s'\|s,a) | Dynamika środowiska | + +### Markov Decision Process (MDP) + +``` +MDP = (S, A, P, R, γ) + +S: Zbiór stanów +A: Zbiór akcji +P: P(s'|s,a) - prawdopodobieństwa przejść +R: R(s,a,s') - funkcja nagrody +γ: Współczynnik dyskontowania + +Właściwość Markowa: + P(sₜ₊₁|s₀,a₀,...,sₜ,aₜ) = P(sₜ₊₁|sₜ,aₜ) + + Przyszłość zależy tylko od obecnego stanu! +``` + +--- + +### 3. Funkcje wartości + +#### State Value Function V(s) + +$$V^\pi(s) = \mathbb{E}_\pi \left[ \sum_{t=0}^{\infty} \gamma^t r_t \mid s_0 = s \right]$$ + +#### Action Value Function Q(s,a) + +$$Q^\pi(s,a) = \mathbb{E}_\pi \left[ \sum_{t=0}^{\infty} \gamma^t r_t \mid s_0 = s, a_0 = a \right]$$ + +#### Równania Bellmana + +``` +V*(s) = max_a [R(s,a) + γ Σ_s' P(s'|s,a) V*(s')] + +Q*(s,a) = R(s,a) + γ Σ_s' P(s'|s,a) max_a' Q*(s',a') + +Rekurencyjne równania - podstawa algorytmów DP +``` + +--- + +### 4. Algorytmy + +#### 4.1 Value-based methods + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ Q-LEARNING (off-policy, model-free) │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Q(s,a) ← Q(s,a) + α[r + γ max_a' Q(s',a') - Q(s,a)] │ +│ └────────────────────────────────┘ │ +│ TD target │ +│ │ +│ Algorytm: │ +│ 1. Obserwuj stan s │ +│ 2. Wybierz akcję a (ε-greedy) │ +│ 3. Wykonaj a, obserwuj r, s' │ +│ 4. Zaktualizuj Q(s,a) │ +│ 5. s ← s', goto 1 │ +│ │ +│ ε-greedy: │ +│ Z prawdop. ε: losowa akcja (exploration) │ +│ Z prawdop. 1-ε: argmax Q(s,a) (exploitation) │ +└─────────────────────────────────────────────────────────────────┘ + +┌─────────────────────────────────────────────────────────────────┐ +│ SARSA (on-policy) │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Q(s,a) ← Q(s,a) + α[r + γ Q(s',a') - Q(s,a)] │ +│ ↑ │ +│ Rzeczywista następna akcja (nie max!) │ +│ │ +│ Różnica od Q-learning: │ +│ - Używa akcji faktycznie wybranej przez policy │ +│ - Bardziej "ostrożny" (uwzględnia exploration) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### 4.2 Deep Q-Network (DQN) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ DQN - Q-learning z siecią neuronową │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ State s → [Neural Network] → Q(s,a₁), Q(s,a₂), ..., Q(s,aₙ) │ +│ │ +│ Innowacje: │ +│ 1. Experience Replay: bufor (s,a,r,s'), losowe próbkowanie │ +│ 2. Target Network: osobna sieć do obliczania targetów │ +│ (aktualizowana co N kroków) │ +│ │ +│ Loss: L = (r + γ max Q_target(s',a') - Q(s,a))² │ +│ │ +│ Przełom: Atari games (2015) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### 4.3 Policy-based methods + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ POLICY GRADIENT │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Bezpośrednia optymalizacja parametrów θ policy π_θ(a|s) │ +│ │ +│ Gradient: │ +│ ∇_θ J(θ) = E_π [∇_θ log π_θ(a|s) · Q(s,a)] │ +│ │ +│ REINFORCE algorithm: │ +│ 1. Generuj trajektorię τ = (s₀,a₀,r₀,s₁,...) │ +│ 2. Oblicz return: Gₜ = Σ_{k=0}^{T-t} γᵏ r_{t+k} │ +│ 3. Update: θ ← θ + α ∇_θ log π_θ(aₜ|sₜ) · Gₜ │ +│ │ +│ Zalety: ciągłe akcje, stochastic policies │ +│ Wady: wysoka wariancja, wolna zbieżność │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### 4.4 Actor-Critic + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ ACTOR-CRITIC - łączy value-based i policy-based │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ ┌─────────┐ ┌─────────┐ │ +│ │ ACTOR │ ←───── │ CRITIC │ │ +│ │ π_θ(a|s)│ │ V_w(s) │ │ +│ └────┬────┘ └────┬────┘ │ +│ │ │ │ +│ ↓ │ │ +│ action value estimate │ +│ │ +│ Actor: wybiera akcje (policy) │ +│ Critic: ocenia jak dobre są akcje (value function) │ +│ │ +│ Advantage: A(s,a) = Q(s,a) - V(s) │ +│ Actor update: θ ← θ + α ∇_θ log π_θ(a|s) · A(s,a) │ +│ Critic update: minimize (r + γV(s') - V(s))² │ +│ │ +│ Algorytmy: A2C, A3C, PPO, SAC │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 5. Klasyfikacja algorytmów + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ │ +│ ┌── Model-based (zna/uczy się P, R) │ +│ RL Methods ─┤ │ +│ └── Model-free (nie zna środowiska) │ +│ │ │ +│ ├── Value-based (Q-learning, DQN) │ +│ ├── Policy-based (REINFORCE) │ +│ └── Actor-Critic (A2C, PPO, SAC) │ +│ │ +│ ┌── On-policy (SARSA, A2C) - używa obecnej π │ +│ RL Methods ─┤ │ +│ └── Off-policy (Q-learning, DQN) - używa innej π │ +│ │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 6. Exploration vs Exploitation + +| Strategia | Opis | +|-----------|------| +| **ε-greedy** | Z prawdop. ε losowa akcja | +| **Softmax/Boltzmann** | P(a) ∝ exp(Q(s,a)/τ) | +| **UCB** | a = argmax[Q(s,a) + c√(ln N / n(a))] | +| **Thompson Sampling** | Próbkowanie z posterior | +| **Curiosity-driven** | Bonus za nowość | + +--- + +### 7. Własności i wyzwania + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ WŁASNOŚCI: │ +│ ✓ Uczenie przez interakcję (nie supervised) │ +│ ✓ Delayed rewards (kredyt za sekwencję akcji) │ +│ ✓ Generalizacja (do nowych stanów) │ +│ ✓ Online learning (ciągłe doskonalenie) │ +│ │ +│ WYZWANIA: │ +│ ✗ Sample inefficiency (wymaga wielu interakcji) │ +│ ✗ Credit assignment (która akcja odpowiada za reward?) │ +│ ✗ Exploration-exploitation tradeoff │ +│ ✗ Partial observability (POMDP) │ +│ ✗ Non-stationarity (środowisko się zmienia) │ +│ ✗ Reward shaping (sparse rewards problem) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +## 🧠 Mnemoniki + +### "SARSA = State Action Reward State Action": +Sekwencja w algorytmie SARSA + +### "Q = Quality of action": +Q(s,a) mierzy jakość akcji a w stanie s + +### "Actor-Critic = Action + Advice": +Actor wybiera akcje, Critic doradza (ocenia) + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Jaka jest różnica między Q-learning a SARSA?" +**Odpowiedź:** Q-learning (off-policy): używa max Q(s',a') - optymistyczne. SARSA (on-policy): używa Q(s',a') gdzie a' to rzeczywista następna akcja - bardziej ostrożne, uwzględnia policy exploration. + +### Q2: "Po co Experience Replay w DQN?" +**Odpowiedź:** Łamie korelację między kolejnymi próbkami (iid requirement), efektywniejsze wykorzystanie danych (wielokrotne uczenie z jednej próbki), stabilizuje trening. + +### Q3: "Kiedy model-based jest lepszy?" +**Odpowiedź:** Gdy środowisko jest przewidywalne, samples są drogie (robotyka), potrzebne planowanie. Model-free lepszy gdy środowisko złożone, trudne do modelowania, dużo samples dostępnych. + +--- + +## 🎯 Kluczowe punkty + +1. **MDP:** (S, A, P, R, γ) - formalizacja problemu +2. **Bellman:** V*(s) = max[R + γ·ΣP·V*] +3. **Q-learning:** off-policy, max Q update +4. **Policy Gradient:** ∇J = E[∇log π · Q] +5. **Actor-Critic:** policy + value function + +--- + +## 📖 Źródła + +1. Sutton, Barto - "Reinforcement Learning: An Introduction" +2. Silver - DeepMind RL lectures +3. Mnih et al. - "Playing Atari with Deep RL" (2015) diff --git a/pytania/odpowiedzi/37-modele-sieci-zlozonych.md b/pytania/odpowiedzi/37-modele-sieci-zlozonych.md new file mode 100644 index 0000000..908b059 --- /dev/null +++ b/pytania/odpowiedzi/37-modele-sieci-zlozonych.md @@ -0,0 +1,296 @@ +# Pytanie 37: Modele sieci złożonych + +## Pytanie +**"Porównać podstawowe modele sieci złożonych. Jak odpowiadają one własnościom rzeczywistych sieci?"** + +Przedmiot: TASS (Technologie i Algorytmy dla Sieci Społecznościowych) + +--- + +## 📚 Odpowiedź główna + +### 1. Właściwości rzeczywistych sieci + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ TYPOWE CECHY SIECI RZECZYWISTYCH │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ 1. SMALL-WORLD EFFECT: │ +│ "Six degrees of separation" │ +│ Średnia ścieżka ~ log(N) │ +│ │ +│ 2. HIGH CLUSTERING: │ +│ "Znajomi moich znajomych są znajomymi" │ +│ Współczynnik grupowania C >> C_random │ +│ │ +│ 3. SCALE-FREE (Power-law degree distribution): │ +│ P(k) ~ k^(-γ), gdzie γ ∈ [2, 3] │ +│ Kilka hubów, wiele węzłów o małym stopniu │ +│ │ +│ 4. COMMUNITY STRUCTURE: │ +│ Gęste grupy połączone rzadkimi mostami │ +│ │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 2. Model Erdős-Rényi (Random Graph) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ G(n, p) - Graf losowy │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Konstrukcja: │ +│ - n węzłów │ +│ - Każda krawędź z prawdopodobieństwem p │ +│ │ +│ Właściwości: │ +│ ┌─────────────────────────────────────────┐ │ +│ │ Średni stopień: = p(n-1) │ │ +│ │ Rozkład stopni: Poisson (dla dużych n)│ │ +│ │ Clustering: C = p (niski!) │ │ +│ │ Średnia ścieżka: L ~ log(n)/log() │ │ +│ │ Giant component: istnieje gdy > 1 │ │ +│ └─────────────────────────────────────────┘ │ +│ │ +│ Rozkład stopni P(k): │ +│ │ +│ P(k) │ +│ ↑ ● │ +│ │ ●●● │ +│ │ ●●●●●● Rozkład Poissona │ +│ │ ●●●●●●●● (symetryczny, wąski) │ +│ │ ●●●●●●●●●● │ +│ └────────────────→ k │ +│ │ +└─────────────────────────────────────────────────────────────────┘ +``` + +### Porównanie z rzeczywistością + +| Cecha | ER Model | Rzeczywiste sieci | +|-------|----------|-------------------| +| **Clustering** | C = p (niski) | C >> p (wysoki) ❌ | +| **Średnia ścieżka** | L ~ log(n) ✓ | L ~ log(n) ✓ | +| **Rozkład stopni** | Poisson | Power-law ❌ | +| **Huby** | Brak | Istnieją ❌ | + +--- + +### 3. Model Watts-Strogatz (Small-World) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ SMALL-WORLD MODEL │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Konstrukcja: │ +│ 1. Zacznij od regularnej kratki (ring lattice) │ +│ 2. Każda krawędź przepinana z prawdop. p │ +│ │ +│ p=0 (regular) p~0.01 p=1 (random) │ +│ │ +│ ●───●───● ●───●───● ● ● ● │ +│ /│ │ │\ /│ \ │ │\ /│\ /│\ /│\ │ +│ ● │ │ │ ● ● │ │ │ ● ● │ X │ X │ ● │ +│ \│ │ │/ \│ │ / │/ \│/ \│/ \│/ │ +│ ●───●───● ●───●───● ● ● ● │ +│ │ +│ C: high C: high C: low │ +│ L: high L: low L: low │ +│ ↑ │ +│ SMALL-WORLD │ +│ (best of both!) │ +│ │ +└─────────────────────────────────────────────────────────────────┘ +``` + +### Właściwości + +``` +Dla małych p (np. p = 0.01): + +L(p) C(p) + ↑ ↑ + │● │●●●●●●●●●●●●●●●●● + │ ● │ ● + │ ●● │ ●● + │ ●●●●│ ●●●●● + └────────→ p └────────────────→ p + +L spada szybko przy małych p (shortcuts) +C pozostaje wysoki do większych p +``` + +### Porównanie z rzeczywistością + +| Cecha | WS Model | Rzeczywiste sieci | +|-------|----------|-------------------| +| **Clustering** | Wysoki ✓ | Wysoki ✓ | +| **Średnia ścieżka** | L ~ log(n) ✓ | L ~ log(n) ✓ | +| **Rozkład stopni** | Wąski (quasi-regular) | Power-law ❌ | +| **Huby** | Brak | Istnieją ❌ | + +--- + +### 4. Model Barabási-Albert (Scale-Free) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ PREFERENTIAL ATTACHMENT MODEL │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Konstrukcja: │ +│ 1. Zacznij od małego grafu (m₀ węzłów) │ +│ 2. Dodawaj węzły jeden po drugim │ +│ 3. Nowy węzeł łączy się z m istniejącymi │ +│ 4. Prawdopodobieństwo połączenia z węzłem i: │ +│ │ +│ kᵢ │ +│ Π(i) = ───────── "Rich get richer" │ +│ Σⱼ kⱼ │ +│ │ +│ Rozkład stopni P(k): │ +│ │ +│ log P(k) │ +│ ↑ ● │ +│ │ ● │ +│ │ ● Power-law: │ +│ │ ● P(k) ~ k^(-3) │ +│ │ ●● │ +│ │ ●●● │ +│ │ ●●●●●●●● │ +│ └───────────────────→ log k │ +│ │ +│ Huby (węzły o wysokim stopniu) pojawiają się naturalnie! │ +└─────────────────────────────────────────────────────────────────┘ +``` + +### Właściwości + +| Właściwość | Wartość | +|------------|---------| +| **Rozkład stopni** | P(k) ~ k^(-γ), γ = 3 | +| **Średnia ścieżka** | L ~ log(n)/log(log(n)) (ultra-small) | +| **Clustering** | C ~ (log n)² / n (niski!) | +| **Odporność** | Odporna na losowe awarie, wrażliwa na celowe ataki | + +### Porównanie z rzeczywistością + +| Cecha | BA Model | Rzeczywiste sieci | +|-------|----------|-------------------| +| **Clustering** | Niski ❌ | Wysoki | +| **Średnia ścieżka** | Ultra-short ✓ | Short ✓ | +| **Rozkład stopni** | Power-law ✓ | Power-law ✓ | +| **Huby** | Tak ✓ | Tak ✓ | + +--- + +### 5. Porównanie zbiorcze + +``` +┌──────────────┬───────────────┬───────────────┬───────────────┐ +│ Właściwość │ Erdős-Rényi │ Watts-Strogatz│ Barabási-Albert│ +├──────────────┼───────────────┼───────────────┼───────────────┤ +│ Clustering │ Niski (C=p) │ Wysoki │ Niski │ +│ Śr. ścieżka │ log(n) │ log(n) │ log(n)/loglog │ +│ Rozkład │ Poisson │ Quasi-regular │ Power-law │ +│ Huby │ Nie │ Nie │ Tak │ +│ Small-world │ Tak │ Tak │ Ultra-small │ +│ Mechanizm │ Losowość │ Rewiring │ Pref. attach. │ +└──────────────┴───────────────┴───────────────┴───────────────┘ + +Rzeczywiste sieci (WWW, social, biological): +• Wysoki clustering → WS lepszy +• Power-law → BA lepszy +• Short paths → wszystkie OK + +Żaden pojedynczy model nie oddaje wszystkich cech! +``` + +--- + +### 6. Modele rozszerzone + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ HOLME-KIM MODEL (BA + clustering): │ +│ Po preferential attachment → dodaj trójkąt z prawdop. p │ +│ Łączy power-law z wysokim clustering │ +├─────────────────────────────────────────────────────────────────┤ +│ HIERARCHICAL MODELS: │ +│ Rekurencyjna struktura (fraktalna) │ +│ Modeluje hierarchie w organizacjach │ +├─────────────────────────────────────────────────────────────────┤ +│ STOCHASTIC BLOCK MODEL: │ +│ Podział na grupy z różnymi p wewnątrz/między │ +│ Modeluje community structure │ +├─────────────────────────────────────────────────────────────────┤ +│ CONFIGURATION MODEL: │ +│ Generuj graf z zadanym rozkładem stopni │ +│ Elastyczny, ale brak mechanizmu wzrostu │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 7. Przykłady rzeczywistych sieci + +| Sieć | N | | C | L | γ | +|------|---|-----|---|---|---| +| **WWW** | 10⁹ | ~7 | 0.11 | 11.2 | 2.1 | +| **Facebook** | 10⁹ | ~200 | 0.16 | 4.7 | ~3 | +| **Internet (AS)** | 10⁴ | ~6 | 0.24 | 3.7 | 2.2 | +| **C. elegans** | 282 | 14 | 0.28 | 2.7 | - | +| **Power grid** | 4941 | 2.7 | 0.08 | 18.7 | exp | + +--- + +## 🧠 Mnemoniki + +### "ER = Equal Random": +Erdős-Rényi - równe prawdopodobieństwo krawędzi + +### "WS = Wires Switched": +Watts-Strogatz - przepinanie krawędzi + +### "BA = Big Attract": +Barabási-Albert - duże węzły przyciągają więcej + +### "Scale-free = -3 power": +P(k) ~ k^(-3) dla BA modelu + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Dlaczego BA ma niski clustering?" +**Odpowiedź:** Preferential attachment łączy nowe węzły głównie z hubami, nie tworząc trójkątów między sąsiadami. Rozwiązanie: Holme-Kim model dodaje krok "triad formation". + +### Q2: "Co to jest robustness vs vulnerability?" +**Odpowiedź:** Scale-free sieci są odporne na losowe awarie (większość węzłów ma mały stopień), ale wrażliwe na celowane ataki na huby. ER sieci są bardziej jednolite w obu przypadkach. + +### Q3: "Jak mierzyć small-world property?" +**Odpowiedź:** Współczynnik σ = (C/C_random) / (L/L_random). Jeśli σ >> 1 → small-world. C wysoki jak w kratce, L niski jak w random graph. + +--- + +## 🎯 Kluczowe punkty + +1. **ER:** Random, Poisson degree, low clustering +2. **WS:** Rewiring, high clustering + short paths +3. **BA:** Preferential attachment, power-law, huby +4. **Real networks:** Power-law + high clustering + short paths +5. **Żaden model nie jest kompletny** - łączone modele + +--- + +## 📖 Źródła + +1. Barabási - "Network Science" (networkscience.com) +2. Newman - "Networks: An Introduction" +3. Watts, Strogatz - "Collective dynamics of small-world networks" (1998) +4. Barabási, Albert - "Emergence of Scaling in Random Networks" (1999) diff --git a/pytania/odpowiedzi/38-projekcje-grafow-dwudzielnych.md b/pytania/odpowiedzi/38-projekcje-grafow-dwudzielnych.md new file mode 100644 index 0000000..5ab4383 --- /dev/null +++ b/pytania/odpowiedzi/38-projekcje-grafow-dwudzielnych.md @@ -0,0 +1,264 @@ +# Pytanie 38: Projekcje grafów dwudzielnych + +## Pytanie +**"Porównać metody projekcji grafów dwudzielnych. Przedstawić ich użyteczność w grupowaniu dokumentów tekstowych."** + +Przedmiot: TASS (Technologie i Algorytmy dla Sieci Społecznościowych) + +--- + +## 📚 Odpowiedź główna + +### 1. Grafy dwudzielne (Bipartite Graphs) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ GRAF DWUDZIELNY │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Zbiór U (np. dokumenty) Zbiór V (np. słowa) │ +│ │ +│ D1 ●────────────────● word1 │ +│ │ ╲ │ │ +│ D2 ●──╲─────────────● word2 │ +│ │ ╲ │ │ +│ D3 ●────╲───────────● word3 │ +│ ╲ │ │ +│ D4 ●──────╲─────────● word4 │ +│ │ +│ Krawędzie tylko między U i V (nigdy wewnątrz zbioru) │ +│ │ +│ Przykłady: │ +│ • Dokumenty - Słowa │ +│ • Użytkownicy - Produkty │ +│ • Autorzy - Artykuły │ +│ • Aktorzy - Filmy │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 2. Projekcja grafu dwudzielnego + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ PROJEKCJA = przekształcenie grafu dwudzielnego na jednomodowy │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Graf dwudzielny: Projekcja na U (dokumenty): │ +│ │ +│ D1 ●───────● w1 D1 ●─────● D2 │ +│ │╲ │ │╲ ╱│ │ +│ D2 ●─╲─────● w2 │ ╲ ╱ │ │ +│ │ ╲ │ │ ╳ │ │ +│ D3 ●───╲───● w3 │ ╱ ╲ │ │ +│ ╲ │╱ ╲│ │ +│ D4 ●───────● w4 D3 ●─────● D4 │ +│ │ +│ Dwa dokumenty połączone ⟺ mają wspólne słowo │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 3. Metody projekcji + +#### 3.1 Projekcja binarna (Simple/Unweighted) + +``` +Macierz sąsiedztwa projekcji: + +P = B · Bᵀ (dla projekcji na U) +P = Bᵀ · B (dla projekcji na V) + +gdzie B = macierz incydencji grafu dwudzielnego + +Pᵢⱼ > 0 ⟹ węzły i, j połączone w projekcji + +Wady: +❌ Utrata informacji o sile powiązania +❌ Wszystkie wspólni sąsiedzi traktowani równo +``` + +#### 3.2 Projekcja ważona (Weighted) + +| Metoda | Waga krawędzi (i,j) | Opis | +|--------|---------------------|------| +| **Simple count** | w_ij = \|N(i) ∩ N(j)\| | Liczba wspólnych sąsiadów | +| **Jaccard** | w_ij = \|N(i) ∩ N(j)\| / \|N(i) ∪ N(j)\| | Normalizacja przez sumę | +| **Cosine** | w_ij = (B_i · B_j) / (\|\|B_i\|\| · \|\|B_j\|\|) | Podobieństwo wektorów | +| **Hyperbolic** | w_ij = Σ_k 1/(k_k - 1) | Rzadkie słowa ważniejsze | +| **Resource allocation** | w_ij = Σ_k 1/k_k | Jak hyperbolic | + +``` +Przykład - Jaccard: + +D1 = {w1, w2, w3} +D2 = {w2, w3, w4} + +Wspólne: {w2, w3} → |∩| = 2 +Suma: {w1, w2, w3, w4} → |∪| = 4 + +w(D1, D2) = 2/4 = 0.5 +``` + +#### 3.3 Projekcja TF-IDF (dla dokumentów) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ TF-IDF weighted projection │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ TF(t,d) = częstość słowa t w dokumencie d │ +│ IDF(t) = log(N / df(t)) gdzie df(t) = liczba dok. z t │ +│ │ +│ TF-IDF(t,d) = TF(t,d) × IDF(t) │ +│ │ +│ Podobieństwo dokumentów: │ +│ sim(d1, d2) = cos(TF-IDF(d1), TF-IDF(d2)) │ +│ │ +│ Rzadkie słowa mają większą wagę (IDF)! │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 4. Porównanie metod + +| Metoda | Zalety | Wady | +|--------|--------|------| +| **Binarna** | Prosta, szybka | Brak wag, utrata info | +| **Simple count** | Intuicyjna | Bias ku popularnym węzłom | +| **Jaccard** | Normalizowana | Ignoruje rozmiar zbiorów | +| **Cosine** | Standard w IR | Wymaga wektorów | +| **Hyperbolic** | Rzadkie elementy ważne | Bardziej złożona | +| **TF-IDF** | Standard dla tekstów | Specyficzna dla dokumentów | + +--- + +### 5. Zastosowanie w grupowaniu dokumentów + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ PIPELINE GRUPOWANIA DOKUMENTÓW │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ 1. PREPROCESSING │ +│ Dokumenty → tokenizacja → stemming → usunięcie stop words │ +│ │ +│ 2. BUDOWA GRAFU DWUDZIELNEGO │ +│ G = (Documents, Terms, Edges) │ +│ Krawędź (d, t) jeśli term t występuje w dokumencie d │ +│ │ +│ 3. PROJEKCJA │ +│ P = projekcja ważona (TF-IDF/Cosine) na dokumenty │ +│ │ +│ 4. GRUPOWANIE │ +│ Na grafie projekcji: │ +│ • Community detection (Louvain, Label Propagation) │ +│ • Spectral clustering │ +│ • K-means na wektorach podobieństwa │ +│ │ +│ 5. WYNIK │ +│ Grupy tematycznie podobnych dokumentów │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### Przykład + +``` +Dokumenty: +D1: "machine learning algorithms" +D2: "deep learning neural networks" +D3: "neural network architecture" +D4: "database query optimization" +D5: "SQL query performance" + +Graf dwudzielny projekcja (cosine similarity): + +D1 ──0.3── D2 ──0.6── D3 Klaster 1: ML/DL + {D1, D2, D3} + +D4 ──0.5── D5 Klaster 2: Databases + {D4, D5} + +Grupowanie znajdzie te dwa klastry! +``` + +--- + +### 6. Algorytmy grupowania na projekcji + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ LOUVAIN (Community Detection): │ +│ • Optymalizuje modularność Q │ +│ • Iteracyjne przenoszenie węzłów między grupami │ +│ • O(n log n) - szybki │ +├─────────────────────────────────────────────────────────────────┤ +│ SPECTRAL CLUSTERING: │ +│ • Eigendecomposition Laplacianu │ +│ • K-means na wektorach własnych │ +│ • Znajduje struktury niekonweksowe │ +├─────────────────────────────────────────────────────────────────┤ +│ LABEL PROPAGATION: │ +│ • Propagacja etykiet po krawędziach │ +│ • Bardzo szybki O(m) │ +│ • Niedeterministyczny │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 7. Problemy i rozwiązania + +| Problem | Opis | Rozwiązanie | +|---------|------|-------------| +| **Gęstość** | Projekcja tworzy gęste grafy | Threshold na wagi | +| **Huby** | Popularne słowa łączą wszystko | TF-IDF, filtering | +| **Skalowalność** | O(n²) krawędzi | Sparse representation, LSH | +| **Utrata info** | Projekcja traci strukturę | Zachowaj oryginalny graf | + +--- + +## 🧠 Mnemoniki + +### "B×Bᵀ = Projekcja": +Mnożenie macierzy incydencji daje projekcję + +### "TF-IDF = Term Frequency × Inverse Document Frequency": +Rzadkie słowa ważniejsze + +### "Jaccard = Intersection over Union": +IoU dla zbiorów + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Dlaczego projekcja binarna jest problematyczna?" +**Odpowiedź:** Traci informację o sile powiązania. Dokument z 1 wspólnym słowem ma taką samą krawędź jak z 100 wspólnymi. Popularne słowa (stop words) tworzą fałszywe powiązania. + +### Q2: "Jak skalować dla dużych zbiorów?" +**Odpowiedź:** MinHash/LSH dla approximate similarity, sparse matrix operations, sampling, dimension reduction (LSA/SVD), distributed computing (Spark GraphX). + +### Q3: "Alternatywy dla projekcji?" +**Odpowiedź:** Bezpośrednie algorytmy na grafach dwudzielnych (bipartite community detection), tensor decomposition, embedding methods (node2vec), GNN na grafach heterogenicznych. + +--- + +## 🎯 Kluczowe punkty + +1. **Projekcja:** Graf dwudzielny → jednomodowy (P = B·Bᵀ) +2. **Metody:** Binarna, Jaccard, Cosine, TF-IDF +3. **TF-IDF:** Rzadkie słowa ważniejsze (IDF) +4. **Grupowanie:** Louvain, Spectral, Label Propagation +5. **Problem:** Gęstość, popularne węzły → filtering, thresholding + +--- + +## 📖 Źródła + +1. Newman - "Networks: An Introduction" +2. Zhou et al. - "Bipartite Network Projection and Personal Recommendation" +3. Manning - "Introduction to Information Retrieval" diff --git a/pytania/odpowiedzi/39-segmentacja-obrazu.md b/pytania/odpowiedzi/39-segmentacja-obrazu.md new file mode 100644 index 0000000..60b1d9b --- /dev/null +++ b/pytania/odpowiedzi/39-segmentacja-obrazu.md @@ -0,0 +1,322 @@ +# Pytanie 39: Segmentacja obrazu + +## Pytanie +**"Scharakteryzować problem segmentacji obrazu. Przedstawić podstawowe strategie i algorytmy segmentacji przy użyciu metod klasycznych oraz sieci neuronowych."** + +Przedmiot: TWM (Techniki Wizji Maszynowej) + +--- + +## 📚 Odpowiedź główna + +### 1. Definicja problemu segmentacji + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ SEGMENTACJA OBRAZU │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Obraz wejściowy: Maska segmentacji: │ +│ ┌────────────────┐ ┌────────────────┐ │ +│ │ ░░████░░░░░░ │ │ ░░1111░░░░░░ │ │ +│ │ ░████████░░░ │ → │ ░11111111░░░ │ │ +│ │ ░░████████░░ │ │ ░░11111111░░ │ │ +│ │ ░░░░████░░░░ │ │ ░░░░1111░░░░ │ │ +│ └────────────────┘ └────────────────┘ │ +│ │ +│ Cel: Przypisać każdemu pikselowi etykietę klasy/regionu │ +│ │ +│ Typy segmentacji: │ +│ • Semantic: klasa dla każdego piksela (person, car, sky) │ +│ • Instance: rozróżnia instancje tej samej klasy │ +│ • Panoptic: semantic + instance (unified) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 2. Metody klasyczne + +#### 2.1 Thresholding (progowanie) + +``` +Globalne: + pixel_out = 255 if pixel_in > T else 0 + +Otsu (automatyczny próg): + - Maksymalizuje wariancję między klasami + - σ²_between = w₀w₁(μ₀ - μ₁)² + +Adaptacyjne: + - Lokalny próg dla każdego regionu + - T(x,y) = mean(neighborhood) - C + +┌──────────────────┐ Threshold ┌──────────────────┐ +│░▒▓█░▒▓█░▒▓█░▒▓█ │ ────────────→ │░░██░░██░░██░░██ │ +│▒▓█░▒▓█░▒▓█░▒▓█░ │ T │░███░███░███░███░ │ +└──────────────────┘ └──────────────────┘ +``` + +#### 2.2 Region Growing + +``` +Algorytm: +1. Wybierz punkt startowy (seed) +2. Badaj sąsiadów +3. Jeśli podobny (|I(neighbor) - I(region)| < threshold) + → dodaj do regionu +4. Powtarzaj aż brak nowych pikseli + + Seed Krok 1 Krok 2 Wynik + ● ●● ●●● ●●●● + ● ●●● ●●●● + ●● ●●●● +``` + +#### 2.3 Watershed + +``` +Obraz jako topografia: +- Intensywność = wysokość +- "Zalewanie" od minimów lokalnych +- Granice gdzie woda z różnych źródeł się spotyka + + ╱╲ ╱╲ + ╱ ╲ ╱ ╲ + ╱ ╲__╱ ╲ + ╱ ↑ ╲ + ↑ granica ↑ + min1 (watershed) min2 +``` + +#### 2.4 Mean Shift + +``` +Iteracyjne przesuwanie okna do maksimum gęstości: + +1. Dla każdego piksela: + m(x) = Σ K(x - xᵢ) × xᵢ / Σ K(x - xᵢ) + +2. x ← m(x) (shift) +3. Powtarzaj do zbieżności +4. Piksele zbiegające do tego samego punktu → jeden segment +``` + +#### 2.5 Graph-based (Normalized Cuts) + +``` +Obraz jako graf: +- Wierzchołki = piksele +- Krawędzie = podobieństwo między pikselami +- w(i,j) = exp(-||I(i) - I(j)||² / σ²) + +Normalized Cut: + Ncut(A,B) = cut(A,B)/assoc(A,V) + cut(A,B)/assoc(B,V) + +Minimalizacja Ncut → eigendecomposition Laplacianu +``` + +--- + +### 3. Porównanie metod klasycznych + +| Metoda | Zalety | Wady | +|--------|--------|------| +| **Thresholding** | Szybki, prosty | Tylko 2 klasy, wrażliwy na oświetlenie | +| **Region Growing** | Intuicyjny | Wymaga seedów, over-segmentation | +| **Watershed** | Dobre krawędzie | Over-segmentation | +| **Mean Shift** | Brak k | Wolny, parametr bandwidth | +| **Graph Cut** | Globalnie optymalne | O(n³), wymaga unary terms | + +--- + +### 4. Metody deep learning + +#### 4.1 FCN (Fully Convolutional Network) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ FCN - pierwsza architektura deep dla segmentacji (2015) │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Input Encoder (VGG) Decoder Output │ +│ H×W×3 → Conv+Pool×5 → Upsampling (deconv) → H×W×C │ +│ │ +│ ┌────┐ ┌──┐ ┌──┐ ┌────┐ │ +│ │ │ → │ │ → │ │ → ··· → upsample → │ │ │ +│ │ │ │ │ │ │ ×32 │ │ │ +│ └────┘ └──┘ └──┘ └────┘ │ +│ input conv conv output │ +│ │ +│ Skip connections: FCN-32s, FCN-16s, FCN-8s │ +│ Coarser + finer features → sharper boundaries │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### 4.2 U-Net + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ U-NET - encoder-decoder ze skip connections (2015) │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Encoder Decoder │ +│ │ ↑ │ +│ ┌──┴──┐ ─ copy ─→ ┌──┴──┐ │ +│ │64×64│ │64×64│ │ +│ └──┬──┘ └──┬──┘ │ +│ ↓ ↑ │ +│ ┌──┴──┐ ─ copy ─→ ┌──┴──┐ │ +│ │32×32│ │32×32│ │ +│ └──┬──┘ └──┬──┘ │ +│ ↓ ↑ │ +│ ┌──┴──┐ ─ copy ─→ ┌──┴──┐ │ +│ │16×16│ │16×16│ │ +│ └──┬──┘ └──┬──┘ │ +│ ↓ ↑ │ +│ └───── bottleneck ───┘ │ +│ │ +│ Concat skip connections (nie add jak w ResNet) │ +│ Popularne w medycynie (małe datasety) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### 4.3 DeepLab (v1-v3+) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ DEEPLAB - Atrous/Dilated Convolutions + CRF │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Atrous Convolution (dilated): │ +│ │ +│ Standard 3×3: Atrous 3×3, rate=2: │ +│ ● ● ● ● ● ● │ +│ ● ● ● (większe receptive field │ +│ ● ● ● ● ● ● bez więcej parametrów) │ +│ │ +│ ● ● ● │ +│ │ +│ ASPP (Atrous Spatial Pyramid Pooling): │ +│ Parallel atrous conv z różnymi rates (6, 12, 18) │ +│ → multi-scale context │ +│ │ +│ DeepLabv3+: │ +│ Encoder-decoder + ASPP + depthwise separable conv │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### 4.4 Transformer-based (SegFormer, Mask2Former) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ SEGFORMER (2021) │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Mix-Transformer encoder: │ +│ • Hierarchical features (1/4, 1/8, 1/16, 1/32) │ +│ • Efficient self-attention │ +│ • No positional encoding │ +│ │ +│ MLP decoder: │ +│ • Simple MLP combines multi-scale features │ +│ • Lightweight │ +│ │ +│ MASK2FORMER (2022): │ +│ • Universal: semantic, instance, panoptic │ +│ • Masked attention (per-segment) │ +│ • Deformable attention │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 5. Porównanie architektur DL + +| Architektura | mIoU (ADE20K) | Parametry | Cechy | +|--------------|---------------|-----------|-------| +| **FCN** | ~30% | ~135M | Pierwsze DL dla segmentacji | +| **U-Net** | - | ~31M | Medical, skip connections | +| **DeepLabv3+** | ~45% | ~60M | ASPP, dilated conv | +| **SegFormer-B5** | ~51% | ~85M | Transformer, efficient | +| **Mask2Former** | ~57% | ~200M | Universal, SOTA | + +--- + +### 6. Loss functions + +``` +Cross-Entropy Loss: + L = -Σᵢ Σc yᵢc log(pᵢc) + + Problem: class imbalance (dużo tła, mało obiektów) + +Dice Loss: + L = 1 - 2|X ∩ Y| / (|X| + |Y|) + + Bezpośrednio optymalizuje IoU-like metric + +Focal Loss: + L = -αₜ(1 - pₜ)^γ log(pₜ) + + γ > 0 → hard examples ważniejsze + +Combined: + L = λ₁ · CE + λ₂ · Dice +``` + +--- + +### 7. Metryki + +| Metryka | Formuła | Opis | +|---------|---------|------| +| **Pixel Accuracy** | TP / (TP+FP+FN+TN) | % poprawnych pikseli | +| **IoU (Jaccard)** | TP / (TP+FP+FN) | Intersection over Union | +| **mIoU** | mean IoU per class | Standard dla segmentacji | +| **Dice** | 2TP / (2TP+FP+FN) | F1 dla segmentacji | + +--- + +## 🧠 Mnemoniki + +### "U-Net = U-shaped skip": +Kształt U z skip connections + +### "ASPP = Atrous at Multiple Scales": +DeepLab's Atrous Spatial Pyramid Pooling + +### "IoU = Intersection / Union": +Podstawowa metryka segmentacji + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Jak radzić sobie z class imbalance?" +**Odpowiedź:** Weighted cross-entropy, Focal Loss, oversampling małych klas, Dice Loss (ignoruje dominację dużych klas), OHEM (Online Hard Example Mining). + +### Q2: "U-Net vs DeepLab?" +**Odpowiedź:** U-Net: encoder-decoder z concat skip, dobre dla małych datasetów (medical). DeepLab: dilated conv zachowuje resolution, ASPP dla multi-scale, lepsze dla dużych datasetów. + +### Q3: "Co to jest panoptic segmentation?" +**Odpowiedź:** Unified semantic + instance. Dzieli na "stuff" (nieczęściowe: sky, road) i "things" (policzalne: person, car). Każdy piksel ma class ID + instance ID. + +--- + +## 🎯 Kluczowe punkty + +1. **Klasyczne:** Thresholding, Region Growing, Watershed, Graph Cut +2. **FCN:** Pierwszy fully convolutional dla segmentacji +3. **U-Net:** Encoder-decoder + skip connections +4. **DeepLab:** Dilated/Atrous conv, ASPP +5. **Metryka:** mIoU (mean Intersection over Union) + +--- + +## 📖 Źródła + +1. Long et al. - "Fully Convolutional Networks" (2015) +2. Ronneberger et al. - "U-Net" (2015) +3. Chen et al. - "DeepLab" series (2014-2018) +4. Xie et al. - "SegFormer" (2021) diff --git a/pytania/odpowiedzi/40-detekcja-obiektow.md b/pytania/odpowiedzi/40-detekcja-obiektow.md new file mode 100644 index 0000000..a7138dd --- /dev/null +++ b/pytania/odpowiedzi/40-detekcja-obiektow.md @@ -0,0 +1,363 @@ +# Pytanie 40: Detekcja obiektów w obrazach + +## Pytanie +**"Opisać problem detekcji obiektów w obrazach. Przedstawić podstawowe strategie i algorytmy detekcji przy użyciu metod klasycznych oraz sieci neuronowych. Jak skonstruować detektor obiektów dysponując istniejącym klasyfikatorem tych obiektów?"** + +Przedmiot: TWM (Techniki Wizji Maszynowej) + +--- + +## 📚 Odpowiedź główna + +### 1. Definicja problemu detekcji + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ DETEKCJA OBIEKTÓW │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Obraz wejściowy: Wynik detekcji: │ +│ ┌────────────────┐ ┌────────────────┐ │ +│ │ 🚗 🚶 │ │ ┌──┐ ┌──┐ │ │ +│ │ 🚗 │ → │ │🚗│ │🚶│ │ │ +│ │ 🚶 │ │ └──┘ └──┘ ┌──┐ │ │ +│ │ │ │ ┌──┐│🚗│ │ │ +│ └────────────────┘ │ ┌──┤🚶│└──┘ │ │ +│ │ └──┴──┘ │ │ +│ └────────────────┘ │ +│ │ +│ Wynik: lista (class, bounding_box, confidence) │ +│ [(car, [x1,y1,x2,y2], 0.95), (person, [...], 0.87)] │ +│ │ +│ Różnica od klasyfikacji: │ +│ • Klasyfikacja: Co jest na obrazie? │ +│ • Detekcja: Co i GDZIE jest na obrazie? │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 2. Metody klasyczne + +#### 2.1 Sliding Window + HOG/SIFT + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ SLIDING WINDOW │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ 1. Przesuwaj okno po obrazie (różne skale, pozycje) │ +│ │ +│ ┌──┐ │ +│ │░░│→→→→→→→→ │ +│ └──┘ │ +│ ↓ ↓ ↓ ↓ ↓ ↓ ↓ │ +│ │ +│ 2. Dla każdego okna: wyekstrahuj features (HOG, SIFT) │ +│ 3. Klasyfikuj (SVM, Random Forest) │ +│ 4. Non-Maximum Suppression (NMS) │ +│ │ +│ Problem: O(scales × positions × classifier) → WOLNE! │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### 2.2 HOG (Histogram of Oriented Gradients) + +``` +HOG descriptor: +1. Oblicz gradienty (Gx, Gy) +2. Magnitude: √(Gx² + Gy²) +3. Orientacja: arctan(Gy/Gx) +4. Podziel na cells (8×8 pikseli) +5. Histogram orientacji (9 bins) +6. Normalizacja w blokach + + ┌───┬───┬───┬───┐ + │ │ │ │ │ + ├───┼───┼───┼───┤ + │ │▓▓▓│▓▓▓│ │ ← histogram dla każdej cell + ├───┼───┼───┼───┤ + │ │▓▓▓│▓▓▓│ │ + └───┴───┴───┴───┘ + +Użycie: HOG + linear SVM → pedestrian detection (Dalal & Triggs) +``` + +#### 2.3 Viola-Jones (Haar Cascades) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ VIOLA-JONES (2001) - real-time face detection │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Haar-like features: │ +│ ┌───┬───┐ ┌───────┐ ┌─┬─┐ │ +│ │░░░│███│ │░░░░░░░│ │░│█│ │ +│ │░░░│███│ │███████│ │█│░│ │ +│ └───┴───┘ └───────┘ └─┴─┘ │ +│ │ +│ Feature = Σ(white) - Σ(black) │ +│ Integral image: O(1) dla każdej feature! │ +│ │ +│ AdaBoost cascade: │ +│ Stage1 → Stage2 → Stage3 → ... → Face! │ +│ ↓ ↓ ↓ │ +│ Reject Reject Reject (szybko odrzuca nie-twarze) │ +│ │ +│ Bardzo szybkie! (30fps w 2001) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 3. Metody Deep Learning + +#### 3.1 Two-Stage Detectors (R-CNN family) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ R-CNN (2014) │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ 1. Selective Search → ~2000 region proposals │ +│ 2. Dla każdego regionu: │ +│ - Resize do 224×224 │ +│ - CNN (AlexNet) → features │ +│ - SVM classifier │ +│ 3. Bounding box regression │ +│ 4. NMS │ +│ │ +│ Problem: 2000 × CNN forward pass → ~50 sec/image! │ +└─────────────────────────────────────────────────────────────────┘ + +┌─────────────────────────────────────────────────────────────────┐ +│ Fast R-CNN (2015) │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Image → CNN → Feature map │ +│ ↓ │ +│ ROI Pooling (region proposals) │ +│ ↓ │ +│ FC layers │ +│ ↓ ↓ │ +│ class bbox │ +│ │ +│ CNN tylko raz! ROI pooling wycina regiony z feature map │ +│ ~2 sec/image (25× szybciej) │ +└─────────────────────────────────────────────────────────────────┘ + +┌─────────────────────────────────────────────────────────────────┐ +│ Faster R-CNN (2016) │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Image → CNN → Feature map → RPN (Region Proposal Network) │ +│ │ ↓ │ +│ └──────→ ROI Pooling │ +│ ↓ │ +│ Detection head │ +│ ↓ ↓ │ +│ class bbox │ +│ │ +│ RPN: mała sieć generująca proposals (zamiast Selective Search) │ +│ End-to-end training! │ +│ ~0.2 sec/image (~5 fps) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### 3.2 One-Stage Detectors (YOLO, SSD) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ YOLO (You Only Look Once) - 2016 │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Image → CNN → S×S×(B×5 + C) tensor │ +│ │ +│ Dzieli obraz na S×S grid: │ +│ ┌───┬───┬───┬───┬───┬───┬───┐ │ +│ │ │ │ │ │ │ │ │ │ +│ ├───┼───┼───┼───┼───┼───┼───┤ │ +│ │ │ │ ● │ │ │ │ │ ← cell odpowiada za obiekt │ +│ ├───┼───┼───┼───┼───┼───┼───┤ którego centrum tu jest │ +│ │ │ │ │ │ │ │ │ │ +│ └───┴───┴───┴───┴───┴───┴───┘ │ +│ │ +│ Każda cell predykuje: │ +│ • B bounding boxes: (x, y, w, h, confidence) │ +│ • C class probabilities │ +│ │ +│ Zaleta: Bardzo szybki! 45-155 fps │ +│ Wada: Gorszy dla małych obiektów, obiektów blisko siebie │ +└─────────────────────────────────────────────────────────────────┘ + +┌─────────────────────────────────────────────────────────────────┐ +│ SSD (Single Shot Detector) - 2016 │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Multi-scale feature maps: │ +│ │ +│ ┌────────────┐ │ +│ │ 38×38×512 │ ← detect small objects │ +│ └─────┬──────┘ │ +│ ↓ │ +│ ┌──────┐ │ +│ │19×19 │ ← detect medium objects │ +│ └──┬───┘ │ +│ ↓ │ +│ ┌────┐ │ +│ │10×10│ ← detect large objects │ +│ └────┘ │ +│ │ +│ Default boxes (anchors) o różnych aspect ratios │ +│ Łączy zalety YOLO (szybkość) i Faster R-CNN (multi-scale) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### 3.3 Nowoczesne architektury + +``` +YOLOv8 (2023): +• Anchor-free detection +• Decoupled head (cls/box separate) +• C2f module (CSP + bottleneck) +• ~80 mAP na COCO, real-time + +DETR (2020): +• Transformer-based +• Bipartite matching loss (Hungarian) +• No anchors, no NMS +• End-to-end set prediction + +RT-DETR (2023): +• Real-time DETR +• Efficient hybrid encoder +• IoU-aware query selection +``` + +--- + +### 4. Konstrukcja detektora z klasyfikatora + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ JAK ZROBIĆ DETEKTOR MAJĄC KLASYFIKATOR? │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Metoda 1: SLIDING WINDOW │ +│ ───────────────────────── │ +│ for scale in scales: │ +│ for (x, y) in positions: │ +│ crop = image[y:y+h, x:x+w] │ +│ if classifier(crop) > threshold: │ +│ detections.append((x, y, w, h, class)) │ +│ return NMS(detections) │ +│ │ +│ Problem: Bardzo wolne (wiele przesunięć × skale) │ +│ │ +│ │ +│ Metoda 2: REGION PROPOSALS + CLASSIFIER │ +│ ───────────────────────────────────────── │ +│ 1. Selective Search / EdgeBoxes → candidate regions │ +│ 2. Dla każdego regionu: │ +│ resize + classifier → class, confidence │ +│ 3. NMS │ +│ │ +│ Szybsze niż sliding window (mniej regionów) │ +│ │ +│ │ +│ Metoda 3: FINE-TUNE na DETECTION │ +│ ───────────────────────────────── │ +│ 1. Użyj pretrained classifier jako backbone │ +│ 2. Dodaj detection head (bbox regression + cls) │ +│ 3. Fine-tune na detection dataset │ +│ │ +│ Najlepsza jakość! │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 5. Non-Maximum Suppression (NMS) + +``` +Problem: Wiele overlapping detections + + ┌─────────┐ + │ ┌──────┼──┐ + │ │ 🚗 │ │ ← 3 nakładające się bbox + │ │ │ │ + └──┼──────┘ │ + └─────────┘ + +NMS Algorithm: +1. Sortuj detekcje wg confidence +2. Weź najlepszą, dodaj do wyników +3. Usuń wszystkie z IoU > threshold +4. Powtarzaj dla pozostałych + +Soft-NMS: Nie usuwa, tylko obniża confidence + score = score × f(IoU) gdzie f maleje z IoU +``` + +--- + +### 6. Metryki + +| Metryka | Opis | +|---------|------| +| **IoU** | Intersection over Union bbox | +| **Precision** | TP / (TP + FP) | +| **Recall** | TP / (TP + FN) | +| **AP** | Area under Precision-Recall curve | +| **mAP** | Mean AP across classes | +| **mAP@0.5** | mAP przy IoU threshold = 0.5 | +| **mAP@[.5:.95]** | mAP average across IoU thresholds | + +--- + +## 🧠 Mnemoniki + +### "YOLO = You Only Look Once": +Jednokrotne przejście przez sieć + +### "R-CNN → Fast → Faster": +Ewolucja: 50s → 2s → 0.2s + +### "Two-stage = proposals + classify": +Faster R-CNN: RPN + detection head + +### "One-stage = direct": +YOLO, SSD: bezpośrednia predykcja + +--- + +## ❓ Pytania dodatkowe + +### Q1: "YOLO vs Faster R-CNN?" +**Odpowiedź:** YOLO: szybszy (real-time), gorszy dla małych obiektów. Faster R-CNN: dokładniejszy, wolniejszy, two-stage (RPN + detection). Trade-off speed vs accuracy. + +### Q2: "Co to są anchor boxes?" +**Odpowiedź:** Predefiniowane boxy o różnych rozmiarach i aspect ratios. Sieć predykuje offset od anchora, nie absolutne koordynaty. Ułatwia uczenie (mniejsza przestrzeń wyjściowa). + +### Q3: "Jak działają anchor-free detektory?" +**Odpowiedź:** Predykują bezpośrednio: punkt centralny + rozmiar (FCOS, CenterNet) lub keypoints (CornerNet). Prostsze, mniej hiperparametrów, konkurencyjne wyniki. + +--- + +## 🎯 Kluczowe punkty + +1. **Klasyczne:** HOG+SVM, Viola-Jones (Haar cascades) +2. **Two-stage:** R-CNN → Fast → Faster (RPN) +3. **One-stage:** YOLO, SSD (szybsze, real-time) +4. **NMS:** Eliminacja overlapping detekcji +5. **Metryka:** mAP@[.5:.95] + +--- + +## 📖 Źródła + +1. Girshick et al. - "R-CNN" (2014), "Fast R-CNN" (2015) +2. Ren et al. - "Faster R-CNN" (2016) +3. Redmon et al. - "YOLO" series (2016-2018) +4. Liu et al. - "SSD" (2016) +5. Carion et al. - "DETR" (2020) diff --git a/pytania/odpowiedzi/41-interaktywne-wspomaganie-decyzji.md b/pytania/odpowiedzi/41-interaktywne-wspomaganie-decyzji.md new file mode 100644 index 0000000..9ff8929 --- /dev/null +++ b/pytania/odpowiedzi/41-interaktywne-wspomaganie-decyzji.md @@ -0,0 +1,270 @@ +# Pytanie 41: Interaktywne wspomaganie decyzji w warunkach ryzyka + +## Pytanie +**"Przedstawić metody interaktywne wspomagania decyzji w warunkach ryzyka."** + +Przedmiot: WDWR (Wspomaganie Decyzji w Warunkach Ryzyka) + +--- + +## 📚 Odpowiedź główna + +### 1. Decyzje w warunkach ryzyka + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ WARUNKI PODEJMOWANIA DECYZJI │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ PEWNOŚĆ: Znamy dokładnie wyniki każdej decyzji │ +│ (deterministyczne) │ +│ │ +│ RYZYKO: Znamy możliwe wyniki i ich prawdopodobieństwa │ +│ (stochastyczne, rozkłady znane) │ +│ │ +│ NIEPEWNOŚĆ: Możliwe wyniki znane, prawdopodobieństwa nie │ +│ (scenariusze bez prawdopodobieństw) │ +│ │ +│ Decyzja w warunkach ryzyka: │ +│ • Wybór między loteriami (gambles) │ +│ • Każda loteria: zbiór wyników z prawdopodobieństwami │ +│ • Decydent ma preferencje dotyczące ryzyka │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 2. Metody interaktywne - przegląd + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ INTERAKTYWNE = Dialog z decydentem │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ ┌──────────────┐ ┌──────────────┐ │ +│ │ DECYDENT │ ←─────→ │ SYSTEM │ │ +│ │ (preferencje)│ │ (analiza) │ │ +│ └──────────────┘ └──────────────┘ │ +│ │ │ │ +│ ↓ ↓ │ +│ Odpowiedzi na Generowanie pytań, │ +│ pytania, wybory eliminacja opcji, │ +│ porównawcze rekomendacje │ +│ │ +│ Cel: Odkryć preferencje decydenta (funkcję użyteczności) │ +│ bez wymagania pełnej specyfikacji z góry │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 3. Metoda loterii (Lottery Method) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ ELICYTACJA FUNKCJI UŻYTECZNOŚCI │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Cel: Wyznaczyć U(x) dla różnych wartości x │ +│ │ +│ Procedura: │ +│ 1. Ustal U(x_worst) = 0, U(x_best) = 1 │ +│ │ +│ 2. Dla wartości pośredniej x_mid, pytaj: │ +│ "Wolisz x_mid na pewno, czy loterię │ +│ (p: x_best, 1-p: x_worst)?" │ +│ │ +│ 3. Znajdź p* gdzie decydent jest obojętny: │ +│ U(x_mid) = p* × U(x_best) + (1-p*) × U(x_worst) │ +│ U(x_mid) = p* × 1 + (1-p*) × 0 = p* │ +│ │ +│ 4. Powtórz dla kolejnych punktów │ +│ │ +│ Przykład: │ +│ x_worst = 0 PLN, x_best = 1000 PLN, x_mid = 500 PLN │ +│ Pytanie: "500 PLN na pewno czy loteria (p: 1000, 1-p: 0)?" │ +│ Jeśli obojętny przy p* = 0.6 → U(500) = 0.6 │ +│ (risk averse: 0.6 < 0.5 liniowego) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 4. Metoda pewnego ekwiwalentu (Certainty Equivalent) + +``` +CE (Certainty Equivalent) = pewna kwota równoważna loterii + +Dla loterii L = (p₁: x₁, p₂: x₂, ...): + CE(L) taki że U(CE) = E[U(L)] = Σ pᵢ U(xᵢ) + +Pytanie interaktywne: +"Ile PLN na pewno jest dla Ciebie równoważne loterii + (50%: 1000 PLN, 50%: 0 PLN)?" + +Odpowiedź CE = 400 PLN oznacza: + U(400) = 0.5 × U(1000) + 0.5 × U(0) = 0.5 + +Risk Premium = E[X] - CE = 500 - 400 = 100 PLN + (ile decydent "płaci" za uniknięcie ryzyka) + +┌─────────────────────────────────────────────────────────────────┐ +│ U(x) │ +│ ↑ Risk Averse Risk Neutral Risk Seeking │ +│ │ ╭─── / ───╮ │ +│ │ ╭─╯ / ╰─╮ │ +│ │ ╭─╯ / ╰─╮ │ +│ │ ╭─╯ / ╰─╮ │ +│ │╭─╯ / ╰╮│ +│ └──────────────────────────────────────────────────────────→ x│ +│ CE < E[X] CE = E[X] CE > E[X] │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 5. Metoda AHP (Analytic Hierarchy Process) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ AHP - Hierarchiczna struktura problemu (Saaty) │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ ┌─────────────┐ │ +│ │ CEL │ │ +│ └──────┬──────┘ │ +│ ┌───────────────┼───────────────┐ │ +│ ↓ ↓ ↓ │ +│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ +│ │Kryterium1│ │Kryterium2│ │Kryterium3│ │ +│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ +│ └──────────────┼──────────────┘ │ +│ ↓ │ +│ ┌─────┬─────┬─────┐ │ +│ │Alt A│Alt B│Alt C│ │ +│ └─────┴─────┴─────┘ │ +│ │ +│ Porównania parami (skala 1-9): │ +│ "Ile razy kryterium K1 jest ważniejsze od K2?" │ +│ │ +│ Macierz porównań → eigenvalue → wagi │ +│ Consistency Ratio CR < 0.1 (sprawdzenie spójności) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 6. Metoda PROMETHEE + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ PROMETHEE - Preference Ranking Organization Method │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ 1. Dla każdego kryterium j, definiuj funkcję preferencji Pⱼ │ +│ Pⱼ(a,b) = P(dⱼ) gdzie dⱼ = fⱼ(a) - fⱼ(b) │ +│ │ +│ Typy funkcji preferencji: │ +│ │ │ ____ │ +│ │ ____ │ / │ +│ │ / │ / │ +│ │___/ │___/ │ +│ Próg (threshold) Liniowa (V-shape) │ +│ │ +│ 2. Agregacja: │ +│ π(a,b) = Σⱼ wⱼ Pⱼ(a,b) (indeks preferencji) │ +│ │ +│ 3. Przepływy: │ +│ Φ⁺(a) = Σᵦ π(a,b) (outranking flow) │ +│ Φ⁻(a) = Σᵦ π(b,a) (outranked flow) │ +│ Φ(a) = Φ⁺(a) - Φ⁻(a) (net flow) │ +│ │ +│ 4. Ranking wg Φ(a) │ +│ │ +│ Interaktywność: wybór funkcji preferencji, progów, wag │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 7. Metoda ELECTRE + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ ELECTRE - ELimination Et Choix Traduisant la REalité │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Outranking: "a jest co najmniej tak dobra jak b" (aSb) │ +│ │ +│ Concordance Index C(a,b): │ +│ C(a,b) = Σ{wⱼ : fⱼ(a) ≥ fⱼ(b)} / Σwⱼ │ +│ (suma wag kryteriów gdzie a ≥ b) │ +│ │ +│ Discordance Index D(a,b): │ +│ D(a,b) = max{(fⱼ(b) - fⱼ(a)) / Δⱼ} │ +│ (największa przewaga b nad a, znormalizowana) │ +│ │ +│ Outranking: │ +│ aSb ⟺ C(a,b) ≥ c* AND D(a,b) ≤ d* │ +│ (wystarczająca zgodność, brak silnego sprzeciwu) │ +│ │ +│ Interaktywność: progi c*, d*, wagi wⱼ │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 8. Porównanie metod + +| Metoda | Typ | Interakcja | Zastosowanie | +|--------|-----|------------|--------------| +| **Lottery** | Utility | Porównania z loteriami | Elicytacja U(x) | +| **CE** | Utility | Pewne ekwiwalenty | Pomiar ryzyka | +| **AHP** | MCDM | Porównania parami | Hierarchie, wagi | +| **PROMETHEE** | Outranking | Funkcje preferencji | Ranking | +| **ELECTRE** | Outranking | Progi zgodności | Eliminacja | + +--- + +## 🧠 Mnemoniki + +### "CE = Certain Equivalent": +Pewna kwota równoważna loterii + +### "AHP = Ask, Hierarchize, Prioritize": +Pytaj, buduj hierarchię, ustal priorytety + +### "PROMETHEE = Przepływy": +Φ⁺ (outgoing), Φ⁻ (incoming), Φ (net) + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Jak wykryć niespójność odpowiedzi decydenta?" +**Odpowiedź:** AHP: Consistency Ratio (CR < 0.1). Utility: sprawdzenie monotoniczności, przechodniości preferencji. Cross-validation różnymi metodami elicytacji. + +### Q2: "Co to jest awersja do ryzyka?" +**Odpowiedź:** Risk averse: U''(x) < 0 (funkcja wklęsła), CE < E[X], preferuje pewność nad loterię o tej samej wartości oczekiwanej. Miernik: Arrow-Pratt coefficient r(x) = -U''(x)/U'(x). + +### Q3: "AHP vs PROMETHEE?" +**Odpowiedź:** AHP: hierarchiczna dekompozycja, porównania parami, pełna kompensacja. PROMETHEE: outranking, progi preferencji, częściowa kompensacja, lepsze dla nieporównywalnych kryteriów. + +--- + +## 🎯 Kluczowe punkty + +1. **Ryzyko:** Znane prawdopodobieństwa wyników +2. **Interaktywność:** Dialog z decydentem +3. **Loterie:** Elicytacja U(x) przez porównania +4. **CE:** Certainty Equivalent, miara awersji do ryzyka +5. **AHP/PROMETHEE/ELECTRE:** Metody wielokryterialne + +--- + +## 📖 Źródła + +1. von Neumann, Morgenstern - "Theory of Games and Economic Behavior" +2. Saaty - "The Analytic Hierarchy Process" +3. Brans, Vincke - "PROMETHEE Method" +4. Roy - "ELECTRE Methods" diff --git a/pytania/odpowiedzi/42-dominacja-stochastyczna.md b/pytania/odpowiedzi/42-dominacja-stochastyczna.md new file mode 100644 index 0000000..88de5cb --- /dev/null +++ b/pytania/odpowiedzi/42-dominacja-stochastyczna.md @@ -0,0 +1,291 @@ +# Pytanie 42: Dominacja stochastyczna + +## Pytanie +**"Scharakteryzować relacje dominacji stochastycznej pierwszego i drugiego rzędu. Jak mogą być użyte w modelach wyboru w warunkach ryzyka?"** + +Przedmiot: WDWR (Wspomaganie Decyzji w Warunkach Ryzyka) + +--- + +## 📚 Odpowiedź główna + +### 1. Idea dominacji stochastycznej + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ DOMINACJA STOCHASTYCZNA (Stochastic Dominance) │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Cel: Porównać rozkłady prawdopodobieństwa (loterie) │ +│ BEZ znajomości dokładnej funkcji użyteczności │ +│ │ +│ Pytanie: "Czy loteria A jest lepsza od loterii B │ +│ dla KAŻDEGO racjonalnego decydenta?" │ +│ │ +│ Jeśli A dominuje B → KAŻDY wybierze A (niezależnie od U) │ +│ │ +│ Hierarchia: │ +│ FSD (First-order) ⊂ SSD (Second-order) ⊂ TSD (Third-order) │ +│ │ +│ FSD implikuje SSD, ale nie odwrotnie │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 2. Dominacja stochastyczna pierwszego rzędu (FSD) + +#### Definicja + +$$A \succeq_{FSD} B \Leftrightarrow F_A(x) \leq F_B(x) \quad \forall x$$ + +gdzie $F(x) = P(X \leq x)$ to dystrybuanta (CDF) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ FSD: "A dominuje B jeśli F_A jest zawsze poniżej F_B" │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ F(x) │ +│ ↑ │ +│ 1 │ ╭───── F_B │ +│ │ ╭──╯ │ +│ │ ╭──╯ │ +│ │ ╭──╯ │ +│ │ ╭──╯ ╭───── F_A │ +│ │ ╭──╯ ╭──╯ │ +│ │ ╭──╯ ╭──╯ │ +│ │──╯ ╭──╯ │ +│ 0 └──────────────────────────────────────────────→ x │ +│ │ +│ F_A(x) ≤ F_B(x) dla każdego x → A dominuje B (FSD) │ +│ │ +│ Interpretacja: A ma zawsze większe prawdopodobieństwo │ +│ przekroczenia dowolnego progu x │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### Charakterystyka FSD + +| Aspekt | Opis | +|--------|------| +| **Warunek na U** | U'(x) ≥ 0 (monotoniczność, "więcej = lepiej") | +| **Klasa decydentów** | WSZYSCY racjonalni (nienasyceni) | +| **Siła** | Najsilniejsza dominacja | +| **Częstość** | Rzadko występuje w praktyce | + +#### Równoważna definicja + +$$E[U(A)] \geq E[U(B)] \quad \forall U: U' \geq 0$$ + +--- + +### 3. Dominacja stochastyczna drugiego rzędu (SSD) + +#### Definicja + +$$A \succeq_{SSD} B \Leftrightarrow \int_{-\infty}^{x} F_A(t) dt \leq \int_{-\infty}^{x} F_B(t) dt \quad \forall x$$ + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ SSD: "Skumulowane pole pod F_A ≤ pole pod F_B" │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ F(x) ∫F(t)dt │ +│ ↑ ↑ │ +│ │ ╭── F_B │ ╭── ∫F_B │ +│ │ ╭─╯ │ ╭─╯ │ +│ │ ╱ ╭── F_A │ ╭─╯ │ +│ │╱ ╭─╯ │ ╭─╯ ╭── ∫F_A │ +│ ┼──────────→ x │ ╭─╯ ╭─╯ │ +│ │─╯───╭─╯ │ +│ Krzywe mogą └───────────────→ x │ +│ się przecinać! Skumulowane nie! │ +│ │ +│ SSD dopuszcza przecięcia CDF, ale całki muszą zachować relację│ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### Charakterystyka SSD + +| Aspekt | Opis | +|--------|------| +| **Warunek na U** | U' ≥ 0 i U'' ≤ 0 (monotoniczne + wklęsłe) | +| **Klasa decydentów** | Risk-averse (awersja do ryzyka) | +| **Siła** | Słabsza niż FSD | +| **Częstość** | Częstsza niż FSD | + +#### Równoważna definicja + +$$E[U(A)] \geq E[U(B)] \quad \forall U: U' \geq 0, U'' \leq 0$$ + +--- + +### 4. Porównanie FSD i SSD + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ FSD vs SSD │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Przykład 1: FSD │ +│ A: 50% szans na 100, 50% na 200 │ +│ B: 50% szans na 50, 50% na 150 │ +│ A dominuje B (FSD) - zawsze lepsze wyniki │ +│ │ +│ Przykład 2: SSD (ale nie FSD) │ +│ A: 100 na pewno │ +│ B: 50% szans na 50, 50% na 150 │ +│ E[A] = 100 = E[B], ale A ma mniejszą wariancję │ +│ A dominuje B (SSD) dla risk-averse │ +│ NIE dominuje (FSD) - B może dać 150 > 100 │ +│ │ +│ Przykład 3: Mean-Preserving Spread (MPS) │ +│ B = A + ε, gdzie E[ε|A] = 0 (noise) │ +│ A dominuje B (SSD) - ta sama średnia, większy rozrzut B │ +└─────────────────────────────────────────────────────────────────┘ +``` + +| Cecha | FSD | SSD | +|-------|-----|-----| +| **Warunek** | F_A(x) ≤ F_B(x) ∀x | ∫F_A ≤ ∫F_B ∀x | +| **Na U** | U' ≥ 0 | U' ≥ 0, U'' ≤ 0 | +| **Decydenci** | Wszyscy racjonalni | Risk-averse | +| **Implikacja** | FSD ⟹ SSD | SSD ⇏ FSD | +| **Praktyka** | Rzadka | Częstsza | + +--- + +### 5. Zastosowanie w modelach wyboru + +#### Portfolio Selection + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ WYBÓR PORTFELA │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Problem: Wybór między portfelami P₁, P₂, ..., Pₙ │ +│ │ +│ Krok 1: Sprawdź FSD │ +│ Jeśli Pᵢ FSD Pⱼ → wyeliminuj Pⱼ │ +│ (żaden racjonalny inwestor nie wybierze Pⱼ) │ +│ │ +│ Krok 2: Sprawdź SSD (dla risk-averse) │ +│ Jeśli Pᵢ SSD Pⱼ → wyeliminuj Pⱼ dla risk-averse │ +│ │ +│ Krok 3: Dla pozostałych - potrzebna specyfikacja U │ +│ │ +│ Efektywny zbiór SD = portfele niezdominowane │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### Ocena inwestycji + +``` +Inwestycja A: Zwrot ~ N(10%, 15%) +Inwestycja B: Zwrot ~ N(8%, 20%) + +Test SSD: +• E[A] = 10% > E[B] = 8% ✓ +• σ[A] = 15% < σ[B] = 20% ✓ + +Dla rozkładów normalnych z E[A] > E[B] i σ[A] < σ[B]: + A dominuje B (SSD) + +Wniosek: Każdy risk-averse inwestor wybierze A +``` + +#### Ubezpieczenia + +``` +Bez ubezpieczenia: Loteria L z ryzykiem straty +Z ubezpieczeniem: CE (pewna strata = składka) + +Jeśli składka = "fair" (E[składka] = E[straty]): + Ubezpieczenie SSD dominuje brak ubezpieczenia + dla każdego risk-averse decydenta + +Uzasadnienie zakupu ubezpieczenia bez znajomości U! +``` + +--- + +### 6. Testowanie dominacji + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ ALGORYTM SPRAWDZANIA SD │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Dane: Dwa rozkłady empiryczne (próbki x₁,...,xₙ i y₁,...,yₘ) │ +│ │ +│ FSD Test: │ +│ 1. Oblicz empiryczne CDF: F̂_X(t), F̂_Y(t) │ +│ 2. Sprawdź czy F̂_X(t) ≤ F̂_Y(t) dla wszystkich t │ +│ │ +│ SSD Test: │ +│ 1. Oblicz ∫F̂_X(t)dt i ∫F̂_Y(t)dt │ +│ 2. Sprawdź czy pierwsza ≤ druga dla wszystkich punktów │ +│ │ +│ Testy statystyczne: │ +│ • Kolmogorov-Smirnov (FSD) │ +│ • Barrett-Donald test │ +│ • Linton-Maasoumi-Whang test │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 7. Ograniczenia + +| Ograniczenie | Opis | +|--------------|------| +| **Częściowe uporządkowanie** | Nie wszystkie pary porównywalne | +| **Konserwatywność** | Wiele par bez dominacji | +| **Wymóg pełnego rozkładu** | Potrzebna cała dystrybuanta | +| **Brak dominacji ≠ obojętność** | Brak dominacji nie znaczy równoważność | + +--- + +## 🧠 Mnemoniki + +### "FSD = F always ≤": +First-order: dystrybuanta A zawsze ≤ B + +### "SSD = Second = Sum (integral)": +Second-order: całka z F_A ≤ całka z F_B + +### "FSD = wszyscy, SSD = risk-averse": +FSD: U' ≥ 0, SSD: U' ≥ 0, U'' ≤ 0 + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Kiedy FSD a kiedy SSD?" +**Odpowiedź:** FSD: gdy jeden rozkład jest jednoznacznie lepszy (przesunięty w prawo). SSD: gdy różnica w ryzyku (rozproszeniu) kompensuje różnicę w średniej dla risk-averse. + +### Q2: "Co jeśli ani FSD ani SSD?" +**Odpowiedź:** Rozkłady są nieporównywalne w sensie SD. Potrzebna dokładniejsza specyfikacja preferencji (konkretna funkcja użyteczności) lub TSD (trzeci rząd). + +### Q3: "Związek SD z mean-variance?" +**Odpowiedź:** Mean-variance (Markowitz) to przybliżenie. SSD jest bardziej ogólne - nie wymaga założenia normalności rozkładu. Dla rozkładów normalnych: SSD ≈ dominacja mean-variance. + +--- + +## 🎯 Kluczowe punkty + +1. **FSD:** F_A(x) ≤ F_B(x) ∀x, dla U' ≥ 0 +2. **SSD:** ∫F_A ≤ ∫F_B, dla U' ≥ 0, U'' ≤ 0 +3. **FSD ⟹ SSD** (ale nie odwrotnie) +4. **Zastosowanie:** Eliminacja zdominowanych opcji +5. **Bez znajomości U:** Decyzja dla klasy decydentów + +--- + +## 📖 Źródła + +1. Hadar, Russell - "Rules for Ordering Uncertain Prospects" +2. Levy - "Stochastic Dominance" +3. Rothschild, Stiglitz - "Increasing Risk" diff --git a/pytania/odpowiedzi/43-szeregowanie-zadan.md b/pytania/odpowiedzi/43-szeregowanie-zadan.md new file mode 100644 index 0000000..c67045c --- /dev/null +++ b/pytania/odpowiedzi/43-szeregowanie-zadan.md @@ -0,0 +1,276 @@ +# Pytanie 43: Klasyfikacja zadań szeregowania + +## Pytanie +**"Jakie cechy zadań szeregowania wykorzystuje się do ich klasyfikacji? Omówić przykładową metodę dla wybranego problemu szeregowania."** + +Przedmiot: ZBOP (Zarządzanie i Badania Operacyjne w Produkcji) + +--- + +## 📚 Odpowiedź główna + +### 1. Notacja Graham'a (α|β|γ) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ NOTACJA KLASYFIKACJI ZADAŃ SZEREGOWANIA │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ α | β | γ │ +│ │ │ │ │ +│ │ │ └── Kryterium optymalizacji │ +│ │ └────── Charakterystyki zadań │ +│ └────────── Środowisko maszynowe │ +│ │ +│ Przykład: Pm | prec, pⱼ=1 | Cmax │ +│ │ │ │ │ │ +│ │ │ │ └── minimalizuj makespan │ +│ │ │ └── jednostkowe czasy │ +│ │ └── ograniczenia kolejnościowe │ +│ └── m maszyn równoległych │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 2. Pole α - Środowisko maszynowe + +| Symbol | Opis | +|--------|------| +| **1** | Jedna maszyna | +| **P** | Maszyny równoległe identyczne | +| **Pm** | m maszyn równoległych identycznych | +| **Q** | Maszyny równoległe o różnych prędkościach | +| **R** | Maszyny niezwiązane (unrelated) | +| **F** | Flow shop (linia produkcyjna) | +| **Fm** | Flow shop z m maszynami | +| **J** | Job shop | +| **Jm** | Job shop z m maszynami | +| **O** | Open shop | + +``` +JEDNA MASZYNA (1): + Job 1 ──→ ┌───┐ + Job 2 ──→ │ M │ ──→ Output + Job 3 ──→ └───┘ + +MASZYNY RÓWNOLEGŁE (Pm): + Job 1 ──→ ┌───┐ + │M1 │ ──→ + Job 2 ──→ ├───┤ + │M2 │ ──→ Output + Job 3 ──→ ├───┤ + │M3 │ ──→ + └───┘ + +FLOW SHOP (F): + Job 1 ──→ ┌───┐ ──→ ┌───┐ ──→ ┌───┐ ──→ + │M1 │ │M2 │ │M3 │ + Job 2 ──→ └───┘ ──→ └───┘ ──→ └───┘ ──→ + +JOB SHOP (J): + Każde zadanie ma własną trasę przez maszyny + Job 1: M1 → M3 → M2 + Job 2: M2 → M1 → M3 +``` + +--- + +### 3. Pole β - Charakterystyki zadań + +| Symbol | Opis | +|--------|------| +| **rⱼ** | Release dates (terminy dostępności) | +| **dⱼ** | Due dates (terminy wymagane) | +| **d̄ⱼ** | Deadlines (nieprzekraczalne terminy) | +| **prec** | Precedence constraints (kolejność) | +| **pmtn** | Preemption allowed (przerwanie dozwolone) | +| **pⱼ=1** | Unit processing times | +| **sᵢⱼ** | Setup times (czasy przezbrojeń) | +| **brkdwn** | Machine breakdowns | +| **batch** | Batch processing | + +--- + +### 4. Pole γ - Kryteria optymalizacji + +| Symbol | Nazwa | Formuła | +|--------|-------|---------| +| **Cmax** | Makespan | max Cⱼ | +| **ΣCⱼ** | Total completion time | Σ Cⱼ | +| **Σwⱼ Cⱼ** | Weighted completion | Σ wⱼ Cⱼ | +| **Lmax** | Max lateness | max(Cⱼ - dⱼ) | +| **Tmax** | Max tardiness | max(0, Cⱼ - dⱼ) | +| **ΣTⱼ** | Total tardiness | Σ max(0, Cⱼ - dⱼ) | +| **ΣUⱼ** | Number of tardy jobs | Σ 𝟙(Cⱼ > dⱼ) | + +``` +Cⱼ = Completion time zadania j +Lⱼ = Cⱼ - dⱼ (lateness, może być ujemne) +Tⱼ = max(0, Lⱼ) (tardiness, ≥ 0) +Uⱼ = 1 jeśli Tⱼ > 0, else 0 (unit penalty) +``` + +--- + +### 5. Złożoność obliczeniowa + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ ZŁOŻONOŚĆ WYBRANYCH PROBLEMÓW │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ WIELOMIANOWE (P): │ +│ 1 || Cmax O(n) (dowolna kolejność) │ +│ 1 || ΣCⱼ O(n log n) (SPT rule) │ +│ 1 || Lmax O(n log n) (EDD rule) │ +│ Pm || Cmax O(n log n) (LPT heuristic) │ +│ │ +│ NP-TRUDNE: │ +│ 1 || ΣTⱼ NP-hard │ +│ 1 || ΣwⱼCⱼ (rⱼ) NP-hard │ +│ Pm || Cmax (m≥2) NP-hard (ale PTAS istnieje) │ +│ Fm || Cmax (m≥3) NP-hard (flow shop ≥3 maszyny) │ +│ Jm || Cmax silnie NP-hard │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 6. Przykładowa metoda: Problem 1 || ΣCⱼ + +#### Problem + +``` +Jedna maszyna, n zadań, minimalizuj sumę czasów zakończenia + +Dane: + Zadanie: J1 J2 J3 J4 J5 + Czas pⱼ: 5 3 8 2 6 +``` + +#### Metoda: SPT (Shortest Processing Time) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ REGUŁA SPT: Szereguj zadania w kolejności rosnących pⱼ │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Posortowane: J4(2), J2(3), J1(5), J5(6), J3(8) │ +│ │ +│ Harmonogram: │ +│ │ +│ ├──J4──┼───J2───┼─────J1─────┼──────J5──────┼────────J3────────┤ +│ 0 2 5 10 16 24 +│ │ +│ Czasy zakończenia: │ +│ C₄ = 2 │ +│ C₂ = 2 + 3 = 5 │ +│ C₁ = 5 + 5 = 10 │ +│ C₅ = 10 + 6 = 16 │ +│ C₃ = 16 + 8 = 24 │ +│ │ +│ ΣCⱼ = 2 + 5 + 10 + 16 + 24 = 57 │ +│ │ +│ Dowód optymalności: │ +│ Zamiana sąsiednich i,j gdzie pᵢ > pⱼ zawsze zwiększa ΣC │ +│ SPT daje globalnie optymalne rozwiązanie │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### Dlaczego SPT jest optymalne? + +``` +Dla dwóch zadań i, j: + Kolejność i→j: Cᵢ = pᵢ, Cⱼ = pᵢ + pⱼ → ΣC = 2pᵢ + pⱼ + Kolejność j→i: Cⱼ = pⱼ, Cᵢ = pⱼ + pᵢ → ΣC = 2pⱼ + pᵢ + +Różnica: (2pᵢ + pⱼ) - (2pⱼ + pᵢ) = pᵢ - pⱼ + +Jeśli pᵢ < pⱼ → kolejność i→j lepsza (mniejsza ΣC) +Stąd: krótsze zadania najpierw! +``` + +--- + +### 7. Inne klasyczne reguły + +| Reguła | Problem | Opis | +|--------|---------|------| +| **SPT** | 1 \|\| ΣCⱼ | Shortest Processing Time | +| **WSPT** | 1 \|\| ΣwⱼCⱼ | Weighted SPT (wⱼ/pⱼ malejąco) | +| **EDD** | 1 \|\| Lmax | Earliest Due Date | +| **LPT** | Pm \|\| Cmax | Longest Processing Time (heur.) | +| **Moore** | 1 \|\| ΣUⱼ | Minimalizacja spóźnionych | +| **Johnson** | F2 \|\| Cmax | 2-machine flow shop | + +--- + +### 8. Algorytm Johnsona (F2 || Cmax) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ ALGORYTM JOHNSONA - Flow shop 2 maszyny │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Dane: n zadań, czasy (a₁,b₁), (a₂,b₂), ..., (aₙ,bₙ) │ +│ aⱼ = czas na maszynie 1, bⱼ = czas na maszynie 2 │ +│ │ +│ Algorytm: │ +│ 1. Podziel zadania na dwa zbiory: │ +│ U = {j : aⱼ < bⱼ} (krótszy czas na M1) │ +│ V = {j : aⱼ ≥ bⱼ} (krótszy czas na M2) │ +│ │ +│ 2. Sortuj U rosnąco wg aⱼ │ +│ Sortuj V malejąco wg bⱼ │ +│ │ +│ 3. Harmonogram: [U posortowane] ++ [V posortowane] │ +│ │ +│ Złożoność: O(n log n) │ +│ Optymalność: gwarantowana! │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +## 🧠 Mnemoniki + +### "α|β|γ = Maszyny|Zadania|Cel": +Trzy pola notacji Graham'a + +### "SPT = Short First": +Najkrótsze zadania najpierw dla ΣCⱼ + +### "EDD = Early Due Date": +Najwcześniejszy termin najpierw dla Lmax + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Kiedy stosować heurystyki a kiedy optymalne?" +**Odpowiedź:** Optymalne (SPT, EDD, Johnson) gdy problem wielomianowy. Heurystyki (LPT, dispatching rules) dla NP-trudnych lub gdy wymagana szybkość. Metaheurystyki (GA, SA) dla trudnych instancji. + +### Q2: "Co to jest preemption?" +**Odpowiedź:** Możliwość przerwania zadania i kontynuacji później. pmtn w notacji. Upraszcza niektóre problemy (1|pmtn,rⱼ|Lmax jest P, bez pmtn jest NP-hard). + +### Q3: "Job shop vs Flow shop?" +**Odpowiedź:** Flow shop: wszystkie zadania ta sama trasa (M1→M2→...→Mm). Job shop: każde zadanie własna trasa. Job shop jest ogólniejszy i trudniejszy (silnie NP-hard nawet dla 3 maszyn). + +--- + +## 🎯 Kluczowe punkty + +1. **Notacja α|β|γ:** Maszyny | Zadania | Kryterium +2. **SPT:** Optymalne dla 1||ΣCⱼ, O(n log n) +3. **EDD:** Optymalne dla 1||Lmax +4. **Johnson:** Optymalne dla F2||Cmax +5. **Większość problemów NP-trudna** + +--- + +## 📖 Źródła + +1. Pinedo - "Scheduling: Theory, Algorithms, and Systems" +2. Brucker - "Scheduling Algorithms" +3. Graham et al. - "Optimization and Approximation in Deterministic Sequencing" diff --git a/pytania/odpowiedzi/44-zarzadzanie-zapasami.md b/pytania/odpowiedzi/44-zarzadzanie-zapasami.md new file mode 100644 index 0000000..5e0863d --- /dev/null +++ b/pytania/odpowiedzi/44-zarzadzanie-zapasami.md @@ -0,0 +1,334 @@ +# Pytanie 44: Zarządzanie zapasami w łańcuchu dostaw + +## Pytanie +**"Jakie problemy wiążą się z zarządzaniem zapasami w łańcuchu dostaw? Omówić przykładowy model zarządzania zapasami w łańcuchu dostaw."** + +Przedmiot: ZBOP (Zarządzanie i Badania Operacyjne w Produkcji) + +--- + +## 📚 Odpowiedź główna + +### 1. Łańcuch dostaw - struktura + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ ŁAŃCUCH DOSTAW │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Dostawcy → Producent → Dystrybutor → Detalista → Klient │ +│ │ │ │ │ │ +│ └──────────┴────────────┴────────────┘ │ +│ Przepływ informacji (zamówienia) │ +│ ┌──────────┬────────────┬────────────┐ │ +│ │ │ │ │ │ +│ Dostawcy ← Producent ← Dystrybutor ← Detalista │ +│ Przepływ produktów │ +│ │ +│ Na każdym etapie: ZAPASY (inventory) │ +│ • Surowce (raw materials) │ +│ • Produkcja w toku (WIP) │ +│ • Wyroby gotowe (finished goods) │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 2. Problemy zarządzania zapasami + +#### 2.1 Bullwhip Effect (Efekt byczego bicza) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ BULLWHIP EFFECT │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Popyt klienta: ─────────────────────────── │ +│ (stabilny) │ +│ │ +│ Zamówienia ┌┐ ┌┐ │ +│ detalisty: ───┘└──┘└───────────────── │ +│ (małe wahania) │ +│ │ +│ Zamówienia ┌──┐ ┌──┐ │ +│ dystrybutora: ──┘ └────┘ └───────── │ +│ (większe wahania) │ +│ │ +│ Zamówienia ┌────┐ ┌────┐ │ +│ producenta: ──┘ └────────┘ └─── │ +│ (jeszcze większe) │ +│ │ +│ Zamówienia ┌──────┐ ┌──────┐ │ +│ dostawcy: ──┘ └──────────────┘ │ +│ (AMPLIFIKACJA!) │ +│ │ +│ Przyczyny: │ +│ • Prognozowanie popytu (forecasting) │ +│ • Batching zamówień │ +│ • Wahania cen (promocje) │ +│ • Rationing/shortage gaming │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### 2.2 Kluczowe problemy + +| Problem | Opis | +|---------|------| +| **Bullwhip effect** | Amplifikacja wahań w górę łańcucha | +| **Stockouts** | Brak towaru, utrata sprzedaży | +| **Overstock** | Nadmiar zapasów, koszty magazynowania | +| **Obsolescence** | Przestarzałe/przeterminowane produkty | +| **Lead time variability** | Zmienność czasu dostawy | +| **Demand uncertainty** | Niepewność popytu | +| **Koordynacja** | Brak współpracy między ogniwami | +| **Visibility** | Brak widoczności zapasów w łańcuchu | + +--- + +### 3. Koszty zapasów + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ STRUKTURA KOSZTÓW │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ 1. KOSZTY UTRZYMANIA (Holding costs) - h │ +│ • Koszt kapitału zamrożonego │ +│ • Magazynowanie, ubezpieczenie │ +│ • Zużycie, przestarzałość │ +│ Typowo: 15-30% wartości rocznie │ +│ │ +│ 2. KOSZTY ZAMAWIANIA (Ordering costs) - K │ +│ • Stałe koszty zamówienia │ +│ • Transport, obsługa │ +│ • Przezbrojenia (setup) │ +│ │ +│ 3. KOSZTY BRAKU (Shortage costs) - p │ +│ • Utrata sprzedaży │ +│ • Kary umowne │ +│ • Utrata reputacji │ +│ │ +│ CEL: Minimalizuj TC = Holding + Ordering + Shortage │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 4. Model EOQ (Economic Order Quantity) + +#### Założenia + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ MODEL EOQ - Klasyczny model Harrisa-Wilsona │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Założenia: │ +│ • Popyt deterministyczny, stały: D jednostek/rok │ +│ • Lead time = 0 (natychmiastowa dostawa) │ +│ • Brak braków (no stockouts) │ +│ • Stały koszt zamówienia: K │ +│ • Stały koszt utrzymania: h na jednostkę/rok │ +│ │ +│ Poziom zapasu: │ +│ Q │╲ │ +│ │ ╲ │ +│ │ ╲ │ +│ │ ╲ ╱╲ │ +│ │ ╲ ╱ ╲ │ +│ │ ╲ ╲ │ +│ 0 └──────────────────────────────→ t │ +│ │←── T ──→│←── T ──→│ │ +│ │ +│ Q = wielkość zamówienia │ +│ T = Q/D = cykl zamawiania │ +└─────────────────────────────────────────────────────────────────┘ +``` + +#### Formuła EOQ + +``` +Koszty roczne: + +Ordering cost = K × (D/Q) (D/Q zamówień rocznie) +Holding cost = h × (Q/2) (średni zapas = Q/2) + +TC(Q) = K·D/Q + h·Q/2 + +Minimalizacja: dTC/dQ = 0 + +-K·D/Q² + h/2 = 0 + + ┌──────────┐ + Q* = │ 2·K·D │ + │ ────── │ + │ h │ + └──────────┘ + +Optymalna wielkość zamówienia! +``` + +#### Przykład numeryczny + +``` +Dane: + D = 10,000 jednostek/rok + K = 100 PLN/zamówienie + h = 2 PLN/jednostkę/rok + +EOQ: + Q* = √(2 × 100 × 10,000 / 2) = √1,000,000 = 1,000 jednostek + +Cykl zamawiania: + T* = Q*/D = 1,000/10,000 = 0.1 roku ≈ 5 tygodni + +Liczba zamówień: + D/Q* = 10,000/1,000 = 10 zamówień/rok + +Koszt całkowity: + TC* = √(2·K·D·h) = √(2×100×10,000×2) = 2,000 PLN/rok + + (lub: TC = 100×10 + 2×500 = 1,000 + 1,000 = 2,000 PLN) +``` + +--- + +### 5. Model z punktem zamawiania (ROP) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ REORDER POINT (ROP) - uwzględnienie lead time │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Poziom zapasu: │ +│ │╲ ╱╲ │ +│ │ ╲ ╱ ╲ │ +│ │ ╲ ╱ ╲ │ +│ ROP │──────╲──────────╲────────────╲── │ +│ │ ╲ ╱ ╲ ╱ ╲ │ +│ SS│──────────╲──╱──────╲──────╱────── │ +│ 0 └────────────────────────────────→ t │ +│ │←L→│ │ +│ zamówienie dostawa │ +│ │ +│ ROP = d × L + SS │ +│ │ +│ gdzie: │ +│ d = średni popyt dzienny │ +│ L = lead time (czas dostawy) │ +│ SS = safety stock (zapas bezpieczeństwa) │ +│ │ +│ SS = z × σ_L │ +│ z = współczynnik (z tablic normalnych, np. 1.65 dla 95%) │ +│ σ_L = odchylenie std popytu w czasie L │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 6. Model (s, S) / (R, Q) + +| Model | Opis | +|-------|------| +| **(s, Q)** | Zamów Q gdy poziom spadnie do s | +| **(s, S)** | Zamów do poziomu S gdy spadnie do s | +| **(R, S)** | Co R okresów uzupełnij do S | +| **(R, s, S)** | Co R okresów: jeśli ≤ s, uzupełnij do S | + +``` +Model (s, S): + Poziom zapasu: + S │╲ + │ ╲ + │ ╲ + s │──────╲──────────────╲── + │ ╲ ╱ ╲ + │ ╲ ╱ ╲ + 0 └────────────────────────→ t + zamów dostawa + S-poziom + + Polityka: Gdy poziom ≤ s, zamów aby osiągnąć S +``` + +--- + +### 7. Vendor Managed Inventory (VMI) + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ VMI - Dostawca zarządza zapasami klienta │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ Tradycyjnie: │ +│ Klient → zamówienie → Dostawca → dostawa │ +│ │ +│ VMI: │ +│ Klient → dane o zapasach/sprzedaży → Dostawca │ +│ Dostawca → decyzja o uzupełnieniu → Klient │ +│ │ +│ Korzyści: │ +│ • Redukcja bullwhip effect │ +│ • Lepsza widoczność popytu │ +│ • Optymalizacja transportu │ +│ • Redukcja stockouts │ +│ │ +│ Przykłady: Walmart-P&G, 7-Eleven-dostawcy │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### 8. Wskaźniki efektywności + +| Wskaźnik | Formuła | Cel | +|----------|---------|-----| +| **Inventory Turnover** | COGS / Avg Inventory | Wyższy = lepszy | +| **Days of Inventory** | 365 / Turnover | Niższy = lepszy | +| **Fill Rate** | Zamówienia zrealizowane / Wszystkie | Wyższy | +| **Service Level** | P(brak stockout) | 95-99% | +| **GMROI** | Gross Margin / Avg Inventory | Wyższy | + +--- + +## 🧠 Mnemoniki + +### "EOQ = √(2KD/h)": +Economic Order Quantity - kwadrat z 2KD/h + +### "ROP = d×L + SS": +Reorder Point = popyt w lead time + safety stock + +### "Bullwhip = Bigger upstream": +Wahania rosną w górę łańcucha + +--- + +## ❓ Pytania dodatkowe + +### Q1: "Jak zredukować bullwhip effect?" +**Odpowiedź:** Współdzielenie informacji (POS data), VMI, CPFR (Collaborative Planning), redukcja lead times, stabilne ceny (EDLP), mniejsze partie (smaller batches), centralizacja decyzji. + +### Q2: "EOQ vs JIT?" +**Odpowiedź:** EOQ: optymalizuje koszty przy danych K, h. JIT (Just-In-Time): redukuje K (częste małe dostawy), redukuje zapasy (Q→0). JIT wymaga: niskich setup costs, niezawodnych dostawców, stabilnego popytu. + +### Q3: "Jak ustalić poziom zapasu bezpieczeństwa?" +**Odpowiedź:** SS = z × σ_L, gdzie z zależy od wymaganego service level (z=1.65 dla 95%, z=2.33 dla 99%). σ_L = σ_d × √L dla niezależnego popytu. Trade-off: wyższy SS = mniej stockouts, ale wyższe koszty. + +--- + +## 🎯 Kluczowe punkty + +1. **Bullwhip effect:** Amplifikacja wahań w łańcuchu +2. **Koszty:** Holding (h), Ordering (K), Shortage (p) +3. **EOQ:** Q* = √(2KD/h) +4. **ROP:** d×L + SS (uwzględnia lead time) +5. **VMI:** Dostawca zarządza zapasami klienta + +--- + +## 📖 Źródła + +1. Silver, Pyke, Peterson - "Inventory Management and Production Planning" +2. Chopra, Meindl - "Supply Chain Management" +3. Simchi-Levi - "Designing and Managing the Supply Chain" diff --git a/pytania/odpowiedzi/45-pytania-o-prace-magisterska.md b/pytania/odpowiedzi/45-pytania-o-prace-magisterska.md new file mode 100644 index 0000000..0e3e1ba --- /dev/null +++ b/pytania/odpowiedzi/45-pytania-o-prace-magisterska.md @@ -0,0 +1,568 @@ +# Pytania egzaminacyjne o pracę magisterską + +## Temat pracy +**"Porównanie wydajności i możliwości współczesnych silników gier komputerowych"** + +--- + +## 🎯 Pytanie 1: Cel i motywacja pracy + +### Pytanie +**"Jaki jest cel Pana pracy magisterskiej i dlaczego wybrano akurat temat porównania silników gier?"** + +### Odpowiedź wzorcowa + +Celem pracy jest **kompleksowe porównanie wydajności i możliwości współczesnych silników gier** (Unity i Unreal Engine), ze szczególnym uwzględnieniem ich wpływu na proces tworzenia gier oraz końcową jakość produktu. + +**Motywacja:** +1. **Praktyczna potrzeba** - wybór silnika to kluczowa decyzja wpływająca na cały cykl życia projektu +2. **Brak obiektywnych porównań** - większość istniejących materiałów ma charakter subiektywny lub marketingowy +3. **Dominacja rynkowa** - Unity i Unreal wspólnie obsługują >70% globalnego rynku gier +4. **Reprezentatywność architektur** - silniki reprezentują fundamentalnie różne podejścia (C# z GC vs C++ z ręcznym zarządzaniem pamięcią) + +**Praktyczne znaczenie:** +- Pomoc deweloperom w świadomym wyborze narzędzi +- Dostarczenie obiektywnych danych wydajnościowych +- Analiza praktycznych aspektów pracy z silnikami + +--- + +## 🎯 Pytanie 2: Metodologia badawcza + +### Pytanie +**"Jaką metodologię badawczą zastosowano w pracy? Dlaczego wybrano takie podejście?"** + +### Odpowiedź wzorcowa + +Zastosowano **metodologię mieszaną** łączącą podejście ilościowe i jakościowe: + +``` +┌────────────────────────────────────────────────────────────────┐ +│ METODOLOGIA BADAWCZA │ +├────────────────────────────────────────────────────────────────┤ +│ │ +│ ILOŚCIOWA (Quantitative): │ +│ ├── Testy wydajnościowe z NVIDIA Nsight Graphics │ +│ ├── Pomiary FPS, CPU, GPU, pamięci RAM/VRAM │ +│ └── Obiektywne metryki porównawcze │ +│ │ +│ JAKOŚCIOWA (Qualitative): │ +│ ├── 8 wywiadów pogłębionych z deweloperami │ +│ ├── Analiza dokumentacji i materiałów edukacyjnych │ +│ └── Doświadczenia z implementacji porównawczej │ +│ │ +│ TRIANGULACJA ŹRÓDEŁ: │ +│ └── Weryfikacja wniosków z wielu perspektyw │ +└────────────────────────────────────────────────────────────────┘ +``` + +**Uzasadnienie podejścia mieszanego:** +1. **Obiektywność** - testy wydajnościowe eliminują subiektywizm +2. **Kontekst praktyczny** - wywiady dostarczają perspektywy użytkowników +3. **Kompletność** - sama wydajność nie determinuje jakości narzędzia +4. **Wiarygodność** - triangulacja zwiększa pewność wniosków + +--- + +## 🎯 Pytanie 3: Wybór gry testowej + +### Pytanie +**"Dlaczego do testów wybrano gatunek bullet hell? Jakie to ma znaczenie dla wyników?"** + +### Odpowiedź wzorcowa + +**Gatunek bullet hell (danmaku)** to strzelanka, w której gracz mierzy się z setkami/tysiącami pocisków tworzących skomplikowane wzory. + +**Uzasadnienie wyboru:** + +| Aspekt | Dlaczego bullet hell? | +|--------|----------------------| +| **Intensywność** | Setki obiektów na ekranie → obciążenie renderingu | +| **Pamięć** | Ciągłe tworzenie/niszczenie pocisków → test GC vs ręczne | +| **Fizyka** | Kolizje gracz↔pociski → obciążenie systemu fizyki | +| **Skalowalność** | Łatwa kontrola obciążenia przez liczbę pocisków | +| **Prostota** | Prosta logika → fokus na wydajność, nie złożoność | +| **Reprezentatywność** | Typowa gra 2D indie → duży segment rynku | + +**Parametry gry testowej:** +- Czas rozgrywki: 90 sekund +- Maksymalnie ~500 jednoczesnych pocisków +- 3 typy przeciwników z różnymi wzorami +- Object pooling dla eliminacji alokacji runtime + +**Znaczenie dla wyników:** +Gatunek wymusza stosowanie technik optymalizacyjnych (object pooling, spatial partitioning), których efektywność może różnić się między silnikami, co pozwala na rzeczywiste porównanie. + +--- + +## 🎯 Pytanie 4: Różnice architektoniczne silników + +### Pytanie +**"Jakie są fundamentalne różnice architektoniczne między Unity a Unreal Engine?"** + +### Odpowiedź wzorcowa + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ PORÓWNANIE ARCHITEKTONICZNE UNITY vs UNREAL │ +├─────────────────────────────────────────────────────────────────┤ +│ │ +│ UNITY: UNREAL ENGINE: │ +│ ├─ Język: C# ├─ Język: C++ / Blueprints │ +│ ├─ Pamięć: Garbage Collector ├─ Pamięć: Ręczne/Smart ptr │ +│ ├─ Architektura: GameObject ├─ Architektura: Actor │ +│ │ └─ Component │ └─ Component │ +│ ├─ Natywne 2D: TAK ├─ Natywne 2D: NIE │ +│ ├─ Kod źródłowy: częściowo ├─ Kod źródłowy: pełny │ +│ └─ Rozmiar projektu: ~100 MB └─ Rozmiar projektu: ~1-2 GB │ +│ │ +│ FILOZOFIA: │ +│ Unity: Prostota, dostępność Unreal: Moc, kontrola │ +│ Mobile, indie AAA, fotorealizm │ +└─────────────────────────────────────────────────────────────────┘ +``` + +**Kluczowe implikacje:** + +1. **C# z GC vs C++:** + - Unity: szybszy rozwój, możliwe GC spikes + - Unreal: maksymalna wydajność, większa złożoność + +2. **Krzywa uczenia:** + - Unity: łagodna, przyjazna początkującym + - Unreal: stroma, wymaga znajomości C++ + +3. **Specjalizacja:** + - Unity: elastyczne, dobre dla różnych typów gier + - Unreal: zoptymalizowane pod FPS/AAA + +--- + +## 🎯 Pytanie 5: Hipotezy badawcze + +### Pytanie +**"Jakie hipotezy badawcze postawiono w pracy? Czy zostały potwierdzone?"** + +### Odpowiedź wzorcowa + +**Hipotezy badawcze:** + +1. **H1:** "Silniki komercyjne oferują lepszą wydajność niż rozwiązania open source" + - *Status:* Nie dotyczy bezpośrednio (oba badane silniki są komercyjne z darmowymi wersjami) + +2. **H2:** "Kompleksowość funkcjonalności wpływa negatywnie na wydajność" + - *Status:* Częściowo potwierdzona - Unreal z większą liczbą wbudowanych mechanizmów wymaga większych zasobów (rozmiar projektu, RAM), ale kompensuje to optymalizacjami niskopoziomowymi + +3. **H3:** "Łatwość użycia jest odwrotnie proporcjonalna do możliwości konfiguracji" + - *Status:* Potwierdzona - Unity z łagodniejszą krzywą uczenia oferuje mniejszą kontrolę nad niskopoziomowymi aspektami; Unreal wymaga większego wysiłku, ale daje pełny dostęp do kodu źródłowego + +**Wnioski z hipotez:** +- Trade-off między dostępnością a kontrolą jest realny +- Nie ma "lepszego" silnika - wybór zależy od kontekstu projektu + +--- + +## 🎯 Pytanie 6: Wyniki wywiadów z deweloperami + +### Pytanie +**"Jakie główne wnioski płyną z wywiadów z deweloperami gier?"** + +### Odpowiedź wzorcowa + +Przeprowadzono **8 wywiadów pogłębionych** z deweloperami o zróżnicowanym doświadczeniu (1-10+ lat). + +**Kluczowe wnioski:** + +``` +┌────────────────────────────────────────────────────────────────┐ +│ WNIOSKI Z WYWIADÓW │ +├────────────────────────────────────────────────────────────────┤ +│ │ +│ 1. DOKUMENTACJA: │ +│ Unity: "dogłębna, szczegółowa, z przykładami" │ +│ Unreal: "szkieletowa, praktycznie nieistniejąca" │ +│ │ +│ 2. MATERIAŁY EDUKACYJNE: │ +│ Unity: więcej, lepszej jakości (Brackeys) │ +│ Unreal: mniej, często nieaktualne, skupione na Blueprints │ +│ │ +│ 3. PRÓG WEJŚCIA: │ +│ Unity: łagodniejszy, C# jako język wysokopoziomowy │ +│ Unreal: wyższy, C++ rozszerzony o makra silnika │ +│ │ +│ 4. SPECJALIZACJA: │ +│ Unity: uniwersalne narzędzie │ +│ Unreal: zoptymalizowane pod FPS/gry akcji │ +│ │ +│ 5. KOMPILACJA: │ +│ Unity: problemy z czasem przy dużych projektach │ +│ Rozwiązanie: Assembly Definitions │ +└────────────────────────────────────────────────────────────────┘ +``` + +**Wspólne problemy:** +- Poradniki skupiają się na pojedynczych mechanikach, nie na architekturze +- Brak holistycznego podejścia do nauczania + +--- + +## 🎯 Pytanie 7: Narzędzia profilowania + +### Pytanie +**"Jakie narzędzia wykorzystano do testów wydajnościowych? Dlaczego akurat te?"** + +### Odpowiedź wzorcowa + +**Główne narzędzie: NVIDIA Nsight Graphics** + +**Uzasadnienie wyboru:** +1. **Niezależność** - zewnętrzne narzędzie, nie faworyzuje żadnego silnika +2. **Precyzja** - niskopoziomowe metryki GPU +3. **Porównywalność** - te same metryki dla obu silników +4. **Kompleksowość** - analiza całego pipeline'u renderowania + +**Mierzone metryki:** + +| Kategoria | Metryki | +|-----------|---------| +| **Rendering** | FPS, frame time, draw calls | +| **GPU** | Obciążenie, pamięć VRAM, shader performance | +| **CPU** | Obciążenie, czas na frame | +| **Pamięć** | RAM allocation, GC events (Unity) | + +**Dodatkowe narzędzia:** +- Wbudowane profilery Unity i Unreal (dla kontekstu wewnętrznego) +- Monitoring systemu operacyjnego + +--- + +## 🎯 Pytanie 8: Ograniczenia badań + +### Pytanie +**"Jakie są ograniczenia przeprowadzonych badań? Co można by ulepszyć?"** + +### Odpowiedź wzorcowa + +**Ograniczenia:** + +1. **Zakres testów:** + - Tylko jeden gatunek gry (bullet hell 2D) + - Brak testów 3D, VR, mobile + +2. **Środowisko:** + - Jedna konfiguracja sprzętowa + - Brak testów na różnych platformach + +3. **Wersje silników:** + - Wyniki specyficzne dla konkretnych wersji + - Silniki szybko się rozwijają + +4. **Próba wywiadów:** + - 8 respondentów (ograniczona reprezentatywność) + - Głównie rynek polski + +5. **Subiektywność implementacji:** + - Implementacja w obu silnikach przez jedną osobę + - Możliwa nieświadoma preferencja + +**Propozycje ulepszeń:** +- Testy na większej liczbie gatunków gier +- Badanie na różnych platformach (mobile, konsole) +- Większa próba do badań jakościowych +- Współpraca z ekspertami od każdego silnika + +--- + +## 🎯 Pytanie 9: Praktyczne rekomendacje + +### Pytanie +**"Jakie praktyczne rekomendacje dla deweloperów wynikają z pracy?"** + +### Odpowiedź wzorcowa + +``` +┌────────────────────────────────────────────────────────────────┐ +│ REKOMENDACJE WYBORU SILNIKA │ +├────────────────────────────────────────────────────────────────┤ +│ │ +│ WYBIERZ UNITY gdy: │ +│ ✓ Tworzysz grę 2D lub mobilną │ +│ ✓ Jesteś początkującym deweloperem │ +│ ✓ Masz ograniczony budżet/zespół (indie) │ +│ ✓ Znasz C# lub języki podobne │ +│ ✓ Priorytetem jest szybkość prototypowania │ +│ │ +│ WYBIERZ UNREAL gdy: │ +│ ✓ Tworzysz grę AAA lub fotorealistyczną │ +│ ✓ Potrzebujesz maksymalnej wydajności │ +│ ✓ Robisz grę FPS/akcji z widokiem pierwszej osoby │ +│ ✓ Masz doświadczenie w C++ │ +│ ✓ Potrzebujesz zaawansowanych narzędzi cinematycznych │ +│ │ +│ UWAGI OGÓLNE: │ +│ • Oba silniki są profesjonalne i dojrzałe │ +│ • Wybór zależy od kontekstu projektu, nie "lepszości" │ +│ • Warto znać oba dla elastyczności kariery │ +└────────────────────────────────────────────────────────────────┘ +``` + +--- + +## 🎯 Pytanie 10: Wkład naukowy pracy + +### Pytanie +**"Jaki jest wkład naukowy Pana pracy? Co wnosi do dziedziny?"** + +### Odpowiedź wzorcowa + +**Wkład naukowy:** + +1. **Metodologia porównawcza:** + - Zaproponowano systematyczne podejście do porównywania silników gier + - Połączenie metod ilościowych (benchmarki) i jakościowych (wywiady) + +2. **Obiektywne dane:** + - Dostarczono konkretnych wyników wydajnościowych zamiast subiektywnych opinii + - Dane z kontrolowanych warunków testowych + +3. **Perspektywa praktyka:** + - Wywiady z deweloperami dostarczają realnego kontekstu użytkowania + - Uzupełnienie luki między marketingiem a rzeczywistością + +4. **Dokumentacja różnic:** + - Szczegółowe opisanie różnic architektonicznych + - Praktyczne implikacje dla procesu deweloperskiego + +**Znaczenie dla branży:** +- Pomoc w świadomych decyzjach technologicznych +- Redukcja ryzyka błędnego wyboru narzędzi +- Materiał edukacyjny dla początkujących deweloperów + +--- + +## 🎯 Pytanie 11: Object pooling + +### Pytanie +**"Czym jest object pooling i dlaczego był kluczowy w pracy?"** + +### Odpowiedź wzorcowa + +**Object pooling** to technika optymalizacyjna polegająca na **ponownym wykorzystywaniu obiektów** zamiast ciągłego tworzenia i niszczenia. + +``` +┌────────────────────────────────────────────────────────────────┐ +│ OBJECT POOLING │ +├────────────────────────────────────────────────────────────────┤ +│ │ +│ BEZ POOLINGU: Z POOLINGIEM: │ +│ ┌─────┐ ┌─────┐ │ +│ │spawn│→ new Bullet() │spawn│→ pool.Get() │ +│ └─────┘ └─────┘ │ +│ ↓ ↓ │ +│ [gameplay] [gameplay] │ +│ ↓ ↓ │ +│ ┌─────┐ ┌─────┐ │ +│ │die │→ destroy + GC │die │→ pool.Return() │ +│ └─────┘ └─────┘ │ +│ │ +│ Problemy: Korzyści: │ +│ • Alokacje każdą klatkę • Zero alokacji runtime │ +│ • GC spikes (Unity) • Brak GC spikes │ +│ • Fragmentacja pamięci • Stały koszt pamięci │ +└────────────────────────────────────────────────────────────────┘ +``` + +**Znaczenie dla pracy:** +- Bullet hell generuje setki pocisków/sekundę +- Bez poolingu → ciągłe alokacje → GC spikes w Unity +- Pooling pozwala na **uczciwe porównanie** silników (eliminuje narzut GC) +- Technika stosowana w obu implementacjach + +--- + +## 🎯 Pytanie 12: Różnice w zarządzaniu pamięcią + +### Pytanie +**"Jak różni się zarządzanie pamięcią w Unity i Unreal Engine? Jakie to ma konsekwencje?"** + +### Odpowiedź wzorcowa + +``` +┌────────────────────────────────────────────────────────────────┐ +│ ZARZĄDZANIE PAMIĘCIĄ: UNITY vs UNREAL │ +├────────────────────────────────────────────────────────────────┤ +│ │ +│ UNITY (C# / .NET): │ +│ ├─ Garbage Collector (GC) - automatyczne zwalnianie │ +│ ├─ Zalety: │ +│ │ • Brak memory leaks z definicji │ +│ │ • Prostsze programowanie │ +│ │ • Bezpieczeństwo typów │ +│ ├─ Wady: │ +│ │ • GC spikes (nieprzewidywalne pauzy) │ +│ │ • Mniejsza kontrola nad alokacją │ +│ │ • Boxing/unboxing overhead │ +│ └─ Mitygacja: object pooling, struct zamiast class │ +│ │ +│ UNREAL (C++): │ +│ ├─ Ręczne zarządzanie + smart pointers │ +│ ├─ Zalety: │ +│ │ • Pełna kontrola nad pamięcią │ +│ │ • Przewidywalna wydajność │ +│ │ • Brak GC spikes │ +│ ├─ Wady: │ +│ │ • Ryzyko memory leaks │ +│ │ • Dangling pointers │ +│ │ • Większa złożoność kodu │ +│ └─ Mechanizmy UE: TSharedPtr, TWeakPtr, garbage collection │ +│ dla UObject │ +└────────────────────────────────────────────────────────────────┘ +``` + +**Konsekwencje praktyczne:** +- Unity: łatwiejsze dla początkujących, ale wymaga uwagi przy wydajności +- Unreal: wymaga doświadczenia, ale daje przewidywalność + +--- + +## 🎯 Pytanie 13: Kryteria porównania + +### Pytanie +**"Według jakich kryteriów porównywano silniki?"** + +### Odpowiedź wzorcowa + +**Trzy główne kategorie kryteriów:** + +### 1. Wydajność +- Szybkość renderowania (FPS) +- Zużycie pamięci RAM +- Obciążenie procesora +- Zużycie pamięci karty graficznej +- Czas ładowania scen + +### 2. Funkcjonalność +- Wsparcie dla różnych typów renderingu +- Systemy fizyki +- Systemy audio +- Wsparcie dla VR/AR +- Możliwości skryptowania + +### 3. Użyteczność +- Intuicyjność interfejsu +- Jakość dokumentacji +- Dostępność tutoriali +- Wsparcie społeczności +- Czas potrzebny na naukę (krzywa uczenia) + +**Dlaczego te kryteria:** +- Pokrywają wszystkie aspekty istotne dla deweloperów +- Możliwe do zmierzenia (ilościowe) lub oceny (jakościowe) +- Odpowiadają realnym potrzebom przy wyborze silnika + +--- + +## 🎯 Pytanie 14: Przyszłość badań + +### Pytanie +**"Jakie kierunki dalszych badań Pan proponuje?"** + +### Odpowiedź wzorcowa + +**Propozycje dalszych badań:** + +1. **Rozszerzenie zakresu testów:** + - Testy na grach 3D (różne gatunki) + - Porównanie wydajności VR/AR + - Testy na platformach mobilnych i konsolach + +2. **Uwzględnienie innych silników:** + - Godot (open source, rosnąca popularność) + - CryEngine, Amazon Lumberyard + - Własne silniki studiów AAA + +3. **Badania longitudinalne:** + - Śledzenie rozwoju silników w czasie + - Porównanie wersji (Unity 2020 vs 2025) + +4. **Pogłębienie badań jakościowych:** + - Większa próba deweloperów + - Badania w różnych krajach/regionach + - Studium przypadków konkretnych produkcji + +5. **Aspekty ekonomiczne:** + - Koszty licencji i royalties + - ROI przy wyborze silnika + - Czas rozwoju projektu + +--- + +## 🎯 Pytanie 15: Blueprints vs C++ w Unreal + +### Pytanie +**"Jakie są różnice między programowaniem w Blueprints a C++ w Unreal Engine?"** + +### Odpowiedź wzorcowa + +``` +┌────────────────────────────────────────────────────────────────┐ +│ BLUEPRINTS vs C++ w UNREAL ENGINE │ +├────────────────────────────────────────────────────────────────┤ +│ │ +│ BLUEPRINTS: C++: │ +│ ├─ Wizualne programowanie ├─ Tradycyjny kod │ +│ ├─ Drag & drop węzłów ├─ Tekstowe pisanie │ +│ ├─ Szybkie prototypowanie ├─ Maksymalna wydajność │ +│ ├─ Dla designerów/artystów ├─ Dla programistów │ +│ ├─ Wolniejsze wykonanie ├─ Kompilacja do natywnego │ +│ └─ Trudniejsze przy złożoności └─ Pełna kontrola │ +│ │ +│ TYPOWE ZASTOSOWANIE: │ +│ Blueprints: UI, proste mechaniki, prototypy │ +│ C++: core gameplay, AI, systemy krytyczne wydajnościowo │ +│ │ +│ BEST PRACTICE: Hybrydowe podejście │ +│ └─ Implementacja w C++, ekspozycja do Blueprints │ +└────────────────────────────────────────────────────────────────┘ +``` + +**Wnioski z wywiadów:** +- Poradniki często skupiają się na Blueprints +- Profesjonalne produkcje głównie C++ +- Blueprints dobre do nauki konceptów silnika + +--- + +## 📋 Lista wszystkich pytań (podsumowanie) + +1. Cel i motywacja pracy +2. Metodologia badawcza +3. Wybór gry testowej (bullet hell) +4. Różnice architektoniczne silników +5. Hipotezy badawcze +6. Wyniki wywiadów z deweloperami +7. Narzędzia profilowania +8. Ograniczenia badań +9. Praktyczne rekomendacje +10. Wkład naukowy pracy +11. Object pooling +12. Różnice w zarządzaniu pamięcią +13. Kryteria porównania +14. Przyszłość badań +15. Blueprints vs C++ w Unreal + +--- + +## 🧠 Mnemoniki dla obrony + +### "MWUK" - Metodologia: +**M**ieszana, **W**ywiady, **U**nity vs Unreal, **K**ryterium porównania + +### "BH = Benchmark Heaven": +**B**ullet **H**ell = idealny test (dużo obiektów, kolizji, alokacji) + +### "Unity = Easy, Unreal = Elite": +Unity: łatwiejsze, Unreal: dla zaawansowanych + +### "C# GC, C++ MC": +C# = Garbage Collection, C++ = Manual Control diff --git a/pytania/pytania_raw.txt b/pytania/pytania_raw.txt new file mode 100644 index 0000000..26ccd0c --- /dev/null +++ b/pytania/pytania_raw.txt @@ -0,0 +1,113 @@ +Pytania na egzamin magisterski specjalności ISY +Luty 2022 +Lp. Pytanie Kod +przedmiotu +Część podstawowa – obowiązkowa +1. Porównać "siłę wyrazu" automatu skończonego, automatu ze stosem oraz maszyny Turinga. Jakie klasy języków +rozpoznaje każdy z nich? +AISDI +2. Omówić i porównać algorytmy najkrótszej ścieżki wskazując ich kluczowe właściwości i logikę budowy: +Dijkstry, Belmana-Forda, A*. +AISDI +3. Omówić zagadnienia redundancji i normalizacji w relacyjnej bazie danych oraz wynikające z tego wymagania. BD2 +4. Dlaczego baza danych stanowi dobry fundament do budowy wielu systemów informatycznych? BD2 +5. Omówić główne kategorie elementów biblioteki STL. Jaka jest ich rola i wzajemne powiązania? Odpowiedź +uzasadnić na przykładach. +PROI +6. Omówić metody reużywalności kodu i struktur danych w obiektowych językach programowania. PROI +7. Które serwery DNS najwięcej zyskują dzięki buforowaniu zapytań (caching) w serwerach rekursywnych? Jakie +znasz rodzaje serwerów DNS? +SKM +8. Jaki jest cel uzgadniania trójetapowego (three way handshake) w protokole TCP? Jaka jest interpretacja +numerów sekwencyjnych i potwierdzenia? Jaka jest wartość początkowa numeru sekwencyjnego? +SKM +9. Procesy i wątki w systemie operacyjnym. Omówić budowę, szybkość działania i zakres zastosowania. +Przedstawić problemy i możliwości komunikacji i synchronizacji. +SOI +10. Scharakteryzować problemy i mechanizmy zarządzania pamięcią. Porównać cechy i przeznaczenie +mechanizmów stronicowania i segmentacji. +SOI +11. Scharakteryzować standardy i narzędzia do modelowania procesów biznesowych. WSYZ +12. Przedstawić sieciowe modele optymalizacji stosowane w systemach zarządzania. Omówić ich właściwości. WSYZ +Część zaawansowana +13. Omówić szczegółowo teorie, definicje, standardy i narzędzia wykorzystywane przy projektowaniu i +implementacji systemów opartych na koncepcji agenta i aktora. +AASD +14. Wymienić i szczegółowo opisać wybrane algorytmy i metody wykorzystywane w systemach wieloagentowych i +aktorowych. +AASD +15. Omówić metody modelowania architektury systemów informatycznych. Przedstawić cele i metody modelowania +architektury. +AIS +16. Czemu służą wzorce architektoniczne? Jak powstają? Jak są katalogowane? Omówić przykładowe wzorce +architektoniczne. +AIS +17. Przedstawić warunki konieczne i dostateczne optymalności różniczkowalnych zadań optymalizacji bez +ograniczeń i z ograniczeniami oraz warunki regularności i omówić metody poszukiwania rozwiązań zadań +optymalizacji nieliniowej. +AMO +18. Omówić metody rozwiązywania zadań liniowych i kwadratowych optymalizacji. AMO +19. Przedstawić metody wyznaczania cech (parametryzacji) sygnału mowy: MFCC (cechy mel-cepstralne) i LPC +(cechy według liniowej predykcji). +EASAR +20. Przedstawić klasyczną metodę rozpoznawania mowy opartą o HMM (Ukryte Modele Markowa). Porównać ją z +metodami korzystającymi z głębokich sieci neuronowych. +EASAR +21. Jak wykorzystuje się agenta upostaciowionego do specyfikacji sterowników robotów? ERPM +22. Omówić specjalizowane języki programowania robotów. Uwypuklić ich klasyfikację. ERPM +23. Przedstawić koncepcję i przeznaczenie zegarów logicznych i wektorów stempli czasowych. ERSMS +24. Omówić silne i słabe modele spójności danych w środowisku rozproszonym. ERSMS +25. Gdzie znajdują zastosowania zadania programowania matematycznego całkowitoliczbowego i jak można je +rozwiązywać? Omówić wybraną metodę dokładną, wyjaśnić dla jakich praktycznych problemów ma ona +zastosowanie i co może wpływać na jej efektywność. +MOD +26. Scharakteryzować informatyczne narzędzia optymalizacji dyskretnej. Jakie są warunki i wymagania, jakie +możliwości oraz trudności wiążą się ze stosowaniem gotowych narzędzi. +MOD +27. Dlaczego jakość modelu danych jest krytycznie ważnym czynnikiem jakości projektu informatycznego? MODA +28. Omówić typowe fazy ewolucji modelu danych i pożądane cechy modelu w każdej z faz. MODA +29. Oszacować ilościowo przyśpieszenie wykonania programu sekwencyjnego z fragmentami równoległymi na +maszynie wielordzeniowej. Co osłabia to ograniczenie? +PORR +30. Omówić metody oraz typowe problemy w modelowaniu matematycznym dla problemów decyzyjnych i +optymalizacyjnych. +MOM +Strona 1 z 2 +31. Wyjaśnić główne zagadnienia modelowania matematycznego w systemach decyzyjnych z wykorzystaniem pojęć +(nie)wypukłości i (nie)liniowości. +MOM +32. Podać definicję komunikacji synchronicznej i asynchronicznej oraz blokującej i nieblokującej. Jak uniknąć +zakleszczenia, gdy dwa symetryczne procesy (np. realizujące algorytm iteracyjny Jacobiego) mają w kodzie +następujące po sobie wywołania funkcji wysyłającej komunikat do partnera i odbierającej komunikat wysłany +przez niego? +PORR +33. Scharakteryzować model przesyłania komunikatów publikuj-subskrybuj oraz przykładowe rozwiązania +techniczne wykorzystujące ten model +PSD +34. Scharakteryzować rozwiązania analityczne działające w na danych o charakterze strumieniowym. PSD +35. Na czym polega specyfika modelowania matematycznego układów cyber-fizycznych? Podać przykłady +współpracy agentów w sieci i problemów w osiąganiu pożądanego zachowania układu. +SIU +36. Omówić ogólny algorytm, elementy składowe oraz własności uczenia się ze wzmocnieniem. SIU +37. Porównać podstawowe modele sieci złożonych. Jak odpowiadają one własnościom rzeczywistych sieci? TASS +38. Porównać metody projekcji grafów dwudzielnych. Przedstawić ich użyteczność w grupowaniu dokumentów +tekstowych. +TASS +39. Scharakteryzować problem segmentacji obrazu. Przedstawić podstawowe strategie i algorytmy segmentacji przy +użyciu pomocą metod klasycznych oraz sieci neuronowych. +TWM +40. Opisać problem detekcji obiektów w obrazach. Przedstawić podstawowe strategie i algorytmy detekcji przy +użyciu metod klasycznych oraz sieci neuronowych. Jak skonstruować detektor obiektów dysponując istniejącym +klasyfikatorem tych obiektów? +TWM +41. Przedstawić metody interaktywne wspomagania decyzji w warunkach ryzyka. WDWR +42. Scharakteryzować relacje dominacji stochastycznej pierwszego i drugiego rzędu. Jak mogą być użyte w +modelach wyboru w warunkach ryzyka? +WDWR +43. Jakie cechy zadań szeregowania wykorzystuje się do ich klasyfikacji? Omówić przykładową metodę dla +wybranego problemu szeregowania. +ZBOP +44. Jakie problemy wiążą się z zarządzaniem zapasami w łańcuchu dostaw? Omówić przykładowy model +zarządzania zapasami w łańcuchu dostaw. +ZBOP +Strona 2 z 2 \ No newline at end of file