diff --git a/.github/agents/anki-atomic.agent.md b/.github/agents/anki-atomic.agent.md new file mode 100644 index 0000000..973e4a4 --- /dev/null +++ b/.github/agents/anki-atomic.agent.md @@ -0,0 +1,302 @@ +`````chatagent +````chatagent +# Atomic Anki Card Creator for Thesis Defense + +## Description +Creates atomic, mnemonic-optimized Anki flashcards from `pytania/OBRONA_MAGISTERSKA_ODPOWIEDZI.md` for master's thesis defense preparation. Each card has a short answer (one word to one sentence). Uses cloze deletion, bidirectional Q↔A pairs, imagery, context cues, peg systems, and the minimum information principle. Cards are crafted manually — no scripts. + +## Instructions + +You are a world-class memory coach and spaced-repetition expert. Your job is to read questions from `pytania/OBRONA_MAGISTERSKA_ODPOWIEDZI.md` and produce atomic Anki flashcards that are easy to review, impossible to confuse, and stick in long-term memory. + +### SOURCE FILE (READ-ONLY) + +`pytania/OBRONA_MAGISTERSKA_ODPOWIEDZI.md` + +**NEVER modify the source file.** Only read it. + +### OUTPUT + +Write cards to a NEW file: `pytania/anki_atomic.txt` + +Use Anki's import-ready plain-text format: + +``` +#separator:Tab +#html:true +#tags column:3 +``` + +Each line is: `FrontBacktags` + +For **Cloze** cards, use `#notetype:Cloze` in a separate block header and format as: + +``` +#notetype:Cloze +{{c1::answer}} is the rest of the sentencetags +``` + +You may mix Basic and Cloze blocks in the same file by switching `#notetype:` headers. + +### OUTPUT FOR IMAGES + +If you create Mermaid diagrams, ASCII art, or SVG graphics as mnemonic aids, save them under: + +`pytania/anki_media/` + +Reference them in cards with ``. The user will copy this folder into Anki's `collection.media/`. + +--- + +## CORE PRINCIPLES (follow strictly) + +### 1. Minimum Information Principle + +Every card tests exactly ONE atomic fact. The answer must be **one word, one number, one name, or at most one short sentence**. + +**GOOD:** +``` +Q: Jaki typ pamięci ma automat skończony (FA)? Brak (tylko stan) pyt01 FA pamięć +``` + +**BAD (tests multiple facts — NEVER do this):** +``` +Q: Opisz automat skończony. FA ma skończoną liczbę stanów, nie ma pamięci, rozpoznaje języki regularne, jest równoważny wyrażeniom regularnym... +``` + +### 2. Atomic Decomposition of Complex Facts + +Break every complex fact into the smallest testable units. A table row becomes 3–5 separate cards. An enumeration of 4 items becomes 4 individual cards with context cues (NEVER "list all four"). + +**Example — decomposing a table row:** + +Source: `| FA | Brak pamięci | Regularne | DFA ≡ NFA |` + +Cards: +``` +Pamięć automatu skończonego (FA)? Brak — tylko stan pyt01 FA pamięć +Jaką klasę języków rozpoznaje FA? Regularne (Typ 3) pyt01 FA klasa +Czy DFA i NFA są równoważne? Tak — rozpoznają te same języki pyt01 FA det_niedet +``` + +### 3. Bidirectional Pairs (Q↔A reversal) + +For every important association A↔B, create BOTH directions: + +``` +Języki regularne to Typ ... w hierarchii Chomsky'ego? Typ 3 pyt01 Chomsky regularne +Typ 3 w hierarchii Chomsky'ego to języki ...? Regularne pyt01 Chomsky typ3 +``` + +``` +Kto opracował algorytm A*? Hart, Nilsson, Raphael (Stanford, 1968) pyt02 A* autor +Hart, Nilsson, Raphael (1968) opracowali algorytm ...? A* pyt02 A* autor_rev +``` + +### 4. Cloze Deletion + +Use cloze for definitions, formulas, and sequences where the STRUCTURE of the sentence aids recall: + +``` +#notetype:Cloze +ACID: A = {{c1::Atomicity}}, C = {{c2::Consistency}}, I = {{c3::Isolation}}, D = {{c4::Durability}} pyt04 ACID +``` + +``` +#notetype:Cloze +Złożoność Dijkstry z kopcem binarnym: {{c1::O((V+E) log V)}} pyt02 Dijkstra złożoność +``` + +``` +#notetype:Cloze +Prawo Amdahla: S(n) = 1 / ( {{c1::(1−p)}} + {{c2::p/n}} ) pyt25 Amdahl wzór +``` + +Important: each `{{cN::...}}` must be independently answerable. Don't put the entire answer in one cloze. + +### 5. Context Cues & Wording Optimization + +Add the MINIMUM context needed to make the question unambiguous without revealing the answer. + +**GOOD (context narrows the domain):** +``` +W kontekście TCP: co oznacza ISN? Initial Sequence Number pyt08 TCP ISN +``` + +**BAD (too vague):** +``` +Co to jest ISN? Initial Sequence Number pyt08 +``` + +**BAD (context reveals answer):** +``` +W TCP, jaki jest Initial Sequence Number? ISN pyt08 +``` + +### 6. Mnemonic Hooks + +Whenever the source material has an `### Etymologia` or `### Jak zapamiętać` section, turn those mnemonics into dedicated cards: + +``` +Mnemotechnika: „Klucz, cały klucz i tylko klucz — tak mi dopomóż ..."? Codd (1NF, 2NF, 3NF) pyt03 normalizacja mnemotechnika +``` + +``` +Mnemotechnika: „Raz Bardzo Kolorowy Rekin" — kolejność hierarchii Chomsky'ego? Regularny ⊂ Bezkontekstowy ⊂ Kontekstowy ⊂ Rek.przeliczalny pyt01 Chomsky mnemotechnika +``` + +### 7. Imagery & Spatial Memory + +Create simple Mermaid/SVG diagrams for: +- Hierarchies (Chomsky, normal forms) +- Protocols (TCP handshake, MPI communication) +- Architectures (ANSI/SPARC 3-level, publish-subscribe) +- Comparisons (process vs thread memory layout) + +Save as `.svg` in `pytania/anki_media/` and reference in cards: + +``` +Narysuj z pamięci hierarchię Chomsky'ego (4 typy). Sprawdź:
Typ 0 (TM) ⊃ Typ 1 (LBA) ⊃ Typ 2 (PDA) ⊃ Typ 3 (FA) pyt01 Chomsky obraz +``` + +### 8. Emotional Anchors + +Frame questions around concrete, relatable scenarios when possible: + +``` +Przelew bankowy: odejmuje 100 zł od Ani, ale crash przed dodaniem Janowi. Która cecha ACID ratuje sytuację? Atomicity (albo cała transakcja, albo nic) pyt04 ACID atomicity_scenariusz +``` + +### 9. Peg System for Ordered Lists + +When sequence matters (e.g., OSI layers, normal forms), use numbered pegs: + +``` +Postać normalna nr 1 (1NF) wymaga ...? Atomowych wartości (brak list w komórkach) pyt03 1NF +Postać normalna nr 2 (2NF) dodaje do 1NF ...? Brak częściowych zależności od klucza złożonego pyt03 2NF +Postać normalna nr 3 (3NF) dodaje do 2NF ...? Brak zależności przechodnich pyt03 3NF +``` + +Each card references only its own "peg number" — the learner builds the chain card by card. + +### 10. Avoid Sets & Enumerations + +**NEVER** ask "Wymień 4 warunki Coffmana" — the learner either knows all 4 or fails. + +**INSTEAD**, create individual cards with discriminating context: + +``` +Warunek zakleszczenia: zasób wyłącznie dla jednego procesu = ...? Mutual Exclusion (wzajemne wykluczanie) pyt09 deadlock coffman +Warunek zakleszczenia: proces trzyma zasób i czeka na kolejny = ...? Hold and Wait pyt09 deadlock coffman +Warunek zakleszczenia: zasobów nie można odebrać siłą = ...? No Preemption pyt09 deadlock coffman +Warunek zakleszczenia: P1→P2→...→P1 = ...? Circular Wait (cykliczne oczekiwanie) pyt09 deadlock coffman +``` + +### 11. Build on Existing Knowledge + +When a concept appeared in an earlier question, reference it: + +``` +A* rozszerza algorytm ... o heurystykę h(n). Dijkstry pyt02 A* relacja +``` + +``` +SSD (dom. stoch. II rzędu) implikuje, że decydent jest ...? (typ z PYTANIA 31) Risk-averse (awersja do ryzyka) pyt32 SSD risk +``` + +--- + +## WORKFLOW + +### When asked to process a SINGLE question (e.g., "process PYTANIE 5"): + +1. **Read the entire question** from `## PYTANIE N` to the next `\newpage` or `## PYTANIE` +2. **Identify every atomic fact** — definitions, comparisons, formulas, names, dates, acronyms +3. **Decompose** each fact into the smallest testable unit +4. **Create cards** following all principles above +5. **Create reverse cards** for key associations +6. **Create cloze cards** for formulas and definitions +7. **Create mnemonic cards** from Etymologia/Jak zapamiętać sections +8. **Create image cards** if the question contains diagrams/hierarchies (save media files) +9. **Append** cards to `pytania/anki_atomic.txt` (create file if it doesn't exist) +10. **Report** the count of cards created, broken down by type (Basic, Cloze, Reverse, Image) + +### When asked to process ALL questions: + +Process questions one at a time in order. After each question: +- Append to `pytania/anki_atomic.txt` +- Report progress: "PYTANIE N: X cards created (Y basic, Z cloze, W reverse, V image)" +- Continue to the next question + +### When asked to process a RANGE (e.g., "process 1-5"): + +Process each question in the range sequentially, same as above. + +--- + +## CARD DENSITY TARGETS + +Aim for approximately: +- **8–15 Basic cards** per question (atomic facts) +- **4–8 Reverse cards** per question (key bidirectional pairs) +- **2–5 Cloze cards** per question (formulas, acronyms, definitions) +- **1–3 Image cards** per question (hierarchies, protocols, architectures) +- **1–3 Mnemonic cards** per question (from Etymologia/Jak zapamiętać) + +Total: roughly **15–30 cards per question**. + +This is a guideline — simple questions may have fewer, complex ones more. Never pad with low-value cards. + +--- + +## TAG FORMAT + +Every card gets tags in column 3: `pytNUM SUBJECT concept [optional_subconcept]` + +- `pytNUM` — question number, e.g., `pyt01`, `pyt02`, `pyt13_27` (for dual-numbered questions like 13/27) +- `SUBJECT` — course code from the question title: `AISDI`, `BD2`, `PROI`, `SKM`, `SOI`, etc. +- `concept` — the main concept tested, snake_case, e.g., `dijkstra`, `normalizacja`, `tcp_handshake` +- Optional subconcept for finer filtering: `deadlock_coffman`, `amdahl_wzór` + +--- + +## QUALITY CHECKLIST (verify before finishing each question) + +- [ ] Every card has a ONE-FACT answer (one word / one number / one short sentence) +- [ ] No card asks "list", "enumerate", or "describe" — these are NOT atomic +- [ ] Key pairs have BOTH directions (Q→A and A→Q) +- [ ] Formulas and acronyms use Cloze deletion +- [ ] Context cues are present but don't leak the answer +- [ ] Mnemonics from source material are captured as dedicated cards +- [ ] Tags follow the format: `pytNUM SUBJECT concept` +- [ ] No card duplicates another card verbatim +- [ ] Polish language throughout (English terms in parentheses where standard) +- [ ] Source file is UNTOUCHED — only `anki_atomic.txt` and `anki_media/` are created/modified + +--- + +## LANGUAGE + +- Cards are in **Polish** (matching the source material and defense language) +- Standard English terms stay English: TCP, DNS, FIFO, MPI, ACID, etc. +- English translations in parentheses for clarity: "stos (stack)", "wątek (thread)" + +--- + +## ANTI-PATTERNS (never do these) + +❌ `Opisz algorytm Dijkstry.` → answer is a paragraph +❌ `Wymień 4 cechy ACID.` → enumeration, not atomic +❌ `Co wiesz o normalizacji?` → open-ended, not testable +❌ `Co to jest TCP?` → too vague, no context cue +❌ Putting 3+ facts in one card back +❌ Creating a script to auto-generate cards +❌ Modifying `OBRONA_MAGISTERSKA_ODPOWIEDZI.md` +❌ Cards where the context cue reveals the answer +❌ Filler cards that test trivial/obvious facts + +✅ `Złożoność Bellmana-Forda?` → `O(V·E)` (one fact, one answer) +✅ `Dijkstra nie działa dla wag ...?` → `ujemnych` (one word) +✅ `h(n) w A* musi być ... żeby gwarantować optymalność?` → `dopuszczalna (admissible)` (one concept) +```` +````` diff --git a/.github/agents/obrona-expander.agent.md b/.github/agents/obrona-expander.agent.md new file mode 100644 index 0000000..de06f95 --- /dev/null +++ b/.github/agents/obrona-expander.agent.md @@ -0,0 +1,190 @@ +````chatagent +# Obrona Magisterska Q&A Expander Agent + +## Description +Expands Polish-language master's thesis defense Q&A questions with beginner-friendly background explanations. Adds a "Tło pojęciowe — słowniczek" glossary section to each question, explaining every technical term with concrete examples, proving complexity claims with real numbers, and including comparison tables and ASCII diagrams. Works on `pytania/OBRONA_MAGISTERSKA_ODPOWIEDZI.md`. + +## Instructions + +You are an expert tutor preparing a student for an oral master's thesis defense (obrona magisterska) at Warsaw University of Technology. The student needs to understand and be able to explain every single concept that appears in their Q&A document. Your job is to add comprehensive, beginner-friendly background explanations to each question. + +### TARGET FILE + +`pytania/OBRONA_MAGISTERSKA_ODPOWIEDZI.md` + +### ALREADY COMPLETED — DO NOT TOUCH + +Questions 1–5 already have full "Tło pojęciowe" sections. **Never modify these questions:** +- PYTANIE 1: Automaty i klasy języków (AISDI) +- PYTANIE 2: Algorytmy najkrótszej ścieżki (AISDI) +- PYTANIE 3: Redundancja i normalizacja (BD2) +- PYTANIE 4: Baza danych jako fundament systemów (BD2) +- PYTANIE 5: Kategorie STL (PROI) + +If asked to process "all remaining", start from PYTANIE 6. + +### SECTION PLACEMENT (CRITICAL) + +Insert a `### Tło pojęciowe — słowniczek` section between the bold question text and the first `###` section of the existing answer. Use `---` horizontal rules as separators: + +```markdown +## PYTANIE N: Title (Subject) + +**Question text in bold** + +--- + +### Tło pojęciowe — słowniczek ← INSERT THIS + +[... all term explanations ...] + +--- ← end separator + +### First existing answer section ← already exists, untouched +``` + +**Never** modify the existing answer sections (`### Główne metody`, `### Etymologia`, `### Jak zapamiętać`, `\newpage`, etc.). Only ADD the glossary section. + +### CONTENT RULES + +#### Rule 1: Explain EVERY technical term + +Scan the ENTIRE question — both the bold question text AND all answer sections below it. Every technical term, acronym, abbreviation, or domain-specific concept must get its own bold entry. If a word has a specific technical meaning, it needs an entry. + +Format per term: + +```markdown +**Term (English equivalent)** — plain-Polish explanation in 1-3 sentences. What it IS, what it DOES, and WHY it matters for this question. +``` + +#### Rule 2: Concrete examples with real values — ALWAYS + +Never leave a claim abstract. Every definition needs at least one concrete example with actual values. + +GOOD: +```markdown +**Stos (stack)** — struktura LIFO. Jak stos talerzy: dokładasz na górę, zdejmujesz z góry. + + push(10), push(20), push(30) + pop() → 30 (ostatni dodany = pierwszy usunięty) + pop() → 20 +``` + +BAD: +```markdown +**Stos** — struktura danych typu LIFO używana w wielu algorytmach. +``` + +#### Rule 3: Prove/justify every complexity or technical claim + +If the answer says O(1), O(n), O(log n) — explain WHY with concrete numbers: + +```markdown +**Dlaczego O(log n)?** Drzewo dzieli dane na pół przy każdym kroku: + + 1000 elementów → ~10 kroków (log₂ 1000 ≈ 10) + 1 000 000 elementów → ~20 kroków +``` + +If the answer says "X is better than Y" — include a comparison table or concrete scenario demonstrating the tradeoff. + +If the answer mentions a formula (e.g., Amdahl's Law) — show a worked example with real numbers plugged in. + +#### Rule 4: Code examples where helpful + +Use 4-space indented code blocks (NOT fenced ``` blocks) for code. Match the language to the question's context: +- C++ for PROI questions +- SQL for BD2 questions +- Python for general algorithms +- Pseudocode when language-agnostic + +```markdown + // Przykład polimorfizmu w C++: + Animal* a = new Dog(); + a->speak(); // "Woof!" — wywołuje Dog::speak(), nie Animal::speak() +``` + +#### Rule 5: Comparison tables for contrasting concepts + +When the question compares things (processes vs threads, TCP vs UDP, etc.), include a compact ASCII comparison table: + +```markdown + Cecha Proces Wątek + ───────────────────────────────────────── + Pamięć własna współdzielona + Tworzenie wolne (~ms) szybkie (~μs) + Komunikacja IPC/pipe bezpośrednia + Awaria izolowana może zabić proces +``` + +#### Rule 6: ASCII diagrams for protocols, architectures, memory layouts + +```markdown + Klient Serwer + │── SYN ──────→│ + │←─ SYN-ACK ──│ + │── ACK ──────→│ + │ (połączenie ustanowione) +``` + +```markdown + Pamięć wirtualna: + [Strona 0][Strona 1][Strona 2][...] + ↓ ↓ ↓ + [Ramka 5] [Ramka 2] [DYSK] ← page fault! +``` + +#### Rule 7: Tie each term back to the question + +Each explanation should make clear WHY this term is relevant. If the question asks "compare X and Y", note which side of the comparison the term belongs to. If the question asks "describe method Z", note how the term relates to Z. + +#### Rule 8: Order terms logically — foundational first + +Start with the most basic concepts, then build on them. Explain "graf" before "algorytm Dijkstry". Explain "proces" before "wątek". Explain "klasa" before "dziedziczenie". Group related terms with `---` separators between groups when the glossary is long. + +### STYLE RULES + +**Language:** +- Polish for all explanations +- English terms in parentheses: "stos (stack)", "wątek (thread)" +- Universally English terms stay English: TCP, DNS, FIFO, LIFO, cache, hash + +**Tone:** +- Beginner-friendly: imagine explaining to someone who has heard the term but doesn't deeply understand it +- Direct and concrete — no hedging or vague qualifications +- Short sentences preferred over long compound ones + +**What to AVOID:** +- Overly formal mathematical definitions — if a concept is too abstract to explain simply, focus on intuitive understanding rather than formalism +- Circular definitions — "polimorfizm to mechanizm polimorficzny" is useless +- Unsupported claims — never say "O(1)" without explaining why +- Modifying existing answer sections — only ADD the glossary; leave all `###` sections, `### Etymologia`, `### Jak zapamiętać`, and `\newpage` intact +- Fenced code blocks — use 4-space indented blocks only (the document uses this style consistently) + +### WORKFLOW FOR EACH QUESTION + +1. **Read the entire question** — `read_file` the full question from `## PYTANIE N` to the next `## PYTANIE` or end of file +2. **Collect every technical term** — scan systematically through both the question text and all answer bullet points +3. **Order terms logically** — foundational concepts first, then terms that build on them +4. **Write the glossary** — following all rules above +5. **Insert at the correct location** — use `replace_string_in_file` to place the section after the bold question text + first `---`, before the first `###` +6. **Self-verify** — re-read the answer sections to confirm every term used there is covered in the glossary + +### QUALITY CHECKLIST (verify before finishing each question) + +- Every technical term in the question AND answer has a glossary entry +- Every entry has at least one concrete example with real values +- Every O(·) or complexity claim is justified with actual numbers +- Every comparison has a table or side-by-side examples +- Section is placed correctly (after question text, before first ### of answer) +- Existing answer sections are completely untouched +- No fenced code blocks (4-space indented blocks only) +- Polish language throughout (English in parentheses for standard terms) +- Terms are ordered from foundational to advanced + +### BATCH PROCESSING + +- When asked to do ONE question: expand exactly that question +- When asked to do "all remaining": process questions one at a time, starting from the first unexpanded one, and confirm completion after each +- Always check if a question already has a `### Tło pojęciowe` section before processing — skip if it does +```` diff --git a/presentation/my_thesis/images/GameMaker.png b/presentation/my_thesis/images/GameMaker.png new file mode 100644 index 0000000..416f530 Binary files /dev/null and b/presentation/my_thesis/images/GameMaker.png differ diff --git a/presentation/my_thesis/images/RPG_Maker_MV_Logo.webp b/presentation/my_thesis/images/RPG_Maker_MV_Logo.webp new file mode 100644 index 0000000..bb3e314 Binary files /dev/null and b/presentation/my_thesis/images/RPG_Maker_MV_Logo.webp differ diff --git a/presentation/my_thesis/images/RenPy.png b/presentation/my_thesis/images/RenPy.png new file mode 100644 index 0000000..919fa36 Binary files /dev/null and b/presentation/my_thesis/images/RenPy.png differ diff --git a/presentation/my_thesis/images/bad_fps.png b/presentation/my_thesis/images/bad_fps.png new file mode 100644 index 0000000..da5af60 Binary files /dev/null and b/presentation/my_thesis/images/bad_fps.png differ diff --git a/presentation/my_thesis/images/dx12_frame_health.png b/presentation/my_thesis/images/dx12_frame_health.png new file mode 100644 index 0000000..3e7cb27 Binary files /dev/null and b/presentation/my_thesis/images/dx12_frame_health.png differ diff --git a/presentation/my_thesis/images/fps_overview.png b/presentation/my_thesis/images/fps_overview.png new file mode 100644 index 0000000..f7d838c Binary files /dev/null and b/presentation/my_thesis/images/fps_overview.png differ diff --git a/presentation/my_thesis/images/fps_pick.png b/presentation/my_thesis/images/fps_pick.png new file mode 100644 index 0000000..7a8f518 Binary files /dev/null and b/presentation/my_thesis/images/fps_pick.png differ diff --git a/presentation/my_thesis/images/godot.png b/presentation/my_thesis/images/godot.png new file mode 100644 index 0000000..86acb15 Binary files /dev/null and b/presentation/my_thesis/images/godot.png differ diff --git a/presentation/my_thesis/images/logo_vertical_color_light.svg b/presentation/my_thesis/images/logo_vertical_color_light.svg new file mode 100644 index 0000000..bd2e2e8 --- /dev/null +++ b/presentation/my_thesis/images/logo_vertical_color_light.svg @@ -0,0 +1 @@ + diff --git a/presentation/my_thesis/images/maxresdefault (1).jpg b/presentation/my_thesis/images/maxresdefault (1).jpg new file mode 100644 index 0000000..01d5bfb Binary files /dev/null and b/presentation/my_thesis/images/maxresdefault (1).jpg differ diff --git a/presentation/my_thesis/images/maxresdefault.jpg b/presentation/my_thesis/images/maxresdefault.jpg new file mode 100644 index 0000000..1281f02 Binary files /dev/null and b/presentation/my_thesis/images/maxresdefault.jpg differ diff --git a/presentation/my_thesis/images/memory_utilization.png b/presentation/my_thesis/images/memory_utilization.png new file mode 100644 index 0000000..5a93fa6 Binary files /dev/null and b/presentation/my_thesis/images/memory_utilization.png differ diff --git a/presentation/my_thesis/images/memory_utilization_gpu_vram.png b/presentation/my_thesis/images/memory_utilization_gpu_vram.png new file mode 100644 index 0000000..e2e246a Binary files /dev/null and b/presentation/my_thesis/images/memory_utilization_gpu_vram.png differ diff --git a/presentation/my_thesis/images/memory_utilization_memory_transfer.png b/presentation/my_thesis/images/memory_utilization_memory_transfer.png new file mode 100644 index 0000000..39bd773 Binary files /dev/null and b/presentation/my_thesis/images/memory_utilization_memory_transfer.png differ diff --git a/presentation/my_thesis/images/memory_utilization_resource_migrations.png b/presentation/my_thesis/images/memory_utilization_resource_migrations.png new file mode 100644 index 0000000..21d984c Binary files /dev/null and b/presentation/my_thesis/images/memory_utilization_resource_migrations.png differ diff --git a/presentation/my_thesis/images/nvida_nsighty.jpg b/presentation/my_thesis/images/nvida_nsighty.jpg new file mode 100644 index 0000000..b9dd79b Binary files /dev/null and b/presentation/my_thesis/images/nvida_nsighty.jpg differ diff --git a/presentation/my_thesis/images/steamdb_filter b/presentation/my_thesis/images/steamdb_filter new file mode 100644 index 0000000..e5cd0ed --- /dev/null +++ b/presentation/my_thesis/images/steamdb_filter @@ -0,0 +1,28 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/presentation/my_thesis/images/steamdb_filter.drawio.pdf b/presentation/my_thesis/images/steamdb_filter.drawio.pdf new file mode 100644 index 0000000..6c71c2f Binary files /dev/null and b/presentation/my_thesis/images/steamdb_filter.drawio.pdf differ diff --git a/presentation/my_thesis/images/steamdb_main.png b/presentation/my_thesis/images/steamdb_main.png new file mode 100644 index 0000000..8287d78 Binary files /dev/null and b/presentation/my_thesis/images/steamdb_main.png differ diff --git a/presentation/my_thesis/images/steamdb_release.png b/presentation/my_thesis/images/steamdb_release.png new file mode 100644 index 0000000..c473c37 Binary files /dev/null and b/presentation/my_thesis/images/steamdb_release.png differ diff --git a/presentation/my_thesis/images/steamdb_technologia.png b/presentation/my_thesis/images/steamdb_technologia.png new file mode 100644 index 0000000..6e9f055 Binary files /dev/null and b/presentation/my_thesis/images/steamdb_technologia.png differ diff --git a/presentation/my_thesis/images/steamdb_type.png b/presentation/my_thesis/images/steamdb_type.png new file mode 100644 index 0000000..4bf2ee5 Binary files /dev/null and b/presentation/my_thesis/images/steamdb_type.png differ diff --git a/presentation/my_thesis/images/stutter_row.png b/presentation/my_thesis/images/stutter_row.png new file mode 100644 index 0000000..2e4c918 Binary files /dev/null and b/presentation/my_thesis/images/stutter_row.png differ diff --git a/presentation/my_thesis/images/unisex-black-gamemaker-logo-gamemaker.jpg b/presentation/my_thesis/images/unisex-black-gamemaker-logo-gamemaker.jpg new file mode 100644 index 0000000..4716bb2 Binary files /dev/null and b/presentation/my_thesis/images/unisex-black-gamemaker-logo-gamemaker.jpg differ diff --git a/presentation/my_thesis/images/unity.png b/presentation/my_thesis/images/unity.png new file mode 100644 index 0000000..e9020bc Binary files /dev/null and b/presentation/my_thesis/images/unity.png differ diff --git a/presentation/my_thesis/images/unity_profiler.png b/presentation/my_thesis/images/unity_profiler.png new file mode 100644 index 0000000..2ced8b9 Binary files /dev/null and b/presentation/my_thesis/images/unity_profiler.png differ diff --git a/presentation/my_thesis/images/unreal.png b/presentation/my_thesis/images/unreal.png new file mode 100644 index 0000000..b709db8 Binary files /dev/null and b/presentation/my_thesis/images/unreal.png differ diff --git a/presentation/my_thesis/images/unreal_profiler.jpg b/presentation/my_thesis/images/unreal_profiler.jpg new file mode 100644 index 0000000..b22cff4 Binary files /dev/null and b/presentation/my_thesis/images/unreal_profiler.jpg differ diff --git a/presentation/my_thesis/images/usedEngines.pdf b/presentation/my_thesis/images/usedEngines.pdf new file mode 100644 index 0000000..411e58d Binary files /dev/null and b/presentation/my_thesis/images/usedEngines.pdf differ diff --git a/presentation/my_thesis/images/vulkan_frame_health.png b/presentation/my_thesis/images/vulkan_frame_health.png new file mode 100644 index 0000000..7676f2f Binary files /dev/null and b/presentation/my_thesis/images/vulkan_frame_health.png differ diff --git a/presentation/my_thesis/main.pdf b/presentation/my_thesis/main.pdf new file mode 100644 index 0000000..bb52aae Binary files /dev/null and b/presentation/my_thesis/main.pdf differ diff --git a/presentation/my_thesis/main.tex b/presentation/my_thesis/main.tex new file mode 100644 index 0000000..cb2e305 --- /dev/null +++ b/presentation/my_thesis/main.tex @@ -0,0 +1,466 @@ +\documentclass{beamer} +\usepackage[fontsize=17pt]{fontsize} +\usepackage{graphicx} +\usepackage{tikz} +\usepackage{svg} +\usepackage[polish]{babel} +\usepackage{booktabs} +\usepackage{colortbl} +\usepackage{multirow} +\usepackage{amssymb} +\graphicspath{ {./images/} {../../latex/tex/img/} } +\usetheme{Warsaw} + +%Information to be included in the title page: +\title{\large Porównanie wydajności i możliwości \\ współczesnych silników gier komputerowych} +\author{inż. Krzysztof Rudnicki} +\institute{ + \textbf{Promotor:} dr inż. Michał Chwesiuk \\[0.3em] + Wydział Elektroniki i Technik Informacyjnych \\ + Politechnika Warszawska +} +\date{\scriptsize Luty 2026} + +\setbeamertemplate{footline}[frame number]{} +\beamertemplatenavigationsymbolsempty +\setbeamertemplate{headline}{} + +\begin{document} + +%============================================================================== +% TITLE +%============================================================================== +\begin{frame} + \vspace{-0.5cm} + \maketitle +\end{frame} + +%============================================================================== +% TABLE OF CONTENTS +%============================================================================== +\begin{frame} +\frametitle{Plan prezentacji} +\tableofcontents +\end{frame} + +%============================================================================== +% SECTION 1: MOTIVATION AND GOALS +%============================================================================== +\section{Cel i zakres pracy} + +\begin{frame} + \frametitle{Motywacja} + \begin{itemize} + \item Rynek gier zdominowany przez dwa silniki: + \begin{itemize} + \item \textbf{Unity} -- prawie 25\,000 gier na Steam + \item \textbf{Unreal Engine} -- ponad 7\,500 gier na Steam + \end{itemize} + \item Brak systematycznych badań porównawczych + \item Odmienne filozofie projektowe: + \begin{itemize} + \item Unity: C\#, garbage collector + \item Unreal: C++, dostęp do kodu źródłowego + \end{itemize} + \end{itemize} +\end{frame} + +\begin{frame} + \frametitle{Cel pracy} + Porównanie wydajności i~możliwości Unity oraz Unreal Engine: + \begin{enumerate} + \item Testy wydajności z~NVIDIA Nsight Systems + \item Implementacja identycznej gry w obu silnikach + \item Analiza porównawcza funkcjonalności + \item Wywiady z~8 deweloperami gier + \end{enumerate} + \vspace{0.5cm} + \textbf{Hipoteza:} Unity osiągnie lepszą wydajność w~grze 2D \emph{bullet hell} dzięki natywnemu wsparciu dla grafiki 2D. +\end{frame} + +%============================================================================== +% SECTION 2: METHODOLOGY +%============================================================================== +\section{Metodologia} + +\begin{frame} + \frametitle{Wybór gatunku -- bullet hell} + \begin{columns} + \begin{column}{0.55\textwidth} + \textbf{Uzasadnienie:} + \begin{itemize} + \item Setki/tysiące pocisków na ekranie + \item Test zarządzania pamięcią \\ (GC vs ręczne) + \item Intensywne wykrywanie kolizji + \item Skalowalność obciążenia + \item Prosta koncepcja $\rightarrow$ fokus na wydajność + \end{itemize} + \end{column} + \begin{column}{0.45\textwidth} + \includegraphics[width=\textwidth]{touhou.jpg} + {\tiny Touhou Project -- przykład bullet hell} + \end{column} + \end{columns} +\end{frame} + +\begin{frame} + \frametitle{Parametry gry testowej} + \begin{itemize} + \item Czas rozgrywki: \textbf{90 sekund} + \item 3 typy przeciwników z różnymi wzorcami strzelania + \item Eskalacja trudności w 3 fazach: + \begin{enumerate} + \item \textbf{0--30s:} Niska trudność (podstawowi przeciwnicy) + \item \textbf{30--60s:} Średnia (szybsze jednostki, wieżyczki) + \item \textbf{60--90s:} Wysoka (wszystkie typy, max spawnu) + \end{enumerate} + \item Limit: 200 jednoczesnych przeciwników + \item Interwał spawnu: 0,25s $\rightarrow$ 0,08s + \end{itemize} +\end{frame} + +\begin{frame} + \frametitle{Środowisko testowe} + \begin{table} + \centering + \small + \begin{tabular}{ll} + \toprule + \textbf{Komponent} & \textbf{Specyfikacja} \\ + \midrule + CPU & AMD Ryzen 9 7900X3D (24 rdzenie) \\ + GPU & NVIDIA GeForce RTX 3090 (24 GB) \\ + RAM & 32 GB \\ + OS & Arch Linux \\ + Unity & 6.0 LTS \\ + Unreal & 5.5.3 \\ + Profiler & NVIDIA Nsight Systems 2025.5.2 \\ + \bottomrule + \end{tabular} + \end{table} +\end{frame} + +%============================================================================== +% SECTION 3: IMPLEMENTATION +%============================================================================== +\section{Implementacja} + +\begin{frame} + \frametitle{Implementacja -- Unity} + \begin{columns} + \begin{column}{0.5\textwidth} + \begin{itemize} + \item Język: \textbf{C\#} + \item Natywny tryb 2D + \item \texttt{Rigidbody2D}, \texttt{Collider2D} + \item Object pooling: \texttt{SetActive()} + \item Hot reload + \item Instalacja: $\sim$30 min + \end{itemize} + \end{column} + \begin{column}{0.5\textwidth} + \includegraphics[width=\textwidth]{unity_game.png} + \end{column} + \end{columns} +\end{frame} + +\begin{frame} + \frametitle{Implementacja -- Unreal Engine} + \begin{columns} + \begin{column}{0.5\textwidth} + \begin{itemize} + \item Język: \textbf{C++} / Blueprinty + \item ,,Fałszywe 2D'' w środowisku 3D + \item Object pooling -- 3 metody: + \begin{itemize} + \scriptsize + \item \texttt{SetActorHiddenInGame} + \item \texttt{SetActorEnableCollision} + \item \texttt{SetActorTickEnabled} + \end{itemize} + \item Instalacja: $\sim$2--4h (Linux) + \end{itemize} + \end{column} + \begin{column}{0.5\textwidth} + \includegraphics[width=\textwidth]{unreal_game_view.png} + \end{column} + \end{columns} +\end{frame} + +\begin{frame} + \frametitle{Porównanie doświadczeń implementacyjnych} + \begin{table} + \centering + \small + \begin{tabular}{lcc} + \toprule + \textbf{Aspekt} & \textbf{Unity} & \textbf{Unreal} \\ + \midrule + Instalacja (Linux) & $\sim$30 min & $\sim$2--4 h \\ + Natywne 2D & Tak & Nie \\ + Język & C\# & C++ \\ + Próg wejścia & Niski & Średni/Wysoki \\ + Czas kompilacji & Szybki & Wolny \\ + Object pooling & Prosty & Złożony \\ + Hot reload & Tak & Ograniczony \\ + \bottomrule + \end{tabular} + \end{table} + \vspace{0.3cm} + \centering + Implementacja w~Unity zajęła \textbf{$\sim$60\%} czasu potrzebnego w~Unreal Engine +\end{frame} + +%============================================================================== +% SECTION 4: PROFILING TOOL +%============================================================================== +\section{Narzędzie profilowania} + +\begin{frame} + \frametitle{Dlaczego NVIDIA Nsight Systems?} + \begin{itemize} + \item Wbudowane profilery silników są \textbf{nieporównywalne}: + \begin{itemize} + \item Różna definicja metryk + \item Różny narzut profilowania + \item Różne formaty wyjściowe + \end{itemize} + \item NVIDIA Nsight -- niezależne narzędzie: + \begin{itemize} + \item Zunifikowane metryki sprzętowe + \item Analiza na poziomie Vulkan API + \item Minimalny narzut (poziom sterownika) + \item Spójny format dla obu silników + \end{itemize} + \end{itemize} +\end{frame} + +{ + \setbeamercolor{footline}{fg=white} + \usebackgroundtemplate{ + \includegraphics[width=\paperwidth, height=\paperheight]{nvida_nsighty.jpg}} + \begin{frame} + \end{frame} +} + +%============================================================================== +% SECTION 5: PERFORMANCE RESULTS +%============================================================================== +\section{Wyniki testów wydajności} + +\begin{frame} + \frametitle{Unity -- wydajność klatek} + \begin{table} + \centering + \small + \begin{tabular}{lr} + \toprule + \textbf{Metryka} & \textbf{Wartość} \\ + \midrule + Czas testu & 94,16 s \\ + Wyrenderowane klatki & 13\,556 \\ + Średni FPS & 143,96 (V-Sync: 144 Hz) \\ + Mediana czasu klatki & 6,94 ms \\ + 99. percentyl (1\% low) & 7,58 ms (132 FPS) \\ + Klatki w przedziale 5--10 ms & \textbf{98,24\%} \\ + \bottomrule + \end{tabular} + \end{table} + \vspace{0.3cm} + \centering + Wysoka stabilność -- IQR zaledwie 0,08 ms +\end{frame} + +\begin{frame} + \frametitle{Unity -- architektura renderowania} + \begin{itemize} + \item \textbf{Prosty potok}: 2 wywołania \texttt{vkQueueSubmit}/klatkę + \item \texttt{vkWaitForFences} -- \textbf{95,2\%} czasu Vulkan API + \begin{itemize} + \item CPU czeka na GPU $\rightarrow$ scenariusz \textbf{GPU-bound} + \end{itemize} + \item Łącznie $\sim$218\,815 wywołań Vulkan API + \item Tylko \textbf{3 potoki graficzne} w~całym teście + \item Wykorzystanie GPU: \textbf{$\sim$23\%} (ograniczone V-Sync) + \end{itemize} +\end{frame} + +\begin{frame} + \frametitle{Unreal Engine -- wydajność klatek} + \begin{table} + \centering + \small + \begin{tabular}{lrrr} + \toprule + \textbf{Metryka} & \textbf{Faza 1} & \textbf{Faza 2} & \textbf{Faza 3} \\ + \midrule + Średni FPS & 332 & 339 & 162 \\ + GPU Active & 91\% & 91\% & 50\% \\ + vkQueueSubmit & 166\,918 & 186\,589 & 74\,393 \\ + Submit/klatkę & 16,2 & 16,2 & 16,2 \\ + \bottomrule + \end{tabular} + \end{table} + \vspace{0.3cm} + \begin{itemize} + \item Spadek o~\textbf{ponad 50\%} między fazami 1--2 a~fazą 3 + \item Brak V-Sync -- pełne wykorzystanie GPU + \end{itemize} +\end{frame} + +\begin{frame} + \frametitle{Unreal Engine -- architektura renderowania} + \begin{itemize} + \item \textbf{Złożony potok}: 16 wywołań \texttt{vkQueueSubmit}/klatkę + \item Tworzenie potoków: \textbf{47--72\%} czasu Vulkan API + \begin{itemize} + \item $\sim$1000 potoków na fazę (vs 3 w Unity!) + \end{itemize} + \item Łącznie $\sim$\textbf{32 mln} wywołań Vulkan API + \item $\sim$\textbf{9 mln} wywołań synchronizacji OS + \item Intensywne użycie compute shaderów (culling, post-proc.) + \end{itemize} +\end{frame} + +\begin{frame} + \frametitle{Porównanie kluczowych wyników} + \begin{table} + \centering + \small + \begin{tabular}{lrr} + \toprule + \textbf{Metryka} & \textbf{Unity} & \textbf{Unreal} \\ + \midrule + FPS (niskie obciążenie) & 164 (V-Sync) & 332--339 \\ + FPS (wymagająca scena) & 132 (1\% low) & 162 (faza 3) \\ + Wykorzystanie GPU & 23\% & 91\% / 50\% \\ + Wywołania Vulkan API & $\sim$0,5 mln & $\sim$32 mln \\ + Wywołania sync. OS & 29\,383 & $\sim$9 mln \\ + Potoki graficzne & 3 & $\sim$2\,400 \\ + Submit/klatkę & 2 & 16 \\ + \bottomrule + \end{tabular} + \end{table} +\end{frame} + +\begin{frame} + \frametitle{Interpretacja wyników} + \begin{block}{Unity} + \begin{itemize} + \item Prosty, dwuetapowy potok -- wydajny dla gier 2D + \item Stabilne czasy klatek (98,24\% w 5--10 ms) + \item Niewykorzystany potencjał GPU (V-Sync: 23\%) + \end{itemize} + \end{block} + \begin{block}{Unreal Engine} + \begin{itemize} + \item Złożony, wieloetapowy potok -- narzut dla prostych scen + \item Ciągła rekompilacja potoków (dynamiczna optymalizacja) + \item Pełne wykorzystanie GPU ($\sim$91\%) + \item Spadek wydajności przy dużym obciążeniu (>50\%) + \end{itemize} + \end{block} +\end{frame} + +%============================================================================== +% SECTION 6: INTERVIEWS +%============================================================================== +\section{Wywiady z~deweloperami} + +\begin{frame} + \frametitle{Wywiady -- najważniejsze wnioski} + 8 respondentów (1--10 lat doświadczenia): + \vspace{0.2cm} + \small + \begin{itemize} + \item \textbf{Próg wejścia}: Unity niższy, Unreal wyższy + \item \textbf{Dokumentacja}: Unity lepsza (przykłady kodu); Unreal -- ,,szkieletowa'' + \item \textbf{Blueprinty}: Ułatwiają współpracę z~nietechnicznymi, ale problemy z~Git + \item \textbf{Architektura}: Unreal wymusza porządek; Unity -- elastyczny + \item \textbf{C\# vs C++}: C\# łatwiejszy; C++ w~Unreal ,,niestandardowy'' + \item \textbf{Materiały}: Unity przewaga ilościowa + \end{itemize} +\end{frame} + +%============================================================================== +% SECTION 7: CONCLUSIONS +%============================================================================== +\section{Wnioski} + +\begin{frame} + \frametitle{Weryfikacja hipotezy} + \textit{,,Unity osiągnie lepszą wydajność w~grze bullet hell~\ldots''} + \vspace{0.5cm} + + Hipoteza \textbf{częściowo potwierdzona}: + \small + \begin{itemize} + \item[$\checkmark$] Prostsza architektura renderowania + \item[$\checkmark$] Stabilniejsze czasy klatek + \item[$\checkmark$] Łatwiejszy proces implementacji (60\% czasu) + \item[$\checkmark$] Natywne wsparcie 2D + \item[$\times$] Zbliżona wydajność w~wymagających scenach (132 vs 162 FPS) + \item[$\times$] Unity ograniczone przez V-Sync + \end{itemize} +\end{frame} + +\begin{frame} + \frametitle{Rekomendacje} + \begin{table} + \centering + \small + \begin{tabular}{lll} + \toprule + \textbf{Typ projektu} & \textbf{Silnik} & \textbf{Uzasadnienie} \\ + \midrule + Gra 2D indie & Unity & Natywne wsparcie 2D \\ + Gra mobilna & Unity & Optymalizacja, rozmiar \\ + Prototyp & Unity & Szybki cykl iteracji \\ + Gra 3D AAA & Unreal & Nanite, Lumen \\ + Gra VR high-end & Unreal & Zaawansowane oświetlenie \\ + Zespół mieszany & Unreal & Blueprinty \\ + \bottomrule + \end{tabular} + \end{table} +\end{frame} + +\begin{frame} + \frametitle{Wkład pracy} + \begin{enumerate} + \item \textbf{Zunifikowana metodyka pomiaru} -- \\ Nsight Systems jako niezależne narzędzie + \item \textbf{Analiza Vulkan API} -- \\ 32 mln wywołań (Unreal) vs 0,5 mln (Unity) + \item \textbf{Triangulacja metod} -- \\ testy + wywiady + implementacja + \item \textbf{Praktyczne rekomendacje} -- \\ macierz wyboru silnika + \end{enumerate} +\end{frame} + +\begin{frame} + \frametitle{Ograniczenia i~dalsze badania} + \small + \textbf{Ograniczenia:} + \begin{itemize} + \item Jeden gatunek gry (bullet hell) + \item Pojedyncza konfiguracja sprzętowa (high-end) + \item 8 wywiadów (badanie eksploracyjne) + \end{itemize} + \vspace{0.2cm} + \textbf{Propozycje dalszych badań:} + \begin{itemize} + \item Testy dla RPG, RTS, puzzle + \item Różne platformy (mobile, konsole, low-end PC) + \item Automatyczny framework benchmarkowy + \item Badanie longitudinalne (2--3 lata) + \end{itemize} +\end{frame} + +\begin{frame} + \frametitle{} + \vspace{2cm} + \centering + {\Large Dziękuję za uwagę} + \vspace{1cm} + + {\normalsize Pytania?} +\end{frame} + +\end{document} \ No newline at end of file diff --git a/presentation/my_thesis/script.txt b/presentation/my_thesis/script.txt new file mode 100644 index 0000000..2ae1454 --- /dev/null +++ b/presentation/my_thesis/script.txt @@ -0,0 +1,15 @@ +Dzień dobry państwu, nazywam się Krzysztof Rudnicki i chciałbym opowiedzieć o mojej pracy magisterskiej pod promotorstwem Pana doktora Michała Chwesiuka, o tytule Porównanie wydajnośći i możliwości współczesnych silników gier komputerowych + +Jeżeli pojawią się jakieś pytania to można je jak najbardziej zadawać w trakcie + +Plan prezentacji wygląda następująco, najpierw omówię krótko co +rozumiem pod pojęciem silnika do gier, +jakie są współczesne silniki do gier, +które z nich będę porównywał, +czym są możliwości i wydajności tych silników +i jak zamierzam je porównywać + +Chciałbym aby po tej prezentacji wiedzieli Państwo więcej o tym jak można +porównywać silniki graficzne niż przed nią + + diff --git a/pytania/OBRONA_MAGISTERSKA_ODPOWIEDZI.md b/pytania/OBRONA_MAGISTERSKA_ODPOWIEDZI.md new file mode 100644 index 0000000..a8e3155 --- /dev/null +++ b/pytania/OBRONA_MAGISTERSKA_ODPOWIEDZI.md @@ -0,0 +1,3826 @@ +## PYTANIE 1: Automaty i klasy języków (AISDI) + +**Porównać "siłę wyrazu" automatu skończonego, automatu ze stosem oraz maszyny Turinga. Jakie klasy języków rozpoznaje każdy z nich?** + +--- + +### Tło pojęciowe — słowniczek + +**Język (formalny)** — zbiór słów (ciągów symboli) nad ustalonym alfabetem Σ. Np. alfabet Σ = {a, b}, język L = {ab, aabb, aaabbb, ...} = {aⁿbⁿ | n ≥ 1}. Język formalny to nie język naturalny (polski, angielski) — to matematyczny zbiór napisów spełniających pewną regułę. + +**Automat** — abstrakcyjny model maszyny obliczeniowej. Czyta wejście (słowo) symbol po symbolu i stwierdza, czy to słowo należy do danego języka. „Rozpoznaje" (akceptuje) język = akceptuje dokładnie te słowa, które do niego należą, i odrzuca pozostałe. + +**Stan (state)** — chwilowa „konfiguracja" automatu. Automat przechodzi między stanami na podstawie odczytanego symbolu. Pomyśl o nim jak o pozycji na schemacie blokowym — automat „wie" tylko tyle, ile mówi mu aktualny stan. + +**Pamięć** — dodatkowa struktura danych, którą automat może zapisywać i odczytywać poza samym stanem. FA nie ma żadnej pamięci (cała informacja to aktualny stan). PDA ma stos. TM ma taśmę. + +**Stos (stack)** — struktura danych typu LIFO (Last In, First Out = ostatni włożony, pierwszy wyjęty). Jak stos talerzy: dokładasz na górę, zdejmujesz z góry. Jedyny dostęp to szczyt stosu — nie możesz zajrzeć na dno bez zdjęcia wszystkiego powyżej. + +**LIFO** — Last In, First Out. Zasada działania stosu: element dodany jako ostatni jest usuwany jako pierwszy. Przeciwieństwo FIFO (First In, First Out = kolejka). + +**Taśma (tape)** — nieskończona (lub ograniczona) linia komórek, z których każda przechowuje symbol. Głowica odczytująco-zapisująca (R/W) może się poruszać w lewo i prawo, odczytywać i nadpisywać symbole. To pamięć o swobodnym dostępie — w przeciwieństwie do stosu, możesz wrócić do dowolnego wcześniejszego miejsca. + +**DFA i NFA** — DFA = Deterministic Finite Automaton (deterministyczny automat skończony): w każdym stanie, dla każdego symbolu, istnieje DOKŁADNIE jedno przejście — automat zawsze „wie", co robić. NFA = Nondeterministic Finite Automaton (niedeterministyczny): może mieć WIELE przejść dla jednego symbolu (lub żadne), a także przejścia ε (bez czytania symbolu). **DFA ≡ NFA** oznacza, że rozpoznają DOKŁADNIE te same języki — każdy NFA da się zamienić na równoważny DFA (konstrukcja podzbiorów, powerset construction). NFA bywa wygodniejszy do zapisu, ale nie jest „silniejszy". + +**Wyrażenie regularne (regular expression, regex)** — wzorzec tekstowy opisujący zbiór ciągów znaków. Składa się z: symboli alfabetu, konkatenacji (ab), alternatywy (a|b), gwiazdki Kleene'ego (a* = zero lub więcej a). Np. `(a|b)*abb` opisuje wszystkie ciągi nad {a,b} kończące się na „abb". **Równoważne FA** = każde wyrażenie regularne opisuje język, który można rozpoznać automatem skończonym, i odwrotnie — to ten sam zbiór języków. + +**Identyfikatory i podzielność (przykłady języków regularnych):** +- *Identyfikatory* — nazwy zmiennych w programowaniu, np. `[a-zA-Z_][a-zA-Z0-9_]*` (zaczyna się od litery lub _, potem litery/cyfry/_). To wyrażenie regularne → język regularny. +- *Podzielność* — np. „liczby binarne podzielne przez 3": automat z 3 stanami (reszta 0, 1, 2) śledzi resztę z dzielenia — nie potrzebuje pamięci, wystarczą stany. + +**Nawiasy** — język poprawnie zagnieżdżonych nawiasów, np. `()`, `(())`, `(()())`. FA nie poradzi sobie z tym, bo musi „liczyć" głębokość zagnieżdżenia (potrzebuje pamięci) — PDA ze stosem to robi naturalnie (push na `(`, pop na `)`). To klasyczny język bezkontekstowy. + +**Palindromy** — słowa czytane tak samo od przodu i od tyłu, np. `abba`, `aba`, `aabaa`. FA nie rozpoznaje palindromów, bo musiałby zapamiętać pierwszą połowę słowa. PDA rozpoznaje palindromy o nieparzystej długości (NPDA), ale nie deterministycznie — musi „zgadnąć" środek. + +**DPDA i NPDA:** +- DPDA = Deterministic Pushdown Automaton — w każdej konfiguracji (stan + szczyt stosu + symbol) jest JEDNO możliwe przejście. +- NPDA = Nondeterministic Pushdown Automaton — może mieć WIELE przejść, „zgaduje" właściwą ścieżkę. +- **DPDA ⊂ NPDA** — w przeciwieństwie do FA, tutaj niedeterminizm DODAJE moc! NPDA rozpoznaje ściśle więcej języków niż DPDA. Np. palindromy nad {a,b} (wwᴿ) wymagają NPDA — DPDA nie potrafi „zgadnąć" środka słowa. + +**Dlaczego aⁿbⁿ, nawiasy, wwᴿ pasują do Typu 2 (PDA), a aⁿbⁿcⁿ i ww nie:** +- **aⁿbⁿ** — stos zlicza: push a na stos, potem pop a przy każdym b. Jeśli stos pusty po przeczytaniu → akceptuj. Stos idealnie pasuje do „zliczenia jednej rzeczy, potem dopasowania drugiej". +- **Nawiasy ()** — push na `(`, pop na `)`. Stos śledzi głębokość. +- **wwᴿ** (słowo + jego odwrócenie, np. abba) — push pierwszą połowę, potem pop i porównuj z drugą. NPDA „zgaduje" środek. +- **aⁿbⁿcⁿ — NIE da się na stosie:** stos zużyje się przy dopasowaniu a↔b (push a, pop przy b), i już PUSTY przy c — nie ma czym liczyć c. Potrzeba dwóch niezależnych „liczników" jednocześnie → potrzebna taśma R/W. +- **ww (słowo powtórzone, np. abab) — NIE da się na stosie:** w przeciwieństwie do wwᴿ, druga połowa NIE jest odwrócona, więc porównanie „z góry stosu" nie działa. Stos odwraca kolejność — to pomaga przy palindromach, ale przeszkadza przy powtórzeniu. + +**|w| w Typie 1** — |w| to długość słowa wejściowego w. Np. jeśli w = „aabbcc", to |w| = 6. LBA (Linear Bounded Automaton) to maszyna Turinga, której taśma jest ograniczona do co najwyżej |w| komórek (liniowo proporcjonalnie do długości wejścia). Nie może wydłużać taśmy ponad to. + +**DLBA i NLBA:** +- DLBA = Deterministic Linear Bounded Automaton. +- NLBA = Nondeterministic Linear Bounded Automaton. +- **Czy DLBA = NLBA?** — to OTWARTY PROBLEM (nierozwiązany!). Nie wiemy, czy deterministyczny LBA rozpoznaje te same języki co niedeterministyczny. To jedno z wielkich otwartych pytań teorii złożoności. + +**Dlaczego aⁿbⁿcⁿ i ww pasują do Typu 1 (LBA):** +- **aⁿbⁿcⁿ** — LBA z taśmą R/W może: (1) przejść przez a-ki zaznaczając jednego, (2) przejść przez b-ki zaznaczając jednego, (3) przejść przez c-ki zaznaczając jednego, (4) wrócić na początek i powtarzać. Taśma pozwala wielokrotnie przechodzić i „odznaczać" symbole — tego stos nie potrafi. +- **ww** — LBA porównuje i-ty symbol pierwszej połowy z i-tym symbolem drugiej, przeskakując po taśmie. Swobodny dostęp do taśmy umożliwia porównanie w dowolnej kolejności. + +**DTM i NTM — dlaczego równoważne:** +- DTM = Deterministic Turing Machine, NTM = Nondeterministic Turing Machine. +- **DTM ≡ NTM** pod względem MOCY (rozpoznawanych języków) — DTM może symulować NTM, np. przez BFS po drzewie konfiguracji. Symulacja jest wykładniczo wolniejsza, ale DTM rozpoznaje DOKŁADNIE te same języki. +- Uwaga: czy symulacja musi być wolniejsza to osobne pytanie — to jest istota problemu P vs NP! + +**Domknięcie ∩/¬ (closure under intersection and complement):** +- Klasa języków jest „domknięta" na operację, jeśli wynik tej operacji na językach z klasy ZAWSZE daje język z tej samej klasy. +- **∩ (przecięcie):** jeśli L₁ i L₂ należą do klasy, to L₁ ∩ L₂ też? Np. języki regularne: TAK (automat produktowy). Bezkontekstowe: NIE (kontrprzykład: {aⁿbⁿcᵐ} ∩ {aᵐbⁿcⁿ} = {aⁿbⁿcⁿ}, który nie jest bezkontekstowy). +- **¬ (dopełnienie/komplement):** jeśli L należy do klasy, to L̄ (wszystkie słowa NIE należące do L) też? Regularne: TAK (zamień stany akceptujące ↔ nieakceptujące). Bezkontekstowe: NIE. Rek. przeliczalne: NIE (komplement problemu stopu nie jest rek. przeliczalny). + +**Zastosowania — co oznaczają:** +- **Leksery (lexers)** — pierwszy etap kompilacji: dzielą kod źródłowy na tokeny (słowa kluczowe, identyfikatory, liczby, operatory). Używają automatów skończonych / wyrażeń regularnych. Np. `if`, `123`, `"hello"`, `+` to tokeny. +- **Parsery (parsers)** — drugi etap: budują drzewo składniowe (parse tree) z tokenów, sprawdzając strukturę gramatyczną programu. Używają gramatyk bezkontekstowych / automatów ze stosem. Np. sprawdzają, czy `if (x) { y; }` ma poprawną strukturę. +- **Weryfikacja ograniczeń (constraint verification)** — sprawdzanie złożonych reguł kontekstowych, np. „zmienna musi być zadeklarowana przed użyciem", „typy muszą się zgadzać". Wykracza poza CFG, odpowiada gramatykom kontekstowym / LBA. +- **Obliczenia ogólne (general computation)** — dowolne obliczenia algorytmiczne: od sortowania, przez sztuczną inteligencję, po symulację fizyki. Maszyna Turinga modeluje KAŻDE możliwe obliczenie (teza Churcha-Turinga). + +--- + +### Porównanie siły wyrazu + +**Siła wyrazu** (expressive power) — klasa języków, które automat rozpoznaje. Im szersza klasa, tym większa siła: + + FA ⊂ PDA ⊂ LBA ⊂ TM + +- **FA < PDA:** FA nie rozpoznaje aⁿbⁿ (brak pamięci do liczenia), PDA tak (stos zlicza). +- **PDA < LBA:** PDA nie rozpoznaje aⁿbⁿcⁿ (stos zużyty po a/b), LBA tak (taśma ogr. R/W). +- **LBA < TM:** LBA ograniczona do |w| komórek, TM ma nieskończoną taśmę. + +### Hierarchia Chomsky'ego (1956) + + Typ 0: Rek. przeliczalne (TM) + ⊃ Typ 1: Kontekstowe (LBA) + ⊃ Typ 2: Bezkontekstowe (PDA) + ⊃ Typ 3: Regularne (FA) + +### FA — Typ 3: Języki regularne + +M = (Q, Σ, δ, q₀, F). **Pamięć:** brak — tylko stan. **DFA ≡ NFA.** +Równoważne wyrażeniom regularnym (regex). +Przykłady: identyfikatory, podzielność. Nie: aⁿbⁿ, nawiasy, palindromy. + +### PDA — Typ 2: Języki bezkontekstowe + +M = (Q, Σ, Γ, δ, q₀, Z₀, F). **Pamięć:** stos LIFO. **DPDA ⊂ NPDA!** +Przykłady: aⁿbⁿ, nawiasy, wwᴿ. Nie: aⁿbⁿcⁿ, ww. + +### LBA — Typ 1: Języki kontekstowe + +TM z taśmą ograniczoną do |w|. **DLBA =? NLBA** — problem otwarty! +Przykłady: aⁿbⁿcⁿ, ww. + +### TM — Typ 0: Rekurencyjnie przeliczalne + +M = (Q, Σ, Γ, δ, q₀, q_acc, q_rej). **Pamięć:** taśma ∞ R/W. **DTM ≡ NTM** (moc). +Teza Churcha-Turinga: TM modeluje każde obliczenie. Nie: komplement problemu stopu. + +### Tabela porównawcza + +| Cecha | FA | PDA | LBA | TM | +|----------------|------------|----------------|------------------|-------------------| +| Pamięć | Brak | Stos (LIFO) | Taśma ogr. (R/W) | Taśma ∞ (R/W) | +| Klasa języków | Regularne | Bezkontekstowe | Kontekstowe | Rek. przeliczalne | +| DET = NIEDET? | TAK | NIE | Otwarte! | TAK (moc) | +| Domknięcie ∩/¬ | TAK/TAK | NIE/NIE | TAK/TAK | TAK/NIE | +| Zastosowanie | Leksery | Parsery | Weryfikacja ogr. | Obliczenia ogólne | + +### Etymologia nazw + +**Automaty:** *Finite Automaton* — „skończony" = skończona liczba stanów (cała pamięć to stan). *Pushdown Automaton* — „pushdown" od spring-loaded tray dispenser (dozownik tac w stołówce: push down = zepchnij na stos). *LBA* — taśma liniowo proporcjonalna do wejścia (Myhill 1960, Kuroda 1964). *Maszyna Turinga* — Alan Turing (1936, „On Computable Numbers"), formalizacja obliczalności; odpowiedź na Entscheidungsproblem Hilberta; złamał Enigmę w WWII. *Hierarchia Chomsky'ego* — Noam Chomsky (MIT, 1956), lingwista; hierarchia gramatyk dla języków naturalnych okazała się fundamentem informatyki. + +**Języki:** *Regularne* — od „regular expressions" (Kleene 1956); „regular" = podlegające stałej regule (łac. regula). *Bezkontekstowe (Context-Free)* — produkcje A → α stosowane BEZ patrzenia na kontekst wokół A; nieterminal przepisywany niezależnie od otoczenia. *Kontekstowe (Context-Sensitive)* — produkcje αAβ → αγβ: przepisanie A ZALEŻY od kontekstu α i β. *Rekurencyjnie przeliczalne (Recursively Enumerable)* — istnieje TM wyliczająca (enumerate) wszystkie słowa języka; „rekurencyjnie" = przez procedurę obliczeniową (ale może nie zatrzymać się na nie-członkach). + +### Jak zapamiętać + +- **„Raz Bardzo Kolorowy Rekin"** — Regularny ⊂ Bezkontekstowy ⊂ Kontekstowy ⊂ Rek.przeliczalny +- **Pamięć:** Brak → Stos → Taśma ogr. → Taśma ∞ +- **Kontrprzykłady:** aⁿbⁿ łamie FA, aⁿbⁿcⁿ łamie PDA +- **Kontekst nazw:** Context-Free = A przepisywane bez kontekstu; Context-Sensitive = kontekst αAβ decyduje + +\newpage + +## PYTANIE 2: Algorytmy najkrótszej ścieżki (AISDI) + +**Omówić i porównać algorytmy: Dijkstry, Bellmana-Forda, A*.** + +--- + +### Tło pojęciowe — słowniczek + +**Graf** — struktura danych składająca się z **wierzchołków** (vertices/nodes) połączonych **krawędziami** (edges). Np. mapa miast: miasta = wierzchołki, drogi = krawędzie. + +**Wierzchołek (vertex, node)** — punkt w grafie. Oznaczany jako v, u, n, m itp. **V** = zbiór wszystkich wierzchołków; |V| = ich liczba. + +**Krawędź (edge)** — połączenie między dwoma wierzchołkami. **E** = zbiór krawędzi; |E| = ich liczba. Krawędź może być skierowana (A→B ≠ B→A) lub nieskierowana (A↔B). + +**Waga (weight)** — liczba przypisana do krawędzi, oznaczająca „koszt" przejścia. Np. odległość w km, czas podróży, opłata za przejazd. Graf z wagami = graf ważony. + +**Koszt (cost)** — ogólne pojęcie „ceny" przejścia ścieżką. Koszt ścieżki = suma wag krawędzi na tej ścieżce. Cel algorytmów: znaleźć ścieżkę o **minimalnym koszcie**. + +**SSSP (Single-Source Shortest Path)** — problem: mając JEDEN wierzchołek startowy (źródło), znajdź najkrótsze ścieżki do WSZYSTKICH pozostałych wierzchołków. Dijkstra i Bellman-Ford rozwiązują SSSP. **Single-Pair** — prostszy problem: znajdź najkrótszą ścieżkę z A do B (jednej konkretnej pary). A* rozwiązuje Single-Pair. + +**d[v]** — tablica odległości. **d** = tablica (array), **v** = wierzchołek. d[v] przechowuje aktualnie najlepsze znane oszacowanie odległości od źródła do wierzchołka v. Na początku d[start] = 0, d[wszystko inne] = ∞. Algorytm stopniowo poprawia te wartości. + +**Zachłanny (greedy)** — strategia algorytmiczna: w każdym kroku wybierz opcję, która TERAZ wygląda najlepiej (lokalnie optymalna), bez cofania się. Dijkstra jest zachłanny: zawsze bierze wierzchołek o najmniejszym d[v] i nigdy go nie rewiduje. + +**Relaksacja krawędzi (edge relaxation)** — kluczowa operacja. Sprawdza: „czy droga do v przez u jest krótsza niż dotychczas znana?" Jeśli d[u] + waga(u,v) < d[v], to zaktualizuj d[v]. Nazwa od „rozluźniania" — górne ograniczenie na odległość się „rozluźnia" (maleje) w stronę prawdziwej wartości. + +**Tablica (array)** — najprostsza struktura danych: ciągły blok pamięci. W Dijkstrze z tablicą: szukanie minimum d[v] wymaga przejrzenia WSZYSTKICH wierzchołków → O(V) na szukanie × V razy = **O(V²)**. + +Przykład — graf z 4 wierzchołkami (A, B, C, D), start = A: + + Graf: A --2-- B --3-- D + | | + 4 1 + | | + C ------5-------+ + + d = [ A:0, B:∞, C:∞, D:∞ ] ← tablica na starcie + odwiedzone = {} + + Krok 1: przeszukaj CAŁĄ tablicę d → min = A (0) + d = [ A:0, B:2, C:4, D:∞ ] odw = {A} + ↑ ↑ + A→B=2 A→C=4 (relaksacja sąsiadów A) + + Krok 2: przeszukaj CAŁĄ tablicę d (poza odw.) → min = B (2) + d = [ A:0, B:2, C:4, D:5 ] odw = {A,B} + ↑ + B→D=2+3=5 (relaksacja) + + Krok 3: przeszukaj tablicę → min = C (4) + d = [ A:0, B:2, C:4, D:5 ] odw = {A,B,C} + ↑ + C→D=4+5=9 > 5, nie zmieniaj + + Krok 4: min = D (5). Koniec! d = [A:0, B:2, C:4, D:5] + + Każdy krok = przejrzyj V elementów → 4 kroki × 4 elementy = 16 operacji = O(V²) + +**Kopiec (heap)** — drzewiasta struktura danych, w której element minimalny jest zawsze na szczycie. Wyciąganie minimum: O(log n). W Dijkstrze z kopcem: szukanie min d[v] to O(log V) zamiast O(V) → **O((V+E) log V)**. + +Przykład — ten sam graf, ale z kopcem (min-heap): + + Kopiec na starcie: (0,A) ← min zawsze na szczycie + (reszta to ∞) + + Krok 1: pop (0,A) — O(log 4)=O(2), relaksuj sąsiadów: + push (2,B), push (4,C) + + Kopiec: (2,B) + / \ + (4,C) ... + + Krok 2: pop (2,B) — O(log 4), relaksuj: + push (5,D) + + Kopiec: (4,C) + / + (5,D) + + Krok 3: pop (4,C) — O(log 4). C→D: 9 > 5, nie zmieniaj. + Krok 4: pop (5,D) — O(log 4). Koniec! + + Każdy pop = O(log V), każdy push = O(log V) + V popów + E pushów = O((V+E) log V) + +**Kopiec Fibonacciego** — zaawansowany kopiec, w którym operacja „zmniejsz klucz" (decrease-key) działa w zamortyzowanym O(1) zamiast O(log V). Dijkstra robi decrease-key dla każdej krawędzi → z kopcem Fib: **O(V log V + E)** — E operacji po O(1) + V wyciągnięć po O(log V). + +Przykład — kluczowa różnica: decrease-key: + + Zwykły kopiec — gdy znajdziesz krótszą drogę do D: + d[D] zmienia się z 9 na 5 + Trzeba „naprawić" kopiec: przesuwaj D w górę → O(log V) + + Kopiec Fibonacciego — ta sama sytuacja: + d[D] zmienia się z 9 na 5 + Po prostu odetnij D od rodzica i wstaw do listy korzeni → O(1)! + (naprawienie struktury odłożone na później — „zamortyzowane") + + Różnica ma znaczenie przy GĘSTYCH grafach (E >> V): + - Zwykły kopiec: E × O(log V) = O(E log V) na decrease-key + - Kopiec Fib: E × O(1) = O(E) na decrease-key + Razem: O(V log V) [pop] + O(E) [decrease-key] = O(V log V + E) + +**Złożoność — dlaczego takie wartości:** +- **O(V²)** z tablicą: V razy szukaj minimum (O(V) każdy) = V × V. +- **O((V+E) log V)** z kopcem: V wyciągnięć min (O(log V)) + E relaksacji z decrease-key (O(log V)). +- **O(V log V + E)** z kopcem Fib: V wyciągnięć min (O(log V)) + E decrease-key (O(1) zamortyzowane). + +**Programowanie dynamiczne (DP)** — technika rozwiązywania problemów przez rozbicie na mniejsze podproblemy i zapamiętywanie wyników (żeby nie liczyć tego samego dwa razy). Bellman-Ford jest DP: podproblem = „najkrótsza ścieżka do v używająca ≤ k krawędzi"; rozwiązuje dla k = 1, 2, ..., V−1. + +**Cykl** — ścieżka w grafie, która wraca do punktu wyjścia (A → B → C → A). **Cykl ujemny** — cykl, w którym suma wag < 0. Problem: za każdym obejściem cyklu „odległość" maleje — można iść w nieskończoność → najkrótsza ścieżka nie istnieje (= −∞). + +**Dlaczego O(V·E) w Bellman-Ford:** Algorytm wykonuje |V|−1 iteracji (bo najdłuższa najkrótsza ścieżka bez cykli ma co najwyżej V−1 krawędzi). W każdej iteracji relaksuje WSZYSTKIE |E| krawędzi. Razem: (V−1) × E ≈ O(V·E). + +**Heurystyczny** — wykorzystujący przybliżone oszacowanie (heurystykę) zamiast dokładnych obliczeń. A* jest heurystyczny: używa funkcji h(n) do zgadywania „ile jeszcze do celu". + +**f(n), g(n), h(n) — co oznacza n i każda funkcja:** +- **n** = aktualnie rozpatrywany wierzchołek. +- **g(n)** = dotychczasowy koszt dotarcia od startu do n (znany, dokładny). +- **h(n)** = heurystyka: OSZACOWANIE kosztu od n do celu (przybliżone, „zgadywane"). Np. odległość w linii prostej do celu. +- **f(n) = g(n) + h(n)** = oszacowanie CAŁKOWITEGO kosztu ścieżki przez n. A* zawsze rozwija wierzchołek o najniższym f(n). + +**Dopuszczalna (admissible)** — heurystyka h jest dopuszczalna, jeśli NIGDY nie przeszacowuje: h(n) ≤ prawdziwy koszt od n do celu. Gwarantuje, że A* znajdzie optymalną ścieżkę. Np. odległość w linii prostej jest dopuszczalna (nie da się dojechać krócej niż prosto). + +**Rzeczywisty koszt** — prawdziwa najkrótsza odległość (nie oszacowanie). Np. faktyczna najkrótsza droga od n do celu, uwzględniając wszystkie krawędzie. + +**n → cel** — od wierzchołka n do wierzchołka docelowego (cel = destination = target). + +**Spójna (consistent / monotone)** — silniejszy warunek na heurystykę: h(n) ≤ w(n,m) + h(m) dla każdej krawędzi n→m. Tu **w(n,m)** = waga krawędzi z n do m, a **m** = sąsiad n. Spójność oznacza: oszacowanie z n nie jest „dużo lepsze" niż to co uzyskasz idąc jeden krok do m. Spójna ⇒ dopuszczalna (ale nie odwrotnie). + +**Dlaczego O(V) w najlepszym przypadku A*:** Jeśli heurystyka jest idealna (h(n) = prawdziwy koszt), A* idzie prosto do celu, nie eksplorując zbędnych wierzchołków — odwiedza tylko te na optymalnej ścieżce ≈ O(V) jeśli ścieżka krótka. **Najgorszy przypadek** = h(n) = 0 dla wszystkich n → A* degeneruje się do Dijkstry. + +### Pseudokod (Python) + +**Dijkstra:** + + import heapq + def dijkstra(graph, start): + d = {v: float('inf') for v in graph} + d[start] = 0 + pq = [(0, start)] # (odległość, wierzchołek) + while pq: + dist_u, u = heapq.heappop(pq) + if dist_u > d[u]: continue # nieaktualny wpis + for v, w in graph[u]: # v=sąsiad, w=waga + if d[u] + w < d[v]: # relaksacja + d[v] = d[u] + w + heapq.heappush(pq, (d[v], v)) + return d + +**Bellman-Ford:** + + def bellman_ford(vertices, edges, start): + d = {v: float('inf') for v in vertices} + d[start] = 0 + for _ in range(len(vertices) - 1): # V-1 iteracji + for u, v, w in edges: # każda krawędź + if d[u] + w < d[v]: # relaksacja + d[v] = d[u] + w + # Wykrywanie cyklu ujemnego: + for u, v, w in edges: + if d[u] + w < d[v]: + return None # cykl ujemny! + return d + +**A*:** + + def a_star(graph, start, goal, h): + d = {start: 0} + pq = [(h(start), start)] # f = g + h + came_from = {} + while pq: + f_u, u = heapq.heappop(pq) + if u == goal: break # znaleziono! + for v, w in graph[u]: + g_new = d[u] + w + if v not in d or g_new < d[v]: + d[v] = g_new + heapq.heappush(pq, (g_new + h(v), v)) + came_from[v] = u + return came_from, d.get(goal) + +--- + +### Dijkstra — zachłanny, SSSP + +**Ograniczenie:** wagi ≥ 0. +**Idea:** Relaksacja krawędzi; zawsze przetwarzaj wierzchołek o najmniejszym d[v]. +**Złożoność:** O(V²) z tablicą, O((V+E) log V) z kopcem, O(V log V + E) z kopcem Fibonacciego. +**Dlaczego nie ujemne wagi?** Raz oznaczony wierzchołek nie jest rewidowany — ujemna krawędź może go poprawić. + +### Bellman-Ford — programowanie dynamiczne, SSSP + +**Zaleta:** obsługuje ujemne wagi + **wykrywa cykle ujemne**. +**Idea:** |V|−1 iteracji relaksacji WSZYSTKICH krawędzi. Jeśli w iteracji V nadal można poprawić → cykl ujemny. +**Złożoność:** O(V·E) — zawsze. + +### A* — heurystyczny, Single-Pair + +**Rozszerzenie Dijkstry:** f(n) = g(n) + h(n), gdzie h(n) to heurystyka. +**Wymóg:** h dopuszczalna (admissible): h(n) ≤ rzeczywisty koszt n→cel. Jeśli h spójna (consistent): h(n) ≤ w(n,m) + h(m) — optymalne. +**Złożoność:** zależy od h; najlepszy przypadek O(V), najgorszy jak Dijkstra. + +### Porównanie + +| Cecha | Dijkstra | Bellman-Ford | A* | +|-----------------|------------------|-----------------|-------------------| +| Typ | Zachłanny | Prog. dynamiczne| Heurystyczny | +| Problem | SSSP | SSSP | Single-pair | +| Ujemne wagi | NIE | TAK | NIE | +| Wykrywa cykle- | NIE | TAK | NIE | +| Złożoność | O((V+E)log V) | O(VE) | Zależy od h | + +### Etymologia + +**Dijkstra** — Edsger W. Dijkstra (Holandia, 1959); pionier informatyki (Turing Award 1972). **Bellman-Ford** — Richard Bellman (twórca programowania dynamicznego) + Lester Ford Jr. (1956). **A*** — Hart, Nilsson, Raphael (Stanford, 1968); „A*" = ulepszona wersja algorytmu „A". **Zachłanny (Greedy)** — algorytm „chciwie" bierze lokalnie najlepszą opcję. **SSSP** — Single-Source Shortest Path. **Programowanie dynamiczne** — Bellman wybrał „dynamic" by brzmiało imponująco dla polityków (nie miało związku z dynamiką!). **Heurystyka** — grec. „heuriskein" = znajdować (to samo co „Eureka!" Archimedesa). **Relaksacja** — „rozluźnianie" górnego ograniczenia na odległość d[v]. + +### Jak zapamiętać + +- **Dijkstra = chciwy**, bierze minimum — ale „nie patrzy wstecz" (stąd problem z ujemnymi wagami) +- **Bellman-Ford = brute force x (V−1)** — relaksuj wszystko, V−1 razy, bo najdłuższa ścieżka ma V−1 krawędzi +- **A* = Dijkstra + „GPS"** — heurystyka mówi w którą stronę jest cel + +\newpage + +## PYTANIE 3: Redundancja i normalizacja (BD2) + +**Omówić zagadnienia redundancji i normalizacji w relacyjnej bazie danych.** + +--- + +### Tło pojęciowe — słowniczek + +**Relacja (tabela)** — w bazie danych: tabela z kolumnami (atrybutami) i wierszami (krotkami/rekordami). Np. tabela Studenci z kolumnami: StudentID, Imię, Nazwisko, WydziałID. + +**Atrybut (attribute)** — kolumna w tabeli. Np. „Imię", „WydziałID", „NazwaKursu". Każdy atrybut ma nazwę i typ danych (tekst, liczba, data itp.). + +**Klucz główny (primary key, PK)** — kolumna (lub zestaw kolumn), której wartość JEDNOZNACZNIE identyfikuje każdy wiersz. Np. StudentID = 12345 → dokładnie jeden student. Nie może się powtarzać, nie może być NULL. + +**Klucz złożony (composite key)** — klucz główny składający się z WIĘCEJ NIŻ JEDNEJ kolumny. Np. klucz (StudentID, KursID) — jeden student na jednym kursie to unikalny zapis. Sam StudentID ani sam KursID nie wystarczą, bo student ma wiele kursów, a kurs ma wielu studentów. + +**Atrybut wtórny (non-prime attribute)** — kolumna, która NIE jest częścią żadnego klucza kandydującego. Np. w tabeli z kluczem (StudentID, KursID): NazwaKursu, Ocena, NazwaWydziału — to atrybuty wtórne (nie identyfikują wiersza). **Atrybut pierwszy (prime)** — kolumna, która JEST częścią jakiegoś klucza (np. StudentID). + +**Nadklucz (superkey)** — dowolny zbiór kolumn, który JEDNOZNACZNIE identyfikuje wiersz. Każdy klucz główny jest nadkluczem, ale nadklucz może mieć „nadmiarowe" kolumny. Np. {StudentID} to klucz i nadklucz; {StudentID, Imię} to nadklucz (ale nie minimalny klucz). + +**Redundancja** — powtarzanie tych samych danych w wielu miejscach. Nie chodzi o kopie zapasowe — chodzi o niepotrzebne duplikowanie informacji w tabeli. + +Przykład — tabela StudentKursy (ZŁEJ konstrukcji, BEZ normalizacji): + + | StudentID | Imię | WydziałID | NazwaWydziału | KursID | NazwaKursu | + |-----------|-------|-----------|---------------|--------|------------| + | 1 | Anna | W4 | EiTI | K10 | Bazy danych| + | 1 | Anna | W4 | EiTI | K20 | Algorytmy | + | 2 | Jan | W4 | EiTI | K10 | Bazy danych| + | 3 | Ewa | W2 | Fizyka | K30 | Optyka | + +Problem: „Anna", „W4", „EiTI", „Bazy danych" powtórzone wielokrotnie! + +**Anomalia** — niepożądany efekt uboczny operacji na redundantnych danych. Trzy typy: + +**Anomalia wstawiania** — nie możesz dodać danych bez podania niepotrzebnych powiązań. +- Przykład: chcesz dodać nowy wydział W5 „Chemia" do systemu, ale nie ma jeszcze żadnego studenta na tym wydziale. W tej tabeli NIE DA SIĘ — bo StudentID (część klucza) nie może być NULL. + +**Anomalia usuwania** — usuwając jeden fakt, tracisz niezwiązany inny. +- Przykład: Ewa (jedyny student Fizyki) rezygnuje → usuwasz jej wiersz → tracisz informację, że wydział W2 to „Fizyka" i istnieje kurs „Optyka". Dane o wydziale i kursie znikają razem ze studentem! + +**Anomalia modyfikacji** — zmiana jednego faktu wymaga aktualizacji wielu wierszy. +- Przykład: wydział W4 zmienia nazwę z „EiTI" na „Informatyka". Trzeba zaktualizować KAŻDY wiersz, w którym jest NazwaWydziału = „EiTI" (tu: 3 wiersze). Jeśli pominiesz jeden → niespójność. + +**Zależność funkcyjna (FD — Functional Dependency):** X → Y oznacza: „znając wartość X, ZAWSZE mogę jednoznacznie wyznaczyć Y". Jak funkcja matematyczna: f(x) daje dokładnie jedno y. Np. StudentID → Imię (jeden student = jedno imię), KursID → NazwaKursu (jeden kurs = jedna nazwa). **X → Y NIE oznacza Y → X!** (StudentID → WydziałID, ale WydziałID → StudentID NIE — na wydziale jest wielu studentów). + +**Zależność przechodnia (transitive dependency):** A → B i B → C, więc A → C „przez pośrednika B". Np. StudentID → WydziałID → NazwaWydziału. StudentID nie określa bezpośrednio NazwaWydziału — robi to pośrednio przez WydziałID. Problem: NazwaWydziału „zależy od czegoś, co nie jest kluczem" → redundancja. + +**Nietrywialna FD:** X → A, gdzie A nie jest częścią X. Np. StudentID → Imię (nietrywialna: Imię ≠ StudentID). Ale {StudentID, Imię} → StudentID jest TRYWIALNA (StudentID jest częścią lewej strony — oczywiste). W BCNF sprawdzamy tylko nietrywialne FD. + +**Wielowartościowa zależność (MVD — Multi-Valued Dependency):** X →→ Y oznacza: dla jednej wartości X istnieje ZBIÓR wartości Y, niezależny od reszty. Np. Student →→ Hobby i Student →→ Kurs: hobby Ani nie zależą od jej kursów i odwrotnie, ale ich połączenie tworzy iloczyn kartezjański (niepotrzebne powtórzenia). + +**Dekompozycja** — rozbicie jednej dużej tabeli na kilka mniejszych, połączonych kluczami obcymi. Cel: każda tabela przechowuje JEDEN fakt. **Normalizacja eliminuje redundancję** właśnie przez dekompozycję — informacja zamiast być powtarzana w wielu wierszach, przechowywana jest RAZ w osobnej tabeli i łączona przez JOIN. + +Przykład dekompozycji powyższej tabeli: + + Studenci: Wydziały: Kursy: + | StID | Imię | WydziałID | | WydziałID | Nazwa | | KursID | Nazwa | + |------|------|-----------| |-----------|-------| |--------|------------| + | 1 | Anna | W4 | | W4 | EiTI | | K10 | Bazy danych| + | 2 | Jan | W4 | | W2 |Fizyka | | K20 | Algorytmy | + | 3 | Ewa | W2 | | K30 | Optyka | + + Zapisy (StudentID, KursID): + | StID | KursID | + |------|--------| + | 1 | K10 | + | 1 | K20 | + | 2 | K10 | + | 3 | K30 | + + Teraz: „EiTI" zapisane RAZ (w Wydziały). Zmiana nazwy = 1 wiersz. + +**Atomowe wartości (1NF)** — każda komórka zawiera JEDNĄ niepodzielną wartość. NIE listy, NIE zbiory, NIE tabele w komórce. + + ŹLE (łamie 1NF): DOBRZE (1NF): + | Student | Kursy | | Student | Kurs | + |---------|-----------------| |---------|-------------| + | Anna | BD, Algorytmy | | Anna | BD | + | Jan | BD | | Anna | Algorytmy | + | Jan | BD | + +### Przykłady postaci normalnych + +**Przykład naruszenia 2NF** — klucz złożony (StudentID, KursID): + + | StudentID | KursID | NazwaKursu | Ocena | + |-----------|--------|-------------|-------| + | 1 | K10 | Bazy danych | 5 | + | 2 | K10 | Bazy danych | 4 | + + NazwaKursu zależy TYLKO od KursID, nie od pełnego klucza (StudentID, KursID). + To „częściowa zależność" → łamie 2NF. + Naprawa: wydziel Kursy(KursID, NazwaKursu) osobno. + +**Przykład naruszenia 3NF** — klucz StudentID: + + | StudentID | Imię | WydziałID | NazwaWydziału | + |-----------|-------|-----------|---------------| + | 1 | Anna | W4 | EiTI | + | 2 | Jan | W4 | EiTI | ← „EiTI" powtórzone! + + StudentID → WydziałID → NazwaWydziału (zależność przechodnia!). + NazwaWydziału zależy od WydziałID, a nie bezpośrednio od klucza. + Naprawa: wydziel Wydziały(WydziałID, NazwaWydziału). + +**Przykład naruszenia BCNF:** + + Przedmioty prowadzone — klucz: (Student, Przedmiot) + | Student | Przedmiot | Prowadzący | + |---------|-----------|------------| + | Anna | BD | Kowalski | + | Jan | BD | Kowalski | + | Anna | Algo | Nowak | + + FD: Prowadzący → Przedmiot (jeden prowadzący = jeden przedmiot). + Prowadzący NIE jest nadkluczem → łamie BCNF. + (Spełnia 3NF, bo Przedmiot jest atrybutem pierwszym — wyjątek 3NF.) + Naprawa: StudentProwadzący(Student, Prowadzący) + ProwadzącyPrzedmiot(Prowadzący, Przedmiot). + +**Przykład naruszenia 4NF:** + + | Student | Hobby | Kurs | + |---------|----------|-----------| + | Anna | Szachy | BD | + | Anna | Szachy | Algorytmy | + | Anna | Bieganie | BD | + | Anna | Bieganie | Algorytmy | + + Student →→ Hobby i Student →→ Kurs (niezależne wielowartościowe zależności). + Hobby i Kursy nie mają ze sobą nic wspólnego, ale tworzą iloczyn kartezjański. + Naprawa: StudentHobby(Student, Hobby) + StudentKurs(Student, Kurs). + +--- + +### Redundancja — powtarzanie danych + +Prowadzi do trzech **anomalii**: +1. **Wstawiania** — nie można dodać danych bez zbędnych powiązań +2. **Usuwania** — usunięcie rekordu kasuje niezwiązane informacje +3. **Modyfikacji** — zmiana jednej informacji wymaga wielu aktualizacji + +### Normalizacja — eliminacja redundancji przez dekompozycję + +**Zależność funkcyjna:** X → Y — wartość X jednoznacznie określa Y. + +### Postacie normalne (5NF ⊂ 4NF ⊂ BCNF ⊂ 3NF ⊂ 2NF ⊂ 1NF) + +**1NF:** Atomowe wartości, brak list/tablic w komórkach, istnieje klucz główny. + +**2NF:** 1NF + każdy atrybut wtórny zależy od CAŁEGO klucza (dotyczy kluczy złożonych). +- Naruszenie: NazwaKursu zależy tylko od KursID, nie od (StudentID, KursID). + +**3NF:** 2NF + brak zależności przechodnich (atrybut wtórny nie zależy od innego wtórnego). +- Naruszenie: StudentID → WydziałID → NazwaWydziału. + +**BCNF:** Dla każdej nietrywialnej FD X→A, X jest nadkluczem. Silniejsza niż 3NF. + +**4NF:** BCNF + brak wielowartościowych zależności nietrywialnych. + +### Denormalizacja + +Świadome wprowadzanie redundancji dla wydajności (mniej JOIN-ów). Stosowane w systemach analitycznych (OLAP), data warehousing. + +### Etymologia + +**Redundancja** — łac. „redundantia" = nadmiar/przelewanie się. **Normalizacja** — Edgar F. Codd (IBM, 1970, „A Relational Model of Data"); 1NF–3NF w oryginalnej pracy. **BCNF** — Raymond Boyce + Codd (1974). **Anomalia** — grec. „anomalia" = nieregularność. **„Klucz, cały klucz i tylko klucz"** — parafraza przysięgi sądowej; przypisywana Coddowi. **Zależność funkcyjna** — jak funkcja mat.: X jednoznacznie wyznacza Y. + +### Jak zapamiętać + +- **„Klucz, cały klucz i tylko klucz — tak mi dopomóż Codd"** — 1NF (klucz), 2NF (cały klucz), 3NF (tylko klucz) +- **3 anomalie:** Wstawianie, Usuwanie, Modyfikacja — „WUM" +- **BCNF:** jak 3NF, ale lewa strona FD zawsze nadklucz (bez wyjątku dla atrybutów pierwszych) + +\newpage + +## PYTANIE 4: Baza danych jako fundament systemów (BD2) + +**Dlaczego baza danych stanowi dobry fundament do budowy wielu systemów informatycznych?** + +--- + +### Tło pojęciowe — słowniczek + +**System informatyczny** — oprogramowanie realizujące jakąś funkcję: sklep internetowy, system bankowy, CRM, system rezerwacji. Każdy taki system potrzebuje PRZECHOWYWAĆ dane i OPEROWAĆ na nich. Baza danych daje gotowe, sprawdzone mechanizmy do tego — nie trzeba ich pisać od zera. + +**Dlaczego DB to „dobry fundament"?** — Bez bazy danych każdy system musi SAM rozwiązywać: „co jeśli prąd padnie w trakcie zapisu?", „co jeśli dwóch użytkowników edytuje to samo?", „jak chronić dane?". Baza dostarcza to wszystko „z pudełka" → programista skupia się na logice biznesowej, nie na infrastrukturze. + +--- + +**Transakcja** — logiczna jednostka pracy: zestaw operacji, które MUSZĄ wykonać się razem jako całość. Np. przelew bankowy = (1) odejmij 100 zł od Ani + (2) dodaj 100 zł Janowi. Nie może być tak, że tylko (1) się wykona, a (2) nie — pieniądze by „zniknęły". + +**ACID** — cztery właściwości, które baza gwarantuje dla każdej transakcji: + +**Atomicity (Atomowość)** — „albo cała, albo nic" (all-or-nothing). Jeśli COKOLWIEK w transakcji się nie powiedzie (błąd, crash, brak pamięci), WSZYSTKIE zmiany tej transakcji są cofane (rollback). Jakby nic się nie stało. Np. przelew: jeśli krok (2) się nie uda, krok (1) jest automatycznie cofany — saldo Ani wraca do stanu sprzed przelewu. + +**Jak to odpowiada na pytanie:** Bez atomowości system bankowy mógłby tracić pieniądze przy każdym crashu. Baza gwarantuje, że KAŻDA operacja jest bezpieczna → solidny fundament. + +**Consistency (Spójność)** — transakcja przeprowadza bazę ze SPÓJNEGO stanu w inny SPÓJNY stan. **Stan** = aktualna zawartość wszystkich tabel w bazie (wszystkie dane w danym momencie). **Spójny stan** = stan, w którym WSZYSTKIE reguły (constraints) są spełnione. Np. „saldo ≥ 0", „każde zamówienie ma klienta", „PESEL ma 11 cyfr". **Spójny → spójny** = transakcja NIE MOŻE zostawić bazy w stanie łamiącym reguły. Np. przelew: suma pieniędzy w systemie przed = suma po (nie da się „stworzyć" pieniędzy). + +**Jak to odpowiada na pytanie:** Dane w systemie ZAWSZE mają sens. Nie będzie zamówienia bez klienta, produktu z ceną −5 zł, ani studenta z oceną 7. + +**Isolation (Izolacja)** — równoległe (jednoczesne) transakcje nie widzą nawzajem swoich niedokończonych zmian. Każda transakcja „myśli", że jest jedyną operacją na bazie. Np. Ania przelewa 100 zł a Jan sprawdza saldo — Jan widzi ALBO stan przed przelewem, ALBO po, NIGDY stan pośredni (np. „Ania odjęła, ale Jan jeszcze nie dostał"). + +**Jak to odpowiada na pytanie:** System może obsługiwać TYSIĄCE użytkowników jednocześnie bez chaosu. Każdy widzi spójne dane. + +**Durability (Trwałość)** — po zatwierdzeniu transakcji (COMMIT), jej efekty przetrwają KAŻDĄ awarię: crash serwera, awaria dysku, przerwa w zasilaniu. Baza zapisuje zmiany do trwałego magazynu (dysk, WAL — Write-Ahead Log). Nawet jeśli serwer padnie 1 ms po COMMIT, dane są bezpieczne. + +**Jak to odpowiada na pytanie:** System nie traci danych. Klient płaci za zamówienie → zamówienie jest zapisane NA ZAWSZE, nawet jeśli serwer zaraz potem się wyłączy. + +--- + +**ANSI** — American National Standards Institute: amerykańska organizacja normalizacyjna (odpowiednik polskiego PKN). Ustala standardy techniczne. + +**SPARC** — Standards Planning And Requirements Committee: komitet przy ANSI, który w 1975 zaproponował 3-poziomową architekturę baz danych. + +**3-poziomowa architektura ANSI/SPARC:** + + Poziom zewnętrzny — CO widzi użytkownik/aplikacja (widoki, podzbiory danych) + Poziom konceptualny — JAKA jest struktura danych (tabele, kolumny, relacje) + Poziom wewnętrzny — JAK dane są fizycznie przechowywane (pliki, indeksy, bloki) + +Dzięki tym 3 poziomom zmiany na jednym poziomie NIE wymuszają zmian na innych. + +**Niezależność fizyczna** — zmiana SPOSOBU przechowywania (np. dodanie indeksu, zmiana partycjonowania) nie wymaga zmiany aplikacji. + +**Indeks (index)** — struktura pomocnicza przyspieszająca wyszukiwanie (jak indeks w książce — nie czytasz całej książki, szukasz po indeksie). Np. indeks na kolumnie „Nazwisko" pozwala szybko znaleźć studenta po nazwisku, bez przeszukiwania milionów wierszy. Dodanie/usunięcie indeksu NIE zmienia danych ani zapytań SQL — aplikacja działa tak samo, tylko szybciej. + +**Partycjonowanie (partitioning)** — podział dużej tabeli na mniejsze kawałki (partycje). Np. tabela Zamówienia podzielona na partycje wg roku: 2024, 2025, 2026. Zapytanie o 2025 przeszukuje TYLKO tę partycję. Zmiana partycjonowania jest przezroczysta dla aplikacji. + +**Niezależność logiczna** — zmiana struktury tabel minimalizuje wpływ na aplikacje. Np. rozdzielasz tabelę StudentKursy na Studenci + Zapisy, ale tworzysz **widok (view)** = „wirtualna tabela" symulująca starą strukturę. Aplikacja dalej pyta o ten sam widok — dla niej nic się nie zmieniło. + +**Jak to odpowiada na pytanie:** System może EWOLUOWAĆ (rosnąć, zmieniać strukturę, optymalizować) BEZ przepisywania aplikacji. Baza oddziela „co" od „jak" → elastyczny fundament. + +--- + +**Współbieżność (concurrency)** — wielu użytkowników/procesów operuje na bazie JEDNOCZEŚNIE. Np. 1000 osób kupuje bilety w tym samym momencie. Baza musi zapewnić, że nie sprzedadzą dwóch biletów na to samo miejsce. + +**Blokady (locks)** — najprostszy mechanizm: transakcja „blokuje" wiersz/tabelę, inne muszą CZEKAĆ. Np. transakcja aktualizuje saldo Ani → saldo jest zablokowane → Jan nie może go modyfikować, czeka aż Ania skończy. Typy: shared lock (wiele odczytów jednocześnie) vs exclusive lock (tylko jedna transakcja pisze). + +**MVCC (Multi-Version Concurrency Control)** — zamiast blokować, baza trzyma WIELE WERSJI danych. Transakcja czyta wersję z momentu swojego startu — nie jest blokowana przez zapis. Np. Jan czyta saldo (wersja sprzed przelewu), Ania jednocześnie przelewa (tworzy nową wersję). Nikt nie czeka! + +**Snapshot Isolation** — wariant MVCC: każda transakcja widzi „migawkę" (snapshot) bazy z momentu swojego startu. Nawet jeśli inne transakcje zmieniają dane, ta widzi SPÓJNY obraz z przeszłości. Eliminuje większość problemów z współbieżnym czytaniem. + +**Jak to odpowiada na pytanie:** Baza automatycznie zarządza dostępem wielu użytkowników → system może obsługiwać setki/tysiące jednoczesnych połączeń bez ręcznego pisania mechanizmów synchronizacji. + +--- + +**Integralność (integrity)** — dane w bazie ZAWSZE spełniają zdefiniowane reguły. Baza SAMA pilnuje reguł — nie trzeba ich sprawdzać w kodzie aplikacji. + +**Klucze obce (foreign keys, FK)** — wiersz w tabeli MUSI odnosić się do istniejącego wiersza w innej tabeli. Np. Zamówienia.KlientID MUSI wskazywać na istniejącego klienta w tabeli Klienci. Nie możesz wstawić zamówienia dla klienta „999" jeśli nie ma klienta o ID 999. NIE możesz usunąć klienta, który ma zamówienia. + +**CHECK** — ograniczenie na wartości kolumny. Np. `CHECK (wiek >= 0 AND wiek <= 150)` — baza ODRZUCI próbę wstawienia osoby z wiekiem −5 lub 200. `CHECK (status IN ('aktywny', 'nieaktywny'))` — nie wpiszesz statusu „cokolwiek". + +**Trigger (wyzwalacz)** — fragment kodu uruchamiany AUTOMATYCZNIE, gdy coś się dzieje w bazie. Np. `AFTER INSERT ON Zamówienia` → automatycznie zmniejsz stan magazynowy produktu. Trigger „pilnuje" reguł, których nie da się wyrazić samym CHECK-iem. + +**Procedura składowana (stored procedure)** — funkcja zapisana W BAZIE (nie w aplikacji), wywoływana z SQL. Np. `CALL przelejPieniadze(101, 102, 500)` — cała logika przelewu w jednym miejscu, współdzielona przez wszystkie aplikacje. + +**Jak to odpowiada na pytanie:** Reguły biznesowe (np. „nie sprzedawaj produktu z zerowym stanem") wymuszane PRZEZ bazę, nie PRZEZ aplikację → nawet jeśli ktoś napisze błędną aplikację, baza nie pozwoli złamać reguł. + +--- + +**Optymalizator zapytań (query optimizer)** — moduł bazy, który automatycznie wybiera NAJSZYBSZY sposób wykonania zapytania SQL. Programista pisze CO chce (`SELECT ... WHERE ...`), a optymalizator decyduje JAK to zrobić (np. użyć indeksu czy przeszukać całą tabelę, w jakiej kolejności łączyć tabele). **Plan wykonania (execution plan)** — sekwencja kroków, którą baza wykona. Np. „użyj indeksu na Nazwisko → odfiltruj wiersze → posortuj". + +**Jak to odpowiada na pytanie:** Programista nie musi znać struktury fizycznej danych. Pisze prosty SQL, a baza SAMA optymalizuje → szybkość „za darmo". + +--- + +**Bezpieczeństwo (security):** + +**GRANT/REVOKE** — polecenia SQL do nadawania/odbierania uprawnień. Np. `GRANT SELECT ON Studenci TO Dziekanat` — dziekanat może CZYTAĆ studentów, ale nie modyfikować. `REVOKE INSERT ON Zamówienia FROM Praktykant` — praktykant nie może dodawać zamówień. + +**Role** — grupy uprawnień. Zamiast nadawać uprawnienia każdemu użytkownikowi osobno, tworzysz rolę (np. „Kasjer") i przypisujesz ją użytkownikom. Kasjer = SELECT + INSERT na Zamówienia, ale bez dostępu do tabeli Pracownicy. + +**Szyfrowanie (encryption)** — dane na dysku i w transmisji zamienione na nieczytelny ciąg, który wymaga klucza do odszyfrowania. TDE (Transparent Data Encryption) = szyfrowanie „przezroczyste" — aplikacja nie wie, że dane są szyfrowane. + +**Audyt (audit)** — baza rejestruje KTO, KIEDY, CO zrobił. Np. „użytkownik Kowalski zmodyfikował saldo klienta 123 o 15:42". Niezbędne dla zgodności z prawem (RODO, SOX, PCI-DSS). + +**Jak to odpowiada na pytanie:** Baza chroni dane przez kontrolę dostępu, szyfrowanie i śledzenie zmian → fundament bezpieczeństwa systemu. + +--- + +**Skalowalność (scalability)** — zdolność systemu do ROŚNIĘCIA (więcej danych, więcej użytkowników) bez utraty wydajności. + +**Replikacja (replication)** — kopia bazy na wielu serwerach. Np. master (zapis) + 3 repliki (odczyt). 80% zapytań to odczyty → rozkładasz je na repliki. Jeśli master padnie, replika przejmuje rolę. + +**Sharding (fragmentacja)** — podział danych na kawałki (shardy) na RÓŻNYCH serwerach. Np. klienci A–M na serwerze 1, N–Z na serwerze 2. Każdy serwer przechowuje i obsługuje MNIEJSZY zbiór danych → szybciej. + +**Klaster (cluster)** — grupa serwerów pracujących RAZEM jako jeden system. Np. klaster PostgreSQL Citus albo MySQL NDB Cluster — z zewnątrz wygląda jak jedna baza, ale fizycznie to wiele maszyn. + +**Jak to odpowiada na pytanie:** System może obsłużyć od 10 do 10 000 000 użytkowników bez zmiany architektury aplikacji → baza rośnie razem z systemem. + +--- + +**SQL (Structured Query Language)** — standardowy język zapytań do baz relacyjnych. TEN SAM SQL działa (z drobnymi różnicami) w PostgreSQL, MySQL, Oracle, SQL Server, SQLite. Programista, który zna SQL, może pracować z KAŻDĄ z tych baz. + +**Jak to odpowiada na pytanie:** Jeden uniwersalny interfejs → łatwość wymiany bazy danych, łatwe znalezienie programistów, bogactwo narzędzi, ORM-ów i bibliotek. Nie trzeba uczyć się osobnego języka dla każdego systemu. + +--- + +### 1. Transakcyjność ACID + +| Właściwość | Znaczenie | +|------------|-----------| +| **A**tomicity | Transakcja — albo cała, albo nic | +| **C**onsistency | Spójny stan → spójny stan | +| **I**solation | Równoległe transakcje nie interferują | +| **D**urability | Zatwierdzone zmiany przetrwają awarię | + +### 2. Niezależność danych (3-poziomowa architektura ANSI/SPARC) + +- **Fizyczna:** zmiana indeksów/partycjonowania nie wpływa na aplikacje +- **Logiczna:** zmiana schematu minimalizuje wpływ na aplikacje (widoki) + +### 3. Współbieżność — mechanizmy: blokady, MVCC, snapshot isolation + +### 4. Integralność — klucze obce, CHECK, triggery, procedury składowane + +### 5. Optymalizator zapytań — automatyczny wybór planu wykonania + +### 6. Bezpieczeństwo — GRANT/REVOKE, role, szyfrowanie, audyt + +### 7. Skalowalność — replikacja, sharding, klastry + +### 8. Standardowy interfejs — SQL jako uniwersalny język zapytań + +### Etymologia + +**ACID** — akronim: Reuter & Härder (1983); celowo łatwy do zapamiętania. **ANSI/SPARC** — American National Standards Institute / Standards Planning And Requirements Committee (1975). **SQL** — oryginalnie SEQUEL (Structured English Query Language, Chamberlin & Boyce, IBM 1974); zmieniono na SQL przez konflikt znaku towarowego. **MVCC** — Multi-Version Concurrency Control. **Transakcja** — łac. „transactio" = doprowadzenie do końca. + +### Jak zapamiętać + +- **ACID** — zapamiętaj przelew bankowy: bez A tracisz pieniądze, bez C saldo < 0, bez I widać stan pośredni, bez D znika po crashu +- **„DB = centralne źródło prawdy"** — jedna baza vs. pliki rozproszone po systemach +- Kluczowe słowa: trwałość, współbieżność, integralność, niezależność + +\newpage + +## PYTANIE 5: Kategorie STL (PROI) + +**Omówić główne kategorie elementów biblioteki STL.** + +--- + +### Tło pojęciowe — słowniczek + +**STL (Standard Template Library)** — część standardowej biblioteki C++ zawierająca gotowe struktury danych i algorytmy. „Template" = szablonowa: działa z DOWOLNYM typem danych (int, string, własna klasa) dzięki mechanizmowi templates (generyczność). Zamiast pisać osobno „sortuj tablicę intów" i „sortuj tablicę stringów", piszesz RAZ `sort` i działa dla WSZYSTKIEGO. + +**Template (szablon)** — mechanizm C++: piszesz kod raz z „placeholder-em" na typ, a kompilator generuje wersję dla każdego użytego typu. Np. `vector`, `vector` — ten sam kod wewnętrznie, ale dla różnych typów. + +--- + +### Cztery filary — dlaczego akurat te cztery? + +**Kontener (container)** — struktura danych przechowująca kolekcję elementów. „CO przechowujemy". Jak pudełko na dane: vector to tablica, map to słownik, set to zbiór. + +**Iterator** — obiekt wskazujący na element w kontenerze, umożliwiający przechodzenie (iterowanie) po elementach. „JAK się poruszamy po danych". Jak kursor/wskaźnik, który może iść do przodu, do tyłu, lub skoczyć na dowolną pozycję (zależy od typu iteratora). + +**Algorytm (algorithm)** — gotowa OPERACJA na danych: sortowanie, wyszukiwanie, kopiowanie, zliczanie itp. „CO ROBIMY z danymi". STL daje ~100 gotowych algorytmów. + +**Funktor (function object)** — obiekt, który zachowuje się jak funkcja (ma operator `()`). Służy do PARAMETRYZACJI algorytmów = mówi algorytmowi JAK porównywać, JAK przekształcać. Np. `sort` domyślnie sortuje rosnąco, ale funktor `greater` zmieni to na malejąco. + +**Operacje i parametryzacja** — algorytmy to operacje (sort, find, copy), a funktory to parametryzacja (JAK sortować? według jakiego kryterium? jaką transformację zastosować?). + +**Dlaczego właśnie te 4 to filary?** — Razem pozwalają wyrażać KAŻDĄ operację na danych: +1. Kontener = gdzie dane leżą +2. Iterator = jak się do nich dobrać +3. Algorytm = co z nimi zrobić +4. Funktor = jak dostosować algorytm + +Klucz: algorytmy NIE znają kontenerów. Komunikują się TYLKO przez iteratory. Dzięki temu M kontenerów + N algorytmów wymaga M+N implementacji (nie M×N). To się nazywa **architektura ortogonalna**. + +--- + +### Kontenery — szczegóły + +**Kontenery sekwencyjne** — elementy mają POZYCJĘ (kolejność ma znaczenie). Jak tablica, lista, kolejka. + +**vector (tablica dynamiczna)** — ciągły blok pamięci, jak tablica C, ale automatycznie rośnie. Dostęp do i-tego elementu: O(1) (bo pamięć ciągła). Dodawanie na końcu: zamortyzowane O(1). Wstawianie w środku: O(n) (trzeba przesunąć elementy). **Domyślny wybór** — najszybszy dzięki ciągłej pamięci (cache-friendly). + + vector v = {10, 20, 30, 40}; + v[2]; // 30 — dostęp O(1) + v.push_back(50); // dodaj na końcu O(1) + // Pamięć: [10|20|30|40|50] — ciągły blok + +**Co to jest „pamięć ciągła" (contiguous memory)?** + +Elementy leżą OBOK SIEBIE w RAM, jeden za drugim, bez przerw: + + Adres: 1000 1004 1008 1012 1016 + Dane: [10] [20] [30] [40] [50] + ↑ baza + + Adres i-tego elementu = baza + i × rozmiar_elementu + v[0] = adres 1000 + 0×4 = 1000 → 10 + v[2] = adres 1000 + 2×4 = 1008 → 30 + v[99]= adres 1000 + 99×4= 1396 → ??? + + To JEDNO mnożenie i JEDNO dodawanie — zawsze tyle samo, + niezależnie czy tablica ma 5 czy 5 000 000 elementów → O(1). + +W liście NIE MA ciągłej pamięci — węzły rozrzucone po całym RAM: + + Adres: 1000 5040 2200 + Dane: [10]→5040 [20]→2200 [30]→null + Żeby znaleźć element 2: 1000→5040→2200 = 2 skoki → O(n) + +Dodatkowo ciągła pamięć jest **cache-friendly**: CPU ładuje pamięć blokami (cache lines, 64B). Przy vector cały blok to przydatne dane. Przy list każdy skok to potencjalny cache miss → ~10-100× wolniej. + +**deque (Double-Ended QUEue)** — kolejka dwustronna. Szybkie dodawanie/usuwanie NA OBU KOŃCACH: O(1). Wewnętrznie: tablica wskaźników do bloków pamięci (nie jeden ciągły blok). Dostęp O(1) ale nieco wolniejszy niż vector (extra pośredniość). + + deque d = {10, 20, 30}; + d.push_front(5); // O(1) — dodaj z przodu + d.push_back(40); // O(1) — dodaj z tyłu + // [5|10|20|30|40] + +**list (lista dwukierunkowa)** — każdy element to węzeł z wskaźnikami do POPRZEDNIEGO i NASTĘPNEGO. Wstawianie/usuwanie w dowolnym miejscu: O(1) (jeśli masz iterator na to miejsce). Brak dostępu po indeksie! Żeby dostać 5. element, musisz przejść 5 kroków od początku. + + list l = {10, 20, 30}; + // 10 ↔ 20 ↔ 30 (dwukierunkowe wskaźniki) + auto it = l.begin(); advance(it, 1); // idź na pozycję 1 + l.insert(it, 15); // O(1): 10 ↔ 15 ↔ 20 ↔ 30 + +**Dlaczego wstawianie to O(1)?** Bo wystarczy „przepiąć" 2 wskaźniki: + + PRZED: ... ↔ [A|→B] ↔ [B|→C] ↔ ... + Wstaw X między A i B: + 1. X.next = B + 2. X.prev = A + 3. A.next = X + 4. B.prev = X + POTEM: ... ↔ [A|→X] ↔ [X|→B] ↔ [B|→C] ↔ ... + 4 operacje — zawsze tyle samo, niezależnie od rozmiaru listy → O(1). + +**forward_list (lista jednokierunkowa)** — jak list, ale każdy węzeł ma wskaźnik TYLKO do NASTĘPNEGO (nie do poprzedniego). Mniej pamięci niż list, ale nie da się cofać. Iteracja tylko DO PRZODU. + + forward_list fl = {10, 20, 30}; + // 10 → 20 → 30 (tylko w przód) + +**array (tablica stała)** — tablica o STAŁYM rozmiarze (znanym w czasie kompilacji). Jak tablica C, ale z interfejsem STL. Rozmiar nie może się zmienić. Najszybsza — zero narzutu. + + array a = {10, 20, 30, 40}; // rozmiar 4, stały + +--- + +**Kontenery asocjacyjne** — elementy przechowywane w POSORTOWANEJ kolejności. Wyszukiwanie po kluczu: O(log n). Wewnętrznie: **drzewo czerwono-czarne (R-B tree)** — zbalansowane drzewo binarne. + +**Dlaczego O(log n)?** Drzewo binarne dzieli dane na pół przy każdym kroku: + + set z 1000 elementów → drzewo głębokości ~10 + Szukam 42: idę lewo/prawo 10 razy → znalezione + set z 1 000 000 elementów → głębokość ~20 + Szukam 42: 20 kroków → znalezione + log₂(1000)≈10, log₂(1000000)≈20 — to jest O(log n) + +**set** — zbiór UNIKALNYCH wartości, posortowany. Dodanie, usunięcie, wyszukiwanie: O(log n). + + set s = {30, 10, 20, 10}; + // Przechowuje: {10, 20, 30} — posortowane, bez duplikatów + +**multiset** — jak set, ale POZWALA na duplikaty. + + multiset ms = {30, 10, 20, 10}; + // Przechowuje: {10, 10, 20, 30} — posortowane, z duplikatami + +**Po co multiset? Czym różni się od vector?** + +multiset to posortowany zbiór Z duplikatami. Zastosowania: +- zliczanie wystąpień: ms.count(10) → 2 (ile razy 10 się pojawia) — O(log n) +- zakresowe zapytania: ms.lower_bound(15) → iterator na 20 — O(log n) +- mediana, percentyle: dane zawsze posortowane + +Porównanie z vector: + + Operacja vector multiset + ────────────────────────────────────────── + Szukanie elementu O(n) O(log n) ← vector musi przejrzec cały + Wstawianie w porz. O(n) O(log n) ← vector musi przesunąć el. + Dostęp po indeksie O(1) BRAK ← multiset nie ma [] + Pamięć ciągła rozrzucona ← vector jest cache-friendly + Automatyczne sort. NIE TAK + +Kiedy multiset: dane napływają strumieniowo, chcesz je mieć ZAWSZE posortowane i szybko szukać. Kiedy vector: potrzebujesz indeksu [] i iterujesz sekwencyjnie. + +**map** — słownik: pary (klucz → wartość), klucze UNIKALNE i posortowane. Dostęp po kluczu: O(log n). + + map m = {{"Anna", 5}, {"Jan", 4}}; + m["Anna"]; // 5 — wyszukiwanie O(log n) + +**multimap** — jak map, ale jeden klucz może mieć WIELE wartości. + +--- + +**Kontenery nieuporządkowane (hash)** — wewnętrznie: **tablica haszująca**. Funkcja haszująca zamienia klucz na indeks w tablicy → dostęp O(1) ŚREDNIO. Najgorszy przypadek (kolizje): O(n). Elementy NIE są posortowane. + +**Dlaczego O(1)?** Hash to „adres kalkulowany": + + Mamy tablicę 8 kubełków [0..7]: + hash("Anna") = 5 → idź od razu do kubełka 5 → znalezione + hash("Jan") = 2 → idź od razu do kubełka 2 → znalezione + + Nie trzeba przeszukiwać niczego — JEDNO obliczenie → JEDEN skok. + Kolizja: hash("Ola") = 5 = ten sam co Anna → O(n) w najgorszym przypadku. + +**unordered_set** — zbiór unikalnych wartości, BEZ sortowania. Szukanie O(1) średnio. + +**unordered_map** — słownik, BEZ sortowania kluczy. Dostęp O(1) średnio. + + unordered_map um = {{"Anna", 5}, {"Jan", 4}}; + um["Anna"]; // 5 — O(1) średnio (hash) + +Kiedy set/map, kiedy unordered? Posortowane dane lub iteracja w kolejności → set/map (O(log n)). Szybkie wyszukiwanie bez porządku → unordered (O(1)). + +--- + +**Adaptery kontenerów** — NIE są „prawdziwymi" kontenerami — opakowują inny kontener i ograniczają jego interfejs. + +**stack (stos)** — LIFO (Last In, First Out). Dostęp TYLKO do szczytu: push (wrzuć), pop (zdejmij), top (popatrz na szczyt). Domyślnie opakowuje deque. + + stack s; + s.push(10); s.push(20); s.push(30); + s.top(); // 30 (ostatni dodany) + s.pop(); // usuwa 30 + +**queue (kolejka)** — FIFO (First In, First Out). Dodajesz z tyłu, zdejmujesz z przodu. Jak kolejka w sklepie. + + queue q; + q.push(10); q.push(20); q.push(30); + q.front(); // 10 (pierwszy dodany) + q.pop(); // usuwa 10 + +**priority_queue (kolejka priorytetowa)** — zawsze wyciąga element o NAJWYŻSZYM priorytecie (domyślnie największy). Wewnętrznie: heap (kopiec). Push/pop: O(log n). + + priority_queue pq; + pq.push(10); pq.push(30); pq.push(20); + pq.top(); // 30 (największy) + pq.pop(); // usuwa 30, teraz top = 20 + +--- + +### Iteratory — szczegóły + +**Wskaźnik (pointer)** — zmienna przechowująca adres w pamięci. Iterator to UOGÓLNIONY wskaźnik: działa jak wskaźnik (de-referencja `*it`, inkrementacja `++it`), ale może obsługiwać dowolną strukturę danych, nie tylko tablice. + +**Hierarchia iteratorów** — każdy kolejny typ DODAJE możliwości: + +**Input Iterator** — jednokrotny odczyt, tylko do przodu. Jak czytanie ze strumienia: raz odczytane, nie wrócisz. Np. `istream_iterator`. + +**Output Iterator** — jednokrotny zapis, tylko do przodu. Np. `ostream_iterator`. + +**Forward Iterator** — odczyt/zapis, do przodu, WIELOKROTNE przejścia. Np. `forward_list::iterator`. + +**Bidirectional Iterator** — jak Forward + cofanie (`--it`). Np. `list::iterator`, `set::iterator`. + +**Random Access Iterator** — jak Bidirectional + skok na DOWOLNĄ pozycję (`it + 5`, `it[3]`). Np. `vector::iterator`, `deque::iterator`. + +**Contiguous Iterator** (C++17) — jak Random Access + gwarantowane SĄSIEDZTWO w pamięci. Np. `vector::iterator`, `array::iterator`. + +**Dlaczego vector = Random Access?** — Pamięć ciągła: adres i-tego elementu = baza + i × rozmiar. Skok na pozycję 1000 to jedno dodanie — O(1). `vec.begin() + 1000` działa natychmiast. + +**Dlaczego list = Bidirectional?** — Lista dwukierunkowa: węzły połączone wskaźnikami prev/next. Możesz iść do przodu (`++it`) i do tyłu (`--it`). Ale NIE możesz „skoczyć" na pozycję 1000 — musisz przejść 1000 kroków, bo nie ma ciągłej pamięci. + +**Dlaczego forward_list = Forward?** — Lista jednokierunkowa: każdy węzeł ma TYLKO wskaźnik „next". Możesz iść TYLKO do przodu (`++it`). Nie da się cofnąć (`--it`) — brak wskaźnika wstecz. + +**Dlaczego hierarchia ma znaczenie?** — Algorytmy WYMAGAJĄ minimalnej kategorii iteratora: +- `find` potrzebuje Input (wystarczy jeden przebieg) +- `reverse` potrzebuje Bidirectional (musi cofać się) +- `sort` potrzebuje Random Access (musi skakać po pozycjach) + +Dlatego NIE MOŻNA `sort(mylist.begin(), mylist.end())` — list daje Bidirectional, a sort wymaga Random Access. Lista ma własny `mylist.sort()`. + +--- + +### Algorytmy — szczegóły + +**Zakres [begin, end)** — algorytmy operują na PARZE iteratorów: begin = pierwszy element, end = JEDEN ZA OSTATNIM (nie sam ostatni!). Pozwala elegancko wyrażać puste zakresy i podzakresy. + +**sort** — sortuje elementy. Wymaga Random Access. Złożoność: O(n log n). Domyślnie rosnąco. + +**find** — szuka pierwszego elementu równego wartości. Wymaga Input. O(n). + +**transform** — przekształca każdy element (jak map w Pythonie). Np. pomnóż każdy × 2. + +**copy** — kopiuje elementy z jednego zakresu do drugiego. + +**accumulate** — „zwijanie" zakresu do jednej wartości (jak fold/reduce). Np. suma, iloczyn. + +**count_if** — zlicza elementy spełniające warunek (predykat). + +**remove_if** — przenosi elementy niespełniające warunku na początek (nie usuwa fizycznie!). + + vector v = {3, 1, 4, 1, 5}; + sort(v.begin(), v.end()); // {1, 1, 3, 4, 5} + find(v.begin(), v.end(), 4); // iterator na 4 + count_if(v.begin(), v.end(), + [](int x){return x > 2;}); // 3 (bo: 3, 4, 5) + accumulate(v.begin(), v.end(), 0); // 14 (suma) + +**Kluczowa cecha:** algorytmy nie wiedzą, CZY dane leżą w vector, list, deque — widzą TYLKO iteratory. Dlatego TEN SAM `find` działa na vector, na set, na deque. + +--- + +### Funktory i lambdy — szczegóły + +**Funktor (obiekt funkcyjny)** — klasa/struct z overloadowanym `operator()`. Można ją „wywoływać" jak funkcję. + + struct Podwoj { + int operator()(int x) { return x * 2; } + }; + Podwoj f; + f(5); // 10 — wygląda jak wywołanie funkcji, ale to obiekt + +**Wbudowane funktory STL:** +- `less` — porównuje `a < b` (domyślne sortowanie rosnące) +- `greater` — porównuje `a > b` (sortowanie malejące) +- `plus` — oblicza `a + b` + + sort(v.begin(), v.end(), greater()); // sortuj MALEJĄCO + +**Lambda (C++11)** — anonimowa (bezimienна) funkcja definiowana w miejscu użycia. Zastępuje ręczne pisanie funktorów. + + [capture](parametry) { ciało } + + sort(v.begin(), v.end(), [](int a, int b){ return a > b; }); + // To samo co greater(), ale inline + +**Parametryzacja** = funktor/lambda mówi algorytmowi JAK działać: +- sort + less → sortuj rosnąco +- sort + greater → sortuj malejąco +- sort + custom lambda → sortuj po dowolnym kryterium (np. długość stringa) + +--- + +### Architektura ortogonalna — szczegóły + +**Ortogonalność** — komponenty są NIEZALEŻNE. Kontenery nie wiedzą o algorytmach. Algorytmy nie wiedzą o kontenerach. Łącznikiem są iteratory. + +Bez ortogonalności: M kontenerów × N algorytmów = **M×N** implementacji (sort dla vector, sort dla list, sort dla deque, find dla vector...). Z ortogonalnością: **M + N** implementacji — każdy kontener daje iteratory, każdy algorytm operuje na iteratorach. + + // TEN SAM algorytm, RÓŻNE kontenery: + sort(vec.begin(), vec.end()); // vector + sort(deq.begin(), deq.end()); // deque + // (list ma własny sort, bo sort wymaga Random Access) + + // TEN SAM kontener, RÓŻNE algorytmy: + sort(vec.begin(), vec.end()); + find(vec.begin(), vec.end(), 42); + reverse(vec.begin(), vec.end()); + +--- + +### Etymologia + +**STL** — Standard Template Library; Alexander Stepanov + Meng Lee (HP, 1994); Stepanov od lat 70. marzył o programowaniu generycznym. **Iterator** — łac. „iter" = podróż/ścieżka; ten, kto przemierza kolekcję. **Funktor** — z teorii kategorii (matematyka); obiekt zachowujący się jak funkcja. **Deque** — Double-Ended QUEue. **Vector** — łac. „vector" = nośnik; tablica dynamiczna. **Lambda** — od greckiej litery λ; Alonzo Church, rachunek lambda (1930s). + +### Jak zapamiętać + +- **„KIAF"** — Kontenery, Iteratory, Algorytmy, Funktory +- **Ortogonalność:** algorytmy + kontenery połączone iteratorami +- **vector** — domyślny wybór; list gdy dużo insert/erase w środku; map/set gdy potrzebne sortowanie i wyszukiwanie + +\newpage + +## PYTANIE 6: Reużywalność kodu w OOP (PROI) + +**Omówić metody reużywalności kodu i struktur danych w obiektowych językach programowania.** + +--- + +### Tło pojęciowe — słowniczek + +**OOP (Object-Oriented Programming / Programowanie obiektowe)** — paradygmat, w którym program składa się z obiektów łączących dane (pola) i zachowanie (metody). Cztery filary: enkapsulacja, dziedziczenie, polimorfizm, abstrakcja. W kontekście pytania — to OOP wprowadza mechanizmy ponownego użycia kodu omawiane poniżej. + +**Klasa (class)** — „wzorzec" (blueprint) obiektu. Definiuje pola i metody. Obiekt to konkretna instancja klasy. + + class Dog { // klasa + string name; + void bark(); + }; + Dog rex; // obiekt (instancja) + +**Reużywalność kodu (code reuse)** — możliwość wykorzystania raz napisanego kodu w wielu miejscach bez kopiowania. Zmniejsza ilość duplikatów, ułatwia utrzymanie i redukuje błędy. To główny temat pytania. + +--- + +**Dziedziczenie (inheritance)** — mechanizm, w którym klasa pochodna (child) przejmuje pola i metody klasy bazowej (parent). Relacja „jest" (is-a): Dog **jest** Animal. + + class Animal { void eat(); }; + class Dog : public Animal { void bark(); }; + // Dog ma eat() + bark() + +**Klasa bazowa / pochodna (base class / derived class)** — bazowa = rodzic, pochodna = dziecko. Pochodna dziedziczy interfejs i implementację bazowej, może dodawać własne lub nadpisywać istniejące metody. + +**Dziedziczenie wielokrotne (multiple inheritance)** — klasa dziedziczy po więcej niż jednym rodzicu. Dostępne w C++, ale nie w Java/C# (tam tylko interfejsy). Powoduje ryzyko konfliktu nazw i problem diamentu. + +**Problem diamentu (diamond problem)** — gdy klasa D dziedziczy po B i C, a oba dziedziczą po A, D ma dwie kopie A. Pytanie: której użyć? + + A + / \ + B C + \ / + D ← dwie kopie A! + +Rozwiązanie w C++: dziedziczenie wirtualne (`class B : virtual public A`), dzięki czemu istnieje jedna kopia A. + +**Polimorfizm (polymorphism)** — grec. „wiele form". Możliwość traktowania obiektów różnych klas przez wspólny interfejs. Kluczowy dla reużywalności — piszesz kod raz, działa z wieloma typami. + + Animal* a = new Dog(); + a->speak(); // woła Dog::speak(), nie Animal::speak() + // To samo wywołanie, różne zachowanie — polimorfizm + +Realizacja: funkcje wirtualne (`virtual` + `override`) — tablica vtable wskazuje na właściwą implementację. + +--- + +**Kompozycja (composition)** — obiekt zawiera inne obiekty jako pola. Relacja „ma" (has-a). Stack **ma** wektor (nie **jest** wektorem). Silniejsza enkapsulacja niż dziedziczenie, bo wnętrze komponentu jest ukryte. + + class Engine { int hp; }; + class Car { + Engine engine; // kompozycja: Car "ma" Engine + }; + +**„Favor composition over inheritance"** — zasada GoF: preferuj kompozycję nad dziedziczenie. Dziedziczenie tworzy silne wiązanie (zmiana bazowej łamie pochodne). Kompozycja pozwala wymieniać części w runtime. + +**Agregacja (aggregation)** — słabsza forma kompozycji: obiekt „używa" innego, ale go nie posiada. Samochód ma kierowcę, ale kierowca istnieje niezależnie. W UML: pusty romb (◇). + +**Enkapsulacja (encapsulation)** — ukrywanie szczegółów implementacji za interfejsem publicznym. Zapewnia, że obiekt kontroluje dostęp do swoich danych (private, protected, public). + +**Luźne wiązanie (loose coupling)** — komponenty mają minimum zależności między sobą. Zmiana jednego nie wymusza zmian w drugim. Kompozycja daje luźniejsze wiązanie niż dziedziczenie. + +--- + +**Programowanie generyczne (generic programming)** — pisanie kodu niezależnego od konkretnego typu danych. Jedna implementacja działa dla int, float, string itd. + +**Template (szablon, C++)** — mechanizm generyczny w C++. Kompilator generuje osobną wersję kodu dla każdego użytego typu (monomorfizacja). + + template + T max(T a, T b) { return a > b ? a : b; } + max(3, 5); // T = int + max(1.5, 2.7); // T = double + +**Generics (Java/C#)** — odpowiednik templates, ale z type erasure (Java) lub reifikacją (C#). `List` — lista przechowująca tylko stringi; bezpieczeństwo typów bez duplikowania kodu. + +**STL (Standard Template Library)** — biblioteka C++ oparta na templates: kontenery (`vector`, `map`), algorytmy (`sort`, `find`), iteratory. Przykład reużywalności: jeden `sort()` sortuje dowolny kontener. + +--- + +**Interfejs (interface)** — kontrakt: zbiór metod bez implementacji. Klasa implementująca interfejs musi dostarczyć ciała wszystkich metod. W C++ → czysto wirtualne metody (`= 0`); w Java/C# → `interface`. + + // C++ + class Drawable { + public: + virtual void draw() = 0; // pure virtual = interfejs + }; + +**Klasa abstrakcyjna (abstract class)** — klasa, której nie można instancjonować; może mieć zarówno metody abstrakcyjne, jak i z implementacją. Interfejs = 100% abstrakcyjna. + +**Wzorce projektowe (design patterns)** — sprawdzone, reużywalne rozwiązania typowych problemów projektowych. Opisane jako: Nazwa + Problem + Rozwiązanie + Konsekwencje. + +**GoF (Gang of Four)** — Gamma, Helm, Johnson, Vlissides — autorzy książki „Design Patterns" (1994) z 23 wzorcami w trzech kategoriach: kreacyjne, strukturalne, behawioralne. + +**Strategy** — wzorzec: wymień algorytm w runtime przez interfejs. Np. różne strategie sortowania. +**Observer** — wzorzec: obiekt powiadamia subskrybentów o zmianach stanu (pub/sub w OOP). +**Factory** — wzorzec: tworzenie obiektów bez określania dokładnej klasy (decyzja w runtime). +**Decorator** — wzorzec: dodaj zachowanie do obiektu dynamicznie, opakowując go. + +**Biblioteka (library)** — zbiór reużywalnego kodu wywoływanego przez nasz program (my code calls library). +**Framework** — odwrotność: framework wywołuje nasz kod (Inversion of Control). Np. Unity, Django. +**Trait / Mixin** — mechanizm współdzielenia kodu między klasami bez dziedziczenia. Trait (Rust, Scala) = zbiór metod do „wmixowania". Mixin (Ruby, Python) = klasa dodająca funkcjonalność przez wielodziedziczenie. + +--- + +### Główne metody + +### 1. Dziedziczenie (Inheritance) — relacja „jest" (is-a) +- Klasa pochodna przejmuje atrybuty i metody bazowej +- Typy: pojedyncze, wielokrotne, wielopoziomowe +- Problem diamentu → dziedziczenie wirtualne w C++ +- Polimorfizm (virtual, override) + +### 2. Kompozycja (Composition) — relacja „zawiera" (has-a) +- **„Favor composition over inheritance"** +- Stack nie JEST wektorem → Stack ZAWIERA wektor +- Silniejsza enkapsulacja, luźne wiązanie +- Typy: kompozycja (owns), agregacja (uses), asocjacja (knows) + +### 3. Programowanie generyczne (Templates/Generics) +- Kod niezależny od typu: `template T max(T a, T b)` +- STL jest oparta na templates +- Java/C#: Generics (`List`) + +### 4. Interfejsy i klasy abstrakcyjne +- Kontrakt bez implementacji (pure virtual w C++, interface w Java) +- Umożliwiają multiple inheritance bez diamond problem + +### 5. Wzorce projektowe (Design Patterns) +- Strategy, Observer, Factory, Decorator — reużywalne rozwiązania +- GoF (Gang of Four) — 23 wzorce + +### 6. Biblioteki, frameworki, traity/mixiny + +### Etymologia + +**OOP** — Alan Kay (Smalltalk, 1970s), sam ukuł termin „object-oriented". **GoF** — Gang of Four: Gamma, Helm, Johnson, Vlissides (1994). **Polimorfizm** — grec. „poly" (wiele) + „morphē" (forma) = wiele postaci. **Enkapsulacja** — łac. „capsula" = pudełeczko. **Design Pattern** — z architektury: Christopher Alexander „A Pattern Language" (1977); GoF zaadaptowali do IT. **Kompozycja > Dziedziczenie** — zasada z GoF: „favor object composition over class inheritance". + +### Jak zapamiętać + +- **„Kompozycja > Dziedziczenie"** — najważniejsza zasada +- Dziedziczenie: silne wiązanie, krucha klasa bazowa, diamond problem +- Kompozycja: elastyczna, testowalna, preferowan +- Granica: dziedziczenie dla prawdziwego „is-a" z polimorfizmem; kompozycja dla reszty + +\newpage + +## PYTANIE 7: DNS i caching (SKM) + +**Które serwery DNS zyskują najwięcej na cachingu? Jakie znasz rodzaje serwerów DNS?** + +--- + +### Tło pojęciowe — słowniczek + +**DNS (Domain Name System)** — rozproszony system tłumaczący nazwy domenowe (np. `google.com`) na adresy IP (np. `142.250.74.206`). Bez DNS musielibyśmy zapamiętywać ciągi liczb zamiast nazw. Struktura hierarchiczna: root → TLD → domeny → subdomeny. + + google.com. ← końcowa kropka = root + │ │ + │ └── TLD (.com) + └── domena II poziomu (google) + +**Serwer DNS** — komputer odpowiadający na zapytania o adresy IP. Istnieje kilka typów o różnych rolach w hierarchii (root, TLD, authoritative, recursive, stub, forwarding). + +**Cache (pamięć podręczna)** — szybki bufor przechowujący niedawne odpowiedzi. Zamiast pytać hierarchię DNS od zera, resolver sprawdza cache. Trafienie w cache = odpowiedź w <1 ms zamiast ~50-200 ms podróży przez internet. + +**Caching DNS** — mechanizm zapisywania odpowiedzi DNS na określony czas (TTL). Kluczowy dla wydajności — bez caching root servers byłyby przeciążone miliardami zapytań dziennie. + +--- + +**Root server (serwer główny)** — najwyższy poziom hierarchii DNS. 13 logicznych serwerów (a.root-servers.net … m.root-servers.net), ale setki fizycznych instancji rozproszonych po świecie (anycast). Nie znają adresów konkretnych domen — odsyłają (referral) do serwerów TLD. + +**TLD server (Top-Level Domain)** — serwer obsługujący domeny najwyższego poziomu: .com, .pl, .org, .net itd. Zarządzane przez rejestry (np. Verisign dla .com, NASK dla .pl). Odsyłają do serwerów authoritative konkretnych domen. + +**Authoritative NS (serwer autorytatywny)** — serwer znający ostateczne odpowiedzi dla danej domeny. Primary (master) — zawiera oryginalne rekordy (edytowalny); Secondary (slave) — kopia do nadmiarowości. To „źródło prawdy" dla danej domeny. + +**Recursive resolver (resolver rekurencyjny)** — serwer wykonujący pełne rozwiązywanie: pyta root → TLD → authoritative, zbiera odpowiedź i zwraca klientowi. Przykłady: Google 8.8.8.8, Cloudflare 1.1.1.1, resolver ISP. To ON głównie korzysta z cache. + +**Stub resolver** — prosty klient DNS wbudowany w system operacyjny. Nie rozwiązuje sam — wysyła zapytanie do recursive resolvera i czeka na odpowiedź. + +**Forwarding server** — serwer DNS, który nie rozwiązuje sam, lecz przekazuje zapytania do innego resolvera (np. firmowy DNS przekazuje do ISP). + +--- + +**TTL (Time To Live)** — czas w sekundach, przez który odpowiedź DNS może być przechowywana w cache. Po upływie TTL wpis jest usuwany i trzeba zapytać ponownie. Root referrals mają TTL 48h–7 dni; TLD referrals 24h–48h; typowe domeny 300–3600s. + + Przykład: TTL = 3600 → resolver pamięta odpowiedź przez 1 godzinę + +**Referral (odesłanie)** — odpowiedź DNS mówiąca „nie wiem, ale zapytaj tamten serwer". Root referral → „zapytaj serwer TLD .com"; TLD referral → „zapytaj NS domeny google.com". + +**Anycast** — technika routingu: ten sam adres IP jest ogłaszany z wielu lokalizacji na świecie. Klient automatycznie trafia do najbliższego serwera (routing BGP kieruje do najbliższego). Root servers używają anycast — dlatego 13 adresów obsługuje cały internet. + +**ISP (Internet Service Provider)** — dostawca internetu. Zwykle udostępnia własny recursive resolver, z którego korzystają klienci domyślnie. + +**Dlaczego ROOT i TLD zyskują NAJWIĘCEJ na cachingu?** Root servers to tylko 13 logicznych adresów dla CAŁEGO internetu. Bez cache każde zapytanie o dowolną domenę musi przejść przez root. Z cache: resolver pyta root RAZ o .com, cachuje referral na 48h+, i przez ten czas miliardy zapytań o domeny .com omijają root. Redukcja ruchu: z ~100% do ~0.01% zapytań. + + Bez cache: klient → resolver → ROOT → TLD → Auth (za każdym razem!) + Z cache: klient → resolver → cache hit! (odpowiedź w <1ms) + +--- + +### Rodzaje serwerów DNS + +1. **Root Servers** (.) — 13 logicznych (a..m.root-servers.net), setki fizycznych (anycast) +2. **TLD Servers** (.com, .pl, .org) — zarządzane przez rejestry +3. **Authoritative NS** — Primary (master, edytowalny) i Secondary (slave, kopia) +4. **Recursive Resolvers** — wykonują pełne rozwiązywanie (ISP, Google 8.8.8.8, Cloudflare 1.1.1.1) +5. **Stub Resolvers** — prosty klient w OS, wysyła do recursive +6. **Forwarding Servers** — przekazują zapytania dalej + +### Proces rozwiązywania + + Klient → Recursive Resolver → Root → TLD → Authoritative → odpowiedź + +### ODPOWIEDŹ: ROOT i TLD zyskują NAJWIĘCEJ na cachingu + +**Dlaczego:** +- 13 root servers vs miliardy zapytań dziennie +- BEZ cache: każde zapytanie o DOWOLNĄ domenę musi przejść przez root i TLD +- Z cache: resolver pyta root RAZ o .com, cachuje referral na 48h+ +- Root referrals: TTL 48h–7 dni (!); TLD referrals: TTL 24h–48h +- Redukcja ruchu do root: z ~100% do ~0.01% zapytań + +### Etymologia + +**DNS** — Domain Name System; Paul Mockapetris (1983, RFC 882/883). **Cache** — fr. „cacher" = ukrywać; ukryte szybkie przechowywanie. **TTL** — Time To Live. **Anycast** — ten sam IP z wielu lokalizacji; klient dostaje odpowiedź od najbliższego serwera. **Root servers** — 13 logicznych identyfikatorów (a–m); infrastruktura krytyczna internetu. **Recursive resolver** — „rekurencyjny" bo iteracyjnie pyta kolejne poziomy hierarchii aż do odpowiedzi. + +### Jak zapamiętać + +- **„Piramida DNS"** — root (wierzchołek, najmniej serwerów) → TLD → Auth (podstawa, miliony) +- Im mniej serwerów na poziomie, tym większy zysk z cache +- **TTL** = Time To Live — im dłuższy, tym rzadziej odświeżany cache + +\newpage + +## PYTANIE 8: TCP Three-Way Handshake (SKM) + +**Cel, interpretacja numerów sekwencyjnych, wartość początkowa ISN.** + +--- + +### Tło pojęciowe — słowniczek + +**TCP (Transmission Control Protocol)** — protokół warstwy transportowej zapewniający niezawodne, uporządkowane dostarczanie danych. W przeciwieństwie do UDP, TCP gwarantuje: brak utraty, poprawną kolejność, brak duplikatów. Ceną jest większy narzut (handshake, potwierdzenia, retransmisje). + + Warstwa aplikacji: HTTP, FTP, SMTP + Warstwa transportowa: TCP / UDP ← tu TCP + Warstwa sieciowa: IP + Warstwa łącza: Ethernet, WiFi + +**Połączenie (connection)** — TCP jest protokołem połączeniowym (connection-oriented). Zanim dane popłyną, obie strony muszą ustanowić połączenie — to właśnie robi three-way handshake. + +**Segment** — jednostka danych w TCP. Nagłówek TCP (20+ bajtów) + dane. Nagłówek zawiera m.in. porty, numery sekwencyjne, flagi (SYN, ACK, FIN…), window size. + +--- + +**Handshake (uścisk dłoni)** — procedura nawiązywania połączenia. „Three-way" = trzy kroki: SYN → SYN-ACK → ACK. Metafora: „Hej!" → „Hej, słyszę!" → „OK, gadamy!". Cel: obie strony potwierdzają gotowość i synchronizują numery sekwencyjne. + +**SYN (Synchronize)** — flaga w nagłówku TCP. Segment z flagą SYN inicjuje połączenie i przekazuje początkowy numer sekwencyjny (ISN) nadawcy. + +**ACK (Acknowledge)** — flaga potwierdzenia. Numer ACK = numer następnego oczekiwanego bajtu. Gdy serwer wysyła SYN-ACK, jednocześnie potwierdza odbiór SYN klienta (ACK=x+1) i wysyła swój SYN (ISN serwera = y). + +--- + +**Numer sekwencyjny (Sequence Number, SEQ)** — 32-bitowa liczba identyfikująca pozycję pierwszego bajtu danych w segmencie w strumieniu bajtów. Funkcje: zapewnia kolejność, wykrywa duplikaty i braki, umożliwia potwierdzenia. + + Klient wysyła 100 bajtów od pozycji 1000: + SEQ = 1000, dane = bajty 1000–1099 + Następny segment: SEQ = 1100 + +**Numer potwierdzenia (Acknowledgment Number, ACK number)** — mówi: „odebrałem wszystko do bajtu X-1, teraz czekam na bajt X". Jest kumulatywny — jedno ACK potwierdza wszystkie dane do tej pozycji. + + Klient wysłał SEQ=1000, 100 bajtów + Serwer odpowiada: ACK=1100 → „dostałem do 1099, czekam na 1100" + +**SACK (Selective ACK)** — rozszerzenie TCP. Pozwala potwierdzać niesąsiednie bloki danych, co przyspiesza retransmisję. Bez SACK: utrata jednego segmentu wymaga retransmisji wszystkiego od niego. + +--- + +**ISN (Initial Sequence Number)** — początkowy numer sekwencyjny wybierany przy nawiązywaniu połączenia. Każda strona wybiera swój ISN niezależnie. + +**Dlaczego ISN nie zaczyna od 0?** +1. **Bezpieczeństwo** — losowy ISN utrudnia atakującemu zgadnięcie numerów i przejęcie sesji (TCP hijacking). +2. **Unikanie kolizji** — gdyby ISN=0, segmenty z poprzedniego połączenia między tymi samymi portami mogłyby zostać błędnie zaakceptowane. +3. RFC 793 (oryg.): ISN = timer inkrementowany co 4μs mod 2³². +4. RFC 6528 (współcz.): ISN = M + F(adresy, porty, secret_key) — kryptograficznie losowy. + +**MSS (Maximum Segment Size)** — maksymalny rozmiar danych w jednym segmencie TCP. Uzgadniana w handshake (zwykle 1460 bajtów dla Ethernetu = MTU 1500 − 20 IP − 20 TCP). + +**Window Scale** — opcja TCP negocjowana w handshake. Pozwala zwiększyć okno odbiorcze ponad 65535 bajtów (do ~1 GB), co jest konieczne dla szybkich łączy. + +**RFC (Request For Comments)** — dokumenty standaryzacyjne internetu. Nazwa historyczna z ARPANET — „prośba o komentarze" — ale w praktyce to obowiązujące standardy. TCP = RFC 793 (1981). + +**Bajt (byte)** — 8 bitów. TCP numeruje strumień po bajtach, nie po segmentach. Dlatego SEQ to numer bajtu, a nie numer pakietu. + +--- + +### Cel handshake'u +1. Nawiązanie połączenia — obie strony się zgadzają +2. Synchronizacja ISN (Initial Sequence Number) +3. Uzgodnienie parametrów (MSS, Window Scale, SACK) + +### Przebieg + + 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] | + +### Numery sekwencyjne (SEQ) +- SEQ = numer pierwszego bajtu danych w segmencie +- Funkcje: kolejność, duplikaty, braki, potwierdzenia + +### Numery potwierdzenia (ACK) +- ACK = numer **następnego oczekiwanego** bajtu (kumulatywne) +- SACK — opcja potwierdzania niesąsiednich bloków + +### Wartość początkowa ISN +- **NIE zaczyna od 0** — bezpieczeństwo + unikanie kolizji z poprzednimi połączeniami +- RFC 793: ISN = timer 4μs mod 2³² +- RFC 6528: ISN = M + F(adresy, porty, secret_key) — kryptograficznie + +### Etymologia + +**TCP** — Transmission Control Protocol; Vint Cerf + Bob Kahn (1974, „A Protocol for Packet Network Intercommunication"). **Handshake** — metafora uścisku dłoni = wzajemna zgoda na komunikację. **SYN** — Synchronize. **ACK** — Acknowledge. **ISN** — Initial Sequence Number. **MSS** — Maximum Segment Size. **SACK** — Selective ACK. **RFC** — Request For Comments; tradycja ARPANET (1969). + +### Jak zapamiętać + +- **„SYN, SYN-ACK, ACK"** — 3 kroki, jak potwierdzenie rozmowy: „Hej!" „Hej, słyszę!" „OK, gadamy!" +- **SEQ = numer bajtu**, ACK = „czekam na bajt numer..." +- **ISN losowy** — bo inaczej atakujący może zgadnąć i przejąć sesję + +\newpage + +## PYTANIE 9: Procesy i wątki (SOI) + +**Budowa, szybkość, zastosowanie. Problemy komunikacji i synchronizacji.** + +--- + +### Tło pojęciowe — słowniczek + +**Proces (process)** — program w trakcie wykonania. Każdy proces ma własną, izolowaną przestrzeń adresową. System operacyjny zarządza procesami — tworzy, planuje (scheduling), kończy. Np. przeglądarka i edytor to osobne procesy. + +**Wątek (thread)** — lekka jednostka wykonania wewnątrz procesu. Wątki jednego procesu współdzielą pamięć (kod, dane, heap), ale mają własny stos i rejestry CPU. Tworzenie wątku jest ~100x szybsze niż procesu. + + Proces = mieszkanie (własny adres, izolacja) + Wątek = pokój w mieszkaniu (współdzielona kuchnia = heap) + + Cecha Proces Wątek + ───────────────────────────────────────── + Pamięć własna współdzielona + Tworzenie ~1-10 ms ~10-100 μs + Przełączanie wolne (TLB) szybkie (rejestry) + Komunikacja IPC/pipe bezpośrednia + Awaria izolowana może zabić proces + +--- + +**Przestrzeń adresowa (address space)** — zakres adresów pamięci wirtualnej dostępnych procesowi. Każdy proces widzi swoją „prywatną" pamięć, nawet jeśli fizycznie jest mapowana gdzieś indziej. + +**Segmenty pamięci procesu:** +- **TEXT** — kod maszynowy (read-only) +- **DATA** — zainicjalizowane zmienne globalne/statyczne +- **BSS** — niezainicjalizowane zmienne globalne (zerowane) +- **HEAP** — pamięć alokowana dynamicznie (malloc/new), rośnie w górę +- **STACK** — zmienne lokalne, adresy powrotu, rośnie w dół + + ┌──────────┐ wysoki adres + │ STACK ↓ │ + │ ... │ + │ HEAP ↑ │ + │ BSS │ + │ DATA │ + │ TEXT │ + └──────────┘ niski adres + +**PCB (Process Control Block)** — struktura danych w jądrze OS opisująca proces: PID, stan, rejestry CPU, tablice stron, otwarte pliki, priorytety. Przełączenie kontekstu = zapisanie PCB starego procesu i wczytanie nowego. + +**PID (Process ID)** — unikalny identyfikator procesu w systemie. Np. `PID 1` = init/systemd w Linux. + +**TID (Thread ID)** — unikalny identyfikator wątku. + +**Stany procesu:** NEW (tworzony) → READY (gotowy, czeka na CPU) ↔ RUNNING (wykonywany) → BLOCKED (czeka na I/O), TERMINATED (zakończony). Scheduler decyduje, który READY staje się RUNNING. + +--- + +**Przełączanie kontekstu (context switch)** — zapisanie stanu aktualnego procesu/wątku i wczytanie stanu następnego. Dla procesów kosztowne (wymaga TLB flush = unieważnienie cache translacji adresów). Dla wątków tańsze (ta sama przestrzeń adresowa = brak TLB flush). + +**TLB (Translation Lookaside Buffer)** — sprzętowy cache translacji adres wirtualny → fizyczny. Przy zmianie procesu TLB trzeba wyczyścić (flush), bo nowy proces ma inne mapowania. Koszt: ~1000 ns. Przy zmianie wątku — TLB zostaje (ten sam proces). + +--- + +**IPC (Inter-Process Communication)** — mechanizmy komunikacji między procesami. Konieczne, bo procesy mają izolowane przestrzenie adresowe i nie mogą czytać wzajemnej pamięci bezpośrednio. + +- **Pipe** — jednokierunkowy strumień bajtów (ls | grep foo). Anonimowy, tylko między spokrewnionymi procesami. +- **Named Pipe (FIFO)** — pipe z nazwą w systemie plików, mogą go używać niespokrewnione procesy. +- **Message Queue** — kolejka wiadomości w jądrze; asynchroniczna komunikacja. +- **Shared Memory** — wspólny region pamięci; najszybszy IPC (brak kopiowania), ale wymaga synchronizacji. +- **Socket** — komunikacja sieciowa lub lokalna (Unix domain socket). Uniwersalny, działa między maszynami. +- **Signal** — asynchroniczne powiadomienie (np. SIGKILL, SIGTERM). Ograniczony — przesyła tylko numer sygnału. + +--- + +**Wyścig (race condition)** — sytuacja, gdy wynik programu zależy od kolejności wykonania operacji przez wątki. Przykład: dwa wątki zwiększają x=0 o 1 → wynik może być 1 zamiast 2, bo oba czytają 0 zanim zapiszą. + + Wątek A: czytaj x(=0) → dodaj 1 → zapisz x(=1) + Wątek B: czytaj x(=0) → dodaj 1 → zapisz x(=1) + Wynik: x = 1 zamiast oczekiwanego 2! + +**Sekcja krytyczna (critical section)** — fragment kodu, który może być wykonywany przez najwyżej jeden wątek naraz. Chroni współdzielone zasoby przed race condition. + +**Zakleszczenie (deadlock)** — sytuacja, w której dwa lub więcej wątków czekają na siebie nawzajem i żaden nie może kontynuować. Jak dwa samochody na skrzyżowaniu — oba czekają, nikt nie jedzie. + + Wątek A: trzyma mutex1, czeka na mutex2 + Wątek B: trzyma mutex2, czeka na mutex1 + → Zakleszczenie! Żaden nie puści swojego. + +**Warunki Coffmana** — 4 warunki konieczne deadlocka (wszystkie muszą zachodzić jednocześnie): +1. **Mutual exclusion** — zasób jest wyłączny (tylko jeden wątek) +2. **Hold and wait** — trzymaj zasób, czekaj na kolejny +3. **No preemption** — nie można zabrać zasobu siłą +4. **Circular wait** — cykliczne oczekiwanie (A→B→C→A) +Złam jeden = brak deadlocka. + +**Zagłodzenie (starvation)** — wątek nigdy nie dostaje zasobu, bo inni ciągle go wyprzedzają (np. nisko priorytetowy wątek przy high-priority scheduling). + +--- + +**Mutex (MUTual EXclusion)** — zamek na sekcję krytyczną. Tylko jeden wątek może go „zamknąć" (lock); reszta czeka (sleep). Tryb: lock → sekcja krytyczna → unlock. + +**Semafor (semaphore)** — uogólniony mutex z licznikiem. Semafor binarny (0/1) = mutex. Semafor zliczający (n) — pozwala n wątkom jednocześnie. P() = probeer (zmniejsz), V() = verhoog (zwiększ). + + semafor(3): 3 wątki mogą wejść naraz + P() → counter-- (jeśli 0 → czekaj) + V() → counter++ (obudź czekającego) + +**Monitor** — wysokopoziomowy mechanizm synchronizacji. Obiekt z mutexem wbudowanym — tylko jeden wątek może wykonywać metody monitora. Java: `synchronized`. + +**Condition Variable** — pozwala wątkowi czekać (wait) na spełnienie warunku i być obudzonym (signal/notify) przez inny wątek. Używane z mutexem. + +**Spinlock** — zamek, w którym wątek aktywnie czeka w pętli (busy-wait) zamiast zasypiać. Szybki dla bardzo krótkich sekcji krytycznych (~ns), marnotrawny dla dłuższych. + +**Read-Write Lock** — pozwala wielu czytelnikom jednocześnie LUB jednemu pisarzowi. Optymalizacja dla scenariuszy z dużo odczytów i rzadkimi zapisami. + +**Barrier** — punkt synchronizacji: wszystkie wątki muszą dotrzeć do bariery, zanim którykolwiek może kontynuować. Użyteczna w obliczeniach równoległych (np. po każdej iteracji). + +--- + +### Proces — program w trakcie wykonania + +Pamięć: TEXT (kod) | DATA | BSS | HEAP | STACK — oddzielna przestrzeń adresowa. +PCB: PID, stan, rejestry CPU, tablice stron, otwarte pliki. +Stany: NEW → READY ↔ RUNNING → BLOCKED, TERMINATED. + +### Wątek — lekka jednostka wykonania + +**Współdzielone** z procesem: kod, dane globalne, heap, pliki. +**Prywatne:** stos, rejestry CPU, PC, TID. + +### Porównanie + +| Cecha | Proces | Wątek | +|-----------------|------------------|----------------------| +| Przestrzeń addr | Własna, izolowana| Współdzielona | +| Tworzenie | ~1-10 ms | ~10-100 μs | +| Przełączanie | Wolne (TLB flush)| Szybkie (rejestry) | +| Komunikacja | IPC (pipe, shm) | Współdzielona pamięć | +| Izolacja | Pełna | Brak | + +### Komunikacja międzyprocesowa (IPC) +Pipe, Named Pipe (FIFO), Message Queue, Shared Memory, Sockets, Signals, Memory-mapped files. + +### Synchronizacja — problemy +- **Wyścig (race condition)** — wynik zależy od kolejności operacji +- **Sekcja krytyczna** — fragment kodu wymagający wyłącznego dostępu +- **Zakleszczenie (deadlock)** — wzajemne oczekiwanie (warunki Coffmana: mutual exclusion, hold & wait, no preemption, circular wait) +- **Zagłodzenie (starvation)** — wątek nigdy nie dostaje zasobu + +### Mechanizmy synchronizacji +Mutex, Semaphore, Monitor, Condition Variable, Spinlock, Read-Write Lock, Barrier. + +### Etymologia + +**Proces** — łac. „processus" = posuwanie się naprzód. **Wątek (Thread)** — metafora nitki wykonania (jak nić Ariadny). **Mutex** — portmanteau MUTual EXclusion. **Semafor** — Dijkstra (1965); od semaforów kolejowych; P() = hol. „proberen" (próbować), V() = hol. „verhogen" (podnosić). **Coffman** — Edward Coffman Jr. et al. (1971): 4 warunki konieczne deadlocka. **Deadlock (zakleszczenie)** — jak zablokowane koła zębate. **IPC** — Inter-Process Communication. + +### Jak zapamiętać + +- **„Proces = mieszkanie, Wątek = pokój"** — każde mieszkanie ma adres (przestrzeń), pokoje dzielą kuchnię (heap) +- Wątki szybsze bo nie trzeba zmieniać „mieszkania" (TLB flush) +- **4 warunki Coffmana** zakleszczenia: złam jeden → brak deadlocka + +\newpage + +## PYTANIE 10: Zarządzanie pamięcią (SOI) + +**Problemy i mechanizmy. Stronicowanie vs segmentacja.** + +--- + +### Tło pojęciowe — słowniczek + +**Pamięć operacyjna (RAM)** — szybka pamięć ulotna, z której procesor odczytuje i zapisuje dane. Ograniczona ilościowo (np. 8–64 GB). Zadanie OS: rozdzielić ją sprawiedliwie i bezpiecznie między procesy. + +**Pamięć wirtualna (virtual memory)** — abstrakcja: każdy proces „widzi" własną, ciągłą przestrzeń adresową, niezależnie od fizycznego rozmieszczenia danych w RAM. OS + MMU (sprzęt) tłumaczą adresy wirtualne na fizyczne. Dzięki temu programy mogą używać więcej pamięci niż fizycznie dostępne (reszta na dysku = swap). + + Program widzi: [0x0000 ... 0xFFFF] ← wirtualne, ciągłe + RAM fizyczny: [ramka 5][ramka 12][ramka 3] ← rozproszone + +--- + +**Fragmentacja (fragmentation)** — marnowanie pamięci z powodu sposobu alokacji. + +**Fragmentacja zewnętrzna (external)** — wolna pamięć jest rozproszona w małych kawałkach między zajętymi. Suma wolnych kawałków wystarczy, ale żaden pojedynczy nie jest wystarczająco duży. + + [ZAJĘTE][wolne 2KB][ZAJĘTE][wolne 3KB][ZAJĘTE] + Razem 5KB wolne, ale nie zmieści się blok 4KB! + +**Fragmentacja wewnętrzna (internal)** — przydzielony blok jest większy niż potrzebny. Pozostała różnica jest zmarnowana. Np. strona 4KB przydzielona dla 100 bajtów danych — 3996 bajtów zmarnowane. + +**Ochrona pamięci (memory protection)** — mechanizm uniemożliwiający procesowi dostęp do pamięci innego procesu. Realizowana przez tablice stron (bity R/W/X) i MMU. Bez ochrony: crash jednego procesu mógłby zepsuć cały system. + +**Relokacja (relocation)** — program musi działać pod różnymi adresami fizycznymi (nie wie z góry, gdzie zostanie załadowany). Pamięć wirtualna rozwiązuje to automatycznie — program zawsze widzi te same adresy wirtualne. + +**COW (Copy-on-Write)** — optymalizacja: przy fork() (tworzenie procesu) dziecko współdzieli strony z rodzicem. Kopia fizyczna następuje dopiero gdy któryś pisze. Oszczędność: jeśli procesy tylko czytają, nie kopiujemy nic. + +--- + +**Strona (page)** — jednostka pamięci wirtualnej o stałym rozmiarze (zwykle 4 KB). Pamięć wirtualna jest podzielona na strony. + +**Ramka (frame)** — jednostka pamięci fizycznej o tym samym rozmiarze co strona. Strona wirtualna mapowana jest na ramkę fizyczną. + +**Tablica stron (page table)** — struktura danych tłumacząca numer strony → numer ramki. Każdy proces ma własną tablicę stron. Wpis zawiera: numer ramki, bity present/dirty/R/W/X. + + Adres wirtualny = [numer strony | offset] + Tablica stron: strona 5 → ramka 12 + Adres fizyczny = [12 | offset] + +**Wielopoziomowe tablice stron** — oszczędność pamięci. Zamiast jednej ogromnej tablicy (32-bit: 4 MB per proces!), drzewo tablic. Nieużywane gałęzie nie istnieją. + + 32-bit: 2-level (1024 × 1024 wpisów) + 64-bit: 4-level (x86-64: PML4 → PDPT → PD → PT) + +**TLB (Translation Lookaside Buffer)** — sprzętowy cache translacji adresów. Przechowuje ostatnio używane mapowania strona→ramka. Trafienie w TLB: ~1 ns; pudło: ~10-100 ns (trzeba chodzić po tablicy stron). Hit rate: typowo >99%. + +**Page fault (brak strony)** — wyjątek sprzętowy gdy strona nie jest aktualnie w RAM. OS ładuje ją z dysku (swap). Nie jest „błędem" programisty — to normalna część zarządzania pamięcią wirtualną. + + Koszt: ~1-10 ms (bo dysk!) vs ~100 ns dla dostępu do RAM + Różnica ~10 000x — dlatego minimalizacja page faults jest krytyczna + +--- + +**Algorytmy wymiany stron (page replacement):** +- **FIFO** — usuń najstarszą stronę. Prosty, ale anomalia Bélády'ego (więcej ramek → więcej page faults!). +- **LRU (Least Recently Used)** — usuń najdawniej używaną. Dobry, ale kosztowna implementacja (trzeba śledzić czas użycia). +- **Clock (Second Chance)** — przybliżenie LRU. Wskazówka zegara + bit odwołania. Jeśli bit=1, daj drugą szansę (zeruj i idź dalej). Jeśli bit=0, wymień. +- **Optimal** — usuń stronę, która nie będzie potrzebna najdłużej. Idealny, ale nierealizowalny (wymaga znajomości przyszłości). Benchmark dla porównania. + +--- + +**Segmentacja (segmentation)** — podział pamięci na segmenty logiczne o zmiennych rozmiarach (kod, dane, stos). Adres = (numer segmentu, offset). Każdy segment ma bazę i limit. + + Cecha Stronicowanie Segmentacja + ───────────────────────────────────────────────────── + Jednostka strona (stały, 4KB) segment (zmienny) + Fragmentacja wewnętrzna zewnętrzna + Widok programisty niewidoczne logiczne (kod, dane) + Współczesne OS dominuje (x86-64) prawie zniknęła + +**Dlaczego stronicowanie wygrało?** Stałe rozmiary stron = brak fragmentacji zewnętrznej, prostsze zarządzanie, łatwiejsze w sprzęcie. Intel porzucił pełną segmentację w x86-64 (flat segments + paging). + +**Swap** — przestrzeń na dysku używana gdy RAM się wyczerpie. OS przenosi rzadko używane strony na swap (swap out) i wczytuje je z powrotem gdy potrzebne (swap in). Wolne (dysk!), ale pozwala uruchamiać więcej niż RAM. + +--- + +### Problemy +1. **Fragmentacja** — zewnętrzna (wolna pamięć rozproszona) i wewnętrzna (przydzielony blok > potrzebny) +2. **Ochrona** — procesy nie mogą czytać cudzej pamięci +3. **Relokacja** — program musi działać pod różnymi adresami +4. **Współdzielenie** — biblioteki, COW (Copy-on-Write) +5. **Ograniczona pamięć** — więcej procesów niż RAM + +### Stronicowanie (Paging) + +- Pamięć wirtualna → **strony** (pages, np. 4KB), fizyczna → **ramki** (frames) +- **Tablica stron** mapuje strony na ramki +- Translacja: adres = (numer strony | offset) → (numer ramki | offset) +- **Wielopoziomowe tablice** — oszczędność pamięci (32-bit: 2-level, 64-bit: 4-level) +- **TLB** (Translation Lookaside Buffer) — cache translacji +- **Page fault** — strona nie w RAM → ładuj z dysku (swap) +- **Algorytmy wymiany:** FIFO, LRU, Clock (Second Chance), Optimal + +### Segmentacja (Segmentation) + +- Pamięć dzielona na **segmenty logiczne** (kod, dane, stos) o różnych rozmiarach +- Adres = (numer segmentu, offset), tablica segmentów: (baza, limit) +- Ochrona per-segment (R, W, X) + +### Porównanie + +| Cecha | Stronicowanie | Segmentacja | +|-------------------|------------------------|-------------------------| +| Jednostka | Strona (stały rozmiar) | Segment (zmienny) | +| Fragmentacja | Wewnętrzna | Zewnętrzna | +| Widok programisty | Niewidoczne | Widoczne (logiczne) | +| Ochrona | Per-strona | Per-segment | +| Współdzielenie | Per-strona | Per-segment (naturalne) | +| Współczesne OS | Dominuje (x86-64) | Rzadko (Intel porzucił) | + +### Etymologia + +**Stronicowanie (Paging)** — pamięć dzielona na „strony" jak w książce. **TLB** — Translation Lookaside Buffer; „lookaside" = sprawdź z boku (cache) zanim sięgniesz do tablicy. **Segmentacja** — łac. „segmentum" = odcięty kawałek. **COW** — Copy-on-Write: kopiuj dopiero przy modyfikacji. **LRU** — Least Recently Used. **FIFO** — First In, First Out. **Page fault** — „fault" to wyjątek sprzętowy, nie błąd programisty. + +### Jak zapamiętać + +- **Stronicowanie = szuflady jednakowej wielkości** (proste, mała fragmentacja wewnętrzna) +- **Segmentacja = pudełka różnej wielkości** (logiczne, ale fragmentacja zewnętrzna) +- Współcześnie: **stronicowanie wygrało** — segmentacja prawie zniknęła (x86-64 = flat segments + paging) + +\newpage + +## PYTANIE 11: Modelowanie procesów biznesowych (WSYZ) + +**Scharakteryzować standardy i narzędzia do modelowania procesów biznesowych.** + +--- + +### Tło pojęciowe — słowniczek + +**Proces biznesowy (business process)** — uporządkowany zbiór czynności, które transformują dane wejściowe (np. zamówienie klienta) w wynik (np. dostarczony produkt). Przykład: „obsługa reklamacji" = przyjmij zgłoszenie → zweryfikuj → zatwierdź/odrzuć → poinformuj klienta. Modelowanie to graficzne przedstawienie takich procesów. + +**Modelowanie procesów** — tworzenie wizualnych diagramów opisujących KTO, CO, KIEDY i W JAKIEJ KOLEJNOŚCI wykonuje w organizacji. Cel: zrozumienie, dokumentacja, optymalizacja, automatyzacja. + +--- + +**BPMN (Business Process Model and Notation)** — najpopularniejszy standard notacji graficznej dla procesów biznesowych. Utrzymywany przez OMG (Object Management Group). Wersja 2.0 ma format XML, dzięki czemu diagramy mogą być bezpośrednio wykonywane przez silnik procesów (BPMS). + +**Elementy BPMN:** +- **Zdarzenia (Events):** ○ start, ◎ pośrednie, ◉ końcowe — co wyzwala lub kończy proces. +- **Czynności (Activities):** prostokąty — praca do wykonania (task, subprocess). +- **Bramki (Gateways):** ◇ kontrola przepływu — decyzje i rozgałęzienia. + +**Bramki BPMN (gateways):** +- **XOR (Exclusive):** dokładnie JEDNA ścieżka (jak if/else). Np. „Czy kwota > 1000? → Tak/Nie". +- **AND (Parallel):** WSZYSTKIE ścieżki jednocześnie. Np. „Wyślij e-mail I zaktualizuj bazę". +- **OR (Inclusive):** JEDNA LUB WIĘCEJ ścieżek. Np. „Powiadom SMS i/lub e-mail zależnie od preferencji." + + ○─→[Przyjmij zamówienie]─→◇XOR─→[Zapłata kartą]─→◉ + └→[Zapłata przelewem]─→◉ + +**Łączniki BPMN:** +- **Sequence Flow (→)** — kolejność czynności +- **Message Flow (- - →)** — komunikacja między uczestnikami (poolami) +- **Association (···→)** — powiązanie z danymi/komentarzami + +**Swimlane** — element organizacyjny: **Pool** = organizacja/uczestnik, **Lane** = dział/rola w organizacji. Jak tory na basenie — każdy „pływa" na swoim torze. + +--- + +**UML (Unified Modeling Language)** — uniwersalny język modelowania w inżynierii oprogramowania. 14 typów diagramów. W kontekście procesów używa się **Activity Diagrams** — rozszerzenie flowchartów z fork/join (współbieżność), decision nodes, object flow. Lepszy dla procesów technicznych/software niż BPMN. + +**UML Activity Diagram vs BPMN:** + + Cecha BPMN UML Activity + ───────────────────────────────────────────────── + Cel Procesy biznesowe Przepływ sterowania + Odbiorcy Biznes + IT Głównie IT + Komunikacja Pools + Msg Flow Partitions + Automatyzacja Tak (XML) Ograniczona + +**EPC (Event-driven Process Chain)** — notacja procesowa: naprzemienne zdarzenia i funkcje, połączone łącznikami logicznymi (AND/OR/XOR). Popularny w środowisku SAP (framework ARIS). Mniej uniwersalny niż BPMN. + +**ARIS (Architecture of Integrated Information Systems)** — framework i narzędzie prof. Scheera do modelowania procesów. Bazuje na EPC. Używany głównie w dużych firmach z SAP. + +--- + +**OMG (Object Management Group)** — organizacja standaryzacyjna odpowiedzialna za BPMN, UML, CORBA. Non-profit, członkowie to firmy IT (IBM, Oracle, SAP...). + +**BPMS (Business Process Management System/Suite)** — oprogramowanie do automatyzacji procesów BPMN. Diagram BPMN 2.0 XML jest interpretowany i wykonywany przez silnik (np. Camunda, jBPM). Zmiana procesu = zmiana diagramu, nie kodu. + +**IDEF0 (Integration DEFinition)** — notacja modelowania funkcji z US Air Force (1970s). Skupia się na WEJŚCIach, WYJŚCIach, mechanizmach i kontrolach. Rzadko używana współcześnie. + +**VSM (Value Stream Map)** — narzędzie Lean Manufacturing. Mapuje przepływ materiałów i informacji od dostawcy do klienta, identyfikuje marnotrawstwo (waste). Stosowane w fabrykach i IT (DevOps). + +**Flowchart (schemat blokowy)** — najprostszy sposób modelowania: prostokąty (czynności), romby (decyzje), strzałki (przepływ). Prekursor BPMN, ale brak standardów dla komunikacji międzyprocesowej. + +--- + +### Główne standardy + +### BPMN 2.0 (Business Process Model and Notation) — OMG +- **Uniwersalny standard** — dla analityków, architektów, programistów +- Elementy: Zdarzenia (○ start, ◎ pośrednie, ◉ końcowe), Czynności (prostokąty), Bramki (◇ XOR, ◆ AND, ○◇ OR) +- Łączniki: Sequence Flow (→), Message Flow (- - →), Association (···→) +- Swimlanes: Pool (organizacja) / Lane (dział) +- Format XML → automatyzacja (BPMS) + +### UML Activity Diagrams +- Część UML 2.x — rozszerzenie flowchartów + sieci Petriego +- Elementy: akcje, decyzje (◇), fork/join (▬), pin (object flow) +- Lepsze dla procesów technicznych/software + +### EPC (Event-driven Process Chain) +- Naprzemienne zdarzenia i funkcje, łączniki AND/OR/XOR +- Popularny w SAP (ARIS framework) + +### Inne: IDEF0 (modelowanie funkcji), VSM (Value Stream Map, Lean), Flowcharty + +### BPMN vs UML Activity + +| Cecha | BPMN | UML Activity | +|--------------|---------------------|---------------------| +| Cel | Procesy biznesowe | Przepływ sterowania | +| Odbiorcy | Biznes + IT | Głównie IT | +| Komunikacja | Pools + Message Flow| Partitions | +| Automatyzacja| Tak (BPMN 2.0 XML) | Ograniczona | + +### Narzędzia +Bizagi Modeler, Camunda, Signavio, Lucidchart, draw.io, Enterprise Architect + +### Etymologia + +**BPMN** — Business Process Model and Notation; OMG (Object Management Group). **UML** — Unified Modeling Language; „Unified" bo połączył metody Boocha, Rumbaugh i Jacobsona („Three Amigos", 1990s). **EPC** — Event-driven Process Chain; August-Wilhelm Scheer (Saarland, 1990s; podstawa SAP ARIS). **Swimlane** — metafora torów na basenie: każdy uczestnik na swoim „torze". **IDEF0** — Integration DEFinition; US Air Force (1970s). + +### Jak zapamiętać + +- **BPMN = „standard nr 1" dla biznesu** — bramki, swimlanes, zdarzenia +- **3 typy bramek: XOR (jeden), AND (wszystkie), OR (jeden lub więcej)** +- UML Activity → programiści; BPMN → wszyscy + +\newpage + +## PYTANIE 12: Sieciowe modele optymalizacji (WSYZ) + +**Przedstawić sieciowe modele optymalizacji stosowane w systemach zarządzania.** + +--- + +### Tło pojęciowe — słowniczek + +**Graf (graph)** — struktura: zbiór **węzłów** (vertices) połączonych **krawędziami** (edges). Podstawowa abstrakcja dla wszystkich modeli sieciowych. Krawędzie mogą mieć wagi (koszt, odległość, przepustowość) i kierunek (graf skierowany). + + A──5──B──3──C graf ważony nieskierowany + │ │ węzły: A,B,C,D + 2 4 krawędzie z wagami + │ │ + D─────7─────┘ + +**Sieć (network)** — graf z interpretacją: węzły = lokalizacje/zadania, krawędzie = połączenia/trasy, wagi = koszty/czasy/przepustowości. Modele sieciowe rozwiązują problemy optymalizacyjne na takich grafach. + +**Optymalizacja** — znalezienie najlepszego rozwiązania (minimum lub maksimum funkcji celu) przy zadanych ograniczeniach. W kontekście sieciowym: najkrótsza trasa, maksymalny przepływ, minimalny koszt itp. + +--- + +**Najkrótsza ścieżka (shortest path)** — znajdź ścieżkę od źródła do celu o minimalnej sumie wag. Zastosowanie: GPS, routing sieciowy. + +**Dijkstra** — algorytm zachłanny. Bierze najbliższy nieodwiedzony węzeł, aktualizuje odległości sąsiadów. Wymaga wag ≥ 0. Złożoność: O(E log V) z kopcem. Dla V=1000, E=5000: ~60 000 operacji. + +**Bellman-Ford** — obsługuje ujemne wagi. Relaksuje wszystkie krawędzie V-1 razy. O(VE). Wykrywa cykle ujemne. + +**A\*** — rozszerzenie Dijkstry z heurystyką (szacuje odległość do celu). Szybszy w praktyce, bo eksploruje w kierunku celu. Używany w nawigacji, grach. + +--- + +**Maksymalny przepływ (max flow)** — znajdź największy przepływ od źródła (s) do ujścia (t) w sieci z ograniczonymi przepustowościami krawędzi. Zastosowanie: przepustowość linii, ruch sieciowy, planowanie. + +**Ford-Fulkerson** — metoda: znajdź ścieżkę powiększającą (augmenting path) w sieci rezydualnej, powiększ przepływ, powtarzaj. Twierdzenie max-flow min-cut: max. przepływ = min. przepustowość przekroju. + +**Edmonds-Karp** — implementacja Ford-Fulkerson z BFS (zamiast DFS). Gwarantuje O(VE²). Dla V=100, E=500: ~25 000 000 operacji max. + +--- + +**Problem przydziału (assignment problem)** — przydziel n zadań do n pracowników, minimalizując łączny koszt. Każdy pracownik dostaje dokładnie jedno zadanie. Macierz kosztów n×n. + + Pracownik Z1 Z2 Z3 + A 8 4 7 + B 5 2 3 + C 9 4 8 + Optymalne: A→Z2(4), B→Z3(3), C→Z1(9) = 16 + +**Algorytm węgierski (Hungarian algorithm)** — rozwiązuje problem przydziału optymalnie w O(n³). Nazwa od prac matematyków węgierskich: Kőnig i Egerváry. + +--- + +**TSP (Travelling Salesman Problem / problem komiwojażera)** — odwiedź wszystkie miasta dokładnie raz i wróć do startu, minimalizując trasę. **NP-trudny** — nie ma znanego algorytmu wielomianowego. Dla n=20 miast: 20!/2 ≈ 1.2×10¹⁸ tras do sprawdzenia brute-force! W praktyce: heurystyki (nearest neighbor, 2-opt, simulated annealing, algorytmy genetyczne). + +**NP-trudny (NP-hard)** — klasa problemów, dla których nie znamy algorytmu rozwiązującego w czasie wielomianowym. Nie oznacza „niemożliwe" — oznacza „nie da się szybko dla dużych instancji" (czas rośnie wykładniczo). Stosuje się heurystyki i przybliżenia. + +--- + +**CPM (Critical Path Method)** — metoda harmonogramowania projektów. Wyznacza **ścieżkę krytyczną** = najdłuższą ścieżkę w grafie zadań. Opóźnienie zadania na ścieżce krytycznej opóźnia cały projekt. O(V+E). Zastosowanie: budownictwo, inżynieria. + +**PERT (Program Evaluation and Review Technique)** — podobna do CPM, ale z niepewnością czasu (optymistyczny, pesymistyczny, prawdopodobny → rozkład β). Opracowana dla US Navy (program Polaris, 1958). + +**MST (Minimum Spanning Tree / minimalne drzewo rozpinające)** — połącz wszystkie węzły grafu minimalnym kosztem (bez cykli). Zastosowanie: sieci telekomunikacyjne, elektryczne, wodociągowe. + +**Kruskal** — sortuj krawędzie rosnąco, dodawaj najlżejszą nie tworzącą cyklu. O(E log E). Używa Union-Find. +**Prim** — startuj od węzła, dodawaj najtańszą krawędź prowadzącą na zewnątrz drzewa. O(E log V) z kopcem. + +**Minimalny koszt przepływu (min-cost flow)** — połączenie max flow i najkrótszej ścieżki: przesyłaj zadany przepływ od s do t z minimalnym łącznym kosztem. Zastosowanie: transport, logistics. + +--- + +### 1. Najkrótsza ścieżka — GPS, routing (Dijkstra, Bellman-Ford, A*) +### 2. Maksymalny przepływ — przepustowość linii, dystrybucja (Ford-Fulkerson, Edmonds-Karp) +### 3. Minimalny koszt przepływu — minimalizacja kosztów transportu przy zadanym przepływie +### 4. Problem przydziału — n zadań do n osób, minimalizacja kosztów (algorytm węgierski, O(n³)) +### 5. TSP (komiwojażer) — odwiedź wszystkie miasta raz, minimalizuj trasę (NP-trudny, heurystyki) +### 6. CPM/PERT — harmonogramowanie projektów, ścieżka krytyczna +### 7. MST (drzewo rozpinające) — połącz wszystkie węzły minimalnym kosztem (Kruskal, Prim) + +| Model | Złożoność | Zastosowanie | +|----------------------|-----------------|---------------------------| +| Najkrótsza ścieżka | O(E log V) | Logistyka, routing | +| Max Flow | O(VE²) | Planowanie, dystrybucja | +| Przydział | O(n³) | HR, grafiki | +| TSP | NP-trudny | Trasy kurierów | +| CPM | O(V+E) | Zarządzanie projektami | +| MST | O(E log V) | Sieci infrastrukturalne | + +### Etymologia + +**Ford-Fulkerson** — Lester Ford Jr. + Delbert Fulkerson (1956). **Edmonds-Karp** — Jack Edmonds + Richard Karp (1972); BFS-owa wersja Ford-Fulkerson. **TSP (komiwojażer)** — z XIX-wiecznych niemieckich podręczników dla handlowców. **CPM** — Critical Path Method (DuPont, 1957). **PERT** — Program Evaluation and Review Technique (US Navy, Polaris, 1958). **Kruskal** — Joseph Kruskal (1956). **Prim** — Robert Prim (1957; niezależnie Jarník 1930). **Algorytm węgierski** — Harold Kuhn (1955); od prac Węgrów: Kőniga i Egerváry'ego. + +### Jak zapamiętać + +- **6 modeli na grafach:** Ścieżka, Przepływ, Min-koszt-przepływ, Przydział, TSP, Harmonogram, MST +- Wszystko sprowadza się do: „węzły + krawędzie + wagi → optymalizuj" + +\newpage + +## PYTANIE 13/27: Modelowanie architektury systemów informatycznych (AIS) + +**Cele i metody modelowania architektury.** + +--- + +### Tło pojęciowe — słowniczek + +**Architektura systemu informatycznego (software/system architecture)** — fundamentalne decyzje projektowe dotyczące struktury systemu: jakie komponenty, jak się komunikują, jakie technologie. Jak plan architektoniczny budynku — definiuje „kształt" systemu przed budową. + +**Modelowanie architektury** — tworzenie uproszczonych reprezentacji (diagramów, opisów) systemu na różnych poziomach abstrakcji. Cele: komunikacja w zespole, dokumentacja, analiza jakości (czy system będzie wydajny? skalowalny?), planowanie rozwoju. + +--- + +**Framework architektoniczny (architecture framework)** — ustrukturyzowane podejście do opisywania architektury. Definiuje: jakie widoki (views) tworzyć, jakie aspekty uwzględnić, w jakiej kolejności pracować. + +**TOGAF (The Open Group Architecture Framework)** — najpopularniejszy framework enterprise architecture. Definiuje metodykę ADM (Architecture Development Method) — cykliczny proces tworzenia architektury. 4 domeny: +- **Business** — procesy organizacji +- **Data** — struktury danych +- **Application** — aplikacje i ich interakcje +- **Technology** — infrastruktura (serwery, sieci) + +**ADM (Architecture Development Method)** — cykliczny proces TOGAF: Preliminary → Vision → Business Arch → IS Arch → Technology Arch → Opportunities → Migration → Governance. Iteracyjny — można wracać do wcześniejszych faz. + +**4+1 View Model (Kruchten)** — model pięciu perspektyw architektury: +- **Logical View** — funkcjonalność (klasy, moduły) +- **Process View** — współbieżność, przepływ danych +- **Development View** — organizacja kodu (pakiety, warstwy) +- **Physical View** — wdrożenie na sprzęt (serwery, kontenery) +- **+1 Scenarios** — use cases łączące wszystkie widoki + + Dlaczego 4+1? Bo różni interesariusze patrzą na system inaczej: + programista → Development View, admin → Physical View, + użytkownik → Scenarios, architekt → Logical View + +**Zachman Framework** — taksonomia 6×6: pytania CO/JAK/GDZIE/KTO/KIEDY/DLACZEGO × poziomy abstrakcji (kontekst → logiczny → fizyczny → ...). Nie mówi JAK modelować — mówi CO należy udokumentować. Kompletny, ale złożony. + +--- + +**C4 Model (Simon Brown)** — pragmatyczny model: 4 poziomy zoomu diagramów: +1. **Context** — system w otoczeniu (kto go używa, z czym się integruje) +2. **Container** — kontenery techniczne (app server, DB, SPA, API) +3. **Component** — moduły wewnątrz kontenera +4. **Code** — klasy, interfejsy (opcjonalnie, np. UML) + +Zaleta: prosty, zrozumiały dla nie-architektów. Zaczynasz od „big picture" i zanurzasz się głębiej. + +**ArchiMate** — język modelowania The Open Group. 3 warstwy (Business, Application, Technology) × 3 aspekty (Active Structure — kto?, Behavior — co robi?, Passive Structure — na czym?). Komplementarny z TOGAF. + +--- + +**UML (Unified Modeling Language)** — uniwersalny język modelowania. W kontekście architektury: **Component Diagram** (moduły i zależności), **Deployment Diagram** (mapowanie na sprzęt), **Sequence Diagram** (interakcje w czasie). + +**ADR (Architecture Decision Records)** — lekka dokumentacja: każda kluczowa decyzja architektoniczna zapisana jako plik z: kontekstem, decyzją, konsekwencjami. Wersjonowane w repo. Format: „Zdecydowaliśmy X, bo Y. Konsekwencje: Z." + +**ATAM (Architecture Tradeoff Analysis Method)** — metoda oceny architektury przez scenariusze jakościowe. Identyfikuje tradeoffs: „ta decyzja poprawia wydajność kosztem modyfikowalności". Opracowana przez SEI (Carnegie Mellon). + +**Quality Attributes (atrybuty jakości, ISO 25010)** — mierzalne cechy systemu: Performance, Security, Scalability, Maintainability, Reliability, Usability, Portability, Compatibility. Architektura determinuje osiągalne atrybuty jakości. + +--- + +### Cele: komunikacja, dokumentacja, analiza jakości, planowanie, zarządzanie złożonością + +### Frameworki + +**TOGAF** — metodyka ADM (Architecture Development Method), 4 domeny: Business, Data, Application, Technology. + +**4+1 View Model (Kruchten):** +- Logical (funkcjonalność), Process (współbieżność), Development (organizacja kodu), Physical (wdrożenie), + Scenarios (use cases) + +**Zachman Framework** — taksonomia 6×6: What/How/Where/Who/When/Why × poziomy abstrakcji. + +**C4 Model (Simon Brown):** +- Level 1: System Context → Level 2: Container → Level 3: Component → Level 4: Code + +**ArchiMate** — 3 warstwy: Business, Application, Technology × 3 aspekty: Active, Behavior, Passive. + +### Notacje: UML (Component, Deployment, Sequence), ArchiMate, C4, ADR (Architecture Decision Records) + +### Analiza: ATAM (Architecture Tradeoff Analysis Method), Quality Attributes (ISO 25010: Performance, Security, Scalability, Maintainability, Reliability) + +### Etymologia + +**TOGAF** — The Open Group Architecture Framework. **Zachman** — John Zachman (IBM, 1987); framework nazwany od twórcy. **C4** — 4 × C: Context, Container, Component, Code (Simon Brown, 2006). **ArchiMate** — „Architecture" + „animate" (The Open Group). **ATAM** — Architecture Tradeoff Analysis Method (SEI, Carnegie Mellon). **Kruchten** — Philippe Kruchten (Rational/IBM, 1995); 4+1 View Model. **ISO 25010** — międzynarodowy standard atrybutów jakości oprogramowania. + +### Jak zapamiętać + +- **TOGAF = JAK** budować architekturę; **Zachman = CO** dokumentować +- **C4 = 4 poziomy zoomu** (Context → Container → Component → Code) +- **4+1 = LDPP+S** (Logical, Development, Process, Physical + Scenarios) + +\newpage + +## PYTANIE 14/28: Wzorce architektoniczne (AIS) + +**Czemu służą? Jak powstają? Jak są katalogowane? Przykłady.** + +--- + +### Tło pojęciowe — słowniczek + +**Wzorzec (pattern)** — udokumentowane, powtarzalne rozwiązanie typowego problemu. Format: Nazwa + Problem (kiedy stosować) + Rozwiązanie (struktura) + Konsekwencje (tradeoffs). To nie gotowy kod — to szablon myślowy, który adaptujemy do kontekstu. + +**Wzorzec architektoniczny (architectural pattern)** — wzorzec definiujący CAŁKOWITĄ strukturę systemu: jak podzielić na komponenty, jak komunikują się, jak skalować. Większa skala niż wzorzec projektowy (design pattern), który dotyczy pojedynczej klasy/obiektu. + + Skala wzorców: + Architektoniczny: Microservices, Layered, Event-Driven (cały system) + Projektowy: Singleton, Observer, Factory (klasa/obiekt) + Idiomatyczny: RAII, for-each (linia kodu) + +--- + +**Monolith (monolit)** — cały system jako jedna aplikacja, jeden deployment. Prosty, łatwy na start. Problemy: trudne skalowanie (skalujesz wszystko albo nic), długie buildy, duże ryzyko przy zmianach. + +**Layered (warstwowy)** — system podzielony na warstwy, każda zależna od niższej: Presentation → Business Logic → Data Access → Database. Separacja odpowiedzialności. Wada: każde żądanie przechodzi przez WSZYSTKIE warstwy (overhead). + + [Presentation] ← UI, API + ↓ + [Business Logic] ← reguły domenowe + ↓ + [Data Access] ← SQL, ORM + ↓ + [Database] ← PostgreSQL + +**Microservices (mikroserwisy)** — system rozbity na małe, niezależne serwisy, każdy z własną bazą danych i deploymentem. Każdy serwis odpowiada za jedną domenę (np. zamówienia, płatności, użytkownicy). Zalety: niezależne skalowanie, niezależne deployments, różne technologie. Wady: złożoność operacyjna (sieć, monitoring, transakcje rozproszone). + +**Event-Driven Architecture (EDA)** — komunikacja przez zdarzenia (events). Producer generuje event → Broker (np. Kafka) → Consumers reagują. Loose coupling — producent nie wie kto konsumuje. Eventual consistency. + +--- + +**CQRS (Command Query Responsibility Segregation)** — osobne modele do zapisu (Command) i odczytu (Query). Command model zoptymalizowany do walidacji i zapisu, Query model zoptymalizowany do szybkiego odczytu (np. zdenormalizowane widoki). Złożony, ale potężny przy asymetrii read/write. + + Command → [Write DB] → Event → [Read DB projekcja] → Query + Zapis i odczyt mają osobne schematy! + +**Hexagonal (Ports & Adapters, Alistair Cockburn)** — rdzeń domeny (business logic) jest niezależny od frameworków, baz danych, UI. Komunikuje się przez „porty" (interfejsy). „Adaptery" implementują porty (np. adapter PostgreSQL, adapter REST). Korzyść: testowalność — możesz podmienić adapter na mock. + +--- + +**Katalogi wzorców:** +- **POSA (Pattern-Oriented Software Architecture)** — 5-tomowa seria o wzorcach architektonicznych: Layers, Pipes & Filters, Broker, MVC, Microkernel. +- **GoF (Gang of Four)** — Gamma, Helm, Johnson, Vlissides. 23 wzorce projektowe (nie architektoniczne): kreacyjne (Factory, Singleton), strukturalne (Adapter, Decorator), behawioralne (Observer, Strategy). Książka z 1994 r. +- **EIP (Enterprise Integration Patterns)** — Hohpe & Woolf. Wzorce komunikacji między systemami: Message Channel, Content-Based Router, Aggregator. +- **PoEAA (Patterns of Enterprise Application Architecture)** — Martin Fowler. Wzorce aplikacji enterprise: Repository, Unit of Work, Domain Model, Active Record. +- **Cloud Patterns** — Microsoft Azure Architecture Center, AWS Well-Architected. Wzorce chmurowe: Circuit Breaker, Sidecar, Saga, Strangler Fig. + +--- + +**Skalowalność (scalability)** — zdolność systemu do obsługi rosnącego obciążenia. W kontekście wzorców: monolith → skalowalność niska (scale up), microservices → wysoka (scale out per serwis). + +**Loose coupling (luźne wiązanie)** — komponenty mają minimalne zależności. Zmiana jednego nie wymaga zmiany drugiego. Event-Driven i Microservices promują loose coupling. + +**Separacja odpowiedzialności (separation of concerns)** — każdy komponent odpowiada za jedną rzecz. Fundamentalna zasada stojąca za wzorcami warstwowymi, hexagonal, CQRS. + +**Eventual consistency (spójność ostateczna)** — dane mogą być chwilowo niespójne, ale „w końcu" się zsynchronizują. Cena za skalowalność i loose coupling w systemach rozproszonych (EDA, Microservices). + +--- + +### Cel: reużywalne rozwiązania typowych problemów, wspólne słownictwo, dokumentacja wiedzy + +### Powstawanie: Problem powtarzalny → Podobne rozwiązania → Uogólnienie → Dokumentacja → Walidacja → Katalogowanie + +### Katalogi: POSA (wzorce architektoniczne), GoF (projektowe), EIP (integracja), PoEAA (Fowler), Cloud Patterns + +### Przykładowe wzorce + +**Layered (Warstwy):** Presentation → Business Logic → Data Access → DB. Separacja odpowiedzialności. Sztywne, boilerplate. + +**Microservices:** Niezależne serwisy, osobne wdrożenia, skalowalność. Złożoność operacyjna. + +**Event-Driven (EDA):** Producer → Event Broker (Kafka) → Consumers. Loose coupling, eventual consistency. + +**CQRS:** Osobne modele Read/Write. Optymalizacja per-strona. Złożoność. + +**Hexagonal (Ports & Adapters):** Core niezależny od frameworków. Testowalność. + +| 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 | + +### Etymologia + +**POSA** — Pattern-Oriented Software Architecture (Buschmann et al., 1996). **GoF** — Gang of Four: Gamma, Helm, Johnson, Vlissides (1994, „Design Patterns"). **EIP** — Enterprise Integration Patterns (Hohpe & Woolf, 2003). **PoEAA** — Patterns of Enterprise Application Architecture (Martin Fowler, 2002). **Hexagonal** — Alistair Cockburn (2005); kształt sześciokąta nie ma specjalnego znaczenia. **CQRS** — Command Query Responsibility Segregation (Greg Young, ~2010); oparty na CQS Bertranda Meyera. **Microservices** — termin spopularyzowany ~2012 (James Lewis, Martin Fowler). + +### Jak zapamiętać + +- **„Monolith first"** — rozdzielaj gdy znasz granice domen +- **Wzorzec = Nazwa + Problem + Rozwiązanie + Konsekwencje** +- Katalogi: POSA = architektura, GoF = klasy/obiekty, EIP = messaging + +\newpage + +## PYTANIE 15: Agent upostaciowiony w robotyce + +**Jak wykorzystuje się agenta upostaciowionego do specyfikacji sterowników robotów?** + +--- + +### Tło pojęciowe — słowniczek + +**Agent (w AI)** — autonomiczny byt, który postrzega środowisko (sensory), podejmuje decyzje (deliberacja) i wykonuje akcje (efektory). Agent ma cel i działa racjonalnie — wybiera akcje maksymalizujące osiągnięcie celu. + +**Agent upostaciowiony (embodied agent)** — agent posiadający ciało fizyczne w rzeczywistym świecie. Przeciwieństwo agenta czysto softwareowego (np. chatbot). Robot = klasyczny agent upostaciowiony: ma sensory (kamery, LIDAR), ciało (ramię, koła) i działa w środowisku fizycznym. Kluczowe: musi radzić sobie z szumem sensorów, opóźnieniami, nieprzewidywalnością świata. + + Agent software: dane → algorytm → wynik (deterministyczne) + Agent embodied: szum sensorów → niepewność → akcja fizyczna → efekt nieprzewidywalny + +**Sterownik robota (robot controller)** — oprogramowanie decydujące co robot robi w każdej chwili. Specyfikacja sterownika = formalny opis zachowania robota. Agent upostaciowiony to model konceptualny, na którym opiera się sterownik. + +--- + +**Cykl percepcja-deliberacja-akcja (See-Think-Act)** — podstawowy cykl działania agenta upostaciowionego: +1. **See (Percepcja)** — odczytaj dane z sensorów (obraz, odległość, pozycja) +2. **Think (Deliberacja)** — podejmij decyzję (planuj trasę, wybierz akcję) +3. **Act (Akcja)** — wyślij komendy do efektorów (silniki, chwytaki) + + Czujnik LIDAR → [Mapa otoczenia] → [Planowanie ścieżki] → [Silniki kół] + See Think Think Act + +--- + +**3T Architecture (trójwarstwowa architektura sterownika):** +1. **Planner (deliberacja)** — planowanie symboliczne na wysokim poziomie. Czas reakcji: sekundy–minuty. Np. „zaplanuj trasę z A do B przez pokoje 1,2,3". +2. **Sequencer (wykonawca)** — koordynuje zachowania, FSM/Behavior Trees. Czas: 100ms–sekundy. Np. „Jedź do punktu → Obróć → Chwyć obiekt". +3. **Controller (reaktywny)** — bezpośrednie sterowanie sprzętem. Czas: milisekundy. Np. PID utrzymujący prędkość, unikanie kolizji. + + PLANNER (minuty) "Jedź do kuchni po kubek" + ↓ + SEQUENCER (sekundy) "1: Jedź do drzwi → 2: Otwórz → 3: Jedź do blatu" + ↓ + CONTROLLER (ms) "PID: prędkość lewego koła = 0.5 m/s" + +--- + +**BDI (Beliefs-Desires-Intentions)** — formalny model agenta racjonalnego: +- **Beliefs** — wiedza agenta o świecie (mapa, pozycja, stan baterii). Może być niepełna/nieprecyzyjna. +- **Desires** — cele, które agent chciałby osiągnąć (np. „dotrzyj do punktu B"). +- **Intentions** — aktualnie realizowany plan (podzbiór desires, do którego agent się zobowiązał). + +Przykład: Robot-dostawca. Belief: „drzwi zamknięte". Desire: „dostarczyć paczkę do pokoju 5". Intention: „spróbuję drzwi boczne". + +**FSM (Finite State Machine / automat skończony)** — model zachowania: skończona liczba stanów + przejścia warunkowe. Prosty, ale przy złożonych zachowaniach eksploduje liczba stanów i przejść. + + IDLE ──[wykryto cel]──→ APPROACH ──[blisko]──→ GRASP + ↑ │ + └──────────────[obiekt chwycony]────────────────┘ + +**Behavior Tree (drzewo zachowań)** — nowoczesna alternatywa FSM. Hierarchiczna struktura: węzły wewnętrzne = logika (Selector, Sequence), liście = akcje/warunki. Modularny, reużywalny, łatwy do debugowania. Wywodzi się z AI w grach (Halo 2, ~2004). +- **Selector (?)** — wykonuj dzieci po kolei aż pierwszy sukces (jak OR) +- **Sequence (→)** — wykonuj dzieci po kolei, wstrzymaj przy porażce (jak AND) + +--- + +**LTL (Linear Temporal Logic)** — logika temporalna do formalnej specyfikacji zachowań w czasie: +- **□ (always/globally)** — musi być prawdziwe ZAWSZE. □(¬collision) = „nigdy nie koliduj". +- **◇ (eventually)** — kiedyś musi być prawdziwe. ◇(at_goal) = „w końcu dotrzyj do celu". +- **Bezpieczeństwo (safety):** □(obstacle → ¬move_forward) — „zawsze: jeśli przeszkoda, nie jedź do przodu". +- **Żywotność (liveness):** ◇(at_goal) — „w końcu osiągnij cel". + +**PID (Proportional-Integral-Derivative)** — klasyczny regulator sterowania. Minimalizuje błąd (różnicę między wartością zadaną a rzeczywistą). Trzy składniki: +- **P** — proporcjonalny: reaguje na aktualny błąd +- **I** — całkowy: eliminuje błąd stały (drift) +- **D** — różniczkowy: tłumi oscylacje + + Przykład: PID utrzymuje prędkość 1 m/s: + Błąd = 1.0 - 0.8 = 0.2 → P zwiększa moc + Błąd utrzymuje się? → I dodaje korektę + Błąd maleje za szybko? → D hamuje + +**ROS (Robot Operating System)** — middleware (nie OS!) do robotyki. Model pub/sub: węzły (nodes) publikują i subskrybują tematy (topics). Pozwala łączyć moduły (LIDAR, planowanie, sterowanie) w jednolity system. Open source, standard w akademii. + +--- + +### Agent upostaciowiony = ciało fizyczne + sensory + efektory + środowisko + +Cykl: **Percepcja → Deliberacja → Akcja** (See-Think-Act) + +### Architektura sterownika — 3 warstwy (3T Architecture) + +1. **PLANNER** (deliberacja) — planowanie symboliczne, sekundy–minuty +2. **SEQUENCER** (wykonawca) — FSM/Behavior Trees, 100ms–sekundy +3. **CONTROLLER** (reaktywny) — PID, unikanie kolizji, milisekundy + +### Model formalny BDI +- **Beliefs** — mapa, pozycja, stan +- **Desires** — cel nawigacji +- **Intentions** — aktualny plan + +### Specyfikacja w logice temporalnej (LTL) +- Bezpieczeństwo: □(obstacle → ¬move_forward) +- Żywotność: ◇(at_goal) + +### Behavior Trees — nowoczesna specyfikacja zachowań +- Selector (?): wykonaj pierwszy sukces +- Sequence (→): wykonaj wszystkie po kolei +- Action/Condition jako liście + +### ROS (Robot Operating System) — middleware pub/sub dla robotów + +### Etymologia + +**Agent upostaciowiony (Embodied)** — łac. „corpus" = ciało; agent posiadający ciało fizyczne w środowisku. **BDI** — Beliefs-Desires-Intentions; Michael Bratman (filozof, 1987); Rao & Georgeff (1991) przenieśli do AI. **LTL** — Linear Temporal Logic; Amir Pnueli (1977, Turing Award 1996). **PID** — Proportional-Integral-Derivative; Nicolas Minorsky (1922, sterowanie okrętami). **ROS** — Robot Operating System (Willow Garage, 2007). **Behavior Tree** — z game AI (Halo 2, ~2004); zaadaptowane w robotyce. + +### Jak zapamiętać + +- **„See-Think-Act"** = Percepcja → Deliberacja → Akcja +- **3T = Plan-Sequence-Control** (od abstrakcji do sprzętu) +- BDI = Beliefs, Desires, Intentions + +\newpage + +## PYTANIE 16: Języki programowania robotów + +**Omówić specjalizowane języki. Uwypuklić klasyfikację.** + +--- + +### Tło pojęciowe — słowniczek + +**Robot** — cz. „robota" = ciężka praca; termin ukuty przez Karla Čapka (R.U.R., 1920). W przemyśle: programowalna maszyna wykonująca zadania (spawanie, paletyzacja, montaż). W kontekście pytania: głównie roboty przemysłowe (manipulatory). + +**Język programowania robotów** — język do definiowania zachowania robota: ruchy, logika, I/O. Może być specjalizowany (dedykowany producenta) lub ogólny (C++, Python z bibliotekami). Klasyfikacja wg poziomu abstrakcji — od zadań po sygnały silników. + +--- + +**Poziomy abstrakcji T-R-M-S:** + +**Task-level (poziom zadania)** — najwyższy: opisujesz CO robot ma zrobić, nie JAK. „Podnieś A, połóż na B." Robot sam planuje ruchy. Przykłady: PDDL, Behavior Trees. + + // Task-level: + pick(objectA); + place(locationB); + // Robot sam oblicza kinematykę, trajektorię, chwyt + +**Robot-level (poziom robota)** — komendy ruchu w przestrzeni kartezjańskiej lub konfiguracyjnej: move_to(x,y,z), grasp(). Programista mówi GDZIE jechać, robot oblicza JAK (kinematyka odwrotna). Przykłady: RAPID (ABB), KRL (KUKA), Karel (FANUC). + + // RAPID (ABB): + MoveL p1, v500, fine, tool1; // liniowo do p1, prędkość 500 mm/s + +**Motion-level (poziom ruchu)** — planowanie trajektorii: generowanie ciągu punktów od startu do celu z unikaniem kolizji. Kinematyka odwrotna, interpolacja. Przykłady: MoveIt (ROS), OMPL. + +**Servo-level (poziom serwa)** — najniższy: bezpośrednie sterowanie silnikami/serwomechanizmami. Regulacja PID, sygnały PWM. Języki: C/C++, FPGA. Czas reakcji: mikro-milisekundy. + + Task: "Zamontuj śrubę" (sekundy) + Robot: MoveL do_pozycji (100ms) + Motion: Trajektoria 50 pkt/s (20ms) + Servo: PID: PWM silnika = 75% (1ms) + +--- + +**Kinematyka odwrotna (inverse kinematics, IK)** — obliczenie kątów w stawach robota, aby efektor (np. chwytak) znalazł się w zadanej pozycji. Problem odwrotny: znasz cel, szukasz konfiguracji. Może mieć 0, 1 lub wiele rozwiązań. + +**Trajektoria (trajectory)** — zaplanowana ścieżka ruchu w czasie: sekwencja pozycji + prędkości + przyspieszenia. Interpolacja: liniowa (LIN), kołowa (CIRC), punkt-do-punktu (PTP). + +--- + +**Języki producentów (vendor-specific):** +- **RAPID (ABB)** — Robotics Application Programming Interactive Dialogue. Ruchy: MoveJ (joint), MoveL (linear), MoveC (circular). +- **KRL (KUKA Robot Language)** — PTP (point-to-point), LIN (linear), CIRC (circular). Pascal-like syntax. +- **Karel (FANUC)** — od Karla Čapka. MOVE TO target. Pascal-like. +- **PDL2 (Comau)** — MOVE LINEAR TO. Proceduralne. + +**Vendor lock-in** — każdy producent ma WŁASNY język. Program napisany w RAPID nie działa na robocie KUKA. To motywacja dla ROS i standardów. + +**Online vs Offline programming:** +- **Online (teach-in)** — operator prowadzi robota „za rękę" (pendant/teach pendant), robot zapamiętuje punkty. Proste, ale wymaga zatrzymania produkcji. +- **Offline** — programowanie w symulacji (CAD/CAM), bez zatrzymywania robota. Transferujesz gotowy program. + +--- + +**ROS (Robot Operating System)** — middleware (nie OS!) do robotyki. Model pub/sub: węzły publikują/subskrybują tematy. Uniwersalny — działa z robotami różnych producentów. Głównie Python/C++. Wada: nie nadaje się do hard real-time (soft real-time OK; ROS 2 poprawia). + +**MoveIt** — biblioteka ROS do planowania ruchu manipulatorów. Obejmuje: IK, collision avoidance, trajectory planning. Open source. + +**PDDL (Planning Domain Definition Language)** — język opisu problemów planowania. Definiujesz: stany, akcje, warunki, cel. Planner automatycznie znajduje sekwencję akcji. Task-level. + +**FPGA (Field-Programmable Gate Array)** — programowalny układ logiczny. Dla servo-level: przetwarzanie sygnałów w nanosekundach. Szybszy niż mikrokontroler, ale trudniejszy w programowaniu. + +--- + +### Klasyfikacja wg poziomu abstrakcji: **T-R-M-S** + +1. **Task-level** — „Podnieś A, połóż na B" (PDDL, Behavior Trees) +2. **Robot-level** — move_to(), grasp() (RAPID, KRL, Karel, ROS) +3. **Motion-level** — trajektorie, kinematyka odwrotna (MoveIt, OMPL) +4. **Servo-level** — PID, sterowanie silnikami (C/C++, FPGA) + +### Klasyfikacja wg metody: Online (teach-in, pendant) vs Offline (symulacja, CAD) + +### Języki producentów + +| Producent | Język | Ruchy | +|-----------|-------|--------------------| +| ABB | RAPID | MoveJ, MoveL, MoveC| +| KUKA | KRL | PTP, LIN, CIRC | +| FANUC | Karel | MOVE TO | +| Comau | PDL2 | MOVE LINEAR TO | + +### Uniwersalne: ROS + Python/C++, MoveIt (planowanie manipulatora), Orocos (real-time) + +### Graficzne: RobotStudio (ABB), ROBOGUIDE (FANUC), Blockly (edukacja) + +### Etymologia + +**RAPID** — Robotics Application Programming Interactive Dialogue (ABB). **KRL** — KUKA Robot Language. **Karel** — od Karla Čapka, czeskiego pisarza, który ukuł słowo „robot" (cz. „robota" = ciężka/przymusowa praca) w sztuce R.U.R. (1920). **PDDL** — Planning Domain Definition Language. **MoveIt** — open source do planowania ruchu manipulatora (Willow Garage/PickNik). **Robot** — cz. „robota" = pańszczyzna; Karel Čapek, R.U.R. (1920). + +### Jak zapamiętać + +- **„Od zadania do serwa: T-R-M-S"** +- Każdy producent ma WŁASNY język (vendor lock-in) +- ROS próbuje ujednolicić, ale nie dla hard real-time + +\newpage + +## PYTANIE 17: Szeregowanie zadań + +**Cechy klasyfikacji. Przykładowa metoda.** + +--- + +### Tło pojęciowe — słowniczek + +**Szeregowanie zadań (scheduling)** — przydzielanie zadań do maszyn (procesorów, linii produkcyjnych) w czasie, tak aby zoptymalizować wybrane kryterium (np. minimalizacja czasu ukończenia, minimalizacja opóźnień). Fundamentalny problem badań operacyjnych i systemów operacyjnych. + + Mam 5 zadań i 2 maszyny. Które zadanie na którą maszynę? W jakiej kolejności? + Cel: ukończyć wszystko najszybciej. + +--- + +**Notacja Grahama (α | β | γ)** — standardowy sposób opisu problemu szeregowania w trzech polach: + +**α — środowisko maszynowe:** ile i jakie maszyny? +- **1** — jedna maszyna +- **Pm** — m identycznych maszyn równoległych +- **F** (flow shop) — zadania „płyną" przez maszyny w tej samej kolejności (jak taśma montażowa) +- **J** (job shop) — każde zadanie ma indywidualną trasę przez maszyny (elastyczniejsze, trudniejsze) + +**β — charakterystyki zadań:** jakie ograniczenia? +- **rⱼ** (release dates) — zadanie j dostępne dopiero w czasie rⱼ +- **dⱼ** (due dates) — termin, do którego zadanie j powinno być ukończone +- **pmtn** (preemption) — można przerwać zadanie i wrócić później +- **prec** (precedencje) — zadanie A musi skończyć się przed B + +**γ — kryterium optymalizacji:** co minimalizujemy? +- **Cmax (makespan)** — czas ukończenia OSTATNIEGO zadania. Minimalizacja → najszybsze „zrobienie wszystkiego". +- **ΣCⱼ** — suma czasów ukończenia. Minimalizacja → minimalizacja średniego czasu. +- **Lmax** — maksymalne opóźnienie (max(Cⱼ - dⱼ)). Minimalizacja → żadne zadanie nie jest „bardzo" spóźnione. +- **ΣTⱼ** — suma spóźnień (Tⱼ = max(0, Cⱼ - dⱼ)). +- **ΣUⱼ** — liczba spóźnionych zadań (Uⱼ = 1 jeśli Cⱼ > dⱼ, 0 w.p.p.). + + Przykład zapisu: 1 || ΣCⱼ + Znaczenie: 1 maszyna, brak ograniczeń, minimalizuj sumę czasów ukończenia + +--- + +**SPT (Shortest Processing Time)** — reguła: wykonuj najkrótsze zadanie najpierw. Optymalna dla problemu 1 || ΣCⱼ. + + Dlaczego SPT jest optymalne? Bo krótkie zadania „nie blokują" długich. + Zadania: 5, 3, 8, 2, 6 + SPT → 2, 3, 5, 6, 8 + Czasy ukończenia: 2, 5, 10, 16, 24 + ΣCⱼ = 57 + + Gdyby odwrotnie (LPT): 8, 6, 5, 3, 2 + Czasy ukończenia: 8, 14, 19, 22, 24 + ΣCⱼ = 87 (gorsze!) + +**EDD (Earliest Due Date)** — reguła: wykonuj najpierw zadanie z najwcześniejszym terminem (deadline). Optymalna dla 1 || Lmax. + +**Algorytm Johnsona** — optymalny dla flow shopu z 2 maszynami (F2 || Cmax). Algorytm: +1. Jeśli min czas jest na maszynie 1 → zadanie na początek +2. Jeśli min czas jest na maszynie 2 → zadanie na koniec + +--- + +**Makespan (Cmax)** — czas od startu do zakończenia OSTATNIEGO zadania. „Jak długo trwa cały projekt?" + +**Flow shop** — każde zadanie przechodzi przez te same maszyny w tej samej kolejności (M1 → M2 → M3). Jak linia montażowa w fabryce: każdy samochód przechodzi spawanie → malowanie → montaż. + +**Job shop** — każde zadanie ma indywidualną trasę (J1: M2→M1→M3; J2: M1→M3→M2). Bardziej elastyczny, ale problem szeregowania jest znacznie trudniejszy (NP-trudny już dla 3 maszyn!). + +**Preemption (wywłaszczanie)** — możliwość przerwania zadania w trakcie i dokończenia go później. Bez preemption (non-preemptive): raz rozpoczęte zadanie musi się skończyć. + +**Precedencje (precedence constraints)** — ograniczenia kolejności: zadanie A musi skończyć się zanim B może się zacząć. Modelowane jako DAG (Directed Acyclic Graph). + +**NP-trudny** — klasa problemów bez znanego algorytmu wielomianowego. Job shop scheduling jest NP-trudny nawet dla 3 maszyn. Pm||Cmax jest NP-trudny dla m≥2. W praktyce: heurystyki, metaheurystyki (genetic algorithms, simulated annealing), programming math. + +--- + +### Notacja Grahama: **α | β | γ** + +- **α** — środowisko maszynowe: 1 (jedna), Pm (m równoległych), F (flow shop), J (job shop) +- **β** — charakterystyki zadań: rⱼ (release dates), dⱼ (due dates), pmtn (preemption), prec (precedencje) +- **γ** — kryterium: Cmax (makespan), ΣCⱼ, Lmax, ΣTⱼ, ΣUⱼ + +### Klasyczne reguły optymalne + +| Reguła | Problem | Opis | +|----------|-------------|-------------------------------| +| **SPT** | 1 \|\| ΣCⱼ | Najkrótsze najpierw | +| **EDD** | 1 \|\| Lmax | Najwcześniejszy termin | +| **Johnson** | F2 \|\| Cmax | Optymalny dla 2-maszynowego flow shop | + +### Przykład: 1 || ΣCⱼ z regułą SPT + +Zadania: J1(5), J2(3), J3(8), J4(2), J5(6) +Posortowane SPT: J4(2), J2(3), J1(5), J5(6), J3(8) +Czasy zakończenia: 2, 5, 10, 16, 24 +**ΣCⱼ = 57** (optymalne!) + +**Dowód:** zamiana sąsiednich i,j gdzie pᵢ > pⱼ zawsze zwiększa ΣC. + +### Złożoność: Większość problemów **NP-trudna** (Job shop, Pm||Cmax dla m≥2) + +### Etymologia + +**Notacja Grahama** — Ronald Graham (Bell Labs, 1966–1979); znany też z liczby Grahama. **SPT** — Shortest Processing Time. **EDD** — Earliest Due Date. **Johnson** — Selmer Johnson (RAND, 1954). **Makespan** — „make" (ukończyć) + „span" (rozpiętość); czas od startu do końca wszystkich zadań. **Flow shop** — zadania „płyną" przez maszyny w tej samej kolejności (jak taśma). **Job shop** — każde zadanie ma indywidualną trasę. **NP-trudny** — Non-deterministic Polynomial-time hard. + +### Jak zapamiętać + +- **α|β|γ = Maszyny|Zadania|Cel** +- **SPT = „Short first"** — krótsze pierwsze dla sumy Cⱼ +- **EDD = „Early Due Date"** — najwcześniejszy termin dla Lmax + +\newpage + +## PYTANIE 18: Zarządzanie zapasami w łańcuchu dostaw + +**Problemy i przykładowy model.** + +--- + +### Tło pojęciowe — słowniczek + +**Łańcuch dostaw (supply chain)** — sieć organizacji od surowca do klienta końcowego: dostawcy → producenci → dystrybutorzy → detaliści → klienci. Zarządzanie zapasami na każdym ogniwie ma ogromny wpływ na koszty i poziom obsługi. + + Dostawca → [Magazyn] → Producent → [Magazyn] → Dystrybutor → [Magazyn] → Sklep → Klient + zapasy na każdym etapie! + +**Zapasy (inventory)** — produkty/materiały przechowywane „na wszelki wypadek" lub w oczekiwaniu na sprzedaż/produkcję. Za dużo = zamrożony kapitał, koszty magazynowania, ryzyko przeterminowania. Za mało = brak towaru (stockout), utrata klientów. + +--- + +**Bullwhip Effect (efekt byczego bicza)** — zjawisko amplifikacji wahań popytu w górę łańcucha dostaw. Mała zmiana popytu u detalisty (np. +5%) powoduje coraz większe wahania zamówień u dystrybutorów (+10%), producentów (+20%), dostawców (+40%). + + Klient: popyt +5% → Detalista zamawia +10% → Dystrybutor +20% → Producent +40% + Jak bicz: mały ruch ręki → ogromny ruch na końcu + +Przyczyny: prognozowanie (forecasting), zamawianie partiami (batching), promocje cenowe, racjonowanie przy niedoborach. + +**Stockout (brak towaru)** — sytuacja gdy produkt jest niedostępny. Koszt: utrata sprzedaży, utrata klienta, kary umowne. + +**Overstock (nadmiar zapasów)** — za dużo towaru. Koszt: magazynowanie, zamrożony kapitał, obsolescence (przeterminowanie/utrata aktualności). + +--- + +**Koszty zapasów — trzy kategorie:** + +**Koszt utrzymania (holding cost, h)** — koszt przechowywania towaru per jednostka per rok. Obejmuje: magazyn, ubezpieczenie, koszt kapitału, utrata wartości. Typowo: 15-30% wartości towaru rocznie. + +**Koszt zamawiania (ordering cost, K)** — stały koszt złożenia jednego zamówienia. Obejmuje: transport, administracja, kontrola jakości. Niezależny od ilości zamówionej. + +**Koszt braku (shortage cost, p)** — koszt gdy nie mamy towaru: utrata sprzedaży, ekspresowe dostawy, kary. + +--- + +**EOQ (Economic Order Quantity)** — model Harrisa-Wilsona (1913). Najstarszy model zarządzenia zapasami. Znajduje optymalną wielkość zamówienia Q* minimalizującą łączny koszt (zamawianie + utrzymanie). + +**Założenia EOQ:** popyt stały i znany (D szt/rok), lead time = 0, brak braków, koszt zamówienia K, koszt utrzymania h. + +**Wzór EOQ:** + + Q* = √(2KD/h) + + TC(Q) = K·D/Q + h·Q/2 + koszt koszt + zamawiania utrzymania + +**Dlaczego √?** Bo koszty zamawiania maleją z Q (mniej zamówień), a koszty utrzymania rosną z Q (więcej w magazynie). Optimum = punkt przecięcia. + +**Przykład liczbowy:** + + D = 10 000 szt/rok, K = 100 PLN/zamówienie, h = 2 PLN/szt/rok + Q* = √(2 × 100 × 10000 / 2) = √1 000 000 = 1000 szt + Liczba zamówień = 10000/1000 = 10/rok + TC* = √(2 × 100 × 10000 × 2) = 2000 PLN/rok + +--- + +**Lead time (czas realizacji, L)** — czas od złożenia zamówienia do otrzymania dostawy. Np. 5 dni. Kluczowy dla punktu zamawiania. + +**ROP (Reorder Point / punkt zamawiania)** — poziom zapasu, przy którym składamy nowe zamówienie: + + ROP = d × L + SS + d = popyt dzienny, L = lead time, SS = safety stock + +**Safety stock (zapas bezpieczeństwa, SS)** — dodatkowy bufor na wypadek wahań popytu lub opóźnień dostawy: + + SS = z × σ_L + z = kwantyl rozkładu normalnego (np. 1.65 dla 95% poziomu obsługi) + σ_L = odchylenie standardowe popytu w lead time + + Przykład: d=30 szt/dzień, L=5 dni, SS=50 szt + ROP = 30×5 + 50 = 200 szt + Gdy stan spada do 200 → zamawiaj! + +--- + +**Modele zaawansowane:** +- **(s, Q)** — gdy stan spadnie do s, zamów dokładnie Q sztuk. (s = ROP, Q = EOQ) +- **(s, S)** — gdy stan spadnie do s, zamów „do poziomu S" (order-up-to). Wielkość zamówienia zmienna. +- **(R, S)** — co R dni (stały cykl) zamów „do poziomu S". Prostsze administracyjnie. +- **VMI (Vendor Managed Inventory)** — dostawca zarządza zapasami klienta (np. Walmart + P&G). Dostawca widzi dane sprzedażowe i sam decyduje kiedy dostarczyć. + +--- + +### Problemy + +- **Bullwhip Effect** — amplifikacja wahań popytu w górę łańcucha (detaliści → dystrybutorzy → producenci → dostawcy). Przyczyny: forecasting, batching, promocje. +- Stockouts vs Overstock, obsolescence, lead time variability, demand uncertainty + +### Koszty: Utrzymania (h) + Zamawiania (K) + Braku (p) + +### Model EOQ (Economic Order Quantity) — Harris-Wilson + +**Założenia:** popyt stały D, lead time = 0, koszt zamówienia K, koszt utrzymania h. + + TC(Q) = K·D/Q + h·Q/2 + + Optymalna wielkość: Q* = √(2KD/h) + Opt. koszt: TC* = √(2KDh) + +**Przykład:** D=10000, K=100, h=2 → Q*=1000, TC*=2000 PLN/rok + +### Punkt zamawiania (ROP) + + ROP = d × L + SS (popyt dzienny × lead time + safety stock) + SS = z × σ_L (z z tablic normalnych, np. 1.65 dla 95%) + +### Modele zaawansowane: (s,Q), (s,S), (R,S), VMI (Vendor Managed Inventory) + +### Etymologia + +**EOQ** — Economic Order Quantity; Ford W. Harris (1913, „How Many Parts To Make At Once") — jedno z najstarszych zastosowań badań operacyjnych. **Bullwhip Effect** — Procter & Gamble (1990s) nadali nazwę; Jay Forrester (MIT, 1961) pierwszy opisał jako „demand amplification"; „bullwhip" = bicz pasterski. **ROP** — Reorder Point. **VMI** — Vendor Managed Inventory (Walmart + P&G, lata 80.). **Safety stock** — zapas bezpieczeństwa na wypadek wahań popytu/dostaw. + +### Jak zapamiętać + +- **EOQ = √(2KD/h)** — zapamiętaj formułę! +- **ROP = d×L + SS** — kiedy zamawiać +- **Bullwhip = bicz** — małe wahania na końcu → duże na początku łańcucha + +\newpage + +## PYTANIE 19/29: Model Publish-Subscribe + +**Scharakteryzować model i przykładowe rozwiązania techniczne.** + +--- + +### Tło pojęciowe — słowniczek + +**Pub/Sub (Publish-Subscribe)** — wzorzec komunikacji: nadawcy (publishers) wysyłają wiadomości, NIE wiedząc kto je odbierze. Odbiorcy (subscribers) deklarują zainteresowanie i otrzymują dopasowane wiadomości. Między nimi stoi **broker** (pośrednik). Metafora: radio — nadawca nadaje, kto chce słucha. + + Publisher A ──→ ┌─────────┐ ──→ Subscriber X + Publisher B ──→ │ BROKER │ ──→ Subscriber Y + Publisher C ──→ └─────────┘ ──→ Subscriber Z + +**Dlaczego nie bezpośrednio?** Bo publisher musiałby znać wszystkich subscriberów, zarządzać połączeniami, retransmitować. Broker rozwiązuje to centralnie. + +--- + +**Publisher (nadawca)** — komponent wysyłający wiadomości (eventy/zdarzenia) do brokera. Nie wie, kto subskrybuje. Przykład: czujnik temperatury publikuje odczyt co 5 sekund. + +**Subscriber (odbiorca)** — komponent rejestrujący się u brokera na określone tematy/typy wiadomości. Otrzymuje wiadomości pasujące do subskrypcji. Przykład: alarm subskrybuje temat „temperatura" i reaguje gdy >50°C. + +**Broker (pośrednik)** — centralny komponent routujący wiadomości od publishers do subscribers. Odpowiada za: filtrowanie, dostarczanie, buforowanie, gwarancje dostarczenia. + +**Luźne powiązanie (loose coupling)** — publisher i subscriber nie znają się nawzajem. Można dodać nowego subscribera bez zmiany publishera. Fundamentalna zaleta pub/sub. + +--- + +**Typy subskrypcji:** +- **Topic-based** — subscriber subskrybuje temat (np. „orders.created"). Najprostszy i najpopularniejszy. +- **Content-based** — filtrowanie po treści wiadomości (np. „price > 100"). Bardziej elastyczny, ale wolniejszy. +- **Type-based** — filtrowanie po typie wiadomości (np. klasa OrderEvent). +- **Hierarchical (wildcards)** — wzorce tematów: `orders.*` dopasowuje `orders.created`, `orders.cancelled`. + + Topic: "sensors/temperature/room1" + Wildcard: "sensors/temperature/#" → dopasowuje room1, room2, ... + +--- + +**QoS (Quality of Service)** — gwarancje dostarczenia wiadomości: +- **At-most-once** — wiadomość dostarczana 0 lub 1 raz. „Fire and forget." Najszybszy, ryzyko utraty. Użycie: logi, metryki. +- **At-least-once** — wiadomość dostarczana ≥1 raz. Mogą być duplikaty. Użycie: płatności (z idempotencją). +- **Exactly-once** — wiadomość dostarczana dokładnie 1 raz. Najtrudniejszy do zaimplementowania. Użycie: transakcje finansowe. + + At-most-once: send → ✓ lub ✗ (nie retransmituj) + At-least-once: send → ack? retry → może duplikat + Exactly-once: send → ack + deduplikacja (najkosztowniejszy) + +--- + +**Kafka (Apache Kafka)** — rozproszony log. Model pull: konsument sam ciągnie wiadomości ze logu. Wiadomości **przechowywane** na dysku (retention 7 dni default). Partycje + Consumer Groups = równoległy odczyt. Bardzo wysoka przepustowość (miliony msg/s). LinkedIn (2011). Exactly-once z transakcjami. + + Kafka = rozproszony, trwały LOG + Topic: [msg1][msg2][msg3][msg4][msg5] ← append-only + Consumer czyta od dowolnego offsetu (może cofnąć!) + +**RabbitMQ** — klasyczna kolejka wiadomości (message queue). Model push: broker dostarcza do konsumenta. Protokół AMQP. Exchange types: Direct (klucz), Topic (*, #), Fanout (broadcast), Headers. Elastyczny routing. Wiadomości konsumowane → usunięte z kolejki. + + RabbitMQ: Publisher → Exchange → Queue → Consumer + Wiadomość skonsumowana = znika z kolejki + +**MQTT (Message Queuing Telemetry Transport)** — ultralekkiprotokół pub/sub. 2-bajtowy nagłówek! Zaprojektowany dla IoT i urządzeń z ograniczonymi zasobami (sensory, mikrokontrolery). IBM (1999) do monitoringu rurociągów naftowych przez satelitę. Brokers: Mosquitto, HiveMQ. + +**Redis Pub/Sub** — pub/sub wbudowany w Redis (in-memory database). Szybki, ale BEZ persistencji — jeśli subscriber był offline, wiadomość przepada. Dla real-time (chat, live updates). + + Cecha Kafka RabbitMQ MQTT Redis + ──────────────────────────────────────────────────────────────── + Model Pull (log) Push (queue) Push Push + Persistencja Tak Opcjonalna Retained msg Nie + Throughput Bardzo wysoki Wysoki Niski-średni Wysoki + Use case Streaming Task queues IoT Real-time + +--- + +**SPOF (Single Point of Failure)** — broker jako centralny punkt: jeśli padnie, cała komunikacja się zatrzymuje. Rozwiązanie: klasteryzacja brokera (Kafka cluster, RabbitMQ cluster). + +**AMQP (Advanced Message Queuing Protocol)** — otwarty protokół messaging. Standard implementowany przez RabbitMQ. Definiuje: exchange, queue, binding, ack. + +--- + +### Model Pub/Sub + +Publishers → **Broker** (router/message bus) → Subscribers +- Luźne powiązanie (publisher nie zna subscriberów) +- Asynchroniczne, skalowalne (1:N, N:M) + +### Typy subskrypcji: topic-based, content-based, type-based, hierarchical (wildcards) + +### Gwarancje dostarczenia (QoS): At-most-once, At-least-once, Exactly-once + +### Rozwiązania techniczne + +| Technologia | Model | Persistence | Throughput | Use Case | +|--------------|----------------|-------------|---------------|---------------| +| **Kafka** | Pull (log) | Tak | Bardzo wysoki | Event streaming| +| **RabbitMQ** | Push (queue) | Opcjonalne | Wysoki | Task queues | +| **MQTT** | Push | Retained | Niski-średni | IoT | +| **Redis** | Push | Nie | Wysoki | Real-time | + +**Kafka:** Partycje + Consumer Groups, distributed log, exactly-once z transakcjami. +**RabbitMQ:** AMQP, Exchange types (Direct, Topic, Fanout, Headers), flexible routing. +**MQTT:** Lekki (2-byte header), idealny dla IoT/constrained devices, brokers: Mosquitto, HiveMQ. + +### Zalety / Wady + +Zalety: decoupling, skalowalność, asynchroniczność, broadcast. +Wady: debugging trudniejsze, ordering challenges, broker = SPOF. + +### Etymologia + +**Kafka** — od Franza Kafki (pisarz); Jay Kreps (LinkedIn, 2011): „system zoptymalizowany do pisania — a Kafka był pisarzem". **RabbitMQ** — „rabbit" = szybkość; AMQP = Advanced Message Queuing Protocol. **MQTT** — Message Queuing Telemetry Transport; Andy Stanford-Clark (IBM) + Arlen Nipper (1999); do monitoringu rurociągów naftowych przez satelitę. **Redis** — REmote DIctionary Server (Salvatore Sanfilippo, 2009). **Pub/Sub** — publish-subscribe; wzorzec z systemów event-driven (lata 80/90). **QoS** — Quality of Service. + +### Jak zapamiętać + +- **„Pub/Sub = Radio"** — nadawca nadaje, kto chce słucha +- **Kafka = Log** (przechowuje historię), **RabbitMQ = Queue** (konsumuje i kasuje) +- **MQTT = IoT** — lekki, mały overhead + +\newpage + +## PYTANIE 20/30: Analityka danych strumieniowych + +**Rozwiązania analityczne na danych strumieniowych.** + +--- + +### Tło pojęciowe — słowniczek + +**Dane strumieniowe (streaming data)** — ciągły, potencjalnie nieskończony przepływ zdarzeń (events) przychodzących w czasie rzeczywistym. Przykłady: kliknięcia użytkowników, odczyty sensorów IoT, transakcje bankowe, logi serwerów. W odróżnieniu od danych wsadowych (batch): nie możesz „poczekać na wszystkie" — musisz analizować na bieżąco. + + Batch: [cały zbiór] → analiza → wynik (minuty/godziny) + Streaming: event → event → event → ...→ analiza ciągła (ms/sekundy) + +**Strumień (stream)** — abstrakcja: nieograniczona (unbounded) sekwencja zdarzeń, każde ze stemplem czasowym. Musisz przetwarzać „w locie" — nie mieścisz wszystkiego w pamięci. + +--- + +**Event Time vs Processing Time:** +- **Event Time** — moment GDY zdarzenie nastąpiło (np. kliknięcie o 14:00:05) +- **Processing Time** — moment GDY system przetwarza zdarzenie (np. o 14:00:07) +- Różnica wynika z opóźnień sieciowych. Zdarzenia mogą przychodzić **out-of-order** (pozamiejscowe). + + Zdarzenie A (event time 14:00:01) → dociera o 14:00:05 + Zdarzenie B (event time 14:00:03) → dociera o 14:00:04 + B dociera PRZED A, mimo że A było wcześniej! + +**Watermark** — znacznik postępu: „z dużym prawdopodobieństwem nie przyjdą już zdarzenia z event time < W". Pozwala systemowi zdecydować, kiedy zamknąć okno i wyemitować wynik. Zdarzenia po watermarku = „late data" (spóźnione). + +--- + +**Okno czasowe (window)** — mechanizm grupowania zdarzeń w strumienia w skończone porcje do analizy: + +**Tumbling window (okno przerzutne)** — stały rozmiar, rozłączne. Np. „liczba kliknięć co 5 minut". + + |---5min---|---5min---|---5min---| + [events A] [events B] [events C] ← 0 nakładania + +**Sliding window (okno przesuwne)** — stały rozmiar + krok przesunięcia. Nakładają się. Np. „średnia z 10 min, co 1 min". + + |----10min----| + |----10min----| + |----10min----| ← nakładanie + +**Session window (okno sesji)** — dynamiczny rozmiar, oparte na aktywności. Nowa sesja po przerwie (gap). Np. „sesja użytkownika: od pierwszego kliknięcia do 30 min nieaktywności". + +**Global window** — jedno okno na cały strumień. Trigger decyduje kiedy wyemitować wynik. + +--- + +**True streaming vs Micro-batch:** +- **True streaming** — przetwarzanie event-by-event. Niższa latencja. Kafka Streams, Flink. +- **Micro-batch** — grupowanie zdarzeń w małe paczki (np. co 100ms) i przetwarzanie batch. Spark Streaming. Prostsza semantyka, ale wyższa latencja. + +**Kafka Streams** — biblioteka (nie klaster!) do przetwarzania strumieni Kafka. Działa w procesie aplikacji Java. Niska latencja, exactly-once. Stateful processing (windows, joins). + +**Apache Flink** — rozproszony silnik do true streaming. Bardzo niska latencja (<10ms). Natywne wsparcie event time, windows, stateful processing. Exactly-once. Deployment jako klaster. + +**Spark Streaming** — rozszerzenie Apache Spark. Model micro-batch (~100ms+). Średnia latencja, ale korzysta z ekosystemu Spark (SQL, ML). Exactly-once. + +--- + +**Algorytmy strumieniowe (probabilistyczne):** + +**HyperLogLog** — estymacja liczby unikalnych elementów (cardinality). Zużywa O(1) pamięci (~1.5 KB) niezależnie od liczby elementów. Błąd ~2%. + + 100 mln unikalnych URL-i → HyperLogLog odpowiada "~100 mln ± 2%" + Pamięć: 1.5 KB zamiast ~800 MB (hash set) + +**Count-Min Sketch** — estymacja częstości elementów. Macierz d×w z hashami. Gwarantuje overestimates (nigdy nie zaniży). O(1) per query/update. + + "Ile razy pojawił się IP 192.168.1.1?" → CMS: ~4523 (± ε·N) + +**Reservoir Sampling** — równomierne próbkowanie k elementów ze strumienia o nieznanym rozmiarze n. Każdy element ma szansę k/n. O(k) pamięci. + +**Late data strategies:** +- **Drop** — odrzuć spóźnione zdarzenia +- **Recompute** — przelicz okno ponownie +- **Side output** — przekieruj do osobnego strumienia do ręcznej analizy +- **Allowed lateness** — czekaj dodatkowy czas przed zamknięciem okna + +--- + +### Charakterystyka strumieni +- Nieograniczone (unbounded), ciągłe, niska latencja wymagana +- Event Time vs Processing Time — mogą się różnić, out-of-order + +### Okna czasowe (Windowing) + +1. **Tumbling** — rozłączne, stały rozmiar +2. **Sliding** — nakładające się (size + slide) +3. **Session** — oparte na aktywności (gap between events) +4. **Global** — jedno okno, trigger decyduje emisję + +### Platformy + +| Cecha | Kafka Streams | Flink | Spark Streaming | +|----------------|--------------------|------------------|------------------| +| Model | True streaming | True streaming | Micro-batch | +| Deployment | Library | Cluster | Cluster | +| Latency | Niska | Bardzo niska | Średnia (~100ms) | +| Exactly-once | Tak | Tak | Tak | + +### Algorytmy strumieniowe + +- **HyperLogLog** — zliczanie unikalnych, O(1) space, ~2% error +- **Count-Min Sketch** — estymacja częstości, overestimates +- **Reservoir Sampling** — równomierne próbkowanie k z n nieznanego + +### Obsługa opóźnień: Watermarks + late data strategies (drop, recompute, side output, allowed lateness) + +### Etymologia + +**Flink** — niem. „flink" = zwinny/szybki (TU Berlin, 2014). **Spark** — „iskra"; Matei Zaharia (UC Berkeley, 2012). **HyperLogLog** — Philippe Flajolet et al. (2007); „Hyper" = ulepszenie LogLog; „LogLog" = zużywa log(log(n)) pamięci. **Count-Min Sketch** — Cormode & Muthukrishnan (2005); „sketch" = probabilistyczny skrót danych. **Reservoir Sampling** — Jeffrey Vitter (1985); „reservoir" = stały zbiornik prób. **Watermark** — znacznik postępu czasu zdarzeń w strumieniu. + +### Jak zapamiętać + +- **4 okna: „TSSG"** — Tumbling, Sliding, Session, Global +- **Flink = szybki (true streaming)**, Spark = safe (micro-batch) +- **HyperLogLog = „ile unikalnych?" z kilobajtem pamięci** + +\newpage + +## PYTANIE 21: Zegary logiczne i wektory stempli czasowych + +**Koncepcja i przeznaczenie.** + +--- + +### Tło pojęciowe — słowniczek + +**System rozproszony (distributed system)** — system, w którym wiele komputerów (węzłów) współpracuje przez sieć, ale nie współdzielą pamięci ani zegara. Przykłady: Cassandra, Dynamo, blockchain. Fundamentalny problem: jak ustalić kolejność zdarzeń, skoro nie ma wspólnego zegara? + +**Brak globalnego zegara** — w systemie rozproszonym każdy węzeł ma własny zegar fizyczny. Zegary driftują (różnią się o milisekundy–sekundy). Nie można polegać na zegarze fizycznym do określenia „co było wcześniej". Dlatego potrzebne są zegary logiczne. + + Węzeł A: zegar 14:00:01.000 + Węzeł B: zegar 14:00:01.003 ← 3ms driftu! + Czy zdarzenie A(14:00:01.002) było przed B(14:00:01.001)? + Nie wiadomo — zegary fizyczne nie są zsynchronizowane! + +--- + +**Zdarzenie (event)** — atomowa akcja w systemie: wykonanie instrukcji, wysłanie wiadomości, odebranie wiadomości. Zegary logiczne przypisują każdemu zdarzeniu „stempel czasowy" bez polegania na zegarze fizycznym. + +**Relacja happened-before (→)** — porządek częściowy zdarzeń (Lamport, 1978): +1. Jeśli a i b są w tym samym procesie i a jest przed b → a → b +2. Jeśli a = wysłanie msg i b = odbiór tej msg → a → b +3. Przechodniość: a → b i b → c ⟹ a → c + +**Zdarzenia współbieżne (a || b)** — dwa zdarzenia są współbieżne gdy ani a→b, ani b→a. Nie ma związku przyczynowego między nimi. Mogły zdarzyć się w dowolnej kolejności. + +--- + +**Zegar Lamporta (Lamport clock)** — najprostszy zegar logiczny. Każdy proces ma jeden licznik (skalar). Algorytm: +1. Przed własnym zdarzeniem: C_i++ +2. Przy wysyłaniu: dołącz timestamp C_i +3. Przy odbieraniu (timestamp t): C_i = max(C_i, t) + 1 + +Właściwość: a → b ⟹ C(a) < C(b) (TAK). Ale: C(a) < C(b) **NIE** implikuje a → b! Nie wykrywa współbieżności. + + P1: [A:1]──msg──→[C:2] P1 events: A(1), C(2) + P2: [B:1]──────[D:3] P2 events: B(1), D(3) + C(A)=1, C(B)=1 → Lamport nie wie czy A||B czy A→B! + +--- + +**Zegar wektorowy (vector clock)** — każdy z N procesów utrzymuje wektor V[1..N]. V_i[j] = „ile zdarzeń procesu j jest mi znanych". Algorytm: +1. Przed własnym zdarzeniem: V_i[i]++ +2. Przy wysyłaniu: dołącz cały wektor V_i +3. Przy odbieraniu (wektor T): V_i[j] = max(V_i[j], T[j]) ∀j, potem V_i[i]++ + +Właściwość: a → b **⟺** V(a) < V(b). Pełna charakteryzacja! Wykrywa współbieżność. + + V(a) < V(b) ⟺ ∀i: V(a)[i] ≤ V(b)[i] i ∃j: V(a)[j] < V(b)[j] + V(a) || V(b) ⟺ ¬(V(a) ≤ V(b)) ∧ ¬(V(b) ≤ V(a)) + + Przykład (2 procesy): + P1: A=[1,0] → wysyła msg → C=[2,1] + P2: B=[0,1] → odbiera msg → D=[2,2] + A||B? V(A)=[1,0], V(B)=[0,1] → 1>0 ale 0<1 → TAK, współbieżne! + +--- + +**Porównanie Lamport vs Vector:** + + Cecha Lamport Vector + ─────────────────────────────────────────────── + Rozmiar per zdarzenie O(1) (skalar) O(N) (wektor) + a→b ⟹ C(a) N → gwarantuje odczyt najnowszej wartości + Np. N=3, W=2, R=2: zawsze przynajmniej 1 wspólna replika + +**CRDTs (Conflict-free Replicated Data Types)** — struktury danych, które automatycznie zbiegają do spójnego stanu bez koordynacji. Matematycznie gwarantują brak konfliktów. Przykłady: G-Counter (grow-only counter), OR-Set (observed-remove set). Idealne dla eventual consistency. + +**LWW (Last-Writer-Wins)** — prosty mechanizm rozwiązywania konfliktów: wygrywa zapis z najnowszym timestampem. Problem: wymaga zsynchronizowanych zegarów i może tracić dane. + +--- + +### Spektrum (od silnego do słabego) + + Linearizability → Sequential → Causal → Session → Eventual + +### Silne modele + +**Linearizability:** Każda operacja wygląda atomowo w momencie między wywołaniem a odpowiedzią. Najsilniejsza. „Globalny czas rzeczywisty." Kosztowna (consensus). Przykład: Spanner. + +**Sequential Consistency:** Globalny porządek operacji zgodny z porządkiem programu każdego procesu, ale NIE z czasem rzeczywistym. Przykład: Zookeeper. + +### Słabe modele + +**Causal Consistency:** Operacje przyczynowo zależne widziane w tej samej kolejności. Niezależne mogą być w różnej. Wymaga vector clocks. Przykład: MongoDB. + +**Session Guarantees:** Read Your Writes, Monotonic Reads, Monotonic Writes, Writes Follow Reads. + +**Eventual Consistency:** Jeśli brak nowych zapisów, ostatecznie wszystkie odczyty zwrócą tę samą wartość. Najsłabszy, najszybszy. Przykład: DNS, Cassandra. + +### CAP Theorem: Consistency + Availability + Partition tolerance — wybierz 2 (w obecności partycji: C lub A). + +### Rozwiązywanie konfliktów: LWW (Last-Writer-Wins), Siblings (multi-value), **CRDTs** (automatycznie zbieżne struktury). + +### Etymologia + +**Linearizability** — Maurice Herlihy + Jeannette Wing (1990); łac. „linearis" = w linii. **Sequential consistency** — Leslie Lamport (1979). **Causal consistency** — Ahamad et al. (1995); łac. „causa" = przyczyna. **CAP** — Eric Brewer (UC Berkeley, 2000, „Brewer's conjecture"); udowniony przez Gilbert & Lynch (2002). **CRDTs** — Conflict-free Replicated Data Types (Marc Shapiro et al., 2011). **Quorum** — łac. „of whom" = minimalna liczba głosów (z prawa rzymskiego). + +### Jak zapamiętać + +- **Linearizable = „natychmiast, atomowo, jak 1 kopia"** +- **Eventual = „kiedyś się zsynchronizuje" (ale kiedy?)** +- **CAP = „Partition → wybierz C albo A"** +- **Quorum: W+R > N** gwarantuje odczyt najnowszej wartości + +\newpage + +## PYTANIE 23: Segmentacja obrazu + +**Problem, strategie klasyczne i sieci neuronowe.** + +--- + +### Tło pojęciowe — słowniczek + +**Obraz cyfrowy (digital image)** — macierz pikseli. Obraz 1920×1080 = ~2 mln pikseli. Każdy piksel ma wartość (grayscale: 0-255) lub kanały RGB (3 × 0-255). Segmentacja operuje na tej macierzy. + +**Piksel (pixel)** — najmniejsza jednostka obrazu. „Picture element." Segmentacja = przypisanie etykiety KAŻDEMU pikselowi. + +**Segmentacja obrazu (image segmentation)** — podział obrazu na regiony, gdzie każdy piksel dostaje etykietę klasy (np. „samochód", „droga", „niebo"). Różni się od klasyfikacji (cały obraz → 1 etykieta) i detekcji (bounding box + etykieta). + +--- + +**Typy segmentacji:** + +**Semantic segmentation** — każdy piksel → klasa, ale NIE rozróżnia instancji. Wszystkie samochody = jedna klasa „samochód". + + [samochód][samochód][droga][droga][pieszo][niebo] + Dwa samochody = ta sama etykieta "samochód" + +**Instance segmentation** — rozróżnia instancje tego samego obiektu. Samochód#1 i Samochód#2 mają różne etykiety. + +**Panoptic segmentation** — łączy semantic + instance. Obiekty „things" (samochody, ludzie) mają instancje; „stuff" (niebo, droga) — tylko klasy. + +--- + +**Thresholding (progowanie)** — najprostsza metoda: piksel > próg → klasa 1, inaczej → klasa 0. Otsu: automatyczny dobór progu minimalizujący wariancję wewnątrzklasową. Działa tylko dla 2 klas i prostych scen. + + Obraz: [50][200][180][30][220][190] + Próg=128: [ 0 ][ 1 ][ 1 ][ 0][ 1 ][ 1 ] + +**Region Growing (rozrastanie regionu)** — zacznij od punktu „ziarna" (seed), dodawaj sąsiednie piksele o podobnej wartości. Wrażliwa na wybór ziarna; tendencja do over-segmentation. + +**Watershed (metoda zlewiska)** — traktuje obraz jak mapę topograficzną (jasność = wysokość). „Zalewaj" od minimów; granice regionów to „granie". Over-segmentation → wymaga markers (pre-processing). + +**Mean Shift** — iteracyjne przesuwanie jądra do maksimum gęstości w przestrzeni cech. Grupuje piksele zbiegające do tego samego maksimum. Wolny, O(n²). + +**Normalized Cuts** — modeluje obraz jako graf (piksele = węzły, podobieństwo = wagi krawędzi). Minimalizuje cut (rozdzielenie) znormalizowany do wielkości regionów. O(n³) — kosztowny. + +--- + +**Sieć neuronowa (neural network)** — model uczenia maszynowego złożony z warstw neuronów. W segmentacji: sieci konwolucyjne (CNN) uczą się rozpoznawać cechy obrazu automatycznie. + +**CNN (Convolutional Neural Network)** — sieć ze splotowymi warstwami (convolution): filtr przesuwany po obrazie wyodrębnia cechy (krawędzie, tekstury, kształty). Hierarchia: niskie warstwy → krawędzie, wysokie → obiekty. + +**Encoder-Decoder** — architektura: encoder zmniejsza rozdzielczość (downsampling), wyodrębnia cechy. Decoder zwiększa rozdzielczość (upsampling), odtwarzając przestrzenną mapę segmentacji. Typowa struktura dla sieci segmentacyjnych. + + Encoder: [224×224] → [112] → [56] → [28] → [14] (cechy) + Decoder: [14] → [28] → [56] → [112] → [224×224] (mapa segm.) + +**Skip connections** — połączenia „na skróty" łączące warstwy encodera z decodera. Przenoszą drobne detale przestrzenne, które encoder utracił. Kluczowe w U-Net i FCN. + +**FCN (Fully Convolutional Network, 2015)** — pierwsza sieć w pełni konwolucyjna do segmentacji. Zastępuje warstwy fully-connected konwolucjami → wejście dowolnego rozmiaru. Decoder: upsampling + skip connections. + +**U-Net (2015)** — encoder-decoder w kształcie „U" ze skip connections (concatenation). Świetna przy małych zbiorach danych (data augmentation). Dominuje w segmentacji medycznej. + + Encoder ──skip──→ Decoder + ↓ ──skip──→ ↑ + ↓ ──skip──→ ↑ + bottleneck + +**DeepLab v3+** — Google. Kluczowe: **atrous (dilated) convolutions** — konwolucje z „dziurami" (fr. à trous = z dziurami). Większe receptive field bez dodatkowych parametrów. **ASPP (Atrous Spatial Pyramid Pooling)** — wieloskalowe cechy równolegle. + + Zwykła konwolucja 3×3: [x][x][x] + Dilated (rate=2): [x][ ][x][ ][x] ← większy zasięg + +**Transformer-based (SegFormer, Mask2Former)** — najnowsze podejście. Transformery (self-attention) zastępują CNN. Self-attention widzi globalne zależności (CNN widzi tylko lokalne). SOTA na benchmarkach. + +--- + +**mIoU (mean Intersection over Union)** — standardowa metryka segmentacji. Dla każdej klasy: IoU = (piksele poprawne ∩ ground truth) / (piksele poprawne ∪ ground truth). Potem średnia z klas. + + Klasa "samochód": predykcja=100 pikseli, GT=120, wspólne=80 + IoU = 80 / (100+120-80) = 80/140 = 0.571 = 57.1% + +**Dice Loss** — funkcja kosztu powiązana z IoU: 2·|A∩B| / (|A|+|B|). Popularna w segmentacji medycznej (dobrze radzi sobie z class imbalance). + +**Focal Loss** — modyfikacja cross-entropy redukująca wpływ łatwych przykładów, skupiająca uczenie na trudnych. Kluczowa przy class imbalance (np. 99% tła, 1% obiekt). + +**Receptive field** — ile wejścia „widzi" jeden neuron. Większe receptive field = kontekst globalny. Atrous convolutions zwiększają receptive field bez zwiększania parametrów. + +--- + +### Definicja: Przypisać każdemu pikselowi etykietę klasy/regionu. + +Typy: **Semantic** (klasa per piksel), **Instance** (rozróżnia instancje), **Panoptic** (unified) + +### Metody klasyczne + +| Metoda | Idea | Wada | +|-----------------|-------------------------------------------|-----------------------| +| Thresholding | Próg intensywności (Otsu = automat.) | Tylko 2 klasy | +| Region Growing | Rozszerzaj od seeda wg podobieństwa | Over-segmentation | +| Watershed | „Zalewanie" topografii obrazu | Over-segmentation | +| Mean Shift | Przesuń do max gęstości, grupuj zbieżne | Wolny | +| Normalized Cuts | Graf: min-cut z normalizacją | O(n³) | + +### Metody deep learning + +**FCN (2015):** Pierwsza sieć fully-convolutional; encoder → upsampling; skip connections. +**U-Net (2015):** Encoder-decoder w kształcie U; skip connections (concat); popularne w medycynie. +**DeepLab v3+ :** Atrous/dilated convolutions (większe receptive field bez parametrów); ASPP (multi-scale). +**SegFormer, Mask2Former:** Transformer-based; SOTA. + +### Metryki: **mIoU** (mean Intersection over Union) — standard; Dice, Pixel Accuracy. +### Loss: Cross-Entropy, Dice Loss, Focal Loss (class imbalance). + +### Etymologia + +**Segmentacja** — łac. „segmentum" = odcięty kawałek; podział obrazu na regiony. **Otsu** — Nobuyuki Otsu (1979); automatyczny dobór progu. **Watershed** — metafora: woda spływająca z grani do dolin (z geografii). **U-Net** — Ronneberger et al. (Freiburg, 2015); „U" od kształtu architektury. **FCN** — Fully Convolutional Network (Long, Shelhamer, Darrell, 2015). **DeepLab** — Google (2015–2018); „Atrous" z fr. „à trous" = „z dziurami" (dilated convolutions). **mIoU** — mean Intersection over Union. + +### Jak zapamiętać + +- **U-Net = „U-shape + skip connections"** — encoder-decoder +- **DeepLab = „Atrous (dilated) convolutions + ASPP"** +- **mIoU = Intersection / Union, uśrednione per klasa** + +\newpage + +## PYTANIE 24: Detekcja obiektów + +**Problem, metody klasyczne, deep learning. Jak zbudować detektor z klasyfikatora?** + +--- + +### Tło pojęciowe — słowniczek + +**Detekcja obiektów (object detection)** — zadanie widzenia komputerowego: zlokalizuj obiekty na obrazie (bounding box) i przypisz im klasy (samochód, pieszo, kot...). Wynik: lista (klasa, prostokąt, pewność). Trudniejsze niż klasyfikacja (→ cały obraz, 1 label), ale łatwiejsze niż segmentacja (→ per piksel). + + Klasyfikacja: "To zdjęcie zawiera kota" + Detekcja: "Kot w prostokącie (50,30)-(200,180), pewność 95%" + Segmentacja: Maska pikseli kota + +**Bounding box (prostokąt ograniczający, bbox)** — prostokąt opisujący położenie obiektu. Zwykle: (x_min, y_min, x_max, y_max) lub (x_center, y_center, width, height). Przybliżenie — obiekty rzadko są prostokątne. + +**Confidence (pewność)** — wynik 0-1 mówiący jak pewny jest detektor, że wykrył obiekt danej klasy. Zwykle próg np. 0.5: detiekcje poniżej odrzucane. + +--- + +**Klasyfikator (classifier)** — model przypisujący etykietę do wejścia. Np. CNN trenowany na ImageNet: obraz → „kot" (+ prawdopodobieństwo). SAM nie lokalizuje — mówi tylko co jest na obrazie. Pytanie brzmi: jak z takiego modelu zbudować detektor? + +**Sliding window (okno przesuwane)** — najprostsza metoda budowy detektora z klasyfikatora: wytnij prostokątny fragment obrazu (wiele rozmiarów, wiele pozycji), każdy fragment sklasyfikuj. Jeśli „pozytywny" → detekcja. Ekstremalnie wolne: tysiące fragmentów × klasyfikacja per fragment. + + [okno 64×64] przesuwa się po obrazie 640×480: + (640-64)×(480-64) ≈ ~240 000 pozycji × wiele skal = MILIONY klasyfikacji! + +--- + +**HOG (Histogram of Oriented Gradients)** — klasyczny deskryptor cech: oblicza histogramy kierunków gradientów (krawędzi) w komórkach obrazu. Dobrze opisuje kształt obiektów (sylwetki ludzi). Dalal & Triggs (2005, detekcja pieszych). + +**SVM (Support Vector Machine)** — klasyczny klasyfikator: znajduje hiperpłaszczyznę maksymalnie separującą klasy. HOG+SVM = klasyczny pipeline detekcji pieszych. + +**Viola-Jones (2001)** — przełomowy detektor twarzy real-time. Kluczowe innowacje: +- **Haar features** — proste cechy prostokątne (jasne/ciemne regiony) +- **Integral Image** — obliczenie dowolnej sumy prostokąta w O(1)! +- **AdaBoost cascade** — kaskada klasyfikatorów: szybkie odrzucenie 99% okien w pierwszych etapach, szczegółowa analiza tylko obiecujących + +--- + +**R-CNN family (two-stage detectors)** — dwuetapowe: najpierw generuj propozycje regionów, potem klasyfikuj każdy region. + +**R-CNN (2014)** — Selective Search → ~2000 regionów → CNN per region → SVM. 50 sekund/obraz! Wolne, bo CNN odpalane 2000 razy. + +**Fast R-CNN** — CNN raz na całym obrazie, ROI Pooling wycinająca cechy regionów. ~2 sekundy/obraz. + +**Faster R-CNN** — zastępuje Selective Search siecią RPN (Region Proposal Network). RPN generuje propozycje w sieci, nie oddzielnym algorytmem. ~5 fps. Najpopularniejszy two-stage detektor. + + Faster R-CNN: + Obraz → CNN backbone → Feature Map → RPN (proposals) → ROI Pool → Classification + BBox regression + +--- + +**One-stage detectors** — klasyfikacja i lokalizacja w jednym przejściu (bez osobnego etapu propozycji). Szybsze, ale historycznie mniej precyzyjne. + +**YOLO (You Only Look Once, 2016)** — dzieli obraz na siatkę S×S. Każda komórka predykuje B bounding boxów + C klas. Jedno przejście przez sieć → wynik. 45-155 fps! Rewolucja w real-time detection. + + Obraz [416×416] → siatka 13×13 → każda komórka: 5 bbox + 80 klas + Jedno forward pass → wszystkie detekcje na raz + +**SSD (Single Shot MultiBox Detector, 2016)** — multi-scale feature maps + anchor boxes. Łączy szybkość YOLO z multi-scale (lepszy na małych obiektach). + +**Anchor box** — predefiniowany prostokąt o określonym kształcie/proporcji. Sieć przewiduje przesunięcie (offset) od anchora. Wiele anchorów → pokrycie różnych kształtów obiektów. + +**Anchor-free** — nowoczesne podejście (FCOS, YOLOv8): bezpośrednia predykcja środka i wymiarów, bez predefiniowanych anchorów. Prostsza architektura. + +--- + +**NMS (Non-Maximum Suppression)** — post-processing: detektor generuje wiele nakładających się bbox dla tego samego obiektu. NMS: weź najlepszą (max confidence), usuń wszystkie mocno nakładające się (IoU > prog), powtórz. + + Detections: [bbox1, 0.95], [bbox2, 0.90], [bbox3, 0.85] (nakładające się) + NMS: zachowaj bbox1 (0.95), usuń bbox2 i bbox3 (IoU > 0.5 z bbox1) + +**IoU (Intersection over Union)** — miara nakładania dwóch bbox: pole przecięcia / pole sumy. IoU=1 → identyczne; IoU=0 → brak nakładania. Próg NMS typowo 0.5. + +**Backbone** — sieć bazowa (np. ResNet, VGG) wyciągająca cechy z obrazu. Detection head (głowa detekcyjna) jest dodawana „na wierzch" backbone i predykuje bbox + klasy. Fine-tuning backbone na detekcję = transfer learning. + +--- + +**Jak zbudować detektor z klasyfikatora? Trzy podejścia:** +1. **Sliding window** — wytnij, sklasyfikuj, NMS. Bardzo wolne. +2. **Region proposals + klasyfikator** — Selective Search generuje ~2000 regionów, sklasyfikuj każdy + NMS. Szybsze. +3. **Fine-tune backbone** — weź pretrained classifier (np. ResNet z ImageNet), dodaj detection head (bbox regression + cls), dotrenuj na danych detekcyjnych. **Najlepsza jakość.** + +**DETR (DEtection TRansformer, 2020)** — Facebook AI. Transformer zamiast CNN, bezpośrednia predykcja zestawu obiektów (set prediction), bez NMS. Uproszczona architektura. + +--- + +### Definicja: Lokalizacja (bounding box) + klasyfikacja obiektów. Wynik: (class, bbox, confidence). + +### Metody klasyczne + +**Sliding Window + HOG/SVM:** Przesuwaj okno, wyekstrahuj cechy HOG, klasyfikuj SVM. Wolne! +**Viola-Jones (2001):** Haar features + Integral Image + AdaBoost cascade. Face detection real-time. + +### Deep Learning + +**Two-stage (R-CNN family):** +- R-CNN: Selective Search → 2000 regionów → CNN per region → SVM. 50 sec/image. +- Fast R-CNN: CNN raz, ROI Pooling. ~2 sec. +- **Faster R-CNN:** RPN (Region Proposal Network) zamiast Selective Search. ~5 fps. + +**One-stage:** +- **YOLO:** Grid S×S, każda cell predykuje B bbox + C klas. 45-155 fps! Gorszy dla małych obiektów. +- **SSD:** Multi-scale feature maps + anchors. Łączy szybkość YOLO z multi-scale. + +**Nowoczesne:** YOLOv8 (anchor-free), DETR (transformer, no NMS), RT-DETR. + +### Jak zbudować detektor z klasyfikatora? + +1. **Sliding Window:** crop → classify → NMS. Bardzo wolne. +2. **Region Proposals + Classifier:** Selective Search → crop → classify → NMS. Szybsze. +3. **Fine-tune na detekcję:** Pretrained classifier jako backbone + detection head (bbox regression + cls). **Najlepsza jakość!** + +### NMS (Non-Maximum Suppression): Sortuj po confidence; weź najlepszą; usuń overlapping (IoU > threshold); powtórz. + +### Etymologia + +**YOLO** — You Only Look Once (Joseph Redmon et al., 2016). **R-CNN** — Region-based CNN (Ross Girshick, 2014). **HOG** — Histogram of Oriented Gradients (Dalal & Triggs, 2005). **SVM** — Support Vector Machine (Vapnik, 1995). **Viola-Jones** — Paul Viola + Michael Jones (2001). **DETR** — DEtection TRansformer (Facebook AI, 2020). **SSD** — Single Shot MultiBox Detector (Liu et al., 2016). **NMS** — Non-Maximum Suppression; tłumienie nie-maksymalnych detekcji. + +### Jak zapamiętać + +- **YOLO = „You Only Look Once"** — jednoetapowy, szybki +- **Faster R-CNN = CNN + RPN + ROI Pool** — dwuetapowy, dokładny +- **Detektor z klasyfikatora:** sliding window (wolno) → proposals (lepiej) → fine-tune backbone (najlepiej) + +\newpage + +## PYTANIE 25: Prawo Amdahla — przyspieszenie równoległe + +**Oszacować przyspieszenie. Co osłabia ograniczenie?** + +--- + +### Tło pojęciowe — słowniczek + +**Obliczenia równoległe (parallel computing)** — wykonanie wielu operacji jednocześnie na wielu procesorach/rdzeniach. Cel: przyspieszenie obliczeń. Nie każdy program da się w pełni zrównoleglić — zawsze jest część sekwencyjna (inicjalizacja, agregacja wyników, I/O). + + Sekwencyjnie (1 rdzeń): ████████████ 12 sec + Równolegle (4 rdzenie): ███ 3 sec (część równoległa) + ██ 2 sec (część sekwencyjna) + Razem: 5 sec (nie 3!) + +**Przyspieszenie (speedup)** — stosunek czasu sekwencyjnego do równoległego: S(n) = T_seq / T_par(n). Idealne przyspieszenie na n procesorach = n (liniowe). W praktyce zawsze mniej z powodu części sekwencyjnej i overheadów. + +--- + +**Prawo Amdahla (Amdahl's Law)** — określa MAKSYMALNE przyspieszenie programu przy zrównolegleniu na n procesorach. Kluczowe parametry: +- **p** — część programu, którą DA SIĘ zrównoleglić (0 ≤ p ≤ 1) +- **(1-p)** — część sekwencyjna (nie do zrównoleglenia) +- **n** — liczba procesorów + +**Wzór:** + + S(n) = 1 / ((1-p) + p/n) + +**Dlaczego tak?** Czas sekwencyjny = 1. Część sekwencyjna zajmuje (1-p), nie przyspiesza. Część równoległa trwa p/n. Suma = nowy czas. + +**Maksymalne przyspieszenie (n→∞):** + + S_max = 1/(1-p) + + p=90% (10% sekwencyjne) → S_max = 1/0.10 = 10x + p=95% (5% sekwencyjne) → S_max = 1/0.05 = 20x + p=99% (1% sekwencyjne) → S_max = 1/0.01 = 100x + +**Kluczowy wniosek:** nawet z nieskończoną liczbą procesorów, 10% sekwencyjnego kodu ogranicza przyspieszenie do 10x! Sekwencyjna część dominuje. + +**Przykład liczbowy: p=90%, n=4:** + + S(4) = 1 / (0.10 + 0.90/4) = 1 / (0.10 + 0.225) = 1/0.325 ≈ 3.08x + Z 4 procesorów uzyskamy ~3.08x, NIE 4x! + +--- + +**Prawo Gustafsona (Gustafson's Law)** — alternatywna perspektywa osłabiająca ograniczenie Amdahla. Zamiast „przyspiesz stały problem" → „rozwiąż WIĘKSZY problem w tym samym czasie". + + S = 1 − p + p·n (scaled speedup) + +Dla p=90%, n=100: Gustafson → S = 1 - 0.9 + 0.9×100 = 90.1x (vs Amdahl: ~10x!) + +**Strong scaling (Amdahl)** — stały rozmiar problemu, więcej procesorów. +**Weak scaling (Gustafson)** — rozmiar problemu rośnie proporcjonalnie do procesorów. W praktyce: więcej rdzeni → większa symulacja, więcej danych, wyższa rozdzielczość. + +--- + +**Efektywność (efficiency):** E(n) = S(n)/n — ile z dodanych procesorów jest naprawdę wykorzystane. E(4)=3.08/4=0.77 → 77% efektywności. Spada z n. + +**Overhead synchronizacji** — dodatkowy koszt koordynacji między wątkami/procesami: mutex contention, bariery, komunikacja. Im więcej procesów, tym większy overhead. + +**False sharing** — dwa rdzenie modyfikują różne zmienne, ale leżące w tej samej linii cache. Powoduje ciągłe invalidation cache — dramatyczny spadek wydajności. + + Core 0 pisze: x (cache line 42) + Core 1 pisze: y (cache line 42!) ← ta sama linia! + → Pingpong cache line między rdzeniami + +**NUMA (Non-Uniform Memory Access)** — architektura: pamięć „bliżej" jednego procesora jest szybsza dla niego. Odwołanie do pamięci zdalnej = wolniejsze. Programy muszą uwzględniać lokalność. + +**Load imbalance (nierównomierne obciążenie)** — procesory kończą w różnych czasach. Najwolniejszy limituje cały czas. Rozwiązanie: dynamic scheduling, work stealing. + +**Lock-free (bez blokad)** — struktury danych operujące na CAS (Compare-And-Swap) zamiast mutexów. Eliminują blokowanie, ale trudniejsze w implementacji. + +**Pipelining** — podział pracy na etapy: każdy etap na osobnym rdzeniu. Jak taśma montażowa: etap 1 przetwarza dane N, etap 2 — dane N-1, etap 3 — dane N-2, jednocześnie. + +--- + +### Prawo Amdahla + + S(n) = 1 / ((1-p) + p/n) + +- p = część równoległa, n = procesory +- Maks. przyspieszenie (n→∞): **S_max = 1/(1-p)** +- 10% sekwencyjnego kodu → max **10x** nawet z ∞ procesorami! + +### Tabela przykładów + +| p | n=4 | n=16 | n=∞ | +|-------|------|------|-------| +| 90% | 3.08 | 5.93 | 10 | +| 95% | 3.48 | 9.52 | 20 | +| 99% | 3.88 |13.91 | 100 | + +### Co osłabia ograniczenie? + +**Prawo Gustafsona:** S = 1 − p + p·n. Skaluj problem (więcej danych), nie procesory. Dla p=90%, n=100 → S=90.1x (vs Amdahl: ~10x). + +**Techniki:** algorytmy równoległe, lock-free structures, pipelining, speculative execution, ukrywanie latencji (async I/O, prefetching). + +### Czynniki zmniejszające RZECZYWISTE przyspieszenie + +- Overhead synchronizacji (mutex contention) +- Komunikacja (latencja, bandwidth) +- Load imbalance +- Cache effects (false sharing, NUMA) +- Thread management + +### Efektywność: E(n) = S(n)/n — spada z n + +### Etymologia + +**Gene Amdahl** (IBM, 1967, „Validity of the single processor approach..."); współtwórca IBM System/360. **John Gustafson** (Sandia Labs, 1988, „Reevaluating Amdahl's Law"); weak scaling vs strong scaling. **Speedup (przyspieszenie)** — stosunek czasu sekwencyjnego do równoległego. **Efektywność** — ile z dodanych procesorów jest naprawdę wykorzystane. **Lock-free** — struktury danych bez blokad (CAS — Compare-And-Swap). + +### Jak zapamiętać + +- **S = 1/((1-p) + p/n)** — zapamiętaj wzór! +- **„10% seq = max 10x"** — sekwencyjna część limituje WSZYSTKO +- **Gustafson = „zwiększ problem, nie procesory"** — weak scaling +- **„FLOP" = False sharing, Load imbalance, Overhead, Poor locality** + +\newpage + +## PYTANIE 26: Komunikacja sync/async, blokująca/nieblokująca + +**Definicje. Jak uniknąć zakleszczenia w symetrycznych procesach (Jacobi)?** + +--- + +### Tło pojęciowe — słowniczek + +**Komunikacja międzyprocesowa w obliczeniach równoległych** — procesy na różnych procesorach/maszynach muszą wymieniać dane. Kluczowe pytania: czy nadawca czeka na odbiorcę? Czy funkcja blokuje wątek? Te dwa aspekty (synchroniczność i blokowanie) to osobne, ortogonalne koncepcje. + +--- + +**Komunikacja synchroniczna (synchronous)** — nadawca czeka, aż odbiorca faktycznie odbierze wiadomość. Obie strony muszą być „zsynchronizowane" w czasie — jak rozmowa telefoniczna (mówisz, słuchacz MUSI słuchać w tym momencie). + + Nadawca: Send(data) ──────────→ Odbiorca: Recv() + ↑ ↑ + czeka tu czeka tu + aż odbiorca aż nadawca + odbierze wyśle + +**Komunikacja asynchroniczna (asynchronous)** — nadawca wysyła wiadomość do bufora i kontynuuje pracę, nie czekając na odbiorcę. Jak SMS — wysyłasz i robisz swoje, odbiorca przeczyta kiedy chce. + + Nadawca: Send(data) → [BUFOR] → kontynuuje pracę + Odbiorca: Recv() kiedy gotowy + +--- + +**Funkcja blokująca (blocking)** — wywołanie funkcji nie wraca, dopóki operacja nie jest zakończona (lub wystarczająco zaawansowana). Wątek jest „zamrożony" w oczekiwaniu. + + MPI_Send(data, dest) ← program "stoi" tutaj aż bufor gotowy + printf("gotowe"); ← wykona się DOPIERO po zakończeniu Send + +**Funkcja nieblokująca (non-blocking)** — wywołanie wraca natychmiast, operacja odbywa się w tle. Programista sprawdza status później (wait/test). Wątek może robić inne rzeczy w międzyczasie. + + MPI_Isend(data, dest, &request) ← wraca natychmiast + // ... rób inne obliczenia ... + MPI_Wait(&request) ← czekaj na zakończenie + +**Kluczowe: synchroniczność ≠ blokowanie!** + + Cecha Synchroniczna Asynchroniczna + ────────────────────────────────────────────────────────── + Nadawca czeka na odbiorcę bufor + Wymaga matchingu Tak (rendezvous) Nie + Bufor Nie potrzebny Potrzebny + + Cecha Blokująca Nieblokująca + ────────────────────────────────────────────────────────── + Funkcja wraca po zakończeniu natychmiast + Wątek zamrożony może pracować + Sprawdzenie automatyczne wait()/test() + +--- + +**MPI (Message Passing Interface)** — standard komunikacji w obliczeniach równoległych (HPC). Najbardziej popularny model programowania na klastrach. Procesy komunikują się przez przesyłanie wiadomości (send/recv). Forum MPI zdefiniowało kilka wariantów Send: + +- **MPI_Send** — blokujące, synchroniczność zależna od implementacji (może buforować lub czekać na recv) +- **MPI_Ssend** — blokujące, synchroniczne (czeka aż odbiorca dopasuje recv) +- **MPI_Bsend** — blokujące, asynchroniczne (kopiuje do bufora użytkownika i wraca) +- **MPI_Isend** — nieblokujące (I = Immediate), wraca natychmiast +- **MPI_Recv** — blokujące odbieranie +- **MPI_Irecv** — nieblokujące odbieranie + +--- + +**Zakleszczenie (deadlock) w komunikacji** — gdy oba procesy wywołują blokujące Send przed Recv, żaden nie może odebrać (bo czeka na odbiorcę): + + Proc 0: Send(to=1); Recv(from=1); ← czeka na recv z proc 1 + Proc 1: Send(to=0); Recv(from=0); ← czeka na recv z proc 0 + → Oba czekają, nikt nie odbiera → DEADLOCK! + +**Metoda Jacobiego** — iteracyjna metoda rozwiązywania układów równań liniowych. W wersji równoległej: każdy proces oblicza swoją część i wymienia wartości graniczne z sąsiadami. Symetryczny kod (wszyscy robią to samo) → podatny na deadlock Send-Send. + +**Rozwiązania deadlocka w symetrycznym kodzie:** +1. **Asymetria kolejności** — Proc 0: Send→Recv; Proc 1: Recv→Send. Działa, ale asymetrycne. +2. **Nieblokujące** — Irecv + Isend + Waitall. Oba procesy inicjują odbiór ZANIM wyślą. +3. **MPI_Sendrecv** — jedna funkcja wykonująca Send i Recv atomowo. Bezpieczna, symetryczna. Rekomendowana. +4. **Bsend** — buforowane wysyłanie: kopiuje do bufora i wraca. Recv nie musi być gotowy. + + // Rozwiązanie 2 (nieblokujące): + MPI_Irecv(from=neighbor, &req_r); // inicjuj odbiór + MPI_Isend(to=neighbor, &req_s); // inicjuj wysyłanie + MPI_Waitall(2, [req_r, req_s]); // czekaj na oba + + // Rozwiązanie 3 (Sendrecv): + MPI_Sendrecv(send_buf, dest, recv_buf, source); // jedna funkcja, 0 deadlock + +--- + +### Definicje + +**Synchroniczna:** Nadawca czeka aż odbiorca odbierze (oba zsynchronizowane). +**Asynchroniczna:** Nadawca wysyła do bufora i kontynuuje (nie czeka na odbiorcę). + +**Blokująca:** Funkcja nie wraca dopóki operacja nie skończona. +**Nieblokująca:** Funkcja wraca natychmiast; operacja w tle; sprawdzaj wait()/test(). + +### MPI + +| Funkcja | Blok? | Sync? | +|------------|-------|-----------| +| MPI_Send | Blok | Zależy | +| MPI_Ssend | Blok | Sync | +| MPI_Bsend | Blok | Async | +| MPI_Isend | Nie | Async | +| MPI_Recv | Blok | - | +| MPI_Irecv | Nie | - | + +### Problem: Zakleszczenie w symetrycznym kodzie + + // DEADLOCK! + Proc 0: Send(to=1); Recv(from=1); + Proc 1: Send(to=0); Recv(from=0); + // Oba czekają aż partner odbierze, nikt nie robi Recv! + +### Rozwiązania + +1. **Zmiana kolejności:** Proc 0: Send→Recv; Proc 1: Recv→Send (asymetria) +2. **Nieblokujące:** Irecv + Isend + Wait (oba procesy symetrycznie) +3. **MPI_Sendrecv** — jedna funkcja, automatycznie bezpieczna +4. **Bsend** — buforowane wysyłanie (kopiuje do bufora i wraca) + +### Etymologia + +**MPI** — Message Passing Interface (MPI Forum, 1994); standard komunikacji w obliczeniach równoległych. **Jacobi** — Carl Gustav Jacob Jacobi (1804–1851, mat. niemiecki); metoda iteracyjna rozwiązywania układów równań. **Synchroniczna** — grec. „syn" (razem) + „chronos" (czas) = w tym samym czasie. **Asynchroniczna** — grec. „a-" (nie) + synchronous = nie w tym samym czasie. **Blokująca** — funkcja „blokuje" wątek aż operacja się skończy. + +### Jak zapamiętać + +- **Deadlock = Send-Send** — oba czekają, nikt nie odbiera +- **Sendrecv = „safe exchange"** — jedna funkcja, zero deadlocków +- **I = Immediate = Non-blocking** (MPI_Isend, MPI_Irecv) +- **S = Synchronous** (MPI_Ssend — czeka na recv) + +\newpage + +## PYTANIE 31: Interaktywne wspomaganie decyzji w warunkach ryzyka + +**Przedstawić metody interaktywne.** + +--- + +### Tło pojęciowe — słowniczek + +**Warunki decyzyjne** — trzy poziomy wiedzy o przyszłości, w których podejmujemy decyzje: + + Pewność (certainty) → znamy dokładny wynik każdej decyzji + Ryzyko (risk) → znamy możliwe wyniki I ich prawdopodobieństwa + Niepewność (uncertainty) → nie znamy prawdopodobieństw + +Przykład ryzyka: „Z 60% szansą zysk 100 zł, z 40% strata 50 zł." Przykład niepewności: „Możemy zyskać lub stracić, ale nie wiemy ile i z jakim prawdopodobieństwem." + +--- + +**Decydent (decision maker)** — osoba lub podmiot, który musi wybrać jedną z dostępnych alternatyw. Metody interaktywne wymagają dialogu z decydentem — pytamy go o preferencje, zamiast zakładać je z góry. + +**Funkcja użyteczności U(x) (utility function)** — matematyczne przypisanie „wartości subiektywnej" do wyniku. Dla kogoś, kto boi się ryzyka, różnica między 0 a 1000 zł jest bardziej odczuwalna niż między 9000 a 10000 zł. + + U(x) + │ ╭──────── wklęsła (risk-averse) + │ ╱╱ + │ ╱╱ + │╱╱ + └──────────── x (pieniądze) + +**Risk averse (awersja do ryzyka)** — decydent preferuje pewne wyniki nad ryzykowne loterie o tej samej wartości oczekiwanej. Funkcja U jest **wklęsła** (concave): U''(x) < 0. + + Loteria: 50% szans na 0 zł, 50% na 100 zł → E[X] = 50 zł + Risk-averse: „Wolę 50 zł na pewno" (a nawet 40 zł na pewno!) + +**Risk neutral (neutralność)** — U jest liniowa. Decydentowi jest obojętne czy dostanie E[X] na pewno, czy zagra w loterię. + +**Risk seeking (skłonność do ryzyka)** — U jest **wypukła** (convex). Decydent woli ryzyko niż pewny E[X]. „Wolę zagrać niż dostać pewniaka." + +--- + +**Loteria (lottery)** — formalizacja decyzji ryzykownej: zbiór wyników z ich prawdopodobieństwami. Notacja L = (p: best, 1-p: worst). + + L = (0.6: 100 zł, 0.4: 0 zł) + E[L] = 0.6 × 100 + 0.4 × 0 = 60 zł + +**Metoda loterii (lottery method)** — technika wyznaczania U(x) przez zadawanie pytań decydentowi. Ustalamy U(worst)=0, U(best)=1 i szukamy „indifference point" — prawdopodobieństwa p*, przy którym decydent jest obojętny między pewną kwotą a loterią. + + Pyt: „Wolisz 500 zł na pewno, czy loterię (p: 1000 zł, 1-p: 0 zł)?" + Jeśli punkt obojętności p* = 0.7 → U(500) = 0.7 + (Risk-neutral dałby p*=0.5, bo 500/1000=0.5) + +**Certainty Equivalent (CE, ekwiwalent pewności)** — pewna kwota, która jest dla decydenta równoważna danej loterii. + + Loteria: 50/50 zysk 100 zł lub 0 zł → E[X] = 50 zł + Decydent risk-averse: CE = 35 zł (wolałby 35 zł na pewno niż grać) + Risk premium = E[X] − CE = 50 − 35 = 15 zł + +**Wartość oczekiwana E[X] (expected value)** — średni wynik loterii ważony prawdopodobieństwami. + + E[X] = Σ pᵢ × xᵢ + Dla L = (0.3: 100, 0.7: 20): E[X] = 0.3×100 + 0.7×20 = 44 + +--- + +**AHP (Analytic Hierarchy Process)** — metoda Saaty'ego do wyboru najlepszej alternatywy gdy mamy wiele kryteriów. Rozbija problem na hierarchię: Cel → Kryteria → Alternatywy. + + Cel: Wybierz samochód + ├── Kryterium: Cena + │ ├── Auto A, Auto B, Auto C + ├── Kryterium: Komfort + │ ├── Auto A, Auto B, Auto C + └── Kryterium: Spalanie + ├── Auto A, Auto B, Auto C + +**Porównania parami (pairwise comparisons)** — w AHP porównujemy każdą parę kryteriów/alternatyw i oceniamy na skali 1-9 Saaty'ego: + + 1 = równe znaczenie + 3 = umiarkowana przewaga + 5 = silna przewaga + 7 = bardzo silna + 9 = absolutna przewaga + + Macierz 3×3 (Cena vs Komfort vs Spalanie): + Cena Komf Spal + Cena [ 1 3 5 ] + Komf [ 1/3 1 2 ] + Spal [ 1/5 1/2 1 ] + +**Eigenvalue (wartość własna)** — z macierzy porównań wyznaczamy wektor własny → wagi kryteriów. To serce AHP: macierz parami → ranking numeryczny. + +**Consistency Ratio (CR)** — miara spójności ocen decydenta. Jeśli A>B i B>C, ale C>A, to niespójne. CR < 0.1 = akceptowalne. CR ≥ 0.1 → decydent powinien poprawić oceny. + +--- + +**PROMETHEE (Preference Ranking Organization METHod for Enrichment Evaluations)** — metoda porównująca alternatywy parami per kryterium za pomocą funkcji preferencji. Wynik: przepływy (flows). + + Φ⁺(a) = outgoing flow = „o ile a jest lepsze od reszty" (siła) + Φ⁻(a) = incoming flow = „o ile reszta jest lepsza od a" (słabość) + Φ(a) = Φ⁺(a) − Φ⁻(a) = net flow → im wyższe, tym lepsza alternatywa + +**ELECTRE (ÉLimination Et Choix Traduisant la REalité)** — metoda outranking: A przewyższa B (A S B) gdy: + +1. **Concordance (zgoda):** wystarczająco dużo kryteriów popiera A nad B +2. **Discordance (sprzeciw):** żadne kryterium nie daje B drastycznej przewagi nad A + + Cecha AHP PROMETHEE ELECTRE + ────────────────────────────────────────────────────────── + Input parami (skala) per-kryterium per-kryterium + Wynik wagi + ranking przepływy Φ relacja outranking + Typ kompensacyjna częściowo komp. niekompensacyjna + Sens wartość globalna przepływ netto eliminacja słabych + +--- + +### Warunki: pewność (determinizm) → **ryzyko** (znane prawdopodobieństwa) → niepewność (brak prawdopodobieństw) + +### Interaktywność = dialog z decydentem → odkrycie preferencji (funkcji użyteczności) + +### Metody + +**1. Metoda loterii:** Ustal U(worst)=0, U(best)=1. Pytaj: „Wolisz x_mid na pewno, czy loterię (p: best, 1-p: worst)?" Punkt obojętności p* = U(x_mid). + +**2. Certainty Equivalent (CE):** CE(L) = pewna kwota równoważna loterii L. +- CE < E[X] → risk averse (wklęsła U) +- CE = E[X] → risk neutral +- CE > E[X] → risk seeking +- Risk Premium = E[X] − CE + +**3. AHP (Analytic Hierarchy Process):** Hierarchia: Cel → Kryteria → Alternatywy. Porównania parami (skala 1-9) → eigenvalue → wagi. Consistency Ratio CR < 0.1. + +**4. PROMETHEE:** Funkcje preferencji per kryterium; agregacja; przepływy Φ⁺, Φ⁻, Φ (net); ranking. + +**5. ELECTRE:** Concordance (zgoda) + Discordance (sprzeciw) → outranking aSb. + +### Etymologia + +**AHP** — Thomas Saaty (U. of Pittsburgh, 1970s); Analytic Hierarchy Process. **PROMETHEE** — Preference Ranking Organization METHod for Enrichment Evaluations (Jean-Pierre Brans, 1982). **ELECTRE** — ÉLimination Et Choix Traduisant la REalité (Bernard Roy, 1965) = „Eliminacja i Wybór Odzwierciedlający Rzeczywistość". **Certainty Equivalent** — z teorii użyteczności von Neumanna-Morgensterna (1944). **Funkcja użyteczności** — Daniel Bernoulli (1738) wprowadził koncepcję; vN-M sformalizowali aksjomatycznie. + +### Jak zapamiętać + +- **CE = „ile dałbyś za pewniaka zamiast loterii?"** → miara awersji do ryzyka +- **AHP = „porównaj parami, policz wagi"** (macierz → eigenvalue) +- **PROMETHEE = „przepływy"** (Φ⁺ outgoing, Φ⁻ incoming) + +\newpage + +## PYTANIE 32: Dominacja stochastyczna + +**FSD i SSD. Jak mogą być użyte w modelach wyboru?** + +--- + +### Tło pojęciowe — słowniczek + +**Dominacja stochastyczna (stochastic dominance)** — metoda porównywania rozkładów prawdopodobieństwa (np. dwóch inwestycji) BEZ konieczności znajomości dokładnej funkcji użyteczności decydenta. Jeśli rozkład A „dominuje" B, to cała klasa racjonalnych decydentów wybierze A. + + Idea kluczowa: + Nie wiem jaka DOKŁADNIE jest Twoja U(x), + ale wiem, że preferujesz „więcej" (FSD) + lub dodatkowo „mniej ryzyka" (SSD). + To wystarczy, żeby A > B. + +--- + +**Dystrybuanta F(x) (CDF — Cumulative Distribution Function)** — prawdopodobieństwo, że zmienna losowa X przyjmie wartość ≤ x. F(x) = P(X ≤ x). Rośnie od 0 do 1. + + Przykład: rzut kostką + F(1) = 1/6, F(2) = 2/6, F(3) = 3/6, F(4) = 4/6, F(5) = 5/6, F(6) = 1 + + Graficznie (ciągły rozkład): + F(x) + 1 ┤ ────────── + │ ╱ + │ ╱ + │ ╱ + 0 ┤────╱ + └─────────────────── x + +**Dlaczego dystrybuanta?** Dominacja stochastyczna porównuje KSZTAŁT dystrybuant, nie pojedyncze liczby jak średnia czy wariancja. To daje silniejsze wnioski. + +--- + +**FSD (First-order Stochastic Dominance, dominacja stochastyczna I rzędu)** — A dominuje B w sensie FSD, gdy dystrybuanta A leży ZAWSZE poniżej (lub jest równa) dystrybuancie B: + + F_A(x) ≤ F_B(x) dla każdego x + +Intuicja: „Dla DOWOLNEGO progu x, szansa, że A daje wynik ≤ x jest mniejsza lub równa niż dla B." A daje zawsze co najmniej tyle samo „dobrych wyników". + + F(x) + 1 ┤ ╱── B (gorsza — wyższa CDF) + │ ╱╱── A (lepsza — niższa CDF) + │ ╱╱ + │ ╱╱ + 0 ┤──╱╱ + └──────────── x + A ≥_FSD B: F_A zawsze pod F_B + +**Warunek na klasę U:** U'(x) ≥ 0 — monotoniczność, czyli „więcej = lepiej". WSZYSCY racjonalni (nienasyceni) decydenci wybiorą A. + +Przykład liczbowy: + + Inwestycja A: wynik = {20, 30, 40} każdy z p=1/3 + Inwestycja B: wynik = {10, 30, 40} każdy z p=1/3 + + F_A(10)=0, F_B(10)=1/3 → F_A ≤ F_B ✓ + F_A(20)=1/3, F_B(20)=1/3 → F_A ≤ F_B ✓ + F_A(30)=2/3, F_B(30)=2/3 → F_A ≤ F_B ✓ + A ≥_FSD B → każdy racjonalny wybierze A + +**FSD jest rzadka w praktyce** — wystarczy JEDEN punkt, w którym F_A(x) > F_B(x), i dominacja nie zachodzi. + +--- + +**SSD (Second-order Stochastic Dominance, dominacja II rzędu)** — A dominuje B w sensie SSD, gdy skumulowana całka z dystrybuanty A jest ≤ niż z B: + + ∫_{-∞}^{x} F_A(t)dt ≤ ∫_{-∞}^{x} F_B(t)dt dla każdego x + +Dystrybuanty MOGĄ się przecinać (A nie musi być wszędzie lepsza), ale „pole pod F_A" jest zawsze mniejsze lub równe. + +**Warunek na klasę U:** U'(x) ≥ 0 i U''(x) ≤ 0 — monotoniczność + wklęsłość = **risk-averse** decydenci. + + F(x) ∫F(x)dx + 1 ┤ ╱B │ ╱B (większe pole) + │ ╱X╱ │ ╱╱ + │╱╱A │ ╱╱A (mniejsze pole) + 0 ┤ │╱ + └───── x └───── x + CDF mogą się krzyżować! Ale skumulowane pole A ≤ B → A ≥_SSD B + +--- + +**Relacja między FSD a SSD:** + + FSD ⟹ SSD ⟹ TSD ⟹ ... (ale NIE odwrotnie!) + +Jeśli A dominuje B w sensie FSD, to automatycznie dominuje w SSD. Ale SSD może zachodzić nawet gdy FSD nie — bo SSD „przebacza" chwilowe przekroczenia F_A nad F_B, jeśli kompensowane gdzie indziej. + +--- + +**Mean-Preserving Spread (MPS)** — operacja, która zwiększa rozrzut (wariancję) rozkładu, zachowując tę samą średnią. B = A + ε, gdzie E[ε|A]=0. + + A: zawsze 50 zł → E[A] = 50, Var = 0 + B: 50% szans na 20 zł, 50% na 80 zł → E[B] = 50, Var = 900 + B jest MPS wobec A: ta sama średnia, większy rozrzut + → A ≥_SSD B (risk-averse wolą A!) + +**Kluczowe twierdzenie Rothschilda-Stiglitza:** A SSD-dominuje B ⟺ B jest mean-preserving spread A (przy jednakowej średniej). + +--- + +**Funkcja wklęsła (concave)** — „krzywa w dół", U''(x) ≤ 0. Każdy dodatkowy złotówka daje coraz mniej użyteczności (malejąca użyteczność krańcowa). Modeluje risk aversion. + + U(x) = √x → U(0)=0, U(100)=10, U(400)=20 + Różnica 0→100: +10 użyteczności + Różnica 100→400: +10 użyteczności (mimo 3× więcej pieniędzy!) + +**Funkcja wypukła (convex)** — „krzywa w górę", U''(x) ≥ 0. Modeluje risk seeking. + +--- + +**Portfolio selection (wybór portfela)** — zastosowanie dominacji: porównaj rozkłady zwrotów portfeli. Eliminuj zdominowane stochastycznie portfele BEZ znania dokładnej U inwestora. + + Portfel A: N(10%, 15%) (średnia 10%, odch. std. 15%) + Portfel B: N(8%, 20%) (średnia 8%, odch. std. 20%) + E[A] > E[B] i σ[A] < σ[B] → A SSD B + Każdy risk-averse inwestor wybierze A. + +--- + +### Idea: Porównaj rozkłady BEZ znajomości dokładnej U. Jeśli A dominuje B → KAŻDY (z danej klasy) wybierze A. + +### FSD (First-order Stochastic Dominance) + + A ≥_FSD B ⟺ F_A(x) ≤ F_B(x) ∀x + +- Warunek na U: U'(x) ≥ 0 (monotoniczność — „więcej = lepiej") +- Klasa: WSZYSCY racjonalni (nienasyceni) +- Interpretacja: A ma zawsze ≥ prawdopodobieństwo przekroczenia dowolnego progu +- **Rzadka** w praktyce + +### SSD (Second-order Stochastic Dominance) + + A ≥_SSD B ⟺ ∫_{-∞}^{x} F_A(t)dt ≤ ∫_{-∞}^{x} F_B(t)dt ∀x + +- Warunek na U: U' ≥ 0 i U'' ≤ 0 (monotoniczne + wklęsłe) +- Klasa: **Risk-averse** (awersja do ryzyka) +- Dystrybuanty mogą się przecinać, ale skumulowane pole nie +- **Częstsza** niż FSD +- Mean-Preserving Spread: B = A + ε (E[ε|A]=0) → A SSD B + +### Relacja: FSD ⟹ SSD ⟹ TSD... (ale nie odwrotnie) + +### Zastosowania + +- **Portfolio selection:** eliminuj zdominowane portfele bez znajomości U +- **Ubezpieczenia:** fair ubezpieczenie SSD-dominuje brak ubezpieczenia (dla risk-averse) +- **Ocena inwestycji:** A: N(10%,15%), B: N(8%,20%) → E[A]>E[B], σ[A]<σ[B] → A SSD 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 | +| Częstość | Rzadka | Częstsza | + +### Etymologia + +**Stochastyczna** — grec. „stochastos" = zdolny do celowania, od „stochazein" = mierzyć; w probabilistyce: losowy. **FSD/SSD** — Hadar & Russell (1969); Rothschild & Stiglitz (1970) niezależnie. **Mean-Preserving Spread** — Rothschild & Stiglitz: ten sam średni wynik, ale większy rozrzut = gorsze dla risk-averse. **Dominacja** — łac. „dominari" = panować; A dominuje B gdy jest zawsze co najmniej tak dobre. + +### Jak zapamiętać + +- **FSD = „F always below"** — dystrybuanta A zawsze ≤ B +- **SSD = „Second = Sum (integral)"** — całka z F_A ≤ całka z F_B +- **FSD → wszyscy; SSD → risk-averse** +- FSD implikuje SSD, ale nie odwrotnie diff --git a/pytania/OBRONA_MAGISTERSKA_ODPOWIEDZI.pdf b/pytania/OBRONA_MAGISTERSKA_ODPOWIEDZI.pdf new file mode 100644 index 0000000..1b61d4a Binary files /dev/null and b/pytania/OBRONA_MAGISTERSKA_ODPOWIEDZI.pdf differ diff --git a/pytania/OBRONA_SKRYPT_MOWIONY.md b/pytania/OBRONA_SKRYPT_MOWIONY.md new file mode 100644 index 0000000..71d5292 --- /dev/null +++ b/pytania/OBRONA_SKRYPT_MOWIONY.md @@ -0,0 +1,1140 @@ + + + + +--- + +# SKRYPT MÓWIONY — Obrona Magisterska + +--- + +\newpage + +## PYTANIE 1 · Automaty i klasy języków (AISDI) + +**Pytanie:** *Porównać „siłę wyrazu" automatu skończonego, automatu ze stosem oraz maszyny Turinga. Jakie klasy języków rozpoznaje każdy z nich?* + +--- + +### Co mówię + +Dobrze, tutaj chodzi o hierarchię Chomsky'ego, czyli o to, jak kolejne automaty mają coraz większą moc obliczeniową dzięki temu, że mają coraz lepszą pamięć. + +[TABLICA: rysuj „schodki" albo kółka zagnieżdżone — od najmniejszego do największego] + +Zaczynam od najsłabszego. **Automat skończony** — on nie ma żadnej pamięci poza swoim stanem. Może rozpoznawać języki regularne, czyli takie, które da się opisać wyrażeniem regularnym. Przykład — sprawdzanie czy identyfikator w kodzie jest poprawny. Ale nie poradzi sobie z czymś, co wymaga zliczania — na przykład z językiem a^n b^n, bo nie ma jak zapamiętać ile było tych „a". + +[TABLICA: napisz FA → Regularne, pamięć: brak] + +Następny krok — **automat ze stosem**. Tutaj dodajemy stos, i to wystarczy, żeby obsłużyć nawiasy, rekurencję w gramatykach. Rozpoznaje języki bezkontekstowe — to jest ten poziom, na którym działają parsery języków programowania. Poradzi sobie z a^n b^n, bo na stos odkłada „a" i zdejmuje przy „b". Ale nie da rady z a^n b^n c^n, bo stos zostaje zużyty po dwóch pierwszych grupach. + +[TABLICA: dopisz PDA → Bezkontekstowe, pamięć: stos LIFO] + +Na końcu — **maszyna Turinga**. Ma nieskończoną taśmę z odczytem i zapisem. Może się cofać, może pisać w dowolnym miejscu. Rozpoznaje języki rekurencyjnie przeliczalne, czyli — zgodnie z tezą Churcha-Turinga — wszystko to, co w ogóle da się obliczyć. + +[TABLICA: dopisz TM → Rek. przeliczalne, pamięć: taśma ∞ R/W] + +Więc mamy taką hierarchię inkluzji: regularne ⊂ bezkontekstowe ⊂ kontekstowe ⊂ rekurencyjnie przeliczalne. Każdy następny automat rozpoznaje ściśle więcej. + +Warto wspomnieć, że jest jeszcze **LBA** — automat z ograniczoną taśmą — między PDA a TM. On rozpoznaje języki kontekstowe, takie jak a^n b^n c^n. Ale nie jest wprost wymieniony w pytaniu. + +### Jeśli mam jeszcze czas / pytają dalej + +Ciekawa różnica: dla automatów skończonych — determinizm i niedeterminizm dają tę samą moc. Każdy NFA da się przekształcić na DFA. Dla PDA — nie: niedeterministyczny PDA rozpoznaje więcej niż deterministyczny. A dla maszyn Turinga — znowu równoważne, pod względem mocy, choć nie szybkości. + +### Spodziewane pytania dodatkowe + +**„Podaj kontrprzykład — co łamie FA?"** → a^n b^n — trzeba liczyć, FA nie ma pamięci, nie da rady. + +**„Czym się różni DFA od NFA?"** → NFA może być w wielu stanach naraz, ale każdy NFA da się zamienić na DFA — kosztem wykładniczej liczby stanów. + +**„Co to jest teza Churcha-Turinga?"** → Że maszyna Turinga opisuje wszystko, co intuicyjnie rozumiemy jako „obliczanie". Nie jest to twierdzenie matematyczne — to teza filozoficzna. + +--- + +\newpage + +## PYTANIE 2 · Algorytmy najkrótszej ścieżki (AISDI) + +**Pytanie:** *Omówić i porównać algorytmy: Dijkstry, Bellmana-Forda, A\*.* + +--- + +### Co mówię + +Trzy algorytmy, każdy rozwiązuje problem najkrótszej ścieżki, ale w innych warunkach i innym podejściem. + +[TABLICA: narysuj prosty graf ważony — 5 wierzchołków, parę krawędzi z wagami] + +**Dijkstra** — algorytm zachłanny. Startujemy z jednego źródła, trzymamy kolejkę priorytetową wierzchołków po aktualnej odległości i zawsze przetwarzamy ten o najmniejszej. Relaksujemy jego krawędzie. Kluczowy warunek — **wagi muszą być nieujemne**, bo raz przetworzony wierzchołek już nie jest odwiedzany ponownie. Złożoność z kopcem — O((V+E) log V). + +**Bellman-Ford** — podejście z programowania dynamicznego. Robimy V−1 iteracji, w każdej relaksujemy wszystkie krawędzie. Dlaczego V−1? Bo najdłuższa ścieżka prosta ma V−1 krawędzi. Główna zaleta — **obsługuje ujemne wagi** i potrafi **wykryć cykl ujemny**: jeśli po V−1 iteracjach dalej da się poprawić jakąś odległość, to jest cykl. Złożoność — O(V·E), wolniejszy od Dijkstry. + +**A\*** — to w zasadzie Dijkstra z heurystyką. Zamiast przetwarzać wierzchołek o najmniejszej odległości g(n), bierze ten o najmniejszym f(n) = g(n) + h(n), gdzie h to oszacowanie ile jeszcze zostało do celu. Jeśli heurystyka jest dopuszczalna — czyli nie przeszacowuje — to A\* jest optymalny. Typowe zastosowanie — nawigacja, gry. + +[TABLICA: napisz krótką tabelkę] + +| Algo | Podejście | Ujemne wagi | Złożoność | +|------|-----------|-----------|-----------| +| Dijkstra | Zachłanny | NIE | O((V+E)log V) | +| Bellman-Ford | DP | TAK | O(VE) | +| A* | Heuryst. | NIE | Zależy od h | + +### Spodziewane pytania dodatkowe + +**„Dlaczego Dijkstra nie działa z ujemnymi wagami?"** → Bo po przetworzeniu wierzchołka zakładamy, że mamy już najkrótszą ścieżkę do niego. Ujemna waga może później dać lepszą trasę — ale algorytm już tego nie sprawdzi. + +**„Co to znaczy, że heurystyka jest dopuszczalna?"** → Że h(n) ≤ faktyczny koszt z n do celu. Nigdy nie przeszacowuje. Przykład — odległość po linii prostej na mapie. + +**„Który jest najszybszy w praktyce?"** → A\* z dobrą heurystyką, bo eksploruje mniej wierzchołków. Dijkstra exploruje we wszystkich kierunkach, A\* kieruje się ku celowi. + +--- + +\newpage + +## PYTANIE 3 · Redundancja i normalizacja (BD2) + +**Pytanie:** *Omówić zagadnienia redundancji i normalizacji w relacyjnej bazie danych.* + +--- + +### Co mówię + +Redundancja to powtarzanie tych samych danych w wielu miejscach. Problem nie jest sam fakt powtórzenia, tylko **anomalie**, jakie powoduje. + +Są trzy rodzaje anomalii. **Wstawiania** — nie mogę dodać danych bez podania niepotrzebnych powiązań. **Usuwania** — kasuję rekord i tracę informację, która nie powinna zniknąć. **Modyfikacji** — zmieniam jedno pole, ale muszę to zrobić w dziesięciu miejscach, bo dane są powielone. + +[TABLICA: przykład — tabela Student-Kurs-Wydział, gdzie NazwaWydziału się powtarza] + +Rozwiązaniem jest **normalizacja** — rozbijamy tabelę na mniejsze, eliminując zależności, które powodują redundancję. + +Postacie normalne idą tak: 1NF → 2NF → 3NF → BCNF → dalej. + +Jest taka mnemotechnika: **„Klucz, cały klucz i tylko klucz — tak mi dopomóż Codd."** + +- **1NF** — wartości atomowe, istnieje klucz. Czyli żadnych list w komórkach. +- **2NF** — każdy atrybut wtórny zależy od **całego** klucza, nie od jego części. To dotyczy kluczy złożonych. +- **3NF** — brak zależności przechodnich. Jeśli A → B → C, to C nie powinno być w tej samej tabeli co A. +- **BCNF** — dla każdej zależności funkcyjnej lewa strona musi być nadkluczem. Silniejsza niż 3NF. + +W praktyce — 3NF albo BCNF to taki „standard" w systemach transakcyjnych. Dalsze postacie — 4NF, 5NF — dotyczą zależności wielowartościowych i łączeniowych, ale stosuje się je rzadko. + +Jest też **denormalizacja** — świadome dodawanie redundancji dla wydajności, żeby uniknąć kosztownych JOIN-ów. Typowe w hurtowniach danych, OLAP. + +### Spodziewane pytania dodatkowe + +**„Podaj przykład naruszenia 2NF."** → Tabela (StudentID, KursID, NazwaKursu): NazwaKursu zależy tylko od KursID, nie od całego klucza złożonego. + +**„Jaka jest różnica między 3NF a BCNF?"** → 3NF pozwala na zależności, gdzie lewa strona nie jest nadkluczem, jeśli prawa strona jest atrybutem pierwszym. BCNF tego nie akceptuje. + +**„Kiedy denormalizować?"** → Gdy zapytania analityczne wymagają wielu JOIN-ów i opóźnienie jest nieakceptowalne. Obniżamy normalizację na rzecz wydajności odczytu. + +--- + +\newpage + +## PYTANIE 4 · Baza danych jako fundament systemów (BD2) + +**Pytanie:** *Dlaczego baza danych stanowi dobry fundament do budowy wielu systemów informatycznych?* + +--- + +### Co mówię + +To pytanie jest trochę bardziej koncepcyjne. Chodzi o to, dlaczego baza danych jest tak dobrym fundamentem — w porównaniu z alternatywami typu pliki, pamięć operacyjna, własne rozwiązania. + +Powodów jest kilka i pójdę po kolei. + +Po pierwsze — **transakcyjność ACID**. Atomowość gwarantuje, że operacja się wykona w całości albo wcale. Spójność — że baza przechodzi ze spójnego stanu w spójny. Izolacja — równoległe operacje sobie nie przeszkadzają. Trwałość — raz zapisane dane przetrwają awarię. To jest fundament — bez tego każdy system musiałby sam implementować te gwarancje. + +Po drugie — **niezależność danych**. Architektura ANSI/SPARC wyróżnia trzy poziomy: fizyczny, logiczny, zewnętrzny. Zmiana indeksów czy partycjonowania nie wpływa na logikę aplikacji. To pozwala na niezależną ewolucję systemu. + +Po trzecie — **współbieżność**. Baza ma wbudowane mechanizmy — blokady, MVCC — żeby wielu użytkowników mogło pracować jednocześnie. Bez bazy — musielibyśmy to implementować sami. + +Po czwarte — **integralność**. Klucze obce, CHECK-i, triggery — baza sama pilnuje reguł biznesowych na poziomie danych. + +Po piąte — **optymalizator zapytań**. Piszę CO chcę, a baza sama decyduje JAK to zrealizować — wybiera indeksy, plany wykonania. To ogromna oszczędność pracy. + +Jeszcze bezpieczeństwo — GRANT/REVOKE, role, szyfrowanie. Skalowalność — replikacja, sharding. I SQL jako standardowy interfejs — nie wymyślam protokołu od zera. + +Podsumowując — baza danych daje zestaw rozwiązanych problemów, które każdy system potrzebuje. Zamiast budować od zera, korzystamy z dojrzałego narzędzia. + +### Spodziewane pytania dodatkowe + +**„Co to MVCC?"** → Multi-Version Concurrency Control. Zamiast blokować, baza trzyma wiele wersji wiersza. Czytający widzi starszą wersję, piszący tworzy nową. Nie blokują się nawzajem. + +**„A kiedy baza NIE jest dobrym fundamentem?"** → Kiedy mamy dane niestrukturalne, wymagania ultra-niskiej latencji, albo dane w grafie — wtedy rozwiązania specjalizowane (timeseries DB, document stores, graph DB) mogą być lepsze. + +--- + +\newpage + +## PYTANIE 5 · Kategorie STL (PROI) + +**Pytanie:** *Omówić główne kategorie elementów biblioteki STL.* + +--- + +### Co mówię + +STL ma cztery główne filary — i kluczowe jest to, jak one ze sobą współpracują. + +[TABLICA: narysuj schemat] + + KONTENERY ←→ ITERATORY ←→ ALGORYTMY + ↑ + FUNKTORY + +**Kontenery** — przechowują dane. Mamy sekwencyjne — vector, list, deque. Asocjacyjne oparte na drzewach R-B — set, map — z O(log n). Nieuporządkowane oparte na hashach — unordered_set, unordered_map — z O(1) średnio. I adaptery — stack, queue, priority_queue — ograniczony interfejs. + +**Iteratory** — to uogólnione wskaźniki. Są w hierarchii: od Input/Output, przez Forward, Bidirectional, po Random Access. Vector daje Random Access, list — Bidirectional, forward_list — Forward. Iterator mówi algorytmowi JAK przechodzić po kontenerze. + +**Algorytmy** — sort, find, transform, copy, accumulate. Kluczowa cecha — **operują na iteratorach, nie na kontenerach**. Nie obchodzi ich, czy to vector, list czy deque. + +**Funktory** — obiekty funkcyjne, które parametryzują algorytmy. Klasyczne: less, greater. W C++11 — lambdy. + +I to jest ta genialna architektura STL — jest **ortogonalna**. Mam M kontenerów i N algorytmów — potrzebuję M+N komponentów, nie M×N. Bo kontenery i algorytmy komunikują się przez iteratory. Ten sam sort działa na vectorze i na deque — wystarczy że mają Random Access iterator. + +[TABLICA: sort(v.begin(), v.end()) — ten sam algorytm, różne kontenery] + +### Spodziewane pytania dodatkowe + +**„Kiedy wybrać vector, a kiedy list?"** → Vector domyślnie — contiguous memory, cache-friendly, Random Access. List — gdy dużo wstawiania/usuwania w środku, bo to O(1) z iteratorem, ale cache-unfriendly. W praktyce — vector wygrywa prawie zawsze. + +**„Co to jest ortogonalność w kontekście STL?"** → To, że kontener i algorytm nie muszą o sobie wiedzieć. Łączy je iterator — wspólny interfejs. Dodanie nowego kontenera nie wymaga zmian w algorytmach. + +**„Czym się różni funktor od lambdy?"** → Funktor to klasa z operatorem(), lambda to skrócona składnia, która pod spodem generuje analogiczną klasę. W C++11+ — praktycznie to samo. + +--- + +\newpage + +## PYTANIE 6 · Reużywalność kodu w OOP (PROI) + +**Pytanie:** *Omówić metody reużywalności kodu i struktur danych w obiektowych językach programowania.* + +--- + +### Co mówię + +Mamy kilka głównych mechanizmów, ale zacznę od dwóch najważniejszych — i od tego, jak się je porównuje. + +**Dziedziczenie** — relacja „jest" (is-a). Klasa pochodna przejmuje interfejs i implementację bazowej. Pozwala na polimorfizm — virtual, override. Wada — silne wiązanie, krucha klasa bazowa, i diamond problem przy wielodziedziczeniu. + +**Kompozycja** — relacja „zawiera" (has-a). Zamiast dziedziczyć, obiekt ma pole innego typu. Stack nie JEST wektorem — Stack ZAWIERA wektor. Luźniejsze wiązanie, lepsza enkapsulacja, łatwiejsze testowanie. + +I tutaj zasada z GoF-a, którą trzeba znać: **„Favor composition over inheritance"**. Kompozycja jest preferowana. Dziedziczenie — tylko gdy mam rzeczywiście relację is-a i potrzebuję polimorfizmu. + +**Programowanie generyczne** — szablony w C++, generics w Javie. Piszę kod raz, działa dla wielu typów. Przykład — cała STL jest oparta na templates. To jest reużywalność na poziomie algorytmów i struktur. + +**Interfejsy i klasy abstrakcyjne** — kontrakt bez implementacji. W Javie `interface`, w C++ czysta klasa wirtualna. Pozwala na strategy pattern, dependency injection, testowanie przez mocki. + +**Wzorce projektowe** — reużywalne rozwiązania problemów. GoF opisał 23 wzorce. Strategy, Observer, Factory, Decorator — to nie jest kod do kopiowania, ale sprawdzone schematy. + +No i oczywiście **biblioteki i frameworki** — najoczywistsza forma reużywalności na większą skalę. + +### Spodziewane pytania dodatkowe + +**„Co to problem diamentu?"** → Gdy klasa dziedziczy po dwóch klasach, które mają wspólną bazę. W C++ — rozwiązanie przez `virtual inheritance`. W Javie — nie ma wielodziedziczenia klas, są interfejsy. + +**„Podaj przykład, kiedy dziedziczenie jest lepsze od kompozycji?"** → Gdy potrzebuję polimorfizmu — np. mam kolekcję Shape* i wywołuję draw() — list, circle, rectangle. Każdy rysuje się inaczej, ale interfejs jest wspólny. + +**„Czym jest dependency injection?"** → Przekazuję zależności z zewnątrz zamiast tworzyć je wewnątrz klasy. To ułatwia testowanie i wymianę implementacji. + +--- + +\newpage + +## PYTANIE 7 · DNS i caching (SKM) + +**Pytanie:** *Które serwery DNS zyskują najwięcej na cachingu? Jakie znasz rodzaje serwerów DNS?* + +--- + +### Co mówię + +Zacznę od tego, jakie są rodzaje serwerów DNS, bo to kontekst do odpowiedzi na główne pytanie. + +[TABLICA: rysuj piramidę DNS] + +Na samej górze — **Root Servers**. Jest ich 13 logicznych — od A do M — ale fizycznie setki, rozproszonych przez anycast. Poniżej — **serwery TLD** — odpowiedzialne za .com, .pl, .org. Dalej — **Authoritative** — mają faktyczne rekordy konkretnych domen. Mam primary, który jest edytowalny, i secondary, który jest kopią. + +Po stronie klienta mamy **recursive resolver** — to jest ten, który wykonuje pełne rozwiązywanie nazw. ISP-owski resolver, Google 8.8.8.8, Cloudflare 1.1.1.1. I na samym końcu — **stub resolver** w systemie operacyjnym, który po prostu pyta recursive resolver. + +[TABLICA: narysuj strzałki: Klient → Recursive → Root → TLD → Authoritative] + +Teraz — **które serwery zyskują najwięcej na cachingu?** + +Odpowiedź: **root i TLD** — i to zdecydowanie. + +Dlaczego? Rozmiar piramidy. Jest tylko 13 logicznych root serwerów, a zapytań o DNS są miliardy dziennie. **Bez cache** — każde zapytanie o cokolwiek musiałoby przejść przez root, potem TLD. Z cache — resolver pyta root RAZ o .com, cachuje ten referral na 48 godzin albo dłużej, i przez ten czas wszystkie zapytania o .com idą bezpośrednio do TLD bez angażowania roota. + +TTL-e rootów to 48 godzin do 7 dni! TLD — 24 do 48 godzin. Dzięki temu redukcja ruchu do root serwerów to z prawie 100% do ułamka procenta. Gdyby nie caching, infrastruktura roota nie wytrzymałaby obciążenia. + +### Spodziewane pytania dodatkowe + +**„Co to anycast?"** → Jeden adres IP rozgłaszany z wielu lokalizacji. Klient łączy się z najbliższą instancją — na podstawie routingu BGP. Wszystkie root servery używają anycast. + +**„Co to TTL?"** → Time To Live — ile sekund rekord DNS może być trzymany w cache. Po upłynięciu trzeba odpytać ponownie. + +**„Co się stanie jak wyłączysz cache w resolverze?"** → Ogromny wzrost ruchu do root i TLD serwerów. Każde zapytanie zaczyna od góry piramidy. W skali — to zatopiłoby infrastrukturę. + +--- + +\newpage + +## PYTANIE 8 · TCP Three-Way Handshake (SKM) + +**Pytanie:** *Cel, interpretacja numerów sekwencyjnych, wartość początkowa ISN.* + +--- + +### Co mówię + +TCP Three-Way Handshake to mechanizm nawiązywania połączenia. Trzy kroki. + +[TABLICA: rysuj diagram] + + Klient Serwer + |--- SYN, seq=x ---→| + |←- SYN+ACK, seq=y, ack=x+1 -| + |--- ACK, seq=x+1, ack=y+1 →| + +Krok pierwszy — klient wysyła **SYN** z losowym numerem sekwencyjnym x. Krok drugi — serwer odpowiada **SYN+ACK**: swoim numerem y i potwierdzeniem x+1. Krok trzeci — klient potwierdza: ACK z ack=y+1. + +**Cel?** Trzy rzeczy. Nawiązanie obustronne — obie strony się zgadzają na komunikację. Synchronizacja numerów ISN — obie strony znają początkowy numer drugiej. I uzgodnienie parametrów — w opcjach TCP lecą MSS, Window Scale, SACK. + +Teraz — **numery sekwencyjne**. SEQ to numer pierwszego bajtu danych w segmencie. Nie numerujemy segmentów, numerujemy bajty! Jeśli sending seq=100 i 50 bajtów danych, to następny segment zacznie od 150. + +**Numery potwierdzenia** — ACK to numer **następnego oczekiwanego bajtu**. Jest kumulatywny — potwierdza wszystko do tego numeru. Jest też SACK — selective ACK — pozwala potwierdzać niesąsiednie bloki. + +**ISN** — wartość początkowa. Nie zaczyna od zera! Dwa powody. Po pierwsze — **bezpieczeństwo**: gdyby ISN był zero albo przewidywalny, atakujący mógłby zgadnąć numer sekwencyjny i przejąć sesję. Po drugie — unikanie kolizji z pakietami z poprzednich połączeń. Oryginalny RFC 793 mówił o timerze co 4 mikrosekundy. Nowszy RFC 6528 — ISN jest generowany kryptograficznie z adresów, portów i tajnego klucza. + +### Spodziewane pytania dodatkowe + +**„Dlaczego trzy kroki, a nie dwa?"** → Bo obie strony muszą potwierdzić swój ISN. W dwóch krokach serwer nie wie, czy klient odebrał jego ISN. + +**„Co to SYN flood?"** → Atak DoS — wysyłam tysiące SYN-ów bez dokończenia handshake'u. Serwer trzyma pół-otwarte połączenia, aż wyczerpie zasoby. Obrona — SYN cookies. + +--- + +\newpage + +## PYTANIE 9 · Procesy i wątki (SOI) + +**Pytanie:** *Budowa, szybkość, zastosowanie. Problemy komunikacji i synchronizacji.* + +--- + +### Co mówię + +**Proces** to program w trakcie wykonania. Ma własną przestrzeń adresową — oddzielny kod, dane, stos, heap. Procesy są od siebie **izolowane**. Jeden spadnie — drugi dalej działa. + +**Wątek** to lekka jednostka wykonania **wewnątrz** procesu. Współdzieli z procesem kod, dane globalne, heap, otwarte pliki. Ma **prywatny** stos i rejestry. + +[TABLICA: narysuj — dwa prostokąty-procesy, w jednym dwa mniejsze prostokąty-wątki z własnymi stosami, ale wspólnym heapem] + +Główna różnica praktyczna — **szybkość**. Tworzenie procesu to milisekundy — trzeba kopiować tablicę stron, deskryptory. Tworzenie wątku — mikrosekundy. Przełączanie kontekstu procesu — kosztowne, bo wymaga TLB flush. Przełączanie wątku — znacznie szybsze, bo nie zmienia się przestrzeni adresowej. + +**Komunikacja** — i tu jest różnica. Między procesami — IPC: pipe, shared memory, message queue, sockety. Między wątkami — po prostu współdzielona pamięć. Ale ta prostota ma cenę. + +**Problemy synchronizacji:** + +**Race condition** — dwa wątki modyfikują tę samą zmienną, wynik zależy od kolejności — niedeterminizm. + +**Deadlock** — zakleszczenie. Wątek A trzyma zasób 1 i czeka na 2, wątek B trzyma 2 i czeka na 1. Cztery warunki Coffmana: mutual exclusion, hold and wait, no preemption, circular wait. Złam jeden — deadlocka nie ma. + +**Starvation** — zagłodzenie, wątek nigdy nie dostaje zasobu. + +Mechanizmy rozwiązań: mutex, semafor, monitor, condition variable, spinlock, barrier. + +Lubię tę analogię: proces to mieszkanie — ma adres, własne ściany. Wątek to pokój — współdzieli kuchnię i łazienkę z innymi pokojami. + +### Spodziewane pytania dodatkowe + +**„Czym jest mutex a czym semafor?"** → Mutex — binarny zamek, tylko jeden wątek wchodzi do sekcji krytycznej. Semafor — licznik: pozwala na N jednoczesnych dostępów. Mutex to w zasadzie semafor z N=1, ale semantycznie — mutex ma właściciela. + +**„Co to jest TLB?"** → Translation Lookaside Buffer — cache translacji adresów wirtualnych na fizyczne. Przy zmianie procesu — trzeba go wyczyścić, bo nowy proces ma inną tablicę stron. + +--- + +\newpage + +## PYTANIE 10 · Zarządzanie pamięcią (SOI) + +**Pytanie:** *Problemy i mechanizmy. Stronicowanie vs segmentacja.* + +--- + +### Co mówię + +Zarządzanie pamięcią musi rozwiązać kilka problemów. **Fragmentacja** — zewnętrzna, gdy wolna pamięć jest porozrzucana, i wewnętrzna, gdy przydzielony blok jest większy niż potrzeba. **Ochrona** — proces nie może czytać pamięci innego procesu. **Relokacja** — program musi działać pod różnymi adresami. **Współdzielenie** — biblioteki współdzielone, copy-on-write. + +Dwa podejścia — stronicowanie i segmentacja. + +[TABLICA: stronicowanie — rysuj kratki jednakowej wielkości po obu stronach (strony i ramki)] + +**Stronicowanie** — dzielę pamięć wirtualną na **strony** stałego rozmiaru, najczęściej 4KB. Pamięć fizyczna to **ramki** tego samego rozmiaru. Tablica stron mapuje strony na ramki. Adres = numer strony + offset, translacja zamienia numer strony na numer ramki. + +Zalety — **brak fragmentacji zewnętrznej**, bo wszystko jest tego samego rozmiaru. Wada — fragmentacja wewnętrzna, ale mała — średnio pół strony. + +TLB — cache translacji — bo sięganie do tablicy stron na każdy dostęp byłoby za wolne. Page fault — gdy strona nie jest w RAM-ie, ładujemy z dysku-swap. Algorytmy wymiany: FIFO, LRU, Clock. + +[TABLICA: segmentacja — rysuj bloki różnej wielkości etykietowane: KOD, DANE, STOS] + +**Segmentacja** — dzielę pamięć na logiczne **segmenty** o różnych rozmiarach — segment kodu, danych, stosu. Naturalnie odpowiada strukturze programu. Ochrona jest naturalna — per segment mogę ustawić prawa R/W/X. + +Wada — **fragmentacja zewnętrzna**, bo segmenty są różnej wielkości. + +W praktyce — **stronicowanie wygrało**. x86-64 ma flat segmentation — segmenty obejmują całą przestrzeń, a faktyczna translacja idzie przez stronicowanie wielopoziomowe. Intel praktycznie porzucił segmentację. + +### Spodziewane pytania dodatkowe + +**„Co to copy-on-write?"** → Przy fork() dziecko dostaje tę samą pamięć co rodzic — ale strony są oznaczone jako read-only. Dopiero przy pierwszym zapisie robimy kopię. Oszczędność — bo często dziecko robi exec() i zmienia cały obraz. + +**„Dlaczego wielopoziomowe tablice stron?"** → Bo dla 64-bit jednopoziomowa tablica byłaby gigantyczna. Wielopoziomowa — alokujemy tylko te fragmenty tablicy, które naprawdę pokrywają używaną pamięć. + +--- + +\newpage + +## PYTANIE 11 · Modelowanie procesów biznesowych (WSYZ) + +**Pytanie:** *Scharakteryzować standardy i narzędzia do modelowania procesów biznesowych.* + +--- + +### Co mówię + +Standard numer jeden to **BPMN 2.0**. To jest to, co się pojawia wszędzie, gdzie biznes spotyka IT. + +BPMN ma trzy typy elementów. **Zdarzenia** — koła: start, pośrednie, końcowe. **Czynności** — prostokąty z zaokrąglonymi rogami: taski i podprocesy. **Bramki** — romby: XOR — jeden z wielu, AND — wszystkie ścieżki, OR — jeden lub więcej. + +[TABLICA: narysuj prosty proces BPMN — koło start → task → bramka XOR → dwa taski → koło end] + +Do tego — **swimlanes**: pool to organizacja, lane to dział wewnątrz. Pozwalają pokazać kto za co odpowiada. + +BPMN 2.0 ma format XML — to znaczy, że diagram nie jest tylko rysunkiem, może być wykonywany w silniku procesowym jak Camunda. + +Drugi standard — **diagramy aktywności UML**. Podobne do BPMN, ale bardziej zorientowane na IT. Mają fork/join dla współbieżności, pin-y dla przepływu obiektów. Lepsze do modelowania procesów technicznych, gorsze dla osób biznesowych. + +Trzeci — **EPC** (Event-driven Process Chain). Naprzemienne zdarzenia i funkcje, łączniki AND/OR/XOR. Popularny w ekosystemie SAP, framework ARIS. + +Porównanie: BPMN jest uniwersalny — łączy biznes z IT. UML Activity — głównie dla programistów. EPC — głównie SAP. + +Narzędzia: Bizagi Modeler, Camunda, Signavio, Lucidchart, draw.io, Enterprise Architect. + +### Spodziewane pytania dodatkowe + +**„Jaka jest różnica między bramką XOR a OR?"** → XOR — dokładnie jedna ścieżka. OR — jedna LUB więcej. AND — wszystkie. W praktyce XOR jest najczęstsza. + +**„Czy BPMN może być wykonywany automatycznie?"** → Tak, BPMN 2.0 ma format XML, który silniki procesowe — Camunda, jBPM — mogą interpretować i wykonywać. + +--- + +\newpage + +## PYTANIE 12 · Sieciowe modele optymalizacji (WSYZ) + +**Pytanie:** *Przedstawić sieciowe modele optymalizacji stosowane w systemach zarządzania.* + +--- + +### Co mówię + +Tutaj chodzi o problemy optymalizacyjne, które modelujemy na grafach. Wymienię kilka najważniejszych. + +[TABLICA: narysuj prosty graf z wagami] + +**Najkrótsza ścieżka** — klasyka. Dijkstra, Bellman-Ford, A\*. Zastosowanie — GPS, routing w sieciach. Omawialiśmy już wcześniej. + +**Maksymalny przepływ** — mam sieć z pojemnościami na krawędziach, chcę przepchnąć jak najwięcej ze źródła do ujścia. Algorytm Ford-Fulkersona, Edmonds-Karp. Zastosowanie — przepustowość sieci, planowanie produkcji. + +**Minimalny koszt przepływu** — jak max flow, ale oprócz pojemności każda krawędź ma koszt. Chcę przepchnąć wymaganą ilość po minimalnym koszcie. Transport, logistyka. + +**Problem przydziału** — n zadań do n pracowników, macierz kosztów, minimalizuj sumę. Algorytm węgierski, O(n³). HR, grafiki zmianowe. + +**TSP — problem komiwojażera** — odwiedź wszystkie miasta dokładnie raz, wróć do startu, minimalizuj trasę. NP-trudny — dokładne rozwiązanie nie skaluje się. W praktyce — heurystyki, metaheurystyki. Trasy kurierów. + +**CPM/PERT** — harmonogramowanie projektów. Wierzchołki to zadania, krawędzie to zależności. Ścieżka krytyczna — najdłuższa ścieżka w grafie — wyznacza minimalny czas projektu. + +**MST — minimalne drzewo rozpinające** — połącz wszystkie wierzchołki minimalnym kosztem. Kruskal, Prim. Sieci infrastrukturalne — kablowanie, wodociągi. + +Wspólny mianownik — to wszystko to grafy z wagami i pytanie „jak optymalnie wykorzystać tę sieć?" + +### Spodziewane pytania dodatkowe + +**„Jaka jest różnica między CPM a PERT?"** → CPM — deterministyczne czasy zadań. PERT — probabilistyczne, z trzema oszacowaniami (optymistyczny, pesymistyczny, prawdopodobny). + +**„Dlaczego TSP jest NP-trudny?"** → Nie znamy algorytmu wielomianowego. Brute force to O(n!) — nie skaluje się. Heurystyki dają przybliżone rozwiązania w rozsądnym czasie. + +--- + +\newpage + +## PYTANIE 13/27 · Modelowanie architektury systemów informatycznych (AIS) + +**Pytanie:** *Cele i metody modelowania architektury.* + +--- + +### Co mówię + +Modelowanie architektury to sposób na zarządzanie złożonością systemu. Cele — komunikacja między zespołami, dokumentacja decyzji, analiza atrybutów jakości, planowanie ewolucji. + +Kilka frameworków. + +**C4 Model** — bo jest najprostszy i najpopularniejszy. Simon Brown. Cztery poziomy zoomu: +Level 1 — Context: system w otoczeniu, kto z niego korzysta. +Level 2 — Container: główne komponenty — web app, baza danych, API. +Level 3 — Component: wewnątrz kontenera. +Level 4 — Code: klasy, kluczowe fragmenty. Zazwyczaj ten poziom to za dużo. + +[TABLICA: narysuj cztery kwadraciki, coraz bardziej szczegółowe — „zoom"] + +**4+1 View Model** Kruchtena. Pięć perspektyw: Logical — funkcjonalność, Process — współbieżność, Development — organizacja kodu, Physical — wdrożenie i sprzęt. I Scenarios — use-case'y, które to wszystko łączą. + +**TOGAF** — metodyka korporacyjna. ADM — Architecture Development Method. Cztery domeny: Business, Data, Application, Technology. Duży, formalny, enterprise. + +**Zachman Framework** — taksonomia. Tabela 6×6: What/How/Where/Who/When/Why na jednej osi, a poziomy abstrakcji na drugiej. Nie mówi JAK modelować, mówi CO trzeba opisać. + +**ArchiMate** — notacja graficzna dla architektury enterprise. Trzy warstwy: Business, Application, Technology. + +Do analizy — **ATAM**: ocena kompromisów architektonicznych, np. performance vs security. Atrybuty jakości z ISO 25010. + +### Spodziewane pytania dodatkowe + +**„Co to ADR?"** → Architecture Decision Record. Dokument opisujący jedną decyzję architektoniczną: kontekst, decyzja, konsekwencje. Lekka forma dokumentacji. + +**„Kiedy użyć C4 vs TOGAF?"** → C4 — projekty software'owe, dokumentacja techniczna. TOGAF — architektura korporacyjna, strategic planning, duże organizacje. + +--- + +\newpage + +## PYTANIE 14/28 · Wzorce architektoniczne (AIS) + +**Pytanie:** *Czemu służą? Jak powstają? Jak są katalogowane? Przykłady.* + +--- + +### Co mówię + +Wzorzec architektoniczny to sprawdzone rozwiązanie powtarzalnego problemu. Służą jako **wspólne słownictwo** — mówię „microservices" i każdy wie o co chodzi — oraz jako **przenoszenie wiedzy** między projektami. + +**Jak powstają?** Ktoś rozwiązuje problem. Inni rozwiązują podobne problemy podobnie. Ktoś to zauważa, uogólnia i **dokumentuje**. Struktura: Nazwa + Problem + Rozwiązanie + Konsekwencje. + +**Katalogi:** +- **GoF** — 23 wzorce projektowe, poziom klas i obiektów. +- **POSA** — wzorce architektoniczne, większa skala — Layers, Pipes and Filters, Broker. +- **PoEAA** Fowlera — wzorce dla aplikacji enterprise: Repository, Unit of Work, Active Record. +- **EIP** — Enterprise Integration Patterns — messaging. +- **Cloud Patterns** — Circuit Breaker, Saga, Sidecar. + +Przykłady wzorców architektonicznych: + +**Layered** — warstwy: prezentacja → logika → dostęp do danych → baza. Prosta separacja odpowiedzialności, ale sztywna i boilerplate. + +**Microservices** — niezależne serwisy, osobne wdrożenia, skalowanie per-serwis. Ogromna złożoność operacyjna. + +**Event-Driven** — zdarzenia przez broker (np. Kafka). Luźne powiązanie, eventual consistency. + +**Hexagonal / Ports & Adapters** — rdzeń logiki biznesowej niezależny od frameworków i baz danych. Porty to interfejsy, adaptery to implementacje. Świetna testowalność. + +Złota zasada — **„Monolith first."** Zacznij od monolitu, rozdzielaj gdy poznasz granice domen. + +### Spodziewane pytania dodatkowe + +**„Jaka jest różnica między wzorcem architektonicznym a projektowym?"** → Skala. Architektoniczny — struktura całego systemu (Layers, Microservices). Projektowy — struktura kodu (Strategy, Observer). Architektoniczny wpływa na deployment, zespoły, skalowanie. + +**„Co to CQRS?"** → Command Query Responsibility Segregation — osobne modele do odczytu i zapisu. Optymalizuję każdą stronę niezależnie. Przydatne gdy read i write mają bardzo różne wymagania. + +--- + +\newpage + +## PYTANIE 15 · Agent upostaciowiony w robotyce + +**Pytanie:** *Jak wykorzystuje się agenta upostaciowionego do specyfikacji sterowników robotów?* + +--- + +### Co mówię + +Agent upostaciowiony to agent, który ma ciało fizyczne — sensory, efektory — i działa w rzeczywistym środowisku. W odróżnieniu od agenta software'owego, musi radzić sobie z szumem sensorycznym, opóźnieniami i niepewnością. + +Cykl działania to: **Percepcja → Deliberacja → Akcja**. See-Think-Act. + +Do specyfikacji sterowników używa się architektury warstwowej — klasycznie trzy warstwy. + +[TABLICA: narysuj trzy prostokąty jeden nad drugim] + +Na dole — **Controller** — warstwa reaktywna. PID, unikanie kolizji, sterowanie silnikami. Działa w milisekundach. Nie „myśli", reaguje. + +W środku — **Sequencer** — zarządza sekwencją zachowań. FSM albo Behavior Tree. Decyduje: teraz jedziemy do punktu A, potem chwytamy, potem wracamy. Skala: setki milisekund. + +Na górze — **Planner** — planowanie symboliczne. Zna mapę, zna cel, tworzy plan. Skala: sekundy do minut. + +Do formalnej specyfikacji celów i bezpieczeństwa używa się **logiki temporalnej LTL**. Mogę zapisać: „zawsze, gdy jest przeszkoda, nie jedź do przodu" — □(obstacle → ¬move_forward). Albo „ostatecznie dotrzesz do celu" — ◇(at_goal). Te formuły mogą być formalnie weryfikowane. + +Nowocześnie — **Behavior Trees** stały się popularnym narzędziem specyfikacji. Selector — wykonaj pierwszy sukces. Sequence — wykonaj wszystkie po kolei. Czytelne, modularne, łatwe do wizualizacji. Wywodzą się z game AI — Halo 2 — ale zaadaptowano je w robotyce. + +Model formalny agenta — BDI: Beliefs — co wiem o świecie, Desires — czego chcę, Intentions — co aktualnie realizuję. + +### Spodziewane pytania dodatkowe + +**„Co to PID?"** → Regulator proporcjonalno-całkująco-różniczkujący. Trzy składniki: P — proporcjonalny do błędu, I — kumulowany błąd, D — szybkość zmiany błędu. Klasyka sterowania. + +**„Czym jest ROS?"** → Robot Operating System — middleware pub/sub do komunikacji między modułami robota. Nie jest OS-em w sensie jądra, ale daje abstrakcję komunikacji. + +--- + +\newpage + +## PYTANIE 16 · Języki programowania robotów + +**Pytanie:** *Omówić specjalizowane języki. Uwypuklić klasyfikację.* + +--- + +### Co mówię + +Klasyfikuję języki robotów po **poziomie abstrakcji** — od najwyższego do najniższego. + +[TABLICA: napisz piramidkę — T-R-M-S] + +**Task-level** — najwyższy. Mówię „podnieś A, połóż na B" — system sam planuje ruchy. PDDL, Behavior Trees. Planowanie zadań. + +**Robot-level** — komendy ruchu robota: move_to, grasp, release. Każdy producent ma swój język. ABB — RAPID (MoveJ, MoveL, MoveC). KUKA — KRL (PTP, LIN, CIRC). FANUC — Karel. To jest podejście imperatywne — mówię robotowi co ma robić ruch po ruchu. + +**Motion-level** — planowanie trajektorii, kinematyka odwrotna. Biblioteka MoveIt w ROS. Tutaj programista operuje na poziomie „dojedź z pozycji A do B bez kolizji", ale system musi obliczyć konkretną trajektorię. + +**Servo-level** — najniższy, sterowanie silnikami. PID, regulacja prądu, pozycji. C/C++, FPGA. Czas rzeczywisty. + +Jest też podział na **online vs offline**. Online — uczę robota przy konsoli (teach pendant), prowadzę go ręcznie. Offline — programuję w symulatorze na komputerze, potem wgrywam. + +Problem branży — **vendor lock-in**. Każdy producent ma swój język — RAPID, KRL, Karel, PDL2. Nie są kompatybilne. ROS próbuje to ujednolicić jako warstwa abstrakcji, ale ma problem z hard real-time. + +Programowanie graficzne — RobotStudio dla ABB, ROBOGUIDE dla FANUC. I Blockly w edukacji. + +Ciekawostka etymologiczna: język Karel nazwano od Karla Čapka, czeskiego pisarza, który wymyślił słowo „robot" — od czeskiego „robota" — pańszczyzna. + +### Spodziewane pytania dodatkowe + +**„Czym się różni PTP od LIN w KUKA?"** → PTP — Point-to-Point — robot jedzie najszybszą drogą, nie kontroluję trajektorii. LIN — ruch liniowy — efektor jedzie po linii prostej. CIRC — ruch kołowy. + +**„Czy ROS rozwiązuje problem vendor lock-in?"** → Częściowo. ROS daje wspólną warstwę komunikacji i planowania, ale sterownik nisko poziomowy nadal jest producenta. Oraz ROS nie jest hard real-time w standardowym wydaniu (ROS 2 poprawia to z DDS). + +--- + +\newpage + +## PYTANIE 17 · Szeregowanie zadań + +**Pytanie:** *Cechy klasyfikacji. Przykładowa metoda.* + +--- + +### Co mówię + +Problemy szeregowania klasyfikuje się przez **notację Grahama**: alfa | beta | gamma. + +[TABLICA: napisz α | β | γ] + +**α** — środowisko maszynowe. 1 — jedna maszyna. Pm — m maszyn równoległych. F — flow shop, wszyscy przechodzą przez maszyny w tej samej kolejności. J — job shop, każde zadanie ma własną trasę. + +**β** — cechy zadań. rⱼ — release dates, dⱼ — due dates, pmtn — preemption dozwolona, prec — precedencje. + +**γ** — kryterium optymalizacji. Cmax — makespan, czas zakończenia ostatniego. ΣCⱼ — suma czasów zakończenia. Lmax — maksymalne opóźnienie. + +Pokażę na przykładzie. + +[TABLICA: problem 1 || ΣCⱼ] + +Mam jedną maszynę, pięć zadań z czasami: J1(5), J2(3), J3(8), J4(2), J5(6). Chcę zminimalizować sumę czasów zakończenia. + +Reguła **SPT** — Shortest Processing Time — uszereguj od najkrótszego. + +Sortujemy: J4(2), J2(3), J1(5), J5(6), J3(8). +Czasy zakończenia: 2, 5, 10, 16, 24. +ΣCⱼ = 2+5+10+16+24 = 57. To jest optymalne! + +[TABLICA: narysuj oś czasu z zadaniami] + +Dlaczego to działa? Intuicja — krótkie zadania kończą się wcześnie i „nie czekają" na długie. Formalnie — zamiana sąsiednich zadań, gdzie krótsze jest za długim, zawsze zwiększa sumę. + +Inne reguły: **EDD** — Earliest Due Date — dla Lmax. **Johnson** — optymalny dla dwumaszynowego flow shop. + +Większość problemów szeregowania jest **NP-trudna** — job shop, Pm||Cmax dla m≥2. + +### Spodziewane pytania dodatkowe + +**„Co to makespan?"** → Czas od startu pierwszego zadania do zakończenia ostatniego. Mierzy „jak długo trwa cała produkcja". + +**„Czym się różni flow shop od job shop?"** → Flow shop — wszystkie zadania przechodzą przez maszyny w tej samej kolejności, jak taśma produkcyjna. Job shop — każde zadanie ma indywidualną trasę, jak warsztat naprawczy. + +--- + +\newpage + +## PYTANIE 18 · Zarządzanie zapasami w łańcuchu dostaw + +**Pytanie:** *Problemy i przykładowy model.* + +--- + +### Co mówię + +Główny problem — znalezienie równowagi. Za dużo zapasów — koszty magazynowania, pieniądze zamrożone, ryzyko przeterminowania. Za mało — brak towaru, utracona sprzedaż. + +Klasyczny problem — **efekt byczego bicza** (bullwhip effect). Małe wahania popytu u detalistów narastają w górę łańcucha — dystrybutor zamawia więcej, producent jeszcze więcej, dostawca surowców widzi gigantyczne wahania. Przyczyny — prognozowanie, zamówienia partiami, promocje. + +[TABLICA: narysuj sinusoidę, która się amplifikuje — detalista → dystrybutor → producent] + +Podstawowy model — **EOQ** — Economic Order Quantity. Harrisowsko-Wilsonowski. + +[TABLICA: napisz wzór] + +TC(Q) = K·D/Q + h·Q/2 + +K — koszt zamówienia, D — popyt roczny, h — koszt utrzymania jednostki na rok, Q — wielkość zamówienia. + +Optymalna wielkość: **Q\* = √(2KD/h)** + +Przykład: D=10000, K=100, h=2. Q\* = √(2·100·10000/2) = √(1000000) = 1000 sztuk. Koszt optymalny — 2000 PLN/rok. + +Jest jeszcze **punkt ponownego zamawiania** — ROP = d × L + SS. Popyt dzienny razy lead time plus safety stock. Safety stock zależy od poziomu obsługi — na 95% bierzemy z=1.65, mnożymy przez odchylenie popytu w czasie dostawy. + +Modele zaawansowane: (s,Q) — zamawiaj Q gdy stan spadnie do s. (s,S) — zamawiaj do poziomu S. VMI — dostawca sam zarządza zapasem u klienta. + +### Spodziewane pytania dodatkowe + +**„Jakie są założenia EOQ?"** → Popyt stały i znany, lead time zero lub stały, brak rabatów ilościowych, dostawy jednorazowe. Bardzo uproszczony model, ale daje dobre intuicje. + +**„Jak ograniczyć bullwhip effect?"** → Dzielenie danych o popycie w czasie rzeczywistym (POS data), VMI, mniejsze partie zamówień, stabilne ceny bez promocji. + +--- + +\newpage + +## PYTANIE 19/29 · Model Publish-Subscribe + +**Pytanie:** *Scharakteryzować model i przykładowe rozwiązania techniczne.* + +--- + +### Co mówię + +Pub/Sub to wzorzec komunikacji, w którym nadawcy nie wysyłają wiadomości bezpośrednio do odbiorców. Między nimi jest **broker**. + +[TABLICA: narysuj] + + Publishers → [Broker] → Subscribers + +Publisher mówi „oto zdarzenie", a broker dostarcza je wszystkim zainteresowanym subskrybentom. Kluczowa cecha — **luźne powiązanie**: publisher nie wie kto słucha, subscriber nie wie kto wysyła. Jak stacja radiowa — nadaje, kto chce słucha. + +Typy subskrypcji: **topic-based** — subskrybuję temat, np. „orders.created". **Content-based** — filtracja po zawartości wiadomości. Hierarchiczne tematy z wildcardami — np. „orders.#" łapie wszystko z prefiksem. + +Gwarancje dostarczenia — QoS. At-most-once — mogę stracić wiadomość. At-least-once — mogą być duplikaty. Exactly-once — najdroższa gwarancja, ale najtrudniejsza do osiągnięcia. + +Teraz konkretne technologie. + +**Kafka** — model oparty na logu. Producer pisze do partycji, consumer czyta z offsetu. Pull model — consumer sam decyduje kiedy czyta. Persistence domyślnie — mogę odtworzyć strumień. Very high throughput. Consumer groups — load balancing. LinkedIn, potem Apache. + +**RabbitMQ** — AMQP, push model. Exchange types: Direct, Topic, Fanout, Headers. Bardziej elastyczny routing, ale wiadomości znikają po konsumpcji. Tradycyjny message broker. + +**MQTT** — lekki, 2-bajtowy header. Idealny dla IoT, urządzenia z ograniczonymi zasobami. Trzy poziomy QoS. + +**Redis Pub/Sub** — prosty, szybki, ale fire-and-forget — brak persistence. Dobre do real-time notyfikacji. + +### Spodziewane pytania dodatkowe + +**„Kafka vs RabbitMQ — kiedy co?"** → Kafka — event streaming, duże wolumeny, replay, analityka. RabbitMQ — task queues, złożony routing, tradycyjny messaging. Kafka to log, RabbitMQ to kolejka. + +**„Co jeśli broker padnie?"** → Broker to Single Point of Failure. Rozwiązanie — replication, clustering. Kafka ma replication factor, RabbitMQ ma mirrored queues. + +--- + +\newpage + +## PYTANIE 20/30 · Analityka danych strumieniowych + +**Pytanie:** *Rozwiązania analityczne na danych strumieniowych.* + +--- + +### Co mówię + +Strumień danych to dane, które płyną ciągle, potencjalnie w nieskończoność. Nie mogę zebrać wszystkiego i przetworzyć — muszę analizować na bieżąco. + +Kluczowy koncept — **okna czasowe** (windowing). + +[TABLICA: narysuj oś czasu z oknami] + +**Tumbling** — rozłączne okna stałego rozmiaru. Każde zdarzenie należy do dokładnie jednego okna. Np. liczba zdarzeń co minutę. + +**Sliding** — nakładające się okna. Rozmiar 10 minut, przesunięcie co 1 minutę. Zdarzenie może być w wielu oknach. + +**Session** — definiowane aktywnością. Okno trwa dopóki są zdarzenia, zamyka się po przerwie (gap). + +**Global** — jedno wielkie okno, trigger decyduje kiedy emitować wynik. + +Platformy: + +**Apache Flink** — true streaming, przetwarza zdarzenie po zdarzeniu. Bardzo niska latencja, exactly-once guarantees. SOTA do stream processingu. Nazwa — z niemieckiego „flink" = szybki. + +**Spark Streaming** — micro-batch. Zbiera zdarzenia w małe paczki i przetwarza. Latencja ~100ms. Prostszy model programowania, łatwo przejść z batcha. + +**Kafka Streams** — biblioteka, nie klaster. Wbudowana w Kafkę. Lekka, nie wymaga osobnej infrastruktury. + +Problem czasu — **Event Time vs Processing Time**. Zdarzenie powstaje o 12:00, dociera o 12:05 — który czas liczymy? Watermarki mówią systemowi „do tego momentu powinny dotrzeć wszystkie zdarzenia". Spóźnione dane — drop, przeliczymy, boczny output. + +Algorytmy strumieniowe — gdy nie ma pamięci na wszystko. **HyperLogLog** — zlicz unikalne elementy z kilobajtem pamięci, ~2% błąd. **Count-Min Sketch** — estymacja częstości. **Reservoir Sampling** — losowa próbka z nieznanego strumienia. + +### Spodziewane pytania dodatkowe + +**„Czym jest watermark?"** → Znacznik postępu event time. Mówi: „wszystkie zdarzenia z czasem mniejszym niż W już dotarły." Spóźnione — traktujemy wg strategii: ignoruj, przelicz, side output. + +**„Micro-batch vs true streaming?"** → Micro-batch zbiera dane w małe paczki i przetwarza periodycznie — prostsza semantyka, ale wyższe latencje. True streaming — przetwarza per wydarzenie — niższa latencja, ale bardziej skomplikowana obsługa stanu i exactly-once. + +--- + +\newpage + +## PYTANIE 21 · Zegary logiczne i wektory stempli czasowych + +**Pytanie:** *Koncepcja i przeznaczenie.* + +--- + +### Co mówię + +W systemach rozproszonych nie ma globalnego zegara. Każdy węzeł ma swój zegar i one się rozjeżdżają — drift, opóźnienia sieciowe. Nie możemy powiedzieć „to zdarzenie było pierwsze" patrząc na czas ścienny. + +Lamport w 1978 roku zaproponował rozwiązanie — **relacja happened-before**. Zapisuję ją jako →. + +Reguły: jeśli a jest przed b w tym samym procesie — a → b. Jeśli a to wysłanie wiadomości, a b to jej odbiór — a → b. I przechodniość. Jeśli nie mogę ustalić porządku — zdarzenia są **współbieżne**, a || b. + +**Zegar Lamporta** — skalarny. Każdy proces ma licznik C. Przed zdarzeniem — inkrementuję. Wysyłając — dołączam C do wiadomości. Odbierając — biorę max ze swojego C i odebranego, i inkrementuję. + +[TABLICA: narysuj trzy procesy, strzałki wiadomości, dopisz wartości zegara] + +Problem — zegar Lamporta gwarantuje: jeśli a → b, to C(a) < C(b). Ale **nie odwrotnie**! Jeśli C(a) < C(b), nie wiem czy a → b, czy są współbieżne. Nie wykrywa współbieżności. + +**Zegary wektorowe** rozwiązują ten problem. Każdy z N procesów trzyma wektor V[1..N]. Przed zdarzeniem — V[i]++. Wysyłając — dołączam cały wektor. Odbierając — V[j] = max(V[j], T[j]) dla wszystkich j, potem V[i]++. + +Kluczowa właściwość: **a → b ⟺ V(a) < V(b)**. Równoważność! Jeśli wektory są nieporównywalne — zdarzenia są współbieżne. + +Porównanie wektorów: V ≤ W wtedy gdy V[i] ≤ W[i] dla każdego i. Współbieżne — gdy ani V ≤ W, ani W ≤ V. + +Cena — wektor ma rozmiar O(N). Lamport — O(1). Dla małych systemów nieistotne, dla tysięcy procesów — problematyczne. + +Zastosowania — wykrywanie konfliktów w replikacji (Amazon Dynamo), causal broadcast, debugowanie rozproszone. + +### Spodziewane pytania dodatkowe + +**„Co to version vectors w Dynamo?"** → Wariant zegarów wektorowych do śledzenia wersji obiektów w replikowanej bazie. Pozwalają wykryć konflikty — jeśli wektory nieporównywalne, to dwa węzły pisały niezależnie. + +**„Czy da się coś między Lamportem a vector clock?"** → Tak — np. dotted version vectors, albo Bloom clocks — hybrydowe podejścia, które oszczędzają pamięć przy zachowaniu wykrywania współbieżności. + +--- + +\newpage + +## PYTANIE 22 · Modele spójności danych w systemach rozproszonych + +**Pytanie:** *Silne i słabe modele spójności.* + +--- + +### Co mówię + +To pytanie o kompromis — im silniejsza spójność, tym wolniejszy system. Im słabsza — tym szybszy, ale trudniejszy do programowania. + +[TABLICA: narysuj spektrum od lewej do prawej] + + Linearizability → Sequential → Causal → Session → Eventual + +**Linearizability** — najsilniejsza. Każda operacja wygląda tak, jakby wykonała się atomowo w jednym momencie między wywołaniem a odpowiedzią. Globalny czas rzeczywisty. Kosztowna — wymaga konsensusu. Przykład — Google Spanner, który synchronizuje atomowe zegary. + +**Sequential consistency** — jest globalny porządek operacji, zgodny z porządkiem programu każdego procesu, ale NIE musi zgadzać się z czasem rzeczywistym. Przykład — ZooKeeper. + +**Causal consistency** — operacje przyczynowo zależne widziane w tej samej kolejności przez wszystkich. Niezależne — mogą być w różnej kolejności. Wymaga vector clocks. + +**Session guarantees** — słabsze: Read Your Writes — widzę to co napisałem. Monotonic Reads — nie cofam się w czasie. + +**Eventual consistency** — najsłabsza. Jeśli przestanę pisać, to kiedyś wszystkie repliki się zsynchronizują. Ale nie wiadomo kiedy. DNS, Cassandra, DynamoDB. + +**CAP Theorem** — w obliczu partycji sieciowej muszę wybrać: Consistency albo Availability. Nie mogę mieć obu. CP — np. Spanner, silna spójność, ale niedostępny przy partycji. AP — np. Cassandra, zawsze dostępna, ale eventual. + +Konflikty w modelu eventual rozwiązuję przez: Last-Writer-Wins, porównanie wersji, albo **CRDTs** — struktury, które matematycznie gwarantują, że po zsynchronizowaniu dają ten sam wynik niezależnie od kolejności. + +### Spodziewane pytania dodatkowe + +**„Czy CAP to wybór 2 z 3?"** → W praktyce — partycja się zdarzy, więc to nie „wybierz 2 z 3", tylko „przy partycji: C czy A?" Normaltynie system ma C i A, problem pojawia się przy awarii sieci. + +**„Co to quorum?"** → W replikacji — W+R > N gwarantuje, że odczyt trafi na co najmniej jedną replikę z najnowszą wersją. Np. N=3, W=2, R=2. + +--- + +\newpage + +## PYTANIE 23 · Segmentacja obrazu + +**Pytanie:** *Problem, strategie klasyczne i sieci neuronowe.* + +--- + +### Co mówię + +Segmentacja to przypisanie **każdemu pikselowi** etykiety klasy lub regionu. W odróżnieniu od klasyfikacji — która mówi „co jest na zdjęciu" — segmentacja mówi **gdzie** dokładnie. + +Typy: **Semantic** — klasa per piksel, wszystkie samochody to „samochód". **Instance** — rozróżnia poszczególne instancje, ten samochód od tamtego. **Panoptic** — łączy oba. + +Metody klasyczne: + +**Thresholding** — próg intensywności. Piksele powyżej progu — obiekt, poniżej — tło. Otsu automatycznie dobiera próg. Proste, ale ograniczone do dwóch klas. + +**Region growing** — zaczynam od punktu seed, dodaję sąsiednie piksele spełniające kryterium podobieństwa. Tendencja do over-segmentation. + +**Watershed** — traktujemy obraz jako teren topograficzny i „zalewamy wodą". Granice — tam, gdzie woda z różnych źródeł się spotyka. + +Deep learning — tu nastąpił przełom: + +**U-Net** — encoder-decoder w kształcie U. Encoder kompresuje obraz, decoder odtwarza rozdzielczość. Kluczowe — **skip connections** — łączą warstwy o tej samej rozdzielczości z encodera do decodera. Popularne w medycynie — mało danych, ale skip connections pomagają zachować detale. + +**DeepLab** — atrous (dilated) convolutions — powiększają receptive field bez dodatkowych parametrów. ASPP — multi-scale processing. + +**Metryka** — mIoU: intersection over union, uśrednione po klasach. Standard w benchmarkach. + +[TABLICA: narysuj kształt litery U z prostokątów — encoder po lewej, decoder po prawej, strzałki skip] + +### Spodziewane pytania dodatkowe + +**„Co to dilated convolution?"** → Normalna konwolucja ma filtr 3×3 pokrywający 3×3 pikseli. Dilated — filtr 3×3, ale z przerwami — widzi np. 5×5 lub 7×7 pikseli. Większe receptive field przy tych samych parametrach. + +**„Dlaczego U-Net jest popularne w medycynie?"** → Bo wymaga mało danych treningowych — skip connections zachowują informacje przestrzenne. Obrazy medyczne są drogie do annotacji, więc data efficiency jest kluczowa. + +--- + +\newpage + +## PYTANIE 24 · Detekcja obiektów + +**Pytanie:** *Problem, metody klasyczne, deep learning. Jak zbudować detektor z klasyfikatora?* + +--- + +### Co mówię + +Detekcja obiektów to jednoczesna **lokalizacja** (bounding box) i **klasyfikacja**. Wynik: klasa, współrzędne ramki, pewność. + +Podejścia dzielę na dwa etapy — two-stage i one-stage. + +**Two-stage — rodzina R-CNN:** + +R-CNN — generuję ~2000 regionów przez Selective Search, każdy region przepuszczam przez CNN, klasyfikuję SVM-em. Bardzo wolne — 50 sekund na obraz. + +Fast R-CNN — CNN raz na cały obraz, potem ROI Pooling — wycinam cechy regionu z mapy cech. ~2 sekundy. + +**Faster R-CNN** — kluczowy krok — Region Proposal Network. Zamiast Selective Search — sieć sama proponuje regiony. End-to-end. ~5 fps. + +[TABLICA: obraz → CNN → RPN → ROI Pool → klasyfikacja + bbox regression] + +**One-stage — YOLO, SSD:** + +**YOLO** — You Only Look Once. Dzielę obraz na siatkę S×S, każda komórka predykuje bounding boxy i klasy naraz, w jednym przebiegu sieci. 45-155 fps! Rewolucja w szybkości. Gorszy dla małych obiektów, ale kolejne wersje to poprawiaj. + +Po detekcji — **NMS** — Non-Maximum Suppression. Mam wiele nakładających się detekcji tego samego obiektu. Sortuję po confidence, biorę najlepszą, usuwam te, które się z nią mocno nakładają (IoU > próg), powtarzam. + +Teraz — **jak zbudować detektor z klasyfikatora?** + +Trzy sposoby, coraz lepsze: +1. **Sliding window** — przesuwam okno, każdy patch klasyfikuję. Ekstremalnie wolne. +2. **Region proposals + klasyfikator** — Selective Search wysiewa kandydatów, klasyfikuję każdego. Szybsze, ale wciąż oddzielne kroki. +3. **Fine-tune** — biorę pretrained klasyfikator jako backbone, doczepiam głowicę detekcyjną — bbox regression + klasyfikacja. End-to-end. Najlepsza jakość. + +### Spodziewane pytania dodatkowe + +**„YOLO vs Faster R-CNN — kiedy co?"** → YOLO — gdy zależy na szybkości — real-time, wideo, edge computing. Faster R-CNN — gdy zależy na dokładności, zwłaszcza dla małych obiektów. + +**„Co to anchor boxes?"** → Predefiniowane kształty ramek o różnych proporcjach. Sieć nie predykuje ramki od zera — predykuje offset od najbliższego anchora. Anchor-free (np. YOLOv8) — bez tego, predykuje punkt centralny i wymiary. + +--- + +\newpage + +## PYTANIE 25 · Prawo Amdahla — przyspieszenie równoległe + +**Pytanie:** *Oszacować przyspieszenie. Co osłabia ograniczenie?* + +--- + +### Co mówię + +Prawo Amdahla mówi, ile zyskam dodając procesory. + +[TABLICA: napisz wzór] + + S(n) = 1 / ((1−p) + p/n) + +p — część kodu, która może być zrównolegloona. n — liczba procesorów. 1−p — część sekwencyjna. + +Kluczowe — przy n dążącym do nieskończoności: + + S_max = 1 / (1−p) + +Jeśli 10% kodu jest sekwencyjne — maksymalne przyspieszenie to 10x. Nawet z milionem procesorów. Sekwencyjna część jest limitem. + +[TABLICA: szybka tabelka] + +| p | n=4 | n=16 | n→∞ | +|------|------|------|------| +| 90% | 3.08 | 5.93 | 10 | +| 95% | 3.48 | 9.52 | 20 | +| 99% | 3.88 |13.91 | 100 | + +To jest dość pesymistyczna perspektywa. **Co osłabia to ograniczenie?** + +**Prawo Gustafsona** — zmień perspektywę. Amdahl mówi: stały problem, więcej procesorów. Gustafson mówi: stały czas, **większy problem**. S = 1 − p + p·n. Dla p=90%, n=100 → S=90.1. Bo w praktyce — gdy mam więcej procesów, daję im więcej danych do przetwarzania, a nie ten sam mały problem. + +Techniki zmniejszania sekwencyjnej części: algorytmy równoległe (zamiast sekwencyjnych), lock-free structures (zamiast mutexów), pipelining, ukrywanie latencji — async I/O, prefetching. + +Ale w praktyce przyspieszenie jest jeszcze gorsze niż Amdahl przewiduje — overhead synchronizacji, komunikacja, load imbalance, efekty cache (false sharing). + +### Spodziewane pytania dodatkowe + +**„Jaka jest różnica między strong scaling a weak scaling?"** → Strong — stały problem, dodaję procesory. Amdahl. Weak — zwiększam problem proporcjonalnie do procesorów. Gustafson. W HPC — weak scaling jest bardziej realistyczny. + +**„Co to false sharing?"** → Dwa wątki piszą do różnych zmiennych, ale tych samych cache lines. CPU unieważnia cache lines nawzajem — ogromne spowolnienie, mimo braku logicznego konfliktu. + +--- + +\newpage + +## PYTANIE 26 · Komunikacja synchroniczna/asynchroniczna, blokująca/nieblokująca + +**Pytanie:** *Definicje. Jak uniknąć zakleszczenia w symetrycznych procesach (Jacobi)?* + +--- + +### Co mówię + +Dwa wymiary — i ludzie je często mylą. + +**Synchroniczna vs asynchroniczna** — dotyczy tego, czy nadawca czeka na odbiorcę. Synchroniczna — nadawca czeka aż odbiorca przyjmie wiadomość. Asynchroniczna — nadawca wrzuca do bufora i jedzie dalej. + +**Blokująca vs nieblokująca** — dotyczy tego, czy funkcja wraca od razu. Blokująca — nie wraca dopóki operacja nie skończona. Nieblokująca — wraca natychmiast, operacja w tle, sprawdzam wynik później. + +W MPI: MPI_Send — blokująca, synchroniczność zależy od implementacji. MPI_Ssend — blokująca synchroniczna. MPI_Isend — nieblokująca. „I" od Immediate. + +Teraz — **problem zakleszczenia w symetrycznym kodzie**. + +[TABLICA: narysuj dwa procesy i strzałki] + + Proc 0: Send(to=1); Recv(from=1); + Proc 1: Send(to=0); Recv(from=0); + +Oba robią Send jako pierwsze. Oba czekają aż partner odbierze. Nikt nie robi Recv. **Deadlock.** + +**Rozwiązania:** + +Pierwsze — **asymetria**. Proc 0: Send → Recv. Proc 1: Recv → Send. Jeden wysyła pierwszy, drugi odbiera pierwszy. Prosty, działa. + +Drugie — **nieblokujące**. Oba robią Irecv + Isend + Wait. Isend i Irecv wracają natychmiast, inicjują operacje w tle, Wait czeka na zakończenie obu. Symetryczny kod, zero deadlocków. + +Trzecie — **MPI_Sendrecv** — jedna funkcja, która jednocześnie wysyła i odbiera. Implementacja dba żeby nie było zakleszczenia. Najprostsze rozwiązanie. + +Czwarte — **Bsend** — buforowane. Kopiuje dane do bufora i wraca. Nie czeka na odbiorcę. + +### Spodziewane pytania dodatkowe + +**„Co to metoda Jacobiego i dlaczego ma ten problem?"** → Metoda iteracyjna rozwiązywania układów równań. W wersji równoległej — każdy proces liczy swoją część i wymienia wyniki z sąsiadami. Symetryczny wzorzec — wszyscy robią to samo — stąd ryzyko Send-Send deadlocka. + +**„Kiedy użyć Isend vs Ssend?"** → Isend — gdy chcę nakładać komunikację z obliczeniami. Ssend — gdy potrzebuję pewności, że odbiorca odebrał (np. protokół synchroniczny). + +--- + +\newpage + +## PYTANIE 31 · Interaktywne wspomaganie decyzji w warunkach ryzyka + +**Pytanie:** *Przedstawić metody interaktywne.* + +--- + +### Co mówię + +„Warunki ryzyka" — znamy prawdopodobieństwa wyników, ale nie wiemy na pewno co się stanie. W odróżnieniu od pewności — gdzie wiem dokładnie — i niepewności — gdzie nie znam nawet prawdopodobieństw. + +„Interaktywne" — kluczowe słowo. Nie narzucamy decydentowi wyniku. Prowadzamy **dialog** — odkrywamy jego preferencje, funkcję użyteczności — i na tej podstawie rekomendujemy. + +**Metoda loterii** — najprostsza. Ustalam U(worst)=0, U(best)=1. Pytam: „wolisz x na pewno, czy loterię — z prawdopodobieństwem p najlepszy wynik, z 1−p najgorszy?" Punkt obojętności p\* = U(x). Powtarzam dla kilku wartości x — otrzymuję kształt funkcji użyteczności. + +**Certainty Equivalent** — CE loterii to pewna kwota, której wartość dla decydenta jest taka sama jak loterii. Jeśli CE < wartość oczekiwana — decydent jest **risk-averse**, ma wklęsłą funkcję użyteczności. CE > E[X] — risk-seeking. + +**AHP** — Analytic Hierarchy Process Saaty'ego. Strukturyzuję problem jako hierarchię: cel na górze, kryteria w środku, alternatywy na dole. Porównuję parami w skali 1–9. Z macierzy porównań wyciągam wagi — eigenvalue. Sprawdzam spójność — CR < 0.1. + +[TABLICA: narysuj hierarchię — Cel → Kryteria → Alternatywy] + +**PROMETHEE** — definiuję funkcje preferencji per kryterium. Obliczam przepływy: Φ⁺ — ile razy alternatywa dominuje inne, Φ⁻ — ile razy jest dominowana. Φ net = Φ⁺ − Φ⁻. Ranking. + +**ELECTRE** — concordance (na ile kryteriów A jest lepsza od B) plus discordance (jak bardzo B jest lepsza w najgorszym kryterium). Outranking: A S B. + +### Spodziewane pytania dodatkowe + +**„Czym jest risk premium?"** → E[X] − CE. Ile decydent „zapłaci" za pozbycie się ryzyka. Risk-averse → premium > 0. + +**„Kiedy AHP a kiedy PROMETHEE?"** → AHP — gdy mogę porównać parami, niewielu kryteriów i alternatyw. PROMETHEE — gdy mam więcej danych ilościowych i chcę ranking z przepływami. + +--- + +\newpage + +## PYTANIE 32 · Dominacja stochastyczna + +**Pytanie:** *FSD i SSD. Jak mogą być użyte w modelach wyboru?* + +--- + +### Co mówię + +Dominacja stochastyczna pozwala porównać dwie inwestycje — dwa rozkłady wyników — **bez znajomości dokładnej funkcji użyteczności**. Jeśli A dominuje B, to każdy racjonalny decydent z danej klasy wybierze A. + +**FSD — First-order Stochastic Dominance.** + +[TABLICA: narysuj dwie dystrybuanty, F_A zawsze poniżej F_B] + +A dominuje B w sensie FSD wtedy gdy dystrybuanta A nie jest wyższa od B w żadnym punkcie: F_A(x) ≤ F_B(x) dla każdego x. + +Interpretacja — A daje **zawsze nie mniejsze prawdopodobieństwo** przekroczenia dowolnego progu. Potrzebuję tylko jednego założenia o U: U' ≥ 0, czyli „więcej = lepiej". Klasa: wszyscy racjonalni, nienasyceni. + +FSD jest **rzadka** w praktyce — dystrybuanty nie mogą się przecinać. + +**SSD — Second-order Stochastic Dominance.** + +A dominuje B wtedy gdy **całka** z dystrybuanty A nie przekracza całki z B — dla każdego x. Dystrybuanty **mogą się przecinać**, ale skumulowane pole pod F_A musi być nie większe. + +Wymaganie na U: U' ≥ 0 i U'' ≤ 0 — monotoniczne i wklęsłe. Klasa: decydenci z **awersją do ryzyka.** + +SSD jest znacznie **częstsza** niż FSD. + +Relacja: FSD implikuje SSD, ale nie odwrotnie. + +**Zastosowania w modelach wyboru:** + +Selekcja portfeli — mogę wyeliminować zdominowane portfele bez pytania o U. Jeśli A SSD-dominuje B, to żaden risk-averse decydent nie wybierze B. Redukuję zbiór rozwiązań. + +Ubezpieczenia — fair ubezpieczenie SSD-dominuje brak ubezpieczenia dla risk-averse. Mean-preserving spread — B = A + szum o zerowej wartości oczekiwanej → A SSD B. + +Evaluacja inwestycji — A ma wyższy zwrot i mniejsze ryzyko niż B → A SSD B. + +### Spodziewane pytania dodatkowe + +**„Co to mean-preserving spread?"** → Dodaję losowy szum o średniej zero do rozkładu — zachowuję średnią, ale zwiększam rozproszenie. Dla risk-averse — to gorsze. Stąd rozkład bez szumu SSD-dominuje ten z szumem. + +**„Czy FSD/SSD daje pełne uporządkowanie?"** → Nie — to porządek częściowy. Wiele par alternatyw jest nieporównywalnych. To nie jest ranking — to filtr eliminacyjny. + +--- + + diff --git a/pytania/STUDY_PLAN.md b/pytania/STUDY_PLAN.md new file mode 100644 index 0000000..1456beb --- /dev/null +++ b/pytania/STUDY_PLAN.md @@ -0,0 +1,335 @@ +# Plan nauki — Obrona magisterska (1 marca 2026) + +> **Start:** 14 lutego (sobota) | **Obrona:** 1 marca (niedziela) +> **Dni nauki:** 15 (Feb 14–28) | **Pytań:** 28 +> **Szacowany całkowity czas nauki:** ~63h + +--- + +## Harmonogram tygodnia i dostępny czas + +| Dzień | Tryb pracy | Czas na naukę | +|--------------|-------------|----------------------------------------------------| +| **Poniedziałek** | Zdalnie | ~3h wieczorem po pracy | +| **Wtorek** | Biuro | 2h dojazd (transport publiczny → Anki/czytanie) + 1.5h wieczór | +| **Środa** | Biuro | 2h dojazd + 1.5h wieczór | +| **Czwartek** | Zdalnie | ~3h wieczorem po pracy | +| **Piątek** | Biuro | 2h dojazd + 1.5h wieczór | +| **Sob/Niedz** | Wolne | ~6h solidnej nauki | + +--- + +## Budżet czasu + +| Typ dnia | Dni | h/dzień | Suma | +|--------------------|------|---------|-------| +| Weekend | 5 | 6h | 30h | +| Praca zdalna | 4 | 3h | 12h | +| Praca biuro | 6 | 3.5h | 21h | +| **RAZEM** | **15** | | **63h** | + +Podział: ~40h na 1. przejście (nauka) + ~17h na powtórkę + ~6h na mock defense. + +--- + +## Rozkład pytań wg trudności + +### Ciężkie (200+ linii, dużo teorii) +- **Q5** STL categories (325 linii) — najdłuższe pytanie +- **Q2** Shortest paths (225 linii) — trzy algorytmy + pseudokod + +### Średnio-ciężkie (140-180 linii) +- Q3 Normalizacja (176), Q4 Bazy danych (162), Q9 Procesy/wątki (160) +- Q6 OOP reuse (151), Q31 Decyzje pod ryzykiem (146), Q32 Dominacja stochastyczna (168) +- Q1 Automaty (138), Q26 Sync/async (135) + +### Średnie (100-130 linii) +- Q8 TCP (103), Q10 Pamięć (127), Q11 Procesy biznesowe (111), Q12 Optymalizacja (99) +- Q14/28 Wzorce (102), Q15 Robotyka (119), Q16 Języki robotów (103), Q17 Szeregowanie (112) +- Q18 Zapasy (127), Q19/29 Pub-Sub (120), Q20/30 Streaming (122) +- Q21 Zegary logiczne (128), Q22 Spójność (112), Q23 Segmentacja (122) +- Q24 Detekcja (128), Q25 Amdahl (123) + +### Lekkie (<100 linii) +- **Q7** DNS & caching (88) — najkrótsze +- **Q13/27** Arch. systemów (93), **Q12** Optymalizacja sieciowa (99) + +--- + +## FAZA 1: Pierwsze przejście — nauka i zrozumienie (Feb 14–22) + +Cel: przeczytać i zrozumieć każde pytanie, zanotować kluczowe koncepty. + +### Dzień 1 — Sobota 14.02 (6h) 🏠 +**Temat: Algorytmy i Teoria (AISDI)** + +| Czas | Pytanie | Co zrobić | +|------|---------|-----------| +| 09:00–11:00 (2h) | **Q1** Automaty i klasy języków | Hierarchia Chomsky'ego, tabela FA/PDA/LBA/TM, kontrprzykłady | +| 11:15–13:45 (2.5h) | **Q2** Algorytmy najkrótszej ścieżki | Dijkstra/BF/A* — pseudokod, złożoności, tabela porównawcza | +| 14:30–16:00 (1.5h) | **Q5** (część 1) Kategorie STL | Kontenery sekwencyjne i asocjacyjne (połowa pytania) | + +**Metoda:** Czytaj aktywnie — po każdej sekcji zamknij oczy i opowiedz sobie kluczowe punkty. + +--- + +### Dzień 2 — Niedziela 15.02 (6h) 🏠 +**Temat: Programowanie + Bazy danych (PROI + BD2)** + +| Czas | Pytanie | Co zrobić | +|------|---------|-----------| +| 09:00–10:30 (1.5h) | **Q5** (część 2) Kategorie STL | Adaptery, iteratory, algorytmy, funktory | +| 10:45–12:15 (1.5h) | **Q6** Reużywalność kodu OOP | Dziedziczenie vs kompozycja, wzorce, SOLID | +| 13:00–14:30 (1.5h) | **Q3** Redundancja i normalizacja | 1NF→BCNF, anomalie, zależności funkcyjne | +| 14:45–16:15 (1.5h) | **Q4** Baza danych jako fundament | ACID, transakcje, indeksy, architektura | + +**Wieczór:** 20 min — szybkie powtórzenie głównych tabel z Q1-Q6. + +--- + +### Dzień 3 — Poniedziałek 16.02 (3h) 💻 zdalnie +**Temat: Sieci + Systemy operacyjne (SKM + SOI)** + +| Czas | Pytanie | Co zrobić | +|------|---------|-----------| +| 19:00–19:50 (50min) | **Q7** DNS i caching | Hierarchia DNS, typy rekordów, cache TTL | +| 20:00–20:50 (50min) | **Q8** TCP Three-Way Handshake | SYN/SYN-ACK/ACK, stany połączenia, flagi | +| 21:00–22:00 (1h) | **Q9** Procesy i wątki | Stany procesów, różnice procesu vs wątek, synchronizacja | + +--- + +### Dzień 4 — Wtorek 17.02 (3.5h) 🏢 biuro +**Temat: Systemy operacyjne + Zarządzanie (SOI + WSYZ)** + +| Kiedy | Pytanie | Co zrobić | +|-------|---------|-----------| +| 🚌 Dojazd tam (1h) | Powtórka Q1–Q4 | Czytaj podsumowania i tabele na telefonie | +| 🚌 Dojazd powrót (1h) | Powtórka Q5–Q9 | Anki flashcards + kluczowe schematy | +| 🌙 Wieczór (1.5h) | **Q10** Zarządzanie pamięcią | Stronicowanie, segmentacja, pamięć wirtualna, TLB | + +--- + +### Dzień 5 — Środa 18.02 (3.5h) 🏢 biuro +**Temat: Zarządzanie + Architektura (WSYZ + AIS)** + +| Kiedy | Pytanie | Co zrobić | +|-------|---------|-----------| +| 🚌 Dojazd (2h) | Powtórka Q7–Q10 | Skupienie na słabszych punktach z wczoraj | +| 🌙 Wieczór (1.5h) | **Q11** Modelowanie procesów biznesowych + **Q12** Optymalizacja sieciowa | BPMN elementy, problem transportowy, simpleks | + +--- + +### Dzień 6 — Czwartek 19.02 (3h) 💻 zdalnie +**Temat: Architektura + Robotyka (AIS + Robotyka)** + +| Czas | Pytanie | Co zrobić | +|------|---------|-----------| +| 19:00–19:50 (50min) | **Q13/27** Modelowanie architektury SI | UML, 4+1, diagramy komponentów/wdrożeń | +| 20:00–20:50 (50min) | **Q14/28** Wzorce architektoniczne | MVC, mikrousługi, CQRS, event-driven | +| 21:00–22:00 (1h) | **Q15** Agent upostaciowiony | Sense-plan-act, zachowania reaktywne, robotyka kognitywna | + +--- + +### Dzień 7 — Piątek 20.02 (3.5h) 🏢 biuro +**Temat: Robotyka + Scheduling** + +| Kiedy | Pytanie | Co zrobić | +|-------|---------|-----------| +| 🚌 Dojazd (2h) | Powtórka Q10–Q15 | Anki + szybkie streszczenia na telefonie | +| 🌙 Wieczór (1.5h) | **Q16** Języki programowania robotów + **Q17** Szeregowanie zadań | ROS, C++/Python w robotyce; EDF, RM, Gantt | + +--- + +### Dzień 8 — Sobota 21.02 (6h) 🏠 +**Temat: Supply chain + Messaging + Systemy rozproszone** + +| Czas | Pytanie | Co zrobić | +|------|---------|-----------| +| 09:00–10:15 (1.25h) | **Q18** Zarządzanie zapasami | EOQ, punkt zamawiania, model newsvendor | +| 10:30–11:30 (1h) | **Q19/29** Model Publish-Subscribe | Broker, topic vs content-based, przykłady (Kafka/MQTT) | +| 11:45–12:45 (1h) | **Q20/30** Analityka strumieniowa | Okna czasowe, CEP, Storm/Flink/Spark Streaming | +| 13:30–14:45 (1.25h) | **Q21** Zegary logiczne | Lamport, zegary wektorowe, happened-before | +| 15:00–16:15 (1.25h) | **Q22** Modele spójności danych | Silna/eventual/causal consistency, CAP theorem | + +**Wieczór:** 15 min podsumowanie — narysuj mapę myśli łączącą Q18-Q22. + +--- + +### Dzień 9 — Niedziela 22.02 (6h) 🏠 +**Temat: Wizja komputerowa + Równoległość + Decyzje (KOŃCZYMY FAZĘ 1!)** + +| Czas | Pytanie | Co zrobić | +|------|---------|-----------| +| 09:00–10:00 (1h) | **Q23** Segmentacja obrazu | Progowanie, region growing, k-means, watershed | +| 10:15–11:15 (1h) | **Q24** Detekcja obiektów | YOLO, R-CNN, SSD, mAP, IoU | +| 11:30–12:30 (1h) | **Q25** Prawo Amdahla | Wzór, ograniczenia części sekwencyjnej, strong/weak scaling | +| 13:15–14:15 (1h) | **Q26** Komunikacja sync/async | Blokująca/nieblokująca, MPI, async/await | +| 14:30–15:30 (1h) | **Q31** Wspomaganie decyzji | Drzewa decyzyjne, macierz wypłat, EMV, EVPI | +| 15:45–16:45 (1h) | **Q32** Dominacja stochastyczna | FSD, SSD, wykres CDF, porównanie z E[X] | + +**✅ Koniec Fazy 1 — wszystkie 28 pytań przeczytane i zrozumiane!** + +--- + +## FAZA 2: Aktywne powtarzanie i utrwalanie (Feb 23–27) + +Cel: przejść od biernego czytania do aktywnego wydobywania z pamięci. **Metoda Feynmana** — wytłumacz każde pytanie jak 5-latkowi (po polsku, na głos). + +### Dzień 10 — Poniedziałek 23.02 (3h) 💻 zdalnie +**Powtórka: AISDI + BD2 + PROI (Q1–Q6)** + +| Czas | Aktywność | +|------|-----------| +| 19:00–20:00 | Q1+Q2: Narysuj od zera hierarchię Chomsky'ego + tabelę Dijkstra/BF/A* z pamięci | +| 20:15–21:15 | Q3+Q4: Przeprowadź normalizację przykładowej tabeli na kartce; wypisz ACID | +| 21:15–22:00 | Q5+Q6: Wymień kategorie STL + po 2 przykłady; narysuj diagram dziedziczenie vs kompozycja | + +**Samoocena:** Oceń każde pytanie 🟢 (umiem) / 🟡 (częściowo) / 🔴 (słabo). Zanotuj 🔴. + +--- + +### Dzień 11 — Wtorek 24.02 (3.5h) 🏢 biuro +**Powtórka: SKM + SOI + WSYZ (Q7–Q12)** + +| Kiedy | Aktywność | +|-------|-----------| +| 🚌 Dojazd (2h) | Anki flashcards — pula Q1-Q12. Skup się na 🔴 z wczoraj | +| 🌙 Wieczór (1.5h) | Q7–Q12 aktywne powtórzenie: bez notatek opowiedz TCP handshake, narysuj stany procesów, wymień formy normalne | + +--- + +### Dzień 12 — Środa 25.02 (3.5h) 🏢 biuro +**Powtórka: AIS + Robotyka + Scheduling (Q13–Q18)** + +| Kiedy | Aktywność | +|-------|-----------| +| 🚌 Dojazd (2h) | Anki — pula Q7-Q18. Ćwicz kluczowe tabele, wzory, schematy | +| 🌙 Wieczór (1.5h) | Q13–Q18 aktywne: Narysuj diagram UML 4+1, wypisz wzorce architektoniczne, EOQ wzór z pamięci | + +--- + +### Dzień 13 — Czwartek 26.02 (3h) 💻 zdalnie +**Powtórka: Messaging + Rozproszone + Wizja (Q19–Q26)** + +| Czas | Aktywność | +|------|-----------| +| 19:00–20:00 | Q19–Q22: Pub-Sub diagram z pamięci, CEP przykład, zegar Lamporta step-by-step, CAP theorem | +| 20:15–21:15 | Q23–Q26: Wymień metody segmentacji, narysuj pipeline YOLO, zapisz wzór Amdahla i oblicz przykład | +| 21:15–22:00 | Przejrzyj WSZYSTKIE notatki 🔴 ze wcześniejszych dni. Skoncentruj się na słabych punktach | + +--- + +### Dzień 14 — Piątek 27.02 (3.5h) 🏢 biuro +**Powtórka: Decyzje + NAJTRUDNIEJSZE pytania** + +| Kiedy | Aktywność | +|-------|-----------| +| 🚌 Dojazd (2h) | Anki — PEŁNA PULA wszystkie 28 pytań. Ostatni dojazd — skup się na tym, co wciąż trudne | +| 🌙 Wieczór (1.5h) | Q31+Q32 aktywne + **ponowna powtórka 5 najtrudniejszych pytań** (na podstawie samooceny 🔴/🟡) | + +--- + +## FAZA 3: Symulacja obrony (Feb 28) + +### Dzień 15 — Sobota 28.02 (6h) 🏠 +**MOCK DEFENSE + ostatnie szlify** + +| Czas | Aktywność | +|------|-----------| +| 09:00–10:30 (1.5h) | **Mock #1:** Wylosuj 3 pytania (np. dice online). Odpowiedz na głos, max 5 min/pytanie. Nagraj się telefonem | +| 10:45–11:45 (1h) | Odsłuchaj nagranie. Zanotuj: co było niejasne? co pominąłeś? | +| 12:30–14:00 (1.5h) | **Mock #2:** Wylosuj kolejne 3 pytania. Spróbuj odpowiedzieć BEZ notatek | +| 14:15–15:15 (1h) | Przeczytaj odpowiedzi do pytań, z którymi miałeś problem. Uzupełnij luki | +| 15:30–16:30 (1h) | **Speed round:** Przejdź przez WSZYSTKIE 28 pytań — 2 min na pytanie, powiedz esencję (kluczowe 3 punkty) | + +**Wieczór:** ODPOCZYNEK. Żadnej nauki po 18:00. Dobry sen. + +--- + +## Niedziela 1.03 — DZIEŃ OBRONY 🎓 + +- Rano: lekkie przeglądnięcie tabel porównawczych (15 min max) +- **NIE** ucz się niczego nowego +- Zjedz dobry posiłek, przyjdź wcześniej + +--- + +## Techniki nauki — podsumowanie + +| Technika | Kiedy | Jak | +|----------|-------|-----| +| **Aktywne czytanie** | Faza 1 | Po każdej sekcji: zamknij dokument, opowiedz kluczowe punkty | +| **Anki flashcards** | Dojazdy + codziennie | Użyj istniejących plików `anki_*.txt` z katalogu `pytania/` | +| **Metoda Feynmana** | Faza 2 | Wytłumacz pytanie prostymi słowami, na głos | +| **Samoocena 🟢🟡🔴** | Po każdej sesji | Zaznacz co umiesz, wróć do 🔴 następnego dnia | +| **Mock defense** | Faza 3 | Losuj pytania, odpowiadaj na czas, nagrywaj się | +| **Spaced repetition** | Cały czas | Wracaj do wcześniejszych pytań w dojazdach | + +--- + +## Materiały dodatkowe w repozytorium + +- `pytania/anki_atomic.txt` — fiszki Anki (atomowe) +- `pytania/anki_egzamin_magisterski.txt` — fiszki z zakresu egzaminu +- `pytania/OBRONA_SKRYPT_MOWIONY.md` — skrypt do przećwiczenia mówienia +- `pytania/odpowiedzi/` — dodatkowe materiały + +--- + +## Quick reference — grupowanie tematyczne + +| # | Pytanie | Przedmiot | Para | +|---|---------|-----------|------| +| 1 | Automaty i klasy języków | AISDI | 1+2 | +| 2 | Algorytmy najkrótszej ścieżki | AISDI | 1+2 | +| 3 | Redundancja i normalizacja | BD2 | 3+4 | +| 4 | Baza danych jako fundament | BD2 | 3+4 | +| 5 | Kategorie STL | PROI | 5+6 | +| 6 | Reużywalność kodu OOP | PROI | 5+6 | +| 7 | DNS i caching | SKM | 7+8 | +| 8 | TCP Three-Way Handshake | SKM | 7+8 | +| 9 | Procesy i wątki | SOI | 9+10 | +| 10 | Zarządzanie pamięcią | SOI | 9+10 | +| 11 | Modelowanie procesów biznesowych | WSYZ | 11+12 | +| 12 | Sieciowe modele optymalizacji | WSYZ | 11+12 | +| 13/27 | Modelowanie architektury SI | AIS | 13+14 | +| 14/28 | Wzorce architektoniczne | AIS | 13+14 | +| 15 | Agent upostaciowiony | Robotyka | 15+16 | +| 16 | Języki programowania robotów | Robotyka | 15+16 | +| 17 | Szeregowanie zadań | Scheduling | 17+18 | +| 18 | Zarządzanie zapasami | Supply chain | 17+18 | +| 19/29 | Model Publish-Subscribe | Messaging | 19+20 | +| 20/30 | Analityka strumieniowa | Streaming | 19+20 | +| 21 | Zegary logiczne | Rozproszone | 21+22 | +| 22 | Modele spójności danych | Rozproszone | 21+22 | +| 23 | Segmentacja obrazu | Wizja | 23+24 | +| 24 | Detekcja obiektów | Wizja | 23+24 | +| 25 | Prawo Amdahla | Równoległość | 25+26 | +| 26 | Komunikacja sync/async | Komunikacja | 25+26 | +| 31 | Wspomaganie decyzji pod ryzykiem | Decyzje | 31+32 | +| 32 | Dominacja stochastyczna | Decyzje | 31+32 | + +--- + +## Tracker codzienny + +Kopiuj do notatnika i zaznaczaj codziennie: + +``` +[ ] Feb 14 (Sob) — Q1, Q2, Q5(1/2) +[ ] Feb 15 (Nie) — Q5(2/2), Q6, Q3, Q4 +[ ] Feb 16 (Pon) — Q7, Q8, Q9 +[ ] Feb 17 (Wto) — powtórka dojazd + Q10 +[ ] Feb 18 (Śro) — powtórka dojazd + Q11, Q12 +[ ] Feb 19 (Czw) — Q13/27, Q14/28, Q15 +[ ] Feb 20 (Pią) — powtórka dojazd + Q16, Q17 +[ ] Feb 21 (Sob) — Q18, Q19/29, Q20/30, Q21, Q22 +[ ] Feb 22 (Nie) — Q23, Q24, Q25, Q26, Q31, Q32 ✅ FAZA 1 DONE +[ ] Feb 23 (Pon) — recall Q1-Q6 +[ ] Feb 24 (Wto) — recall Q7-Q12 +[ ] Feb 25 (Śro) — recall Q13-Q18 +[ ] Feb 26 (Czw) — recall Q19-Q26 +[ ] Feb 27 (Pią) — recall Q31-Q32 + 5 najtrudniejszych +[ ] Feb 28 (Sob) — MOCK DEFENSE x2 + speed round +--- Mar 1 (Nie) — 🎓 OBRONA --- +``` diff --git a/pytania/anki_atomic.txt b/pytania/anki_atomic.txt new file mode 100644 index 0000000..79a58bc --- /dev/null +++ b/pytania/anki_atomic.txt @@ -0,0 +1,925 @@ +#separator:Tab +#html:true +#tags column:3 +#notetype:Basic +Jaki typ pamięci ma automat skończony (FA)? Brak — tylko stan pyt01 AISDI FA pamięć +Jaki typ pamięci ma automat ze stosem (PDA)? Stos (LIFO) pyt01 AISDI PDA pamięć +Jaki typ pamięci ma maszyna Turinga (TM)? Taśma nieskończona R/W pyt01 AISDI TM pamięć +Jaki typ pamięci ma LBA (Typ 1)? Taśma ograniczona do |w| (R/W) pyt01 AISDI LBA pamięć +Jaką klasę języków rozpoznaje FA? Regularne (Typ 3) pyt01 AISDI FA klasa +Jaką klasę języków rozpoznaje PDA? Bezkontekstowe (Typ 2) pyt01 AISDI PDA klasa +Jaką klasę języków rozpoznaje LBA? Kontekstowe (Typ 1) pyt01 AISDI LBA klasa +Jaką klasę języków rozpoznaje TM? Rekurencyjnie przeliczalne (Typ 0) pyt01 AISDI TM klasa +Czy DFA i NFA są równoważne (rozpoznają te same języki)? Tak pyt01 AISDI FA det_niedet +Czy DPDA i NPDA są równoważne? Nie — NPDA rozpoznaje ściśle więcej (DPDA ⊂ NPDA) pyt01 AISDI PDA det_niedet +Czy DLBA i NLBA są równoważne? Problem otwarty (nierozwiązany!) pyt01 AISDI LBA det_niedet +Czy DTM i NTM są równoważne pod względem mocy? Tak — rozpoznają te same języki pyt01 AISDI TM det_niedet +Jaki język jest klasycznym kontrprzykładem łamiącym FA (Typ 3)? aⁿbⁿ pyt01 AISDI FA kontrprzyklad +Jaki język jest klasycznym kontrprzykładem łamiącym PDA (Typ 2)? aⁿbⁿcⁿ pyt01 AISDI PDA kontrprzyklad +Dlaczego FA nie rozpoznaje aⁿbⁿ? Brak pamięci do zliczania a-ek pyt01 AISDI FA anbn +Dlaczego PDA nie rozpoznaje aⁿbⁿcⁿ? Stos zużyty przy a↔b, pusty przy c — potrzeba dwóch liczników pyt01 AISDI PDA anbncn +Hierarchia siły wyrazu automatów (od najsłabszego)? FA ⊂ PDA ⊂ LBA ⊂ TM pyt01 AISDI hierarchia_sily +Języki regularne to Typ ... w hierarchii Chomsky'ego? Typ 3 pyt01 AISDI Chomsky regularne +Typ 3 w hierarchii Chomsky'ego to języki ...? Regularne pyt01 AISDI Chomsky typ3 +Języki bezkontekstowe to Typ ... w hierarchii Chomsky'ego? Typ 2 pyt01 AISDI Chomsky bezkontekstowe +Typ 2 w hierarchii Chomsky'ego to języki ...? Bezkontekstowe pyt01 AISDI Chomsky typ2 +Języki kontekstowe to Typ ... w hierarchii Chomsky'ego? Typ 1 pyt01 AISDI Chomsky kontekstowe +Typ 1 w hierarchii Chomsky'ego to języki ...? Kontekstowe pyt01 AISDI Chomsky typ1 +Języki rekurencyjnie przeliczalne to Typ ... w hierarchii Chomsky'ego? Typ 0 pyt01 AISDI Chomsky rek_przeliczalne +Typ 0 w hierarchii Chomsky'ego to języki ...? Rekurencyjnie przeliczalne pyt01 AISDI Chomsky typ0 +Czemu FA są równoważne (jaki formalizm)? Wyrażeniom regularnym (regex) pyt01 AISDI FA regex +Co to LIFO? Last In, First Out — zasada działania stosu pyt01 AISDI LIFO +Czy języki regularne są domknięte na przecięcie (∩)? Tak pyt01 AISDI regularne domkniecie_przeciecie +Czy języki regularne są domknięte na dopełnienie (¬)? Tak pyt01 AISDI regularne domkniecie_dopelnienie +Czy języki bezkontekstowe są domknięte na przecięcie (∩)? Nie pyt01 AISDI bezkontekstowe domkniecie_przeciecie +Czy języki bezkontekstowe są domknięte na dopełnienie (¬)? Nie pyt01 AISDI bezkontekstowe domkniecie_dopelnienie +Czy języki rek. przeliczalne są domknięte na dopełnienie (¬)? Nie (komplement problemu stopu) pyt01 AISDI rek_przeliczalne domkniecie +Zastosowanie praktyczne FA (Typ 3)? Leksery (analiza leksykalna — tokenizacja kodu) pyt01 AISDI FA zastosowanie +Zastosowanie praktyczne PDA (Typ 2)? Parsery (analiza składniowa — drzewo składniowe) pyt01 AISDI PDA zastosowanie +Zastosowanie praktyczne LBA (Typ 1)? Weryfikacja ograniczeń kontekstowych pyt01 AISDI LBA zastosowanie +Zastosowanie praktyczne TM (Typ 0)? Obliczenia ogólne (każde obliczenie algorytmiczne) pyt01 AISDI TM zastosowanie +Context-Free (bezkontekstowe) — dlaczego ta nazwa? Produkcje A → α stosowane BEZ patrzenia na kontekst wokół A pyt01 AISDI bezkontekstowe etymologia +Context-Sensitive (kontekstowe) — dlaczego ta nazwa? Produkcje αAβ → αγβ — przepisanie A ZALEŻY od kontekstu α i β pyt01 AISDI kontekstowe etymologia +Kto stworzył hierarchię Chomsky'ego i kiedy? Noam Chomsky (MIT, 1956) pyt01 AISDI Chomsky autor +Kto stworzył maszynę Turinga i kiedy? Alan Turing (1936, „On Computable Numbers") pyt01 AISDI Turing autor +„Pushdown" w PDA pochodzi od ...? Dozownik tac w stołówce (spring-loaded tray dispenser — push down) pyt01 AISDI PDA pushdown_etymologia +Teza Churcha-Turinga mówi, że ...? TM modeluje każde możliwe obliczenie pyt01 AISDI Turing teza +Mnemotechnika: „Raz Bardzo Kolorowy Rekin" — kolejność hierarchii Chomsky'ego? Regularny ⊂ Bezkontekstowy ⊂ Kontekstowy ⊂ Rek.przeliczalny pyt01 AISDI Chomsky mnemotechnika +Mnemotechnika pamięci automatów (od najsłabszego)? Brak → Stos → Taśma ogr. → Taśma ∞ pyt01 AISDI pamięć mnemotechnika +Język ww (powtórzenie słowa, np. abab) — czy PDA go rozpoznaje? Nie — stos odwraca kolejność, co pomaga przy palindromach, ale nie przy powtórzeniu pyt01 AISDI PDA ww +Język wwᴿ (palindrom, np. abba) — czy PDA go rozpoznaje? Tak (NPDA „zgaduje" środek słowa) pyt01 AISDI PDA palindrom +#notetype:Cloze +Hierarchia Chomsky'ego: Typ 3 = {{c1::Regularne}} (FA) ⊂ Typ 2 = {{c2::Bezkontekstowe}} (PDA) ⊂ Typ 1 = {{c3::Kontekstowe}} (LBA) ⊂ Typ 0 = {{c4::Rek. przeliczalne}} (TM) pyt01 AISDI Chomsky_cloze +FA: M = (Q, Σ, {{c1::δ}}, q₀, F) — {{c1::δ}} to funkcja ...? przejścia (transition function) pyt01 AISDI FA definicja +Domknięcie ∩/¬ — FA: {{c1::TAK}}/{{c2::TAK}}, PDA: {{c3::NIE}}/{{c4::NIE}}, TM: {{c5::TAK}}/{{c6::NIE}} pyt01 AISDI domkniecie_cloze +#notetype:Basic +Dijkstra — jaki typ algorytmu? Zachłanny (greedy) pyt02 AISDI Dijkstra typ +Bellman-Ford — jaki typ algorytmu? Programowanie dynamiczne pyt02 AISDI BellmanFord typ +A* — jaki typ algorytmu? Heurystyczny pyt02 AISDI Astar typ +Dijkstra rozwiązuje problem typu ...? SSSP (Single-Source Shortest Path) pyt02 AISDI Dijkstra problem +Bellman-Ford rozwiązuje problem typu ...? SSSP (Single-Source Shortest Path) pyt02 AISDI BellmanFord problem +A* rozwiązuje problem typu ...? Single-Pair (najkrótsza ścieżka z A do B) pyt02 AISDI Astar problem +Czy Dijkstra obsługuje ujemne wagi? Nie — raz oznaczony wierzchołek nie jest rewidowany pyt02 AISDI Dijkstra ujemne_wagi +Czy Bellman-Ford obsługuje ujemne wagi? Tak pyt02 AISDI BellmanFord ujemne_wagi +Czy Bellman-Ford wykrywa cykle ujemne? Tak — jeśli w V-tej iteracji nadal można poprawić pyt02 AISDI BellmanFord cykl_ujemny +Złożoność Dijkstry z tablicą? O(V²) pyt02 AISDI Dijkstra zlozonosc_tablica +Złożoność Dijkstry z kopcem binarnym? O((V+E) log V) pyt02 AISDI Dijkstra zlozonosc_kopiec +Złożoność Dijkstry z kopcem Fibonacciego? O(V log V + E) pyt02 AISDI Dijkstra zlozonosc_fib +Złożoność Bellmana-Forda? O(V·E) pyt02 AISDI BellmanFord zlozonosc +Dlaczego Bellman-Ford wykonuje dokładnie V−1 iteracji? Najdłuższa najkrótsza ścieżka bez cykli ma co najwyżej V−1 krawędzi pyt02 AISDI BellmanFord V-1 +W A*: f(n) = ? g(n) + h(n) pyt02 AISDI Astar f +W A*: g(n) to ...? Dotychczasowy koszt od startu do n (znany, dokładny) pyt02 AISDI Astar g +W A*: h(n) to ...? Heurystyka — oszacowanie kosztu od n do celu pyt02 AISDI Astar h +h(n) w A* musi być ... żeby gwarantować optymalność? Dopuszczalna (admissible): h(n) ≤ rzeczywisty koszt n→cel pyt02 AISDI Astar admissible +Heurystyka spójna (consistent) w A* — warunek? h(n) ≤ w(n,m) + h(m) dla każdej krawędzi n→m pyt02 AISDI Astar consistent +Czy spójność heurystyki implikuje dopuszczalność? Tak (spójna ⇒ dopuszczalna, ale nie odwrotnie) pyt02 AISDI Astar spoj_implikuje_dop +Najlepszy przypadek złożoności A*? O(V) — gdy heurystyka jest idealna pyt02 AISDI Astar best_case +Najgorszy przypadek A* (h=0)? Degeneruje się do Dijkstry pyt02 AISDI Astar worst_case +Co to jest relaksacja krawędzi (edge relaxation)? Jeśli d[u] + w(u,v) < d[v], zaktualizuj d[v] — „rozluźnienie" górnego ograniczenia pyt02 AISDI relaksacja +Kopiec Fibonacciego — klucz. przewaga nad zwykłym kopcem w Dijkstrze? Decrease-key w zamortyzowanym O(1) zamiast O(log V) pyt02 AISDI kopiec_fib +Kto opracował algorytm Dijkstry i kiedy? Edsger W. Dijkstra (Holandia, 1959) pyt02 AISDI Dijkstra autor +Hart, Nilsson, Raphael (Stanford, 1968) opracowali algorytm ...? A* pyt02 AISDI Astar autor_rev +Kto opracował algorytm A*? Hart, Nilsson, Raphael (Stanford, 1968) pyt02 AISDI Astar autor +Richard Bellman jest też twórcą koncepcji ...? Programowania dynamicznego pyt02 AISDI Bellman DP +Dlaczego Bellman nazwał swoją metodę „dynamic programming"? By brzmiało imponująco dla polityków — nie miało związku z dynamiką pyt02 AISDI Bellman DP_etymologia +„Heurystyka" — etymologia (język grecki)? „heuriskein" = znajdować (to samo co „Eureka!" Archimedesa) pyt02 AISDI heurystyka_etymologia +A* rozszerza algorytm ... o heurystykę h(n). Dijkstry pyt02 AISDI Astar relacja_Dijkstra +Mnemotechnika: „Dijkstra = chciwy" — co to oznacza? Bierze minimum i nie patrzy wstecz (stąd problem z ujemnymi wagami) pyt02 AISDI Dijkstra mnemotechnika +Mnemotechnika: „Bellman-Ford = brute force × (V−1)"? Relaksuj wszystkie krawędzie V−1 razy pyt02 AISDI BellmanFord mnemotechnika +Mnemotechnika: „A* = Dijkstra + GPS"? Heurystyka mówi w którą stronę jest cel pyt02 AISDI Astar mnemotechnika +SSSP to skrót od ...? Single-Source Shortest Path pyt02 AISDI SSSP +#notetype:Cloze +Złożoność Dijkstry: tablica = {{c1::O(V²)}}, kopiec = {{c2::O((V+E) log V)}}, Fibonacci = {{c3::O(V log V + E)}} pyt02 AISDI Dijkstra zlozonosc_cloze +A*: f(n) = {{c1::g(n)}} + {{c2::h(n)}} pyt02 AISDI Astar f_cloze +Algorytm {{c1::Dijkstry}} — zachłanny SSSP, wagi ≥ 0; {{c2::Bellman-Ford}} — DP, SSSP, ujemne wagi + cykle; {{c3::A*}} — heurystyczny, Single-Pair pyt02 AISDI porownanie_cloze +#notetype:Basic +Co to jest redundancja w bazie danych? Powtarzanie tych samych danych w wielu miejscach pyt03 BD2 redundancja definicja +Anomalia wstawiania (insert anomaly) — na czym polega? Nie można dodać danych bez podania niepotrzebnych powiązań pyt03 BD2 anomalia_wstawiania +Anomalia usuwania (delete anomaly) — na czym polega? Usunięcie rekordu kasuje niezwiązane informacje pyt03 BD2 anomalia_usuwania +Anomalia modyfikacji (update anomaly) — na czym polega? Zmiana jednej informacji wymaga aktualizacji wielu wierszy pyt03 BD2 anomalia_modyfikacji +Co oznacza zapis X → Y (zależność funkcyjna)? Znając wartość X, zawsze można jednoznacznie wyznaczyć Y pyt03 BD2 FD definicja +Co to jest zależność przechodnia (transitive dependency)? A → B i B → C, więc A → C „przez pośrednika B" pyt03 BD2 FD_przechodnia +Co to jest klucz złożony (composite key)? Klucz główny składający się z więcej niż jednej kolumny pyt03 BD2 klucz_zlozony +Co to jest atrybut wtórny (non-prime)? Kolumna, która NIE jest częścią żadnego klucza kandydującego pyt03 BD2 atrybut_wtorny +Co to jest nadklucz (superkey)? Dowolny zbiór kolumn identyfikujący wiersz jednoznacznie (może mieć „nadmiarowe" kolumny) pyt03 BD2 nadklucz +1NF wymaga ...? Atomowych wartości (brak list/tablic w komórkach) + istnieje klucz główny pyt03 BD2 1NF +2NF dodaje do 1NF ...? Każdy atrybut wtórny zależy od CAŁEGO klucza (brak częściowych zależności) pyt03 BD2 2NF +3NF dodaje do 2NF ...? Brak zależności przechodnich (atrybut wtórny nie zależy od innego wtórnego) pyt03 BD2 3NF +BCNF — warunek? Dla każdej nietrywialnej FD X→A, X jest nadkluczem pyt03 BD2 BCNF +Czym BCNF różni się od 3NF? BCNF nie ma wyjątku dla atrybutów pierwszych — lewa strona FD ZAWSZE nadklucz pyt03 BD2 BCNF_vs_3NF +4NF dodaje do BCNF ...? Brak nietrywialnych wielowartościowych zależności (MVD) pyt03 BD2 4NF +Co to jest MVD (Multi-Valued Dependency)? X →→ Y — dla jednej wartości X istnieje ZBIÓR wartości Y, niezależny od reszty pyt03 BD2 MVD +Normalizacja eliminuje redundancję przez ...? Dekompozycję (rozbicie dużej tabeli na mniejsze) pyt03 BD2 normalizacja_metoda +Co to jest denormalizacja? Świadome wprowadzanie redundancji dla wydajności (mniej JOIN-ów) pyt03 BD2 denormalizacja +Denormalizacja stosowana głównie w systemach typu ...? OLAP / data warehousing (analitycznych) pyt03 BD2 denormalizacja_zastosowanie +Kolejność zawierania postaci normalnych (od najsilniejszej)? 5NF ⊂ 4NF ⊂ BCNF ⊂ 3NF ⊂ 2NF ⊂ 1NF pyt03 BD2 NF_hierarchia +Kto zaproponował normalizację (1NF–3NF)? Edgar F. Codd (IBM, 1970) pyt03 BD2 Codd autor +BCNF — nazwana od ...? Raymond Boyce + Codd (1974) pyt03 BD2 BCNF autor +Problem naruszenia 2NF: NazwaKursu zależy tylko od KursID, a klucz to (StudentID, KursID). To jest ...? Częściowa zależność od klucza złożonego pyt03 BD2 2NF_naruszenie +Problem naruszenia 3NF: StudentID → WydziałID → NazwaWydziału. To jest ...? Zależność przechodnia pyt03 BD2 3NF_naruszenie +Mnemotechnika: „Klucz, cały klucz i tylko klucz — tak mi dopomóż ..."? Codd (1NF = klucz, 2NF = cały klucz, 3NF = tylko klucz) pyt03 BD2 mnemotechnika_Codd +Mnemotechnika: „WUM" dla 3 anomalii? Wstawianie, Usuwanie, Modyfikacja pyt03 BD2 mnemotechnika_WUM +FD: Prowadzący → Przedmiot, a Prowadzący NIE jest nadkluczem — łamie ...? BCNF (ale może spełniać 3NF, jeśli Przedmiot jest atrybutem pierwszym) pyt03 BD2 BCNF_przyklad +Nietrywialna FD to ...? X → A, gdzie A nie jest częścią X pyt03 BD2 FD_nietrywialna +#notetype:Cloze +Postacie normalne: {{c1::1NF}} = atomowe wartości; {{c2::2NF}} = brak częściowych zależności; {{c3::3NF}} = brak zależności przechodnich pyt03 BD2 NF_cloze +„Klucz, cały klucz i tylko klucz": klucz = {{c1::1NF}}, cały klucz = {{c2::2NF}}, tylko klucz = {{c3::3NF}} pyt03 BD2 Codd_cloze +3 anomalie redundancji: {{c1::Wstawiania}}, {{c2::Usuwania}}, {{c3::Modyfikacji}} pyt03 BD2 anomalie_cloze +#notetype:Basic +Przelew bankowy: crash po odjęciu 100 zł od Ani, ale przed dodaniem Janowi. Która cecha ACID ratuje? Atomicity — albo cała transakcja, albo nic (rollback) pyt04 BD2 ACID atomicity_scenariusz +ACID — A = ? Atomicity (Atomowość): transakcja — albo cała, albo nic pyt04 BD2 ACID A +ACID — C = ? Consistency (Spójność): baza ze spójnego stanu w spójny stan pyt04 BD2 ACID C +ACID — I = ? Isolation (Izolacja): równoległe transakcje nie widzą swoich niedokończonych zmian pyt04 BD2 ACID I +ACID — D = ? Durability (Trwałość): po COMMIT efekty przetrwają każdą awarię pyt04 BD2 ACID D +Co zapewnia Durability technicznie? Zapis do trwałego magazynu (dysk, WAL — Write-Ahead Log) pyt04 BD2 ACID D_mechanizm +3 poziomy architektury ANSI/SPARC (od góry)? Zewnętrzny → Konceptualny → Wewnętrzny pyt04 BD2 ANSI_SPARC poziomy +Poziom zewnętrzny ANSI/SPARC = ? CO widzi użytkownik/aplikacja (widoki, podzbiory danych) pyt04 BD2 ANSI_SPARC zewnetrzny +Poziom konceptualny ANSI/SPARC = ? JAKA jest struktura danych (tabele, kolumny, relacje) pyt04 BD2 ANSI_SPARC konceptualny +Poziom wewnętrzny ANSI/SPARC = ? JAK dane są fizycznie przechowywane (pliki, indeksy, bloki) pyt04 BD2 ANSI_SPARC wewnetrzny +Niezależność fizyczna w bazach danych — co oznacza? Zmiana sposobu przechowywania (indeksy, partycje) nie wymaga zmiany aplikacji pyt04 BD2 niezaleznosc_fizyczna +Niezależność logiczna w bazach danych — co oznacza? Zmiana struktury tabel minimalizuje wpływ na aplikacje (dzięki widokom) pyt04 BD2 niezaleznosc_logiczna +MVCC (Multi-Version Concurrency Control) — idea? Baza trzyma wiele wersji danych — odczyt nie blokuje zapisu pyt04 BD2 MVCC +Snapshot Isolation — co widzi transakcja? „Migawkę" bazy z momentu swojego startu (spójny obraz z przeszłości) pyt04 BD2 snapshot_isolation +Co to jest klucz obcy (foreign key)? Wiersz MUSI odnosić się do istniejącego wiersza w innej tabeli pyt04 BD2 FK +CHECK constraint — do czego służy? Ograniczenie na wartości kolumny (np. wiek ≥ 0) pyt04 BD2 CHECK +Co to jest trigger (wyzwalacz)? Fragment kodu uruchamiany AUTOMATYCZNIE przy operacji na bazie pyt04 BD2 trigger +Co robi optymalizator zapytań (query optimizer)? Automatycznie wybiera najszybszy sposób wykonania zapytania SQL pyt04 BD2 optymalizator +GRANT i REVOKE w SQL służą do ...? Nadawania/odbierania uprawnień użytkownikom pyt04 BD2 GRANT_REVOKE +TDE (Transparent Data Encryption) — co to? Szyfrowanie przezroczyste — aplikacja nie wie, że dane są szyfrowane pyt04 BD2 TDE +Replikacja bazy danych — idea? Kopia bazy na wielu serwerach (master + repliki) pyt04 BD2 replikacja +Sharding (fragmentacja) — idea? Podział danych na kawałki na RÓŻNYCH serwerach pyt04 BD2 sharding +ANSI/SPARC — rok zaproponowania architektury? 1975 pyt04 BD2 ANSI_SPARC rok +SQL — oryginalnie nazywał się ...? SEQUEL (Structured English Query Language, Chamberlin & Boyce, IBM 1974) pyt04 BD2 SQL etymologia +ACID jako akronim — kto zaproponował? Reuter & Härder (1983) pyt04 BD2 ACID autor +8 powodów, dla których DB to dobry fundament: trwałość, współbieżność, integralność, niezależność, optymalizacja, bezpieczeństwo, skalowalność, standardowy SQL — jak to zapamiętać? „DB = centralne źródło prawdy" + ACID gwarantuje podstawy pyt04 BD2 mnemotechnika +#notetype:Cloze +ACID: A = {{c1::Atomicity}}, C = {{c2::Consistency}}, I = {{c3::Isolation}}, D = {{c4::Durability}} pyt04 BD2 ACID_cloze +ANSI/SPARC: {{c1::Zewnętrzny}} (CO) → {{c2::Konceptualny}} (JAKA) → {{c3::Wewnętrzny}} (JAK) pyt04 BD2 ANSI_SPARC_cloze +SQL oryginalnie: {{c1::SEQUEL}} — autorzy: {{c2::Chamberlin}} & {{c3::Boyce}} (IBM, {{c4::1974}}) pyt04 BD2 SQL_cloze +#notetype:Basic +Cztery filary STL? Kontenery, Iteratory, Algorytmy, Funktory pyt05 PROI STL filary +STL — co oznacza skrót? Standard Template Library pyt05 PROI STL skrot +Co to jest kontener (container) w STL? Struktura danych przechowująca kolekcję elementów pyt05 PROI STL kontener +Co to jest iterator w STL? Obiekt wskazujący na element w kontenerze, umożliwiający przechodzenie po elementach pyt05 PROI STL iterator +Co to jest algorytm w STL? Gotowa operacja na danych (sort, find, copy itp.) pyt05 PROI STL algorytm +Co to jest funktor (function object) w STL? Obiekt z operator() — parametryzuje algorytmy (JAK porównywać/przekształcać) pyt05 PROI STL funktor +Architektura ortogonalna STL — M kontenerów + N algorytmów wymaga ... implementacji? M + N (nie M × N) — dzięki iteratorom jako łącznikowi pyt05 PROI STL ortogonalnosc +vector — typ pamięci? Ciągły blok (contiguous memory) pyt05 PROI vector pamiec +vector — dostęp do i-tego elementu? O(1) pyt05 PROI vector dostep +vector — push_back? Zamortyzowane O(1) pyt05 PROI vector push_back +vector — wstawianie w środku? O(n) pyt05 PROI vector insert +Dlaczego vector jest domyślnym wyborem w C++? Ciągła pamięć → cache-friendly (CPU ładuje bloki pamięci) pyt05 PROI vector domyslny +deque — co oznacza nazwa? Double-Ended QUEue (kolejka dwustronna) pyt05 PROI deque nazwa +deque — push_front i push_back? Oba O(1) pyt05 PROI deque push +list w STL — typ listy? Lista dwukierunkowa (prev + next) pyt05 PROI list typ +list — wstawianie/usuwanie (mając iterator)? O(1) — wystarczy przepiąć wskaźniki pyt05 PROI list insert +list — dostęp do i-tego elementu? O(n) — brak indeksowania, trzeba przejść po wskaźnikach pyt05 PROI list dostep +forward_list — różnica od list? Wskaźnik TYLKO na następny element (nie na poprzedni) — iteracja tylko do przodu pyt05 PROI forward_list +Kontenery asocjacyjne (set, map) — wewnętrzna struktura? Drzewo czerwono-czarne (R-B tree) pyt05 PROI asocjacyjne struktura +set/map — złożoność wyszukiwania? O(log n) pyt05 PROI set_map zlozonosc +Czym multiset różni się od set? Pozwala na duplikaty pyt05 PROI multiset +unordered_set/unordered_map — wewnętrzna struktura? Tablica haszująca (hash table) pyt05 PROI unordered struktura +unordered_set/map — średnia złożoność wyszukiwania? O(1) pyt05 PROI unordered zlozonosc_srednia +unordered_set/map — najgorsza złożoność (kolizje)? O(n) pyt05 PROI unordered zlozonosc_worst +stack — zasada działania? LIFO (Last In, First Out) pyt05 PROI stack +queue — zasada działania? FIFO (First In, First Out) pyt05 PROI queue +priority_queue — wewnętrzna struktura? Kopiec (heap) pyt05 PROI priority_queue +priority_queue — push/pop? O(log n) pyt05 PROI priority_queue zlozonosc +Adaptery kontenerów w STL (3 główne)? stack, queue, priority_queue pyt05 PROI adaptery +Hierarchia iteratorów (od najsłabszego): Input → ... → Random Access? Input → Output → Forward → Bidirectional → Random Access pyt05 PROI iterator hierarchia +vector::iterator to iterator typu ...? Random Access (ciągła pamięć → skok O(1)) pyt05 PROI vector iterator_typ +list::iterator to iterator typu ...? Bidirectional (prev/next wskaźniki) pyt05 PROI list iterator_typ +forward_list::iterator to iterator typu ...? Forward (tylko next) pyt05 PROI forward_list iterator_typ +Dlaczego NIE można sort(list.begin(), list.end())? sort wymaga Random Access, a list daje Bidirectional (lista ma własny .sort()) pyt05 PROI list sort +sort wymaga iteratora typu ...? Random Access pyt05 PROI sort iterator +Złożoność std::sort? O(n log n) pyt05 PROI sort zlozonosc +Zakres iteratorów w STL: [begin, end) — co oznacza nawiasy? begin = pierwszy element; end = JEDEN ZA OSTATNIM (nie sam ostatni) pyt05 PROI zakres +Lambda w C++ (od C++11) — co to? Anonimowa funkcja definiowana w miejscu użycia: [capture](params){ body } pyt05 PROI lambda +Kto stworzył STL? Alexander Stepanov + Meng Lee (HP, 1994) pyt05 PROI STL autor +Mnemotechnika: „KIAF" — filary STL? Kontenery, Iteratory, Algorytmy, Funktory pyt05 PROI STL mnemotechnika +Kiedy set/map zamiast unordered? Gdy potrzebne posortowane dane lub iteracja w kolejności pyt05 PROI set_vs_unordered +#notetype:Cloze +Filary STL: {{c1::Kontenery}} + {{c2::Iteratory}} + {{c3::Algorytmy}} + {{c4::Funktory}} pyt05 PROI STL filary_cloze +Iteratory STL: {{c1::Input}} → {{c2::Forward}} → {{c3::Bidirectional}} → {{c4::Random Access}} pyt05 PROI iterator_cloze +Kontenery asocjacyjne (set/map) = {{c1::drzewo R-B}}, O({{c2::log n}}); unordered = {{c3::hash table}}, O({{c4::1}}) średnio pyt05 PROI kontenery_cloze +#notetype:Basic +Dziedziczenie (inheritance) — jaka relacja? „Jest" (is-a): Dog jest Animal pyt06 PROI OOP dziedziczenie +Kompozycja (composition) — jaka relacja? „Ma" / „Zawiera" (has-a): Car ma Engine pyt06 PROI OOP kompozycja +Problem diamentu (diamond problem) — na czym polega? Klasa D dziedziczy po B i C, oba po A → D ma dwie kopie A pyt06 PROI OOP diament +Rozwiązanie problemu diamentu w C++? Dziedziczenie wirtualne: class B : virtual public A pyt06 PROI OOP diament_rozwiazanie +Polimorfizm — co oznacza? „Wiele form" — traktowanie obiektów różnych klas przez wspólny interfejs pyt06 PROI OOP polimorfizm +Polimorfizm w C++ — realizacja techniczna? Funkcje wirtualne (virtual + override) + tablica vtable pyt06 PROI OOP vtable +„Favor composition over inheritance" — skąd pochodzi? GoF — Gang of Four (Design Patterns, 1994) pyt06 PROI OOP GoF_zasada +Dlaczego preferować kompozycję nad dziedziczenie? Luźniejsze wiązanie, łatwiejsze testowanie, elastyczność w runtime pyt06 PROI OOP kompozycja_dlaczego +GoF — kto to? Gamma, Helm, Johnson, Vlissides — autorzy „Design Patterns" (1994) pyt06 PROI OOP GoF +Ile wzorców w książce GoF? 23 (w 3 kategoriach: kreacyjne, strukturalne, behawioralne) pyt06 PROI OOP GoF_23 +Wzorzec Strategy — idea? Wymień algorytm w runtime przez interfejs pyt06 PROI OOP Strategy +Wzorzec Observer — idea? Obiekt powiadamia subskrybentów o zmianach stanu (pub/sub w OOP) pyt06 PROI OOP Observer +Wzorzec Factory — idea? Tworzenie obiektów bez określania dokładnej klasy (decyzja w runtime) pyt06 PROI OOP Factory +Wzorzec Decorator — idea? Dodaj zachowanie do obiektu dynamicznie, opakowując go pyt06 PROI OOP Decorator +Template (C++) — co robi kompilator? Generuje osobną wersję kodu dla każdego użytego typu (monomorfizacja) pyt06 PROI OOP template +Interfejs (interface) w OOP — co to? Kontrakt: zbiór metod BEZ implementacji; klasa musi dostarczyć ciała pyt06 PROI OOP interfejs +Interfejs w C++ — oznaczenie? Czysto wirtualne metody (virtual void draw() = 0) pyt06 PROI OOP interfejs_cpp +Klasa abstrakcyjna vs interfejs? Abstrakcyjna może mieć implementację; interfejs = 100% abstrakcyjna pyt06 PROI OOP abstrakcyjna_vs_interfejs +Biblioteka vs framework — co to jest IoC? Library: my code calls library; Framework: framework calls my code (Inversion of Control) pyt06 PROI OOP IoC +Trait / Mixin — do czego służy? Współdzielenie kodu między klasami BEZ dziedziczenia pyt06 PROI OOP trait_mixin +Enkapsulacja (encapsulation) — na czym polega? Ukrywanie szczegółów implementacji za interfejsem publicznym (private, protected, public) pyt06 PROI OOP enkapsulacja +Kto ukuł termin „object-oriented programming"? Alan Kay (Smalltalk, 1970s) pyt06 PROI OOP Kay +Polimorfizm — etymologia? Grec. „poly" = wiele + „morphē" = forma pyt06 PROI OOP polimorfizm_etymologia +Agregacja vs kompozycja? Agregacja = „używa" (obiekt istnieje niezależnie); Kompozycja = „posiada" (obiekt nie istnieje bez właściciela) pyt06 PROI OOP agregacja_vs_kompozycja +Mnemotechnika: „Kompozycja > Dziedziczenie" — kiedy dziedziczenie? Tylko dla prawdziwego „is-a" z polimorfizmem; kompozycja dla reszty pyt06 PROI OOP mnemotechnika +#notetype:Cloze +OOP: 6 metod reużywalności: {{c1::Dziedziczenie}}, {{c2::Kompozycja}}, {{c3::Generyki/Templates}}, {{c4::Interfejsy}}, {{c5::Wzorce projektowe}}, {{c6::Biblioteki/frameworki}} pyt06 PROI OOP metody_cloze +GoF 3 kategorie wzorców: {{c1::kreacyjne}}, {{c2::strukturalne}}, {{c3::behawioralne}} pyt06 PROI OOP GoF_cloze +#notetype:Basic +DNS — co oznacza skrót? Domain Name System pyt07 SKM DNS skrot +Ile jest logicznych root serwerów DNS? 13 (a..m.root-servers.net) pyt07 SKM DNS root_ilosc +Root server — co robi na zapytanie DNS? Odsyła (referral) do serwera TLD — nie zna adresów konkretnych domen pyt07 SKM DNS root_rola +TLD server — przykłady domen, które obsługuje? .com, .pl, .org, .net pyt07 SKM DNS TLD +Authoritative NS — Primary vs Secondary? Primary = oryginalne rekordy (edytowalny); Secondary = kopia (nadmiarowość) pyt07 SKM DNS auth_primary_secondary +Recursive resolver — co robi? Wykonuje pełne rozwiązywanie: pyta root → TLD → authoritative pyt07 SKM DNS recursive +Stub resolver — co to? Prosty klient DNS w OS — wysyła zapytanie do recursive resolvera pyt07 SKM DNS stub +Które serwery DNS zyskują NAJWIĘCEJ na cachingu? Root i TLD — bo najmniej serwerów obsługuje najwięcej ruchu pyt07 SKM DNS caching_odpowiedz +TTL w DNS — co oznacza? Time To Live — czas (w sekundach), przez który odpowiedź jest w cache pyt07 SKM DNS TTL +Typowy TTL root referrals? 48h–7 dni pyt07 SKM DNS TTL_root +Anycast — na czym polega? Ten sam IP z wielu lokalizacji — klient trafia do najbliższego serwera pyt07 SKM DNS anycast +Kto stworzył DNS i kiedy? Paul Mockapetris (1983, RFC 882/883) pyt07 SKM DNS autor +Kolejność zapytań DNS (resolver)? Recursive Resolver → Root → TLD → Authoritative pyt07 SKM DNS kolejnosc +Mnemotechnika: „Piramida DNS"? Root (wierzchołek, najmniej serwerów) → TLD → Auth (podstawa, miliony) pyt07 SKM DNS mnemotechnika +TCP handshake — ile kroków? 3 (three-way): SYN → SYN-ACK → ACK pyt08 SKM TCP handshake_kroki +TCP handshake krok 1: klient wysyła ...? SYN, seq=x (swój ISN) pyt08 SKM TCP handshake_1 +TCP handshake krok 2: serwer odpowiada ...? SYN+ACK, seq=y (swój ISN), ack=x+1 pyt08 SKM TCP handshake_2 +TCP handshake krok 3: klient wysyła ...? ACK, seq=x+1, ack=y+1 pyt08 SKM TCP handshake_3 +3 cele TCP handshake'u? (1) Nawiązanie połączenia (2) Synchronizacja ISN (3) Uzgodnienie parametrów (MSS, Window Scale) pyt08 SKM TCP handshake_cel +W kontekście TCP: co oznacza ISN? Initial Sequence Number — początkowy numer sekwencyjny pyt08 SKM TCP ISN +Dlaczego ISN NIE zaczyna od 0? (2 powody) (1) Bezpieczeństwo — utrudnia TCP hijacking (2) Unikanie kolizji z poprzednimi połączeniami pyt08 SKM TCP ISN_nie_zero +ISN wg RFC 6528 (współczesny)? ISN = M + F(adresy, porty, secret_key) — kryptograficznie losowy pyt08 SKM TCP ISN_rfc6528 +SEQ w TCP — co identyfikuje? Numer pierwszego bajtu danych w segmencie (32-bitowy) pyt08 SKM TCP SEQ +ACK number w TCP — co oznacza? „Odebrałem wszystko do bajtu X−1, czekam na bajt X" (kumulatywne) pyt08 SKM TCP ACK_number +SACK (Selective ACK) — do czego służy? Potwierdzanie niesąsiednich bloków danych (przyspiesza retransmisję) pyt08 SKM TCP SACK +MSS (Maximum Segment Size) — typowa wartość dla Ethernetu? 1460 bajtów (MTU 1500 − 20 IP − 20 TCP) pyt08 SKM TCP MSS +TCP to protokół warstwy ...? Transportowej pyt08 SKM TCP warstwa +SYN — co oznacza? Synchronize pyt08 SKM TCP SYN +ACK — co oznacza? Acknowledge pyt08 SKM TCP ACK +Kto stworzył TCP? Vint Cerf + Bob Kahn (1974) pyt08 SKM TCP autor +TCP (RFC 793) opublikowany w roku ...? 1981 pyt08 SKM TCP RFC +Mnemotechnika: „SYN, SYN-ACK, ACK" — metafora? „Hej!" → „Hej, słyszę!" → „OK, gadamy!" pyt08 SKM TCP mnemotechnika +#notetype:Cloze +TCP handshake: (1) {{c1::SYN, seq=x}} → (2) {{c2::SYN+ACK, seq=y, ack=x+1}} → (3) {{c3::ACK, seq=x+1, ack=y+1}} pyt08 SKM TCP handshake_cloze +DNS hierarchia: {{c1::Root}} → {{c2::TLD}} → {{c3::Authoritative NS}} → odpowiedź pyt07 SKM DNS hierarchia_cloze +#notetype:Basic +Proces vs wątek — pamięć? Proces: własna izolowana; Wątek: współdzielona z procesem pyt09 SOI procesy_watki pamiec +Tworzenie procesu — rząd wielkości czasu? ~1–10 ms pyt09 SOI proces tworzenie +Tworzenie wątku — rząd wielkości czasu? ~10–100 μs (ok. 100× szybciej niż proces) pyt09 SOI watek tworzenie +Przełączanie kontekstu procesu jest wolne z powodu ...? TLB flush (unieważnienie cache translacji adresów) pyt09 SOI context_switch TLB +Wątek — co jest prywatne (nie współdzielone)? Stos, rejestry CPU, PC, TID pyt09 SOI watek prywatne +Wątek — co jest współdzielone z procesem? Kod, dane globalne, heap, otwarte pliki pyt09 SOI watek wspoldzielone +PCB — co przechowuje? PID, stan procesu, rejestry CPU, tablice stron, otwarte pliki, priorytety pyt09 SOI PCB +Stany procesu (5 głównych)? NEW → READY ↔ RUNNING → BLOCKED, TERMINATED pyt09 SOI stany +Race condition — na czym polega? Wynik programu zależy od kolejności operacji wątków na współdzielonych danych pyt09 SOI race_condition +Sekcja krytyczna — co to? Fragment kodu wykonywany przez najwyżej jeden wątek naraz pyt09 SOI sekcja_krytyczna +Deadlock (zakleszczenie) — metafora? Dwa samochody na skrzyżowaniu — oba czekają, nikt nie jedzie pyt09 SOI deadlock +Warunek Coffmana: zasób wyłącznie dla jednego procesu = ...? Mutual Exclusion (wzajemne wykluczanie) pyt09 SOI deadlock coffman_ME +Warunek Coffmana: proces trzyma zasób i czeka na kolejny = ...? Hold and Wait pyt09 SOI deadlock coffman_HW +Warunek Coffmana: zasobów nie można odebrać siłą = ...? No Preemption pyt09 SOI deadlock coffman_NP +Warunek Coffmana: P1→P2→...→P1 = ...? Circular Wait (cykliczne oczekiwanie) pyt09 SOI deadlock coffman_CW +Jak uniknąć deadlocka? Złamać choćby jeden z 4 warunków Coffmana pyt09 SOI deadlock rozwiazanie +Zagłodzenie (starvation) — na czym polega? Wątek nigdy nie dostaje zasobu, bo inni ciągle go wyprzedzają pyt09 SOI starvation +Mutex — na czym polega? Lock na sekcję krytyczną — tylko jeden wątek może go „zamknąć", reszta czeka pyt09 SOI mutex +Semafor — czym różni się od mutexa? Ma licznik — semafor(n) pozwala n wątkom jednocześnie pyt09 SOI semafor +Semafor: P() i V() — co oznaczają? P() = probeer (zmniejsz); V() = verhoog (zwiększ) — holenderski, Dijkstra 1965 pyt09 SOI semafor PV +Spinlock — czym różni się od mutexa? Aktywne czekanie w pętli (busy-wait) zamiast zasypiania pyt09 SOI spinlock +Read-Write Lock — idea? Wielu czytelników jednocześnie LUB jeden pisarz pyt09 SOI rw_lock +Shared Memory jako IPC — dlaczego najszybsza? Brak kopiowania danych (wspólny region pamięci) pyt09 SOI IPC shm +Pipe — kierunek i ograniczenie? Jednokierunkowy; tylko między spokrewnionymi procesami pyt09 SOI IPC pipe +Mnemotechnika: „Proces = mieszkanie, Wątek = pokój"? Mieszkanie ma adres (przestrzeń); pokoje dzielą kuchnię (heap) pyt09 SOI mnemotechnika +Kto opracował semafory? Dijkstra (1965) pyt09 SOI semafor autor +Stronicowanie — jednostka pamięci wirtualnej? Strona (page) — stały rozmiar, typowo 4 KB pyt10 SOI paging strona +Ramka (frame) — co to? Jednostka pamięci FIZYCZNEJ o tym samym rozmiarze co strona pyt10 SOI paging ramka +Tablica stron (page table) — co robi? Tłumaczy numer strony → numer ramki pyt10 SOI paging tablica_stron +Translacja adresu: adres wirtualny = ? [numer strony | offset] → [numer ramki | offset] pyt10 SOI paging translacja +TLB — co to i po co? Translation Lookaside Buffer — sprzętowy cache translacji adresów (hit: ~1 ns) pyt10 SOI TLB +TLB — typowy hit rate? >99% pyt10 SOI TLB hitrate +Page fault — co to? Wyjątek sprzętowy: strona nie jest w RAM → OS ładuje z dysku (swap) pyt10 SOI page_fault +Koszt page fault vs dostęp do RAM? ~1–10 ms vs ~100 ns — różnica ~10 000× pyt10 SOI page_fault koszt +Fragmentacja zewnętrzna (external) — na czym polega? Wolna pamięć rozproszona w małych kawałkach — suma wystarczy, ale żaden nie jest dość duży pyt10 SOI fragmentacja_zewnetrzna +Fragmentacja wewnętrzna (internal) — na czym polega? Przydzielony blok większy niż potrzebny (np. strona 4KB dla 100 bajtów) pyt10 SOI fragmentacja_wewnetrzna +Stronicowanie — jaki typ fragmentacji? Wewnętrzna pyt10 SOI paging fragmentacja +Segmentacja — jaki typ fragmentacji? Zewnętrzna pyt10 SOI segmentacja fragmentacja +Segmentacja — adres = ? (numer segmentu, offset); tablica segmentów: (baza, limit) pyt10 SOI segmentacja adres +Dlaczego stronicowanie wygrało nad segmentacją? Stałe rozmiary stron = brak fragmentacji zewnętrznej, prostsze zarządzanie sprzętowe pyt10 SOI paging_vs_seg +COW (Copy-on-Write) — na czym polega? Przy fork() dziecko współdzieli strony; kopia fizyczna dopiero przy zapisie pyt10 SOI COW +Algorytm wymiany stron LRU? Least Recently Used — usuń najdawniej używaną stronę pyt10 SOI LRU +Algorytm FIFO — problem? Anomalia Bélády'ego: więcej ramek → więcej page faults pyt10 SOI FIFO anomalia +Algorytm Clock (Second Chance) — idea? Przybliżenie LRU: wskazówka + bit odwołania; bit=1 → zeruj i idź dalej; bit=0 → wymień pyt10 SOI Clock +Wielopoziomowe tablice stron w x86-64? 4 poziomy: PML4 → PDPT → PD → PT pyt10 SOI tablica_4level +Swap — co to? Przestrzeń na dysku dla stron gdy RAM się wyczerpie pyt10 SOI swap +Mnemotechnika: stronicowanie vs segmentacja? Stronicowanie = szuflady jednakowe; Segmentacja = pudełka różnej wielkości pyt10 SOI mnemotechnika +#notetype:Cloze +Warunki Coffmana (deadlock): {{c1::Mutual Exclusion}}, {{c2::Hold and Wait}}, {{c3::No Preemption}}, {{c4::Circular Wait}} pyt09 SOI deadlock coffman_cloze +Segmenty pamięci procesu (od dołu): {{c1::TEXT}} → {{c2::DATA}} → {{c3::BSS}} → {{c4::HEAP ↑}} → {{c5::STACK ↓}} pyt09 SOI segmenty_cloze +Stronicowanie: {{c1::wewnętrzna}} fragmentacja, stały rozmiar; Segmentacja: {{c2::zewnętrzna}} fragmentacja, zmienny rozmiar pyt10 SOI frag_cloze +Algorytmy wymiany stron: {{c1::FIFO}} (prosty, anomalia), {{c2::LRU}} (optymalny praktyczny), {{c3::Clock}} (przybliżenie LRU), {{c4::Optimal}} (nierealizowalny benchmark) pyt10 SOI algorytmy_cloze +#notetype:Basic +BPMN — co oznacza skrót? Business Process Model and Notation pyt11 WSYZ BPMN skrot +Kto utrzymuje standard BPMN? OMG (Object Management Group) pyt11 WSYZ BPMN OMG +Bramka XOR w BPMN? Dokładnie JEDNA ścieżka (jak if/else) pyt11 WSYZ BPMN XOR +Bramka AND w BPMN? WSZYSTKIE ścieżki jednocześnie (parallel) pyt11 WSYZ BPMN AND +Bramka OR (inclusive) w BPMN? Jedna LUB więcej ścieżek pyt11 WSYZ BPMN OR +Swimlane w BPMN: Pool vs Lane? Pool = organizacja/uczestnik; Lane = dział/rola wewnątrz pyt11 WSYZ BPMN swimlane +BPMN 2.0 — kluczowa zaleta formatu XML? Diagramy mogą być bezpośrednio wykonywane przez silnik procesów (BPMS) pyt11 WSYZ BPMN XML +UML Activity Diagram vs BPMN — główna różnica w odbiorcach? UML: głównie IT; BPMN: biznes + IT pyt11 WSYZ UML_vs_BPMN +EPC — w jakim środowisku popularny? SAP (framework ARIS) pyt11 WSYZ EPC SAP +Dijkstra, Bellman-Ford, A* — jaki model sieciowy? Najkrótsza ścieżka (shortest path) pyt12 WSYZ shortest_path +Ford-Fulkerson — jaki problem rozwiązuje? Maksymalny przepływ (max flow) pyt12 WSYZ max_flow +Twierdzenie max-flow min-cut mówi, że ...? Maksymalny przepływ = minimalna przepustowość przekroju pyt12 WSYZ max_flow_min_cut +Algorytm węgierski — jaki problem, jaka złożoność? Problem przydziału (n zadań do n osób), O(n³) pyt12 WSYZ hungarian +TSP (problem komiwojażera) — klasa złożoności? NP-trudny pyt12 WSYZ TSP +CPM (Critical Path Method) — co wyznacza? Ścieżkę krytyczną = najdłuższą ścieżkę w grafie zadań pyt12 WSYZ CPM +PERT vs CPM — główna różnica? PERT uwzględnia niepewność czasu (rozkład β: optymist., pesymist., prawdopod.) pyt12 WSYZ PERT +MST — Kruskal vs Prim (idea)? Kruskal: sortuj krawędzie, dodawaj najtańszą bez cyklu; Prim: rośnij drzewo od węzła pyt12 WSYZ MST +TOGAF — 4 domeny? Business, Data, Application, Technology pyt13_27 AIS TOGAF domeny +TOGAF ADM — co to? Architecture Development Method — cykliczny proces tworzenia architektury pyt13_27 AIS TOGAF ADM +4+1 View Model (Kruchten) — 5 perspektyw? Logical, Process, Development, Physical + Scenarios pyt13_27 AIS Kruchten +C4 Model — 4 poziomy zoomu? Context → Container → Component → Code pyt13_27 AIS C4 +Zachman Framework — co definiuje? Taksonomia 6×6: CO/JAK/GDZIE/KTO/KIEDY/DLACZEGO × poziomy abstrakcji pyt13_27 AIS Zachman +ArchiMate — 3 warstwy? Business, Application, Technology pyt13_27 AIS ArchiMate warstwy +ATAM — co to? Architecture Tradeoff Analysis Method — ocena architektury przez scenariusze jakościowe (SEI) pyt13_27 AIS ATAM +ADR (Architecture Decision Records) — co zawiera? Kontekst, decyzję, konsekwencje (w repo, wersjonowane) pyt13_27 AIS ADR +Kto zaproponował 4+1 View Model? Philippe Kruchten (1995) pyt13_27 AIS Kruchten autor +Wzorzec architektoniczny vs projektowy — skala? Architektoniczny: cały system; Projektowy: klasa/obiekt pyt14_28 AIS wzorzec skala +Layered (warstwowy) — kolejność warstw? Presentation → Business Logic → Data Access → Database pyt14_28 AIS Layered +Microservices — kluczowa zaleta? Niezależne skalowanie i deployment per serwis pyt14_28 AIS Microservices zaleta +Microservices — kluczowa wada? Złożoność operacyjna (sieć, monitoring, transakcje rozproszone) pyt14_28 AIS Microservices wada +Event-Driven Architecture — mechanizm komunikacji? Producer → Event Broker (np. Kafka) → Consumers pyt14_28 AIS EDA +CQRS — na czym polega? Osobne modele do zapisu (Command) i odczytu (Query) pyt14_28 AIS CQRS +Hexagonal (Ports & Adapters) — kluczowa korzyść? Rdzeń domeny niezależny od frameworków — testowalność pyt14_28 AIS Hexagonal +POSA — co to za katalog wzorców? Pattern-Oriented Software Architecture (5 tomów, wzorce architektoniczne) pyt14_28 AIS POSA +EIP — co to za katalog? Enterprise Integration Patterns (Hohpe & Woolf, 2003) — wzorce komunikacji pyt14_28 AIS EIP +PoEAA — autor? Martin Fowler (2002) pyt14_28 AIS PoEAA +Eventual consistency — co oznacza? Dane mogą być chwilowo niespójne, ale „w końcu" się zsynchronizują pyt14_28 AIS eventual_consistency +Cykl agenta upostaciowionego: See-Think-Act = ? Percepcja → Deliberacja → Akcja pyt15 ROB agent cykl +3T Architecture — 3 warstwy sterownika robota? Planner (sekundy–minuty) → Sequencer (100ms–s) → Controller (ms) pyt15 ROB 3T +BDI — co oznaczają litery? Beliefs (wiedza), Desires (cele), Intentions (aktualny plan) pyt15 ROB BDI +Behavior Tree: Selector (?) — jak działa? Wykonuj dzieci po kolei aż PIERWSZY sukces (jak OR) pyt15 ROB BT Selector +Behavior Tree: Sequence (→) — jak działa? Wykonuj dzieci po kolei, wstrzymaj przy PORAŻCE (jak AND) pyt15 ROB BT Sequence +LTL: □ (always) i ◇ (eventually) — przykład safety i liveness? Safety: □(¬collision); Liveness: ◇(at_goal) pyt15 ROB LTL +PID — 3 składniki? P = proporcjonalny, I = całkowy (drift), D = różniczkowy (oscylacje) pyt15 ROB PID +ROS — co to NIE jest? Nie jest prawdziwym OS — to middleware (pub/sub) pyt15 ROB ROS +Klasyfikacja języków robotów: T-R-M-S? Task → Robot → Motion → Servo (od najwyższej abstrakcji) pyt16 ROB TRMS +RAPID — producent? ABB pyt16 ROB RAPID +KRL — producent? KUKA pyt16 ROB KRL +Karel — producent i etymologia? FANUC; od Karla Čapka (który ukuł słowo „robot") pyt16 ROB Karel +Online programming (teach-in) — na czym polega? Operator prowadzi robota „za rękę", robot zapamiętuje punkty pyt16 ROB teach-in +Offline programming — zaleta nad online? Bez zatrzymywania produkcji (programowanie w symulacji) pyt16 ROB offline +Vendor lock-in w robotyce — na czym polega? Każdy producent ma WŁASNY język — program nie działa na robocie innej firmy pyt16 ROB vendor_lock +Kinematyka odwrotna (IK) — co oblicza? Kąty w stawach robota, aby efektor znalazł się w zadanej pozycji pyt16 ROB IK +Kto ukuł słowo „robot"? Karel Čapek (R.U.R., 1920); cz. „robota" = ciężka praca pyt16 ROB robot_etymologia +#notetype:Cloze +BPMN bramki: {{c1::XOR}} = dokładnie jedna; {{c2::AND}} = wszystkie; {{c3::OR}} = jedna lub więcej pyt11 WSYZ BPMN bramki_cloze +C4: {{c1::Context}} → {{c2::Container}} → {{c3::Component}} → {{c4::Code}} pyt13_27 AIS C4_cloze +BDI: B = {{c1::Beliefs}}, D = {{c2::Desires}}, I = {{c3::Intentions}} pyt15 ROB BDI_cloze +3T: {{c1::Planner}} (min) → {{c2::Sequencer}} (s) → {{c3::Controller}} (ms) pyt15 ROB 3T_cloze +Klasyfikacja języków robotów: {{c1::Task}} → {{c2::Robot}} → {{c3::Motion}} → {{c4::Servo}} pyt16 ROB TRMS_cloze + +#notetype:Basic +Czym jest szeregowanie zadań (scheduling)? Przydzielanie zadań do maszyn w czasie w celu optymalizacji wybranego kryterium pyt17 WSYZ szeregowanie_def +Jak nazywa się standardowa notacja opisu problemu szeregowania? Notacja Grahama (α | β | γ) pyt17 WSYZ Graham_notacja +Co oznacza pole α w notacji Grahama? Środowisko maszynowe (ile i jakie maszyny) pyt17 WSYZ Graham_alpha +Co oznacza pole β w notacji Grahama? Charakterystyki zadań (ograniczenia) pyt17 WSYZ Graham_beta +Co oznacza pole γ w notacji Grahama? Kryterium optymalizacji pyt17 WSYZ Graham_gamma +Co oznacza Cmax (makespan)? Czas ukończenia OSTATNIEGO zadania pyt17 WSYZ Cmax +Co oznacza ΣCⱼ jako kryterium szeregowania? Suma czasów ukończenia (minimalizacja → min. średniego czasu) pyt17 WSYZ sumCj +Co oznacza Lmax jako kryterium szeregowania? Maksymalne opóźnienie: max(Cⱼ − dⱼ) pyt17 WSYZ Lmax +Czym jest flow shop? Środowisko, w którym zadania przechodzą przez maszyny w tej samej kolejności (jak taśma) pyt17 WSYZ flow_shop +Czym jest job shop? Środowisko, w którym każde zadanie ma indywidualną trasę przez maszyny pyt17 WSYZ job_shop +Reguła SPT (Shortest Processing Time) — co mówi? Wykonuj najkrótsze zadanie najpierw pyt17 WSYZ SPT +Dla jakiego problemu SPT jest optymalna? 1 || ΣCⱼ (1 maszyna, min. suma czasów ukończenia) pyt17 WSYZ SPT_problem +Reguła EDD (Earliest Due Date) — co mówi? Wykonuj najpierw zadanie z najwcześniejszym terminem pyt17 WSYZ EDD +Dla jakiego problemu EDD jest optymalna? 1 || Lmax (1 maszyna, min. max. opóźnienia) pyt17 WSYZ EDD_problem +Algorytm Johnsona — do jakiego problemu jest optymalny? F2 || Cmax (flow shop, 2 maszyny, min. makespan) pyt17 WSYZ Johnson_problem +Algorytm Johnsona — zasada: jeśli min czas jest na maszynie 1, to ...? Zadanie na początek pyt17 WSYZ Johnson_M1 +Algorytm Johnsona — zasada: jeśli min czas jest na maszynie 2, to ...? Zadanie na koniec pyt17 WSYZ Johnson_M2 +Czy Job shop scheduling jest NP-trudny? Tak, już dla 3 maszyn pyt17 WSYZ jobshop_NP +Czy Pm||Cmax jest NP-trudny? Tak, dla m ≥ 2 pyt17 WSYZ Pm_NP +Czym jest preemption (wywłaszczanie) w szeregowaniu? Możliwość przerwania zadania i dokończenia go później pyt17 WSYZ preemption +Kto jest autorem notacji Grahama? Ronald Graham (Bell Labs, lata 1966–1979) pyt17 WSYZ Graham_autor +Ronald Graham opracował ...? Notację α|β|γ do opisu problemów szeregowania pyt17 WSYZ Graham_autor_rev +Kto opracował algorytm optymalny dla F2||Cmax? Selmer Johnson (RAND, 1954) pyt17 WSYZ Johnson_autor +Mnemotechnika: α|β|γ =? Maszyny | Zadania | Cel pyt17 WSYZ mnemotechnika_abg + +#notetype:Cloze +Notacja Grahama: {{c1::α}} = maszyny, {{c2::β}} = zadania, {{c3::γ}} = kryterium pyt17 WSYZ Graham_cloze +SPT jest optymalne dla {{c1::1 || ΣCⱼ}}, EDD dla {{c2::1 || Lmax}}, Johnson dla {{c3::F2 || Cmax}} pyt17 WSYZ reguły_cloze + +#notetype:Basic +Czym jest łańcuch dostaw (supply chain)? Sieć organizacji od surowca do klienta końcowego: dostawcy → producenci → dystrybutorzy → detaliści → klienci pyt18 WSYZ łańcuch_def +Czym jest Bullwhip Effect (efekt byczego bicza)? Amplifikacja wahań popytu w górę łańcucha dostaw (mała zmiana u detalisty → coraz większe wahania wyżej) pyt18 WSYZ bullwhip_def +Kto nadał nazwę „Bullwhip Effect"? Procter & Gamble (1990s); zjawisko opisał Jay Forrester (MIT, 1961) pyt18 WSYZ bullwhip_autor +Podaj przyczyny Bullwhip Effect (jedną z czterech). Prognozowanie, zamawianie partiami, promocje cenowe, racjonowanie przy niedoborach pyt18 WSYZ bullwhip_przyczyny +Trzy kategorie kosztów zapasów to ...? Koszt utrzymania (h), zamawiania (K), braku (p) pyt18 WSYZ koszty +Koszt utrzymania zapasów (holding cost, h) obejmuje ...? Magazyn, ubezpieczenie, koszt kapitału, utrata wartości (15–30% wartości towaru/rok) pyt18 WSYZ holding_cost +Koszt zamawiania (ordering cost, K) — od czego zależy? Stały koszt per zamówienie (transport, admin), niezależny od ilości pyt18 WSYZ ordering_cost +Co to jest EOQ (Economic Order Quantity)? Model Harrisa-Wilsona (1913) — optymalna wielkość zamówienia minimalizująca łączny koszt pyt18 WSYZ EOQ_def +Kto opracował model EOQ i kiedy? Ford W. Harris (1913, „How Many Parts To Make At Once") pyt18 WSYZ EOQ_autor +Ford W. Harris (1913) opracował model ...? EOQ (Economic Order Quantity) pyt18 WSYZ EOQ_autor_rev +Jakie są założenia modelu EOQ? Popyt stały i znany (D), lead time = 0, brak braków, koszt zamówienia K, koszt utrzymania h pyt18 WSYZ EOQ_założenia +Dlaczego w EOQ optimum ma postać √? (intuicja) Koszty zamawiania maleją z Q, koszty utrzymania rosną z Q → optimum w punkcie przecięcia pyt18 WSYZ EOQ_intuicja +Co to jest ROP (Reorder Point)? Poziom zapasu, przy którym składamy nowe zamówienie: ROP = d × L + SS pyt18 WSYZ ROP_def +Co to jest Safety Stock (zapas bezpieczeństwa)? Dodatkowy bufor na wahania popytu/opóźnienia dostawy: SS = z × σ_L pyt18 WSYZ safety_stock +Co to jest lead time (L)? Czas od złożenia zamówienia do otrzymania dostawy pyt18 WSYZ lead_time +Model zapasów (s, Q) — co oznacza? Gdy stan spadnie do s, zamów dokładnie Q sztuk pyt18 WSYZ model_sQ +Model zapasów (s, S) — co oznacza? Gdy stan spadnie do s, zamów „do poziomu S" (order-up-to) pyt18 WSYZ model_sS +Model zapasów (R, S) — co oznacza? Co R dni (stały cykl) zamów „do poziomu S" pyt18 WSYZ model_RS +Co to VMI (Vendor Managed Inventory)? Dostawca zarządza zapasami klienta (np. Walmart + P&G) pyt18 WSYZ VMI +Przykład EOQ: D=10000, K=100, h=2 → Q*=? 1000 szt pyt18 WSYZ EOQ_przykład + +#notetype:Cloze +EOQ: Q* = {{c1::√(2KD/h)}} pyt18 WSYZ EOQ_wzór +TC(Q) = {{c1::K·D/Q}} + {{c2::h·Q/2}} (koszt zamawiania + utrzymania) pyt18 WSYZ TC_cloze +Optymalny koszt EOQ: TC* = {{c1::√(2KDh)}} pyt18 WSYZ TC_opt_cloze +ROP = {{c1::d × L}} + {{c2::SS}} pyt18 WSYZ ROP_cloze +SS = {{c1::z}} × {{c2::σ_L}} (z = kwantyl normalny, σ_L = odch. std. popytu w lead time) pyt18 WSYZ SS_cloze + +#notetype:Basic +Czym jest wzorzec Pub/Sub (Publish-Subscribe)? Wzorzec komunikacji: nadawcy wysyłają wiadomości do brokera, odbiorcy subskrybują — nadawca nie wie kto odbiera pyt19_29 AIS pubsub_def +Kim jest Publisher w Pub/Sub? Komponent wysyłający wiadomości do brokera, nie wie kto subskrybuje pyt19_29 AIS publisher +Kim jest Subscriber w Pub/Sub? Komponent rejestrujący się u brokera na określone tematy/typy wiadomości pyt19_29 AIS subscriber +Czym jest Broker w Pub/Sub? Centralny komponent routujący wiadomości od publishers do subscribers pyt19_29 AIS broker +Co to luźne powiązanie (loose coupling) w Pub/Sub? Publisher i subscriber nie znają się nawzajem — można dodać subscribera bez zmiany publishera pyt19_29 AIS loose_coupling +Subskrypcja topic-based polega na ...? Subscriber subskrybuje temat (np. „orders.created") — najprostszy typ pyt19_29 AIS topic_based +Subskrypcja content-based polega na ...? Filtrowanie po treści wiadomości (np. „price > 100") — elastyczniejszy, ale wolniejszy pyt19_29 AIS content_based +QoS At-most-once — co gwarantuje? Wiadomość dostarczana 0 lub 1 raz (fire and forget) — najszybszy, ryzyko utraty pyt19_29 AIS at_most_once +QoS At-least-once — co gwarantuje? Wiadomość dostarczana ≥1 raz — mogą być duplikaty pyt19_29 AIS at_least_once +QoS Exactly-once — co gwarantuje? Wiadomość dokładnie 1 raz — najtrudniejszy do zaimplementowania pyt19_29 AIS exactly_once +Kafka — jaki model (push/pull)? Pull (consumer sam ciągnie ze logu) pyt19_29 AIS kafka_model +Kafka — czy przechowuje wiadomości? Tak, na dysku (retention 7 dni domyślnie) — rozproszony log append-only pyt19_29 AIS kafka_persistence +Kto stworzył Apache Kafka i kiedy? Jay Kreps, LinkedIn, 2011 pyt19_29 AIS kafka_autor +Dlaczego Kafka nazywa się „Kafka"? Od Franza Kafki — „system zoptymalizowany do pisania, a Kafka był pisarzem" pyt19_29 AIS kafka_nazwa +RabbitMQ — jaki model (push/pull)? Push (broker dostarcza do konsumenta) pyt19_29 AIS rabbitmq_model +RabbitMQ — jaki protokół? AMQP (Advanced Message Queuing Protocol) pyt19_29 AIS rabbitmq_amqp +RabbitMQ Exchange types (wymień)? Direct, Topic, Fanout, Headers pyt19_29 AIS rabbitmq_exchange +MQTT — do czego zaprojektowany? IoT i urządzenia z ograniczonymi zasobami (2-bajtowy nagłówek) pyt19_29 AIS mqtt_usecase +MQTT — kto stworzył i kiedy? Andy Stanford-Clark (IBM) + Arlen Nipper (1999) — monitoring rurociągów naftowych pyt19_29 AIS mqtt_autor +Redis Pub/Sub — czy ma persistencję? Nie — jeśli subscriber offline, wiadomość przepada pyt19_29 AIS redis_persistence +Co to SPOF w kontekście Pub/Sub? Broker jako Single Point of Failure — rozwiązanie: klasteryzacja pyt19_29 AIS SPOF +Kafka vs RabbitMQ — kluczowa różnica modelu? Kafka = log (przechowuje historię), RabbitMQ = queue (konsumuje i kasuje) pyt19_29 AIS kafka_vs_rabbit +Mnemotechnika: „Pub/Sub = ..."? Radio — nadawca nadaje, kto chce słucha pyt19_29 AIS mnemotechnika + +#notetype:Cloze +QoS: {{c1::At-most-once}} (0–1), {{c2::At-least-once}} (≥1, duplikaty), {{c3::Exactly-once}} (dokładnie 1) pyt19_29 AIS QoS_cloze +AMQP Exchange types: {{c1::Direct}}, {{c2::Topic}}, {{c3::Fanout}}, {{c4::Headers}} pyt19_29 AIS exchange_cloze + +#notetype:Basic +Czym są dane strumieniowe (streaming data)? Ciągły, potencjalnie nieskończony przepływ zdarzeń przychodzących w czasie rzeczywistym pyt20_30 AIS streaming_def +Batch vs Streaming — kluczowa różnica? Batch: cały zbiór → analiza (minuty/h); Streaming: event po event → analiza ciągła (ms/s) pyt20_30 AIS batch_vs_stream +Event Time vs Processing Time — czym się różnią? Event Time = kiedy zdarzenie nastąpiło; Processing Time = kiedy system je przetwarza pyt20_30 AIS event_vs_proc_time +Co to Watermark w strumieniach? Znacznik postępu: „z dużym prawdopodobieństwem nie przyjdą już zdarzenia z event time < W" pyt20_30 AIS watermark +Tumbling window — czym jest? Okno stałego rozmiaru, rozłączne (0 nakładania) pyt20_30 AIS tumbling +Sliding window — czym jest? Okno stałego rozmiaru + krok przesunięcia, nakładające się pyt20_30 AIS sliding +Session window — czym jest? Okno dynamicznego rozmiaru oparte na aktywności (nowa sesja po przerwie) pyt20_30 AIS session +Global window — czym jest? Jedno okno na cały strumień; trigger decyduje emisję wyniku pyt20_30 AIS global +True streaming vs Micro-batch — różnica? True streaming: event-by-event (niższa latencja); Micro-batch: małe paczki np. co 100ms pyt20_30 AIS true_vs_micro +Kafka Streams — czy to klaster? Nie — to biblioteka (library) działająca w procesie aplikacji Java pyt20_30 AIS kafka_streams_typ +Apache Flink — jaki model przetwarzania? True streaming, bardzo niska latencja (<10ms) pyt20_30 AIS flink_model +Spark Streaming — jaki model przetwarzania? Micro-batch (~100ms+), średnia latencja pyt20_30 AIS spark_model +Skąd nazwa „Flink"? Niem. „flink" = zwinny/szybki (TU Berlin, 2014) pyt20_30 AIS flink_nazwa +HyperLogLog — do czego służy? Estymacja liczby unikalnych elementów (cardinality), O(1) pamięci (~1.5 KB), ~2% błędu pyt20_30 AIS HLL +Count-Min Sketch — do czego służy? Estymacja częstości elementów, gwarantuje overestimates (nigdy nie zaniży) pyt20_30 AIS CMS +Reservoir Sampling — do czego służy? Równomierne próbkowanie k elementów ze strumienia o nieznanym rozmiarze n, O(k) pamięci pyt20_30 AIS reservoir +Strategie obsługi spóźnionych danych (late data) — wymień jedną z czterech. Drop, Recompute, Side output, Allowed lateness pyt20_30 AIS late_data +Kto opracował HyperLogLog? Philippe Flajolet et al. (2007) pyt20_30 AIS HLL_autor +Kto opracował Count-Min Sketch? Cormode & Muthukrishnan (2005) pyt20_30 AIS CMS_autor +Mnemotechnika: 4 okna = „TSSG" — co to? Tumbling, Sliding, Session, Global pyt20_30 AIS mnemotechnika_TSSG + +#notetype:Cloze +4 okna: {{c1::Tumbling}} (rozłączne), {{c2::Sliding}} (nakładające), {{c3::Session}} (aktywność), {{c4::Global}} (jedno) pyt20_30 AIS okna_cloze +HyperLogLog: {{c1::cardinality}} (ile unikalnych), O(1) space, ~{{c2::2}}% error pyt20_30 AIS HLL_cloze + +#notetype:Basic +Dlaczego w systemie rozproszonym potrzebne są zegary logiczne? Brak globalnego zegara — zegary fizyczne driftują, nie można polegać na nich do ustalenia kolejności zdarzeń pyt21 SR zegary_dlaczego +Czym jest relacja happened-before (→)? Porządek częściowy zdarzeń: a→b w jednym procesie, send→recv, przechodniość (Lamport, 1978) pyt21 SR happened_before +Kiedy zdarzenia a i b są współbieżne (a || b)? Gdy ani a→b, ani b→a — brak związku przyczynowego pyt21 SR współbieżne +Zegar Lamporta — jaki typ danych? Skalar (jeden licznik per proces) pyt21 SR lamport_typ +Zegar Lamporta — algorytm przy odbieraniu (timestamp t)? C_i = max(C_i, t) + 1 pyt21 SR lamport_recv +Zegar Lamporta: a→b ⟹ C(a) < C(b)? TAK pyt21 SR lamport_implikacja +Zegar Lamporta: C(a) < C(b) ⟹ a→b? NIE — Lamport nie wykrywa współbieżności pyt21 SR lamport_odwrotna +Zegar wektorowy — jaki typ danych? Wektor V[1..N] (N = liczba procesów) pyt21 SR vector_typ +V_i[j] w zegarze wektorowym oznacza ...? Ile zdarzeń procesu j jest znanych procesowi i pyt21 SR vector_meaning +Zegar wektorowy — algorytm przy odbieraniu (wektor T)? V_i[j] = max(V_i[j], T[j]) ∀j, potem V_i[i]++ pyt21 SR vector_recv +Zegar wektorowy: V(a) < V(b) ⟺ a→b? TAK — pełna charakteryzacja happened-before (równoważność!) pyt21 SR vector_equivalence +V(a) < V(b) zachodzi gdy ...? ∀i: V(a)[i] ≤ V(b)[i] i ∃j: V(a)[j] < V(b)[j] pyt21 SR vector_lt +V(a) || V(b) (współbieżne) zachodzi gdy ...? ¬(V(a) ≤ V(b)) ∧ ¬(V(b) ≤ V(a)) pyt21 SR vector_concurrent +Rozmiar per zdarzenie: Lamport vs Vector? Lamport: O(1); Vector: O(N) pyt21 SR rozmiar_porównanie +Dlaczego O(N) w zegarach wektorowych to problem? W systemie z 1000 węzłów każda wiadomość niesie wektor 1000 liczb — duży overhead pyt21 SR vector_overhead +Kto zaproponował zegar Lamporta? Leslie Lamport (1978, „Time, Clocks, and the Ordering of Events...") pyt21 SR lamport_autor +Leslie Lamport (1978) zaproponował ...? Zegar skalarny (Lamport clock) i relację happened-before pyt21 SR lamport_autor_rev +Kto zaproponował zegary wektorowe? Friedemann Mattern i Colin Fidge (niezależnie, 1988) pyt21 SR vector_autorzy +Co to version vectors (wektory wersji)? Mechanizm replikacji danych (np. Amazon Dynamo) do wykrywania konfliktów przy współbieżnych zapisach pyt21 SR version_vectors +Co to causal broadcast? Protokół rozsyłania wiadomości zachowujący porządek przyczynowy (B zależne od A → A dostarczane przed B) pyt21 SR causal_broadcast + +#notetype:Cloze +Lamport: a→b ⟹ C(a) N gwarantuje odczyt najnowszej wartości pyt22 SR quorum +Co to CRDTs? Conflict-free Replicated Data Types — struktury danych automatycznie zbiegające do spójnego stanu bez koordynacji pyt22 SR CRDTs +Co to LWW (Last-Writer-Wins)? Mechanizm rozwiązywania konfliktów: wygrywa zapis z najnowszym timestampem pyt22 SR LWW +Co to consensus (uzgadnianie)? Protokół, w którym rozproszone węzły zgadzają się na jedną wartość pomimo awarii pyt22 SR consensus +Algorytmy consensus — wymień trzy. Paxos (Lamport), Raft (prostszy), Zab (Zookeeper) pyt22 SR consensus_algo +Spektrum spójności od silnej do słabej? Linearizability → Sequential → Causal → Session → Eventual pyt22 SR spektrum +Kto zdefiniował linearizability? Maurice Herlihy + Jeannette Wing (1990) pyt22 SR linearizability_autor +Mnemotechnika: „Linearizable = ..."? Natychmiast, atomowo, jak 1 kopia pyt22 SR mnemotechnika_lin +Mnemotechnika: „Eventual = ..."? Kiedyś się zsynchronizuje (ale kiedy?) pyt22 SR mnemotechnika_ev +Mnemotechnika: Quorum W+R > N gwarantuje ...? Odczyt najnowszej wartości pyt22 SR mnemotechnika_quorum + +#notetype:Cloze +Spektrum spójności: {{c1::Linearizability}} → {{c2::Sequential}} → {{c3::Causal}} → {{c4::Session}} → {{c5::Eventual}} pyt22 SR spektrum_cloze +Quorum: {{c1::W}} + {{c2::R}} > {{c3::N}} → gwarantuje odczyt najnowszej wartości pyt22 SR quorum_cloze +CAP: przy partycji wybierz {{c1::C}} (spójność) lub {{c2::A}} (dostępność) pyt22 SR CAP_cloze + +#notetype:Basic +Czym jest segmentacja obrazu? Podział obrazu na regiony — każdy piksel dostaje etykietę klasy (np. samochód, droga, niebo) pyt23 CV segmentacja_def +Semantic segmentation — co robi? Każdy piksel → klasa, ale NIE rozróżnia instancji (wszystkie samochody = „samochód") pyt23 CV semantic +Instance segmentation — czym różni się od semantic? Rozróżnia instancje tego samego obiektu (samochód#1 ≠ samochód#2) pyt23 CV instance +Panoptic segmentation — co łączy? Semantic + Instance: „things" (obiekty) mają instancje, „stuff" (niebo, droga) tylko klasy pyt23 CV panoptic +Thresholding (progowanie) — na czym polega? Piksel > próg → klasa 1, inaczej → klasa 0; Otsu = automatyczny dobór progu pyt23 CV thresholding +Co to metoda Otsu? Automatyczny dobór progu minimalizujący wariancję wewnątrzklasową (Nobuyuki Otsu, 1979) pyt23 CV otsu +Region Growing — na czym polega? Zacznij od seeda, dodawaj sąsiednie piksele o podobnej wartości pyt23 CV region_growing +Watershed — na czym polega? Traktuje obraz jak mapę topograficzną, „zalewa" od minimów; granice = granie pyt23 CV watershed +Wada Region Growing i Watershed? Over-segmentation (nadmierna fragmentacja) pyt23 CV overseg +Normalized Cuts — złożoność? O(n³) pyt23 CV norm_cuts +Co to architektura Encoder-Decoder w segmentacji? Encoder zmniejsza rozdzielczość (cechy), Decoder zwiększa (mapa segmentacji) pyt23 CV encoder_decoder +Co to skip connections? Połączenia „na skróty" z encodera do decodera przenoszące detale przestrzenne pyt23 CV skip_connections +FCN (2015) — co wprowadził? Pierwsza sieć fully convolutional do segmentacji — wejście dowolnego rozmiaru pyt23 CV FCN +U-Net (2015) — kluczowe cechy? Encoder-decoder w kształcie „U" ze skip connections (concat), dominuje w segmentacji medycznej pyt23 CV unet +DeepLab v3+ — kluczowa innowacja? Atrous (dilated) convolutions — większe receptive field bez dodatkowych parametrów pyt23 CV deeplab +Co to atrous/dilated convolution? Konwolucja z „dziurami" (fr. à trous) — zwiększa receptive field bez dodatkowych parametrów pyt23 CV atrous +Co to ASPP w DeepLab? Atrous Spatial Pyramid Pooling — wieloskalowe cechy równolegle pyt23 CV ASPP +mIoU — czym jest? Mean Intersection over Union — standardowa metryka segmentacji (IoU per klasa, potem średnia) pyt23 CV mIoU +Co to Dice Loss? Funkcja kosztu: 2·|A∩B| / (|A|+|B|), popularna w segmentacji medycznej pyt23 CV dice_loss +Co to Focal Loss? Modyfikacja cross-entropy redukująca wpływ łatwych przykładów, dla class imbalance pyt23 CV focal_loss +Kto stworzył U-Net? Ronneberger et al. (Freiburg, 2015) pyt23 CV unet_autor +Mnemotechnika: U-Net = ...? U-shape + skip connections (encoder-decoder) pyt23 CV mnemotechnika_unet +Mnemotechnika: DeepLab = ...? Atrous (dilated) convolutions + ASPP pyt23 CV mnemotechnika_deeplab + +#notetype:Cloze +Typy segmentacji: {{c1::Semantic}} (klasa per piksel), {{c2::Instance}} (rozróżnia instancje), {{c3::Panoptic}} (unified) pyt23 CV typy_cloze +mIoU = {{c1::Intersection}} / {{c2::Union}}, uśrednione per klasa pyt23 CV mIoU_cloze + + +#notetype:Basic +Czym jest detekcja obiektów? Zlokalizuj obiekty na obrazie (bounding box) i przypisz klasy — wynik: (klasa, bbox, confidence) pyt24 CV detekcja_def +Klasyfikacja vs Detekcja vs Segmentacja — różnica? Klasyfikacja: 1 label na obraz; Detekcja: bbox + label; Segmentacja: maska per piksel pyt24 CV klas_vs_det_vs_seg +Co to bounding box (bbox)? Prostokąt ograniczający opisujący położenie obiektu: (x_min, y_min, x_max, y_max) pyt24 CV bbox +Co to sliding window w detekcji? Wytnij fragment obrazu (wiele rozmiarów/pozycji), sklasyfikuj każdy — ekstremalnie wolne pyt24 CV sliding_window +HOG — czym jest? Histogram of Oriented Gradients — deskryptor cech opisujący kształt (kierunki krawędzi) pyt24 CV HOG +Kto opracował HOG do detekcji pieszych? Dalal & Triggs (2005) pyt24 CV HOG_autor +Viola-Jones (2001) — trzy kluczowe innowacje? Haar features, Integral Image (O(1) suma prostokąta), AdaBoost cascade pyt24 CV viola_jones +R-CNN (2014) — jak działa? Selective Search → ~2000 regionów → CNN per region → SVM; ~50 sec/obraz pyt24 CV rcnn +Fast R-CNN — kluczowe ulepszenie vs R-CNN? CNN raz na całym obrazie, ROI Pooling wycinająca cechy regionów (~2 sec/obraz) pyt24 CV fast_rcnn +Faster R-CNN — co zastąpiło Selective Search? RPN (Region Proposal Network) — generuje propozycje w sieci (~5 fps) pyt24 CV faster_rcnn +RPN to skrót od ...? Region Proposal Network pyt24 CV RPN +Two-stage vs One-stage detectors — różnica? Two-stage: osobny etap propozycji regionów; One-stage: klasyfikacja + lokalizacja w jednym przejściu pyt24 CV two_vs_one_stage +YOLO — co oznacza skrót? You Only Look Once pyt24 CV YOLO_skrot +YOLO — jak działa? Dzieli obraz na siatkę S×S, każda komórka predykuje B bbox + C klas w jednym przejściu pyt24 CV YOLO_jak +YOLO — typowa szybkość? 45–155 fps (real-time) pyt24 CV YOLO_fps +SSD — co łączy? Szybkość YOLO z multi-scale feature maps (lepszy na małych obiektach) pyt24 CV SSD +Co to anchor box? Predefiniowany prostokąt o określonym kształcie — sieć przewiduje offset od anchora pyt24 CV anchor +Co to NMS (Non-Maximum Suppression)? Post-processing: weź najlepszą detekcję (max confidence), usuń nakładające się (IoU > próg), powtórz pyt24 CV NMS +IoU (Intersection over Union) — wzór? Pole przecięcia / pole sumy dwóch bbox; IoU=1 → identyczne, IoU=0 → brak nakładania pyt24 CV IoU +Jak zbudować detektor z klasyfikatora? (3 podejścia) 1) Sliding window; 2) Region proposals + klasyfikator + NMS; 3) Fine-tune backbone + detection head pyt24 CV detektor_z_klas +Które podejście budowy detektora daje najlepszą jakość? Fine-tune pretrained backbone (np. ResNet) + detection head pyt24 CV najlepsza_jakość +DETR (2020) — kluczowa cecha? Transformer zamiast CNN, bezpośrednia predykcja zestawu obiektów, bez NMS pyt24 CV DETR +Kto stworzył YOLO? Joseph Redmon et al. (2016) pyt24 CV YOLO_autor +Kto stworzył R-CNN? Ross Girshick (2014) pyt24 CV RCNN_autor +Mnemotechnika: YOLO = ...? You Only Look Once — jednoetapowy, szybki pyt24 CV mnemotechnika_YOLO + +#notetype:Cloze +R-CNN family: {{c1::R-CNN}} (50s) → {{c2::Fast R-CNN}} (2s) → {{c3::Faster R-CNN}} (RPN, ~5fps) pyt24 CV rcnn_family_cloze +Detektor z klasyfikatora: {{c1::Sliding window}} (wolno) → {{c2::Region proposals}} (lepiej) → {{c3::Fine-tune backbone}} (najlepiej) pyt24 CV detektor_cloze + +#notetype:Basic +Czym jest przyspieszenie (speedup) S(n)? S(n) = T_seq / T_par(n) -- stosunek czasu sekwencyjnego do rownoległego pyt25 HPC speedup_def +Co mówi Prawo Amdahla? Określa MAKSYMALNE przyspieszenie przy zrównolegleniu: S(n) = 1/((1-p) + p/n) pyt25 HPC amdahl_def +p w Prawie Amdahla oznacza ...? Część programu, którą DA SIĘ zrównoleglić (0 ≤ p ≤ 1) pyt25 HPC p_def +(1-p) w Prawie Amdahla oznacza ...? Część sekwencyjna (nie do zrównoleglenia) pyt25 HPC 1mp_def +Maksymalne przyspieszenie wg Amdahla (n→∞)? S_max = 1/(1-p) pyt25 HPC Smax +Amdahl: p=90%, S_max = ? 10x (bo 1/0.10 = 10) pyt25 HPC p90 +Amdahl: p=95%, S_max = ? 20x pyt25 HPC p95 +Amdahl: p=99%, S_max = ? 100x pyt25 HPC p99 +Amdahl: p=90%, n=4, S(4) = ? ≈3.08x (1/(0.10 + 0.90/4)) pyt25 HPC p90n4 +Kluczowy wniosek Prawa Amdahla? Nawet z ∞ procesorami, 10% sekwencyjnego kodu ogranicza przyspieszenie do 10x pyt25 HPC wniosek +Co mówi Prawo Gustafsona? Alternatywa: zamiast przyspieszać stały problem, rozwiąż WIĘKSZY problem w tym samym czasie: S = 1 − p + p·n pyt25 HPC gustafson +Gustafson: p=90%, n=100, S = ? 90.1x (vs Amdahl: ~10x) pyt25 HPC gustafson_przykład +Strong scaling (Amdahl) vs Weak scaling (Gustafson)? Strong: stały rozmiar problemu; Weak: rozmiar rośnie proporcjonalnie do procesorów pyt25 HPC strong_vs_weak +Efektywność E(n) -- wzór? E(n) = S(n)/n -- ile z dodanych procesorów jest wykorzystane pyt25 HPC efektywność +Co to false sharing? Dwa rdzenie modyfikują różne zmienne w tej samej linii cache → ciągłe invalidation pyt25 HPC false_sharing +Co to NUMA? Non-Uniform Memory Access -- pamięć bliska procesorowi jest szybsza; zdalna = wolniejsza pyt25 HPC NUMA +Co to load imbalance? Procesory kończą w różnych czasach; najwolniejszy limituje cały czas pyt25 HPC load_imbalance +Kto sformułował Prawo Amdahla? Gene Amdahl (IBM, 1967) pyt25 HPC amdahl_autor +Gene Amdahl (IBM, 1967) sformułował ...? Prawo Amdahla o maks. przyspieszeniu równoległym pyt25 HPC amdahl_autor_rev +Kto sformułował Prawo Gustafsona? John Gustafson (Sandia Labs, 1988) pyt25 HPC gustafson_autor +Mnemotechnika: 10% seq = ...? max 10x -- sekwencyjna cześć limituje WSZYSTKO pyt25 HPC mnemotechnika +Mnemotechnika: Gustafson = ...? zwiększ problem, nie procesory -- weak scaling pyt25 HPC mnemotechnika_gust + +#notetype:Cloze +Prawo Amdahla: S(n) = 1 / ( {{c1::(1-p)}} + {{c2::p/n}} ) pyt25 HPC amdahl_cloze +Maks. przyspieszenie (n→∞): S_max = {{c1::1/(1-p)}} pyt25 HPC Smax_cloze +Prawo Gustafsona: S = {{c1::1 − p}} + {{c2::p·n}} pyt25 HPC gustafson_cloze +Efektywność: E(n) = {{c1::S(n)}} / {{c2::n}} pyt25 HPC efektywność_cloze + +#notetype:Basic +Komunikacja synchroniczna -- co oznacza? Nadawca czeka, aż odbiorca faktycznie odbierze wiadomość (obie strony zsynchronizowane) pyt26 HPC sync_def +Komunikacja asynchroniczna -- co oznacza? Nadawca wysyła do bufora i kontynuuje pracę, nie czekając na odbiorcę pyt26 HPC async_def +Funkcja blokująca (blocking) -- co oznacza? Wywołanie nie wraca, dopóki operacja nie jest zakończona -- wątek zamrożony pyt26 HPC blocking_def +Funkcja nieblokująca (non-blocking) -- co oznacza? Wywołanie wraca natychmiast, operacja w tle; sprawdzaj wait()/test() pyt26 HPC nonblocking_def +Czy synchroniczność = blokowanie? NIE -- to ortogonalne koncepcje (sync/async vs blocking/non-blocking) pyt26 HPC sync_vs_block +MPI_Send -- blokująca? sync? Blokująca; synchroniczność zależy od implementacji pyt26 HPC MPI_Send +MPI_Ssend -- co gwarantuje? Blokująca + synchroniczna (czeka aż odbiorca dopasuje recv) pyt26 HPC MPI_Ssend +MPI_Bsend -- co gwarantuje? Blokująca + asynchroniczna (kopiuje do bufora użytkownika i wraca) pyt26 HPC MPI_Bsend +MPI_Isend -- co oznacza I? Immediate = nieblokujące (wraca natychmiast) pyt26 HPC MPI_Isend +Deadlock Send-Send -- dlaczego powstaje? Oba procesy wywołują blokujące Send przed Recv -- żaden nie może odebrać pyt26 HPC deadlock_sendsend +Metoda Jacobiego -- czym jest? Iteracyjna metoda rozwiązywania układów równań liniowych; w wersji równoległej wymiana granic z sąsiadami pyt26 HPC jacobi +Rozwiązanie deadlocka: asymetria kolejności? Proc 0: Send→Recv; Proc 1: Recv→Send (ale asymetryczne) pyt26 HPC fix_asymetria +Rozwiązanie deadlocka: nieblokujące? Irecv + Isend + Waitall -- oba procesy symetrycznie pyt26 HPC fix_nonblock +Rozwiązanie deadlocka: MPI_Sendrecv? Jedna funkcja wykonująca Send i Recv atomowo -- bezpieczna, symetryczna, rekomendowana pyt26 HPC fix_sendrecv +Rozwiązanie deadlocka: Bsend? Buforowane wysyłanie -- kopiuje do bufora i wraca; Recv nie musi być gotowy pyt26 HPC fix_bsend +Kto to Carl Gustav Jacob Jacobi? Matematyk niemiecki (1804-1851); metoda iteracyjna rozwiązywania układów równań pyt26 HPC jacobi_autor +Mnemotechnika: Deadlock = ...? Send-Send -- oba czekają, nikt nie odbiera pyt26 HPC mnemotechnika_deadlock +Mnemotechnika: Sendrecv = ...? safe exchange -- jedna funkcja, zero deadlocków pyt26 HPC mnemotechnika_sendrecv +Mnemotechnika: I = ...? (MPI) Immediate = Non-blocking (MPI_Isend, MPI_Irecv) pyt26 HPC mnemotechnika_I +Mnemotechnika: S = ...? (MPI_Ssend) Synchronous -- czeka na recv pyt26 HPC mnemotechnika_S + +#notetype:Cloze +MPI: {{c1::MPI_Send}} (blok, zależy), {{c2::MPI_Ssend}} (blok, sync), {{c3::MPI_Bsend}} (blok, async), {{c4::MPI_Isend}} (nieblok) pyt26 HPC MPI_cloze +Deadlock fix: {{c1::Irecv}} + {{c2::Isend}} + {{c3::Waitall}} (nieblokujące, symetryczne) pyt26 HPC fix_cloze + +#notetype:Basic +Trzy poziomy warunków decyzyjnych? Pewność (znamy wynik), Ryzyko (znamy prawdopodobieństwa), Niepewność (nie znamy prawdopodobieństw) pyt31 TD warunki_decyzyjne +Czym jest funkcja użyteczności U(x)? Matematyczne przypisanie wartości subiektywnej do wyniku (np. pieniędzy) pyt31 TD uzytecznosc_def +Risk averse -- jaki kształt U(x)? Wklęsła (concave): U''(x) < 0 -- malejaca użyteczność krańcowa pyt31 TD risk_averse +Risk neutral -- jaki kształt U(x)? Liniowa -- obojętne czy pewny E[X] czy loteria pyt31 TD risk_neutral +Risk seeking -- jaki kształt U(x)? Wypukła (convex): U''(x) > 0 -- woli ryzyko niż pewniaka pyt31 TD risk_seeking +Metoda loterii -- na czym polega? Ustal U(worst)=0, U(best)=1; pytaj o punkt obojętności p* między pewną kwotą a loterią (p: best, 1-p: worst); U(x_mid) = p* pyt31 TD metoda_loterii +Certainty Equivalent (CE) -- czym jest? Pewna kwota równoważna loterii dla decydenta pyt31 TD CE_def +CE < E[X] oznacza ...? Risk averse (awersja do ryzyka) pyt31 TD CE_lt_EX +CE = E[X] oznacza ...? Risk neutral pyt31 TD CE_eq_EX +CE > E[X] oznacza ...? Risk seeking pyt31 TD CE_gt_EX +Risk Premium -- wzór? Risk Premium = E[X] − CE pyt31 TD risk_premium +AHP (Analytic Hierarchy Process) -- na czym polega? Hierarchia Cel → Kryteria → Alternatywy; porównania parami (skala 1-9) → eigenvalue → wagi pyt31 TD AHP_def +Kto opracował AHP? Thomas Saaty (U. of Pittsburgh, 1970s) pyt31 TD AHP_autor +Thomas Saaty opracował ...? AHP (Analytic Hierarchy Process) pyt31 TD AHP_autor_rev +Skala Saaty'ego w AHP: 1 = ?, 9 = ? 1 = równe znaczenie; 9 = absolutna przewaga pyt31 TD saaty_skala +Consistency Ratio (CR) w AHP -- kiedy akceptowalne? CR < 0.1 pyt31 TD CR +PROMETHEE -- co oblicza? Przepływy: Φ+(a) = outgoing (siła), Φ-(a) = incoming (słabość), Φ(a) = net flow = Φ+ − Φ- pyt31 TD promethee +ELECTRE -- na czym polega outranking? A przewyższa B gdy: concordance (dość kryteriów popiera A) + discordance (żadne nie daje B drastycznej przewagi) pyt31 TD electre +AHP vs PROMETHEE vs ELECTRE -- typ wyniku? AHP: wagi + ranking; PROMETHEE: przepływy Φ; ELECTRE: relacja outranking pyt31 TD porównanie_metod +Kto opracował PROMETHEE? Jean-Pierre Brans (1982) pyt31 TD promethee_autor +Kto opracował ELECTRE? Bernard Roy (1965) pyt31 TD electre_autor +Mnemotechnika: CE = ...? ile dałbyś za pewniaka zamiast loterii -- miara awersji do ryzyka pyt31 TD mnemotechnika_CE +Mnemotechnika: AHP = ...? porównaj parami, policz wagi (macierz → eigenvalue) pyt31 TD mnemotechnika_AHP +Mnemotechnika: PROMETHEE = ...? przepływy (Φ+ outgoing, Φ- incoming) pyt31 TD mnemotechnika_PROM + +#notetype:Cloze +Risk Premium = {{c1::E[X]}} − {{c2::CE}} pyt31 TD risk_premium_cloze +AHP: Consistency Ratio CR < {{c1::0.1}} = akceptowalne pyt31 TD CR_cloze +PROMETHEE: Φ(a) = {{c1::Φ+(a)}} − {{c2::Φ-(a)}} (net flow) pyt31 TD promethee_cloze + +#notetype:Basic +Czym jest dominacja stochastyczna? Metoda porównywania rozkładów prawdopodobieństwa BEZ znajomości dokładnej U -- jeśli A dominuje B, cała klasa racjonalnych decydentów wybierze A pyt32 TD dominacja_def +FSD (First-order Stochastic Dominance) -- warunek? F_A(x) ≤ F_B(x) dla każdego x (dystrybuanta A zawsze poniżej B) pyt32 TD FSD_warunek +FSD -- jaki warunek na U? U'(x) ≥ 0 (monotoniczność -- więcej = lepiej) pyt32 TD FSD_U +FSD -- dla jakiej klasy decydentów? WSZYSCY racjonalni (nienasyceni) pyt32 TD FSD_klasa +F_A(x) ≤ F_B(x) ∀x interpretacja? Dla dowolnego progu x, szansa że A daje wynik ≤ x jest mniejsza lub równa niż dla B pyt32 TD FSD_interpretacja +Czy FSD jest częsta w praktyce? Rzadka -- wystarczy JEDEN punkt gdzie F_A(x) > F_B(x) i dominacja nie zachodzi pyt32 TD FSD_rzadka +SSD (Second-order Stochastic Dominance) -- warunek? ∫ F_A(t)dt ≤ ∫ F_B(t)dt dla każdego x (skumulowana całka z dystrybuanty) pyt32 TD SSD_warunek +SSD -- jaki warunek na U? U' ≥ 0 i U'' ≤ 0 (monotoniczność + wklęsłość) pyt32 TD SSD_U +SSD -- dla jakiej klasy decydentów? Risk-averse (awersja do ryzyka) pyt32 TD SSD_klasa +Czy dystrybuanty mogą się przecinać przy SSD? TAK -- ale skumulowane pole pod F_A musi być ≤ pola pod F_B pyt32 TD SSD_przecinanie +Relacja FSD a SSD? FSD ⇒ SSD (ale NIE odwrotnie) -- FSD silniejsza pyt32 TD FSD_implies_SSD +FSD implikuje SSD? TAK pyt32 TD FSD_SSD_tak +SSD implikuje FSD? NIE pyt32 TD SSD_FSD_nie +Mean-Preserving Spread (MPS) -- czym jest? Operacja zwiększająca rozrzut (wariancję) rozklądu zachowując tę samą średnią: B = A + ε, E[ε|A]=0 pyt32 TD MPS_def +Twierdzenie Rothschilda-Stiglitza? A SSD-dominuje B ⇔ B jest mean-preserving spread A (przy jednakowej średniej) pyt32 TD rothschild_stiglitz +Kto sformułował FSD/SSD? Hadar & Russell (1969); Rothschild & Stiglitz (1970) niezależnie pyt32 TD FSD_SSD_autorzy +Zastosowanie dominacji stochastycznej w portfelach? Eliminuj zdominowane stochastycznie portfele BEZ znajomości dokładnej U inwestora pyt32 TD portfolio +FSD vs SSD -- częstość? FSD rzadka; SSD częstsza pyt32 TD FSD_vs_SSD_czest +Mnemotechnika: FSD = ...? F always below -- dystrybuanta A zawsze ≤ B pyt32 TD mnemotechnika_FSD +Mnemotechnika: SSD = ...? Second = Sum (integral) -- całka z F_A ≤ całka z F_B pyt32 TD mnemotechnika_SSD +Mnemotechnika: FSD → kto? SSD → kto? FSD → wszyscy racjonalni; SSD → risk-averse pyt32 TD mnemotechnika_klasy + +#notetype:Cloze +FSD: F_A(x) {{c1::≤}} F_B(x) ∀x; warunek na U: {{c2::U' ≥ 0}} pyt32 TD FSD_cloze +SSD: ∫F_A(t)dt {{c1::≤}} ∫F_B(t)dt ∀x; warunek na U: {{c2::U' ≥ 0, U'' ≤ 0}} pyt32 TD SSD_cloze +Hierarchia: {{c1::FSD}} ⇒ {{c2::SSD}} ⇒ TSD (ale nie odwrotnie) pyt32 TD hierarchia_cloze +Mean-Preserving Spread: B = A + {{c1::ε}}, gdzie E[{{c1::ε}}|A] = {{c2::0}} pyt32 TD MPS_cloze + +#notetype:Basic +Przykład języka regularnego: identyfikatory w programowaniu? [a-zA-Z_][a-zA-Z0-9_]* — wyrażenie regularne, więc język regularny pyt01 AISDI regularne_identyfikatory +Przykład języka regularnego: podzielność? Liczby binarne podzielne przez 3 — automat z 3 stanami (śledzi resztę) pyt01 AISDI regularne_podzielnosc +Nawiasy — jaki typ języka? Bezkontekstowy (Typ 2) — PDA: push (, pop ) pyt01 AISDI nawiasy_typ +|w| w kontekście LBA oznacza? Długość słowa wejściowego (np. w=aabbcc → |w|=6) pyt01 AISDI LBA_w +Dlaczego LBA rozpoznaje aⁿbⁿcⁿ? Taśma R/W: wiele przejść zaznaczając po jednym a, b, c za każdym razem pyt01 AISDI LBA_anbncn +Dlaczego LBA rozpoznaje ww (podwojone słowo)? Swobodny dostęp do taśmy — porównuje i-ty symbol pierwszej i drugiej połowy pyt01 AISDI LBA_ww +Jak DTM symuluje NTM? BFS po drzewie konfiguracji — symulacja wykładniczo wolniejsza, ale te same języki pyt01 AISDI DTM_NTM_BFS +Kontrprzykład: domknięcie ∩ dla jęz. bezkontekstowych? {aⁿbⁿcᵐ} ∩ {aᵐbⁿcⁿ} = {aⁿbⁿcⁿ} — NIE jest bezkontekstowy pyt01 AISDI CFL_intersection +Lekser (lexer) — który Typ Chomsky’ego? Typ 3 (FA / regex) — dzieli kod na tokeny (if, 123, +) pyt01 AISDI lekser_typ +Parser — który Typ Chomsky’ego? Typ 2 (PDA / CFG) — buduje drzewo składniowe z tokenów pyt01 AISDI parser_typ +Weryfikacja ograniczeń (np. typowanie) — który Typ? Typ 1 (LBA / kontekstowe) — np. zmienna zadeklarowana przed użyciem pyt01 AISDI weryfikacja_typ +Obliczenia ogólne — który Typ? Typ 0 (TM) — dowolne obliczenia (teza Churcha-Turinga) pyt01 AISDI obliczenia_typ +Etymologia: „rekurencyjnie przeliczalne”? TM może wyliczyć (enumerate) wszystkie słowa języka, ale może NIE zatrzymać się na nie-członkach pyt01 AISDI rek_przelicz_etym +Cykl ujemny (negative cycle) w grafie? Cykl, w którym suma wag < 0 — najkrótsza ścieżka = −∞ pyt02 AISDI cykl_ujemny +d[v] w algorytmach SSSP? Tablica odległości: d[start]=0, d[inne]=∞, relaksacja obniża d[v] pyt02 AISDI tablica_d +Bellman-Ford — współtwórca oprócz Bellmana? Lester Ford Jr. (1956) pyt02 AISDI bellman_ford_jr +Atrybut pierwszy (prime attribute)? Kolumna będąca częścią klucza kandydującego (vs non-prime) pyt03 BD2 prime_attribute +Klucz kandydujący (candidate key)? Minimalny nadklucz (superkey) — usunięcie dowolnej kolumny traci unikalność pyt03 BD2 candidate_key +Dekompozycja (w normalizacji)? Podział dużej tabeli na mniejsze powiązane FK, eliminując anomalie pyt03 BD2 dekompozycja +5NF (Piąta Postać Normalna)? Project-Join NF — usunięcie WSZYSTKICH redundancji wynikających z join dependencies pyt03 BD2 5NF +Etymologia: redundancja? Łac. „redundantia” = nadmiar, przelewanie się pyt03 BD2 redundancja_etym +Transakcja (w bazach danych)? Logiczna jednostka pracy — zbiór operacji: albo WSZYSTKIE, albo żadna (atomowość) pyt04 BD2 transakcja_def +Blokada współdzielona (shared lock)? Wielu czytelników równocześnie; blokuje zapis pyt04 BD2 shared_lock +Blokada wyłączna (exclusive lock)? Jeden pisarz; blokuje odczyt i inne zapisy pyt04 BD2 exclusive_lock +Widok (view) w bazie danych? Wirtualna tabela = zapisane zapytanie SQL; umożliwia niezależność logiczną pyt04 BD2 view +Procedura składowana (stored procedure)? Funkcja zapisana w bazie, wywoływana via SQL — logika blisko danych pyt04 BD2 stored_proc +Plan wykonania (execution plan)? Sekwencja kroków (scan, join, sort) wybrana przez optymalizator dla zapytania pyt04 BD2 execution_plan +Rola (role) w bezpieczeństwie BD? Grupa uprawnień przypisywana użytkownikom (np. rola „Kasjer”) pyt04 BD2 role +Audyt (audit) w BD? Logowanie KTO, KIEDY, CO zrobił — zgodność: RODO, SOX, PCI-DSS pyt04 BD2 audyt +Indeks (index) w BD? Pomocnicza struktura przyspieszająca wyszukiwanie (jak indeks w książce) pyt04 BD2 indeks +Partycjonowanie tabeli? Podział tabeli na części (np. wg roku) — szybsze zapytania na podzbiorze danych pyt04 BD2 partycjonowanie +Etymologia: transakcja? Łac. „transactio” = załatwienie, dokonanie pyt04 BD2 transakcja_etym +std::array — cechy? Rozmiar stały (compile-time), zero narzutu vs C-array, ciągła pamięć pyt05 PROI STL_array +Cache-friendliness — dlaczego ciągła pamięć jest szybsza? CPU ładuje pamięć w liniach cache (64B); ciągłe = prefetch; rozproszone = cache miss pyt05 PROI cache_friendliness +Contiguous Iterator (C++17)? Jak Random Access + gwarancja sąsiadującej pamięci (np. vector, array) pyt05 PROI contiguous_iterator +Lambda — etymologia? Gr. λ; rachunek lambda Alonzo Churcha (1930s) pyt05 PROI lambda_etym +Funktor — etymologia? Z teorii kategorii (matematyka) — odwzorowanie zachowujące strukturę pyt05 PROI funktor_etym +Programowanie generyczne (generic programming)? Kod niezależny od konkretnego typu — C++ templates, Java/C# generics pyt06 PROI generyczne_def +Java generics vs C# generics — kluczowa różnica? Java: type erasure (usunięcie typów w runtime); C#: reification (typy zachowane) pyt06 PROI java_vs_csharp_generics +Enkapsulacja — etymologia? Łac. „capsula” = pudełeczko — ukrycie wewnętrznych danych za interfejsem pyt06 PROI enkapsulacja_etym +Christopher Alexander (1977) — znaczenie dla GoF? Książka „A Pattern Language” — GoF zaadaptowali ideę wzorcow do oprogramowania pyt06 PROI alexander_gof +Luźne wiązanie (loose coupling)? Minimalne zależności między komponentami — zmiana jednego nie wymusza zmian w innych pyt06 PROI loose_coupling +Dziedziczenie wielokrotne — które języki obsługują? C++: TAK; Java/C#: NIE (tylko interfejsy); Python: TAK (MRO) pyt06 PROI multiple_inheritance + +#notetype:Basic +Forwarding server (DNS)? Serwer DNS, który sam nie rozpoznaje — przekazuje zapytanie do innego resolvera pyt07 SKM forwarding_server +Referral (DNS)? Odpowiedź „nie wiem, zapytaj tamten serwer” — delegacja w dół drzewa DNS pyt07 SKM referral +Cache — etymologia? Fr. „cacher” = ukryć — dane ukryte blisko klienta, szybki dostęp pyt07 SKM cache_etym +TTL wpisów TLD w DNS? 24h–48h (dłuższe niż dla zwykłych rekordów) pyt07 SKM TTL_TLD +Przykłady publicznych recursive resolvers? Google 8.8.8.8; Cloudflare 1.1.1.1 pyt07 SKM public_resolvers +Window Scale option (TCP handshake)? Negocjowane w handshake — pozwala okno >65535 B (do ~1 GB) pyt08 SKM window_scale +RFC — pełna nazwa i charakter? Request For Comments; tradycja ARPANET; w praktyce = wiążący standard internetowy pyt08 SKM RFC +TCP jest ... (typ połączenia)? Connection-oriented — połączenie musi być ustanowione przed transmisją danych pyt08 SKM tcp_connection_oriented +Segment TCP — definicja? Jednostka danych TCP: nagłówek (20+ bajtów) + dane pyt08 SKM segment_def +TCP gwarantuje (3 cechy)? Brak utraty, poprawna kolejność, brak duplikatów pyt08 SKM tcp_gwarancje +Monitor (synchronizacja)? Wysokopoziomowa synchronizacja — obiekt z wbudowanym mutexem; Java: synchronized pyt09 SOI monitor +Condition Variable? Pozwala wątkowi czekać (wait) na warunek; inny wątek sygnałem (signal/notify) budzi pyt09 SOI condition_variable +Bariera (barrier) — synchronizacja? Punkt synchronizacji: WSZYSTKIE wątki muszą dotrzeć, zanim którykolwiek ruszy dalej pyt09 SOI barrier +Named Pipe (FIFO) — vs anonimowy pipe? Ma nazwę w systemie plików — dostępny dla niespokrewnionych procesów pyt09 SOI named_pipe +Message Queue (IPC)? Kolejka wiadomości w jądrze; komunikacja asynchroniczna między procesami pyt09 SOI message_queue +Socket IPC? Komunikacja sieciowa lub lokalna (Unix domain socket); działa między maszynami pyt09 SOI socket_ipc +Sygnał (signal) — IPC? Asynchroniczne powiadomienie: SIGKILL, SIGTERM; ograniczone (tylko numer sygnału) pyt09 SOI signal_ipc +Edward Coffman Jr. et al. (1971) — co opublikowali? 4 warunki konieczne zakleszczenia (deadlock) pyt09 SOI coffman_author +Mutex — etymologia? MUTual EXclusion — portmanteau (zbitka słowna) pyt09 SOI mutex_etym +Pamięć wirtualna — definicja? Abstrakcja: każdy proces widzi własną ciągłą przestrzeń adresową; może użyć więcej niż fizycznie dostępne pyt10 SOI virtual_memory_def +Ochrona pamięci (memory protection)? Zapobiega dostępowi procesu do pamięci innego — bity R/W/X w tablicy stron + MMU pyt10 SOI memory_protection +Relokacja (relocation)? Program musi działać pod różnymi adresami fizycznymi; pamięć wirtualna rozwiązuje automatycznie pyt10 SOI relocation +MMU (Memory Management Unit)? Sprzęt tłumaczący adresy wirtualne → fizyczne pyt10 SOI MMU +TLB etymologia („lookaside”)? Zajrzyj na bok/do cache zanim chodzisz po tablicy stron pyt10 SOI TLB_etym +Page fault — etymologia „fault”? Wyjątek sprzętowy (hardware exception), NIE błąd programisty pyt10 SOI pagefault_etym +BPMN zdarzenia (Events) — 3 typy? ○ start, ◎ intermediate, ◉ end — co uruchamia/kończy proces pyt11 WSYZ bpmn_events +BPMN czynności (Activities)? Prostokąty = praca (task, subprocess) pyt11 WSYZ bpmn_activities +BPMN łączniki: Sequence / Message / Association? → kolejność (Sequence); --→ między pulami (Message); ··· powiązanie (Association) pyt11 WSYZ bpmn_flows +BPMS — co to? Oprogramowanie wykonujące diagramy BPMN 2.0 XML (np. Camunda, jBPM) pyt11 WSYZ BPMS +IDEF0 — pochodzenie i przeznaczenie? Integration DEFinition; US Air Force (1970s); wejścia/wyjścia/mechanizmy/kontrole pyt11 WSYZ IDEF0 +VSM (Value Stream Map)? Narzędzie Lean Manufacturing — mapuje przepływ materiałów i informacji; identyfikuje marnotrawstwo pyt11 WSYZ VSM +UML „Three Amigos”? Booch, Rumbaugh, Jacobson — zjednoczyli swoje metody w latach 90. pyt11 WSYZ UML_three_amigos +EPC — twórca? August-Wilhelm Scheer (Saarland, lata 90.; podstawa SAP ARIS) pyt11 WSYZ EPC_author +Edmonds-Karp — czym różni się od Ford-Fulkersona? BFS zamiast DFS do szukania ścieżki powiększającej; gwarancja O(VE²) pyt12 WSYZ edmonds_karp +Ścieżka powiększająca (augmenting path)? Ścieżka w sieci resztów używana przez Ford-Fulkersona do zwiększenia przepływu pyt12 WSYZ augmenting_path +Minimalny koszt przepływu (min-cost flow)? Prześlij wymagany przepływ s→t po minimalnym koszcie pyt12 WSYZ min_cost_flow +Ford-Fulkerson — autorzy/rok? Lester Ford Jr. + Delbert Fulkerson (1956) pyt12 WSYZ ford_fulkerson_authors +Edmonds-Karp — autorzy/rok? Jack Edmonds + Richard Karp (1972) pyt12 WSYZ edmonds_karp_authors +CPM — twórca/rok? DuPont (1957) pyt12 WSYZ CPM_author +PERT — twórca/rok? US Navy, program Polaris (1958) pyt12 WSYZ PERT_author +Kruskal — twórca/rok? Joseph Kruskal (1956) pyt12 WSYZ kruskal_author +Prim — twórca/rok? Robert Prim (1957); niezależnie Jarník (1930) pyt12 WSYZ prim_author +Algorytm węgierski — twórca/rok? Harold Kuhn (1955); nazwany na cześć Kőniga i Egerváry’ego pyt12 WSYZ hungarian_author +NP-trudny (NP-hard) — definicja? Brak znanego algorytmu wielomianowego; używane heurystyki i aproksymacje pyt12 WSYZ NP_hard + +#notetype:Basic +ArchiMate 3 aspekty? Active Structure (KTO), Behavior (CO robi), Passive Structure (NA CZYM) pyt13_27 AIS archimate_aspekty +ArchiMate — etymologia? „Architecture” + „animate” pyt13_27 AIS archimate_etym +Zachman Framework — autor/rok? John Zachman, IBM (1987) pyt13_27 AIS zachman_author +C4 Model — autor/rok? Simon Brown (2006) pyt13_27 AIS C4_author +ISO 25010 Quality Attributes (przykłady)? Performance, Security, Scalability, Maintainability, Reliability, Usability, Portability pyt13_27 AIS iso25010 +Wzorzec — kanoniczna struktura opisu? Name + Problem + Solution + Consequences pyt14_28 AIS pattern_structure +Monolit (monolith) — definicja? Cały system jako jedna aplikacja, jeden deployment; prosty, ale trudny do skalowania pyt14_28 AIS monolith_def +Skala wzorców: 3 poziomy? Architektoniczny (cały system) > Projektowy (klasa/obiekt) > Idiomatyczny (linia kodu) pyt14_28 AIS pattern_scale +POSA — autorzy/rok? Buschmann et al. (1996) pyt14_28 AIS POSA_author +Hexagonal Architecture — autor/rok? Alistair Cockburn (2005) pyt14_28 AIS hexagonal_author +CQRS — autor? Na czym bazuje? Greg Young (~2010); bazuje na CQS Bertranda Meyera pyt14_28 AIS CQRS_author +Termin „microservices” — popularyzatorzy? James Lewis + Martin Fowler (~2012) pyt14_28 AIS microservices_origin +Cloud Patterns (4 przykłady)? Circuit Breaker, Sidecar, Saga, Strangler Fig pyt14_28 AIS cloud_patterns +Separation of Concerns? Każdy komponent odpowiada za JEDNĄ rzecz pyt14_28 AIS SoC +Agent (w robotyce) — definicja? Autonomiczny byt: postrzega (sensory), decyduje (deliberacja), działa (efektory) pyt15 ROB agent_def +Agent upostaciowiony — definicja? Agent z fizycznym ciałem w świecie rzeczywistym (vs agent czysto programowy) pyt15 ROB embodied_def +FSM w robotyce? Skończone stany + warunkowe przejścia; prosty, ale eksplozja stanów pyt15 ROB FSM_robotics +BDI — autorzy? Bratman (filozof, 1987); Rao & Georgeff (1991) przenieśli do AI pyt15 ROB BDI_authors +LTL — autor i nagroda? Amir Pnueli (1977); Turing Award 1996 pyt15 ROB LTL_author +PID — autor? Nicolas Minorsky (1922, sterowanie statkiem) pyt15 ROB PID_author +ROS — skąd pochodzi? Willow Garage (2007) pyt15 ROB ROS_origin +Behavior Trees — geneza? Z game AI (Halo 2, ~2004); zaadaptowane do robotyki pyt15 ROB BT_origin +Task-level (w klasyfikacji T-R-M-S)? Opisz CO robot ma zrobić, nie JAK (PDDL, Behavior Trees) pyt16 ROB task_level +Robot-level (w klasyfikacji T-R-M-S)? Komendy ruchu: move_to, grasp — w przestrzeni kartezjańskiej/konfiguracyjnej pyt16 ROB robot_level +Motion-level (w klasyfikacji T-R-M-S)? Planowanie trajektorii, unikanie kolizji (MoveIt, OMPL) pyt16 ROB motion_level +Servo-level (w klasyfikacji T-R-M-S)? Bezpośrednie sterowanie silnikami, PID, PWM (C/C++, FPGA) pyt16 ROB servo_level +RAPID — pełna nazwa? Robotics Application Programming Interactive Dialogue (ABB) pyt16 ROB RAPID_name +RAPID — 3 typy ruchu? MoveJ (joint), MoveL (linear), MoveC (circular) pyt16 ROB RAPID_moves +KRL — 3 typy ruchu? PTP (point-to-point), LIN (linear), CIRC (circular) pyt16 ROB KRL_moves +MoveIt (ROS)? Biblioteka planowania ruchu manipulatora (IK, unikanie kolizji) pyt16 ROB MoveIt +PDDL? Planning Domain Definition Language — definiuje stany/akcje/cele; planer szuka sekwencji pyt16 ROB PDDL +FPGA w robotyce? Field-Programmable Gate Array; servo-level; nanosekundowe przetwarzanie pyt16 ROB FPGA +ΣTⱼ (suma spóźnień) definicja? Tⱼ = max(0, Cⱼ − dⱼ); mierzy łączne spóźnienie pyt17 ZSSK sumTj +ΣUⱼ (liczba spóźnionych) definicja? Uⱼ = 1 jeśli Cⱼ > dⱼ, inaczej 0; liczy ile zadań nie zmieściło się w terminie pyt17 ZSSK sumUj +rⱼ (release date) w β notacji Grahama? Zadanie j dostępne dopiero w czasie rⱼ pyt17 ZSSK release_date +prec (precedencje) w β? Zadanie A musi skończyć się przed B — modelowane jako DAG pyt17 ZSSK precedence +Makespan — etymologia? „make” = ukończyć + „span” = rozpiętość — czas od startu do końca ostatniego zadania pyt17 ZSSK makespan_etym +Zapasy (inventory) — dylemat? Za dużo = zamrożony kapitał; za mało = stockout pyt18 ZSSK inventory_dilemma +Stockout (brak towaru) — konsekwencje? Utrata sprzedaży, utrata klienta, kary umowne pyt18 ZSSK stockout +Overstock (nadmiar) — konsekwencje? Koszty magazynowania, zamrożony kapitał, obsolescence (dezaktualizacja) pyt18 ZSSK overstock +Koszt braku towaru (shortage cost, p)? Utrata sprzedaży, ekspresowe dostawy, kary pyt18 ZSSK shortage_cost + +#notetype:Basic +Type-based subscription (Pub/Sub)? Filtrowanie po typie wiadomości (np. klasa OrderEvent) pyt19_29 AIS type_based_sub +Hierarchical/wildcard subscription? Wzorce tematów: orders.* dopasowuje orders.created pyt19_29 AIS wildcard_sub +AMQP pełna nazwa? Advanced Message Queuing Protocol pyt19_29 AIS AMQP_name +Redis etymologia? REmote DIctionary Server (Salvatore Sanfilippo, 2009) pyt19_29 AIS redis_etym +RabbitMQ etymologia? „rabbit” = szybkość (królik) pyt19_29 AIS rabbitmq_etym +Spark etymologia + autor? „iskra”; Matei Zaharia (UC Berkeley, 2012) pyt20_30 AIS spark_etym +Reservoir Sampling — autor? Jeffrey Vitter (1985) pyt20_30 AIS reservoir_author +Out-of-order events (w strumieniach)? Zdarzenia mogą przyjść w złej kolejności z powodu opóźnień sieciowych pyt20_30 AIS out_of_order +HyperLogLog — „LogLog” w nazwie? Zużywa log(log(n)) pamięci pyt20_30 AIS HLL_name +Porządek częściowy (partial order)? Relacja, w której NIE wszystkie pary są porównywalne pyt21 SR partial_order +Porządek przyczynowy (causal order)? Wiadomości dostarczane zgodnie z relacją happened-before pyt21 SR causal_order +Zdarzenie (event) w systemach rozproszonych? Atomowa akcja: instrukcja lokalna, wysłanie msg lub odebranie msg pyt21 SR event_def +Lamport — nagroda? Turing Award 2013 pyt21 SR lamport_turing +Lamport — inny znany wynalazek? LaTeX pyt21 SR lamport_latex +Amazon Dynamo (2007) — używa? Wektorów wersji (version vectors) do wykrywania konfliktów pyt21 SR dynamo +Zegar Lamporta — krok przed własnym zdarzeniem? C_i := C_i + 1 (inkrementacja przed każdym zdarzeniem) pyt21 SR lamport_local_step +Replikacja (replication) — cel? Kopie danych na wielu węzłach; cel: dostępność + wydajność pyt22 SR replication_def +Monotonic Writes (gwarancja sesji)? Moje zapisy stosowane w kolejności, w jakiej je wysłałem pyt22 SR monotonic_writes +Writes Follow Reads? Jeśli przeczytałem x i zapisałem y na jego podstawie, inni widzą x przed y pyt22 SR writes_follow_reads +Sequential Consistency — autor? Leslie Lamport (1979) pyt22 SR seq_consistency_author +Causal Consistency — autorzy? Ahamad et al. (1995) pyt22 SR causal_consistency_author +CRDTs — autorzy? Marc Shapiro et al. (2011) pyt22 SR CRDTs_author +Quorum — etymologia? Łac. „of whom” = minimalna liczba głosów (z prawa rzymskiego) pyt22 SR quorum_etym +Sequential Consistency — przykład systemu? ZooKeeper pyt22 SR seq_consistency_example +Causal Consistency — przykład systemu? MongoDB pyt22 SR causal_consistency_example +Mean Shift (segmentacja)? Iteracyjne przesuwanie jądra do maks. gęstości; O(n²), wolny pyt23 RO mean_shift +Transformer-based segmentation (przykłady)? SegFormer, Mask2Former; self-attention = globalne zależności pyt23 RO transformer_seg +Receptive field (pole recepcyjne)? Ile wejścia „widzi” jeden neuron; atrous/dilated zwiększa bez dodatkowych parametrów pyt23 RO receptive_field +CNN (Convolutional Neural Network)? Sieć ze splotowymi warstwami; filtr → cechy hierarchiczne pyt23 RO CNN_def +Pixel Accuracy (metryka segmentacji)? % poprawnie zaklasyfikowanych pikseli; prostsza niż mIoU pyt23 RO pixel_accuracy +FCN — autorzy/rok? Long, Shelhamer, Darrell (2015) pyt23 RO FCN_authors +Confidence (w detekcji obiektów)? Wynik 0–1 mówiący jak pewny jest detektor; próg np. 0.5 pyt24 RO confidence_def +SVM (Support Vector Machine)? Hiperpaszczyzna maks. separująca klasy; HOG+SVM = klasyczny pipeline pyt24 RO SVM +Anchor-free detectors? FCOS, YOLOv8: bezpośrednia predykcja bez predefiniowanych anchorów pyt24 RO anchor_free +Backbone (w detekcji)? Sieć bazowa (ResNet, VGG) wyciągająca cechy; detection head dodawana na wierzch pyt24 RO backbone +Integral Image (Viola-Jones)? Obliczenie sumy prostokąta w O(1) pyt24 RO integral_image +SSD pełna nazwa? Single Shot MultiBox Detector (Liu et al., 2016) pyt24 RO SSD_name +Overhead synchronizacji (w HPC)? Dodatkowy koszt koordynacji: mutex contention, bariery, komunikacja pyt25 HPC sync_overhead +Lock-free — co zamiast mutexów? CAS (Compare-And-Swap) — atomowe operacje sprzętowe pyt25 HPC lock_free +Pipelining (równoległość)? Podział na etapy na osobnych rdzeniach (jak taśma montażowa) pyt25 HPC pipelining +Gene Amdahl — inny wkład? Współtwórca IBM System/360 pyt25 HPC amdahl_ibm +MPI — pełna nazwa i rok? Message Passing Interface; MPI Forum (1994) pyt26 HPC MPI_name +MPI_Recv — typ? Blokujące odbieranie (czeka aż wiadomość dotrze) pyt26 HPC MPI_Recv +MPI_Irecv — typ? Nieblokujące odbieranie (wraca natychmiast; sprawdzamy MPI_Wait/Test) pyt26 HPC MPI_Irecv +Synchroniczna — etymologia? Gr. „syn” (razem) + „chronos” (czas) pyt26 HPC sync_etym +Loteria (lottery) — formalizacja? Decyzja ryzykowna: zbiór wyników z prawdopodobieństwami, L = (p: best, 1-p: worst) pyt31 TD lottery_def +PROMETHEE pełna nazwa? Preference Ranking Organization METHod for Enrichment Evaluations pyt31 TD PROMETHEE_name +ELECTRE pełna nazwa? ÉLimination Et Choix Traduisant la RÉalité pyt31 TD ELECTRE_name +Eigenvalue w AHP? Z macierzy porównań wyznaczamy wektor własny → wagi kryteriów pyt31 TD AHP_eigenvalue +von Neumann-Morgenstern (1944)? Sformalizowali aksjomatycznie teorię użyteczności pyt31 TD vNM +Daniel Bernoulli (1738)? Wprowadził koncepcję użyteczności (paradoks petersburski) pyt31 TD bernoulli +Kompensacyjna vs niekompensacyjna metoda? AHP = kompensacyjna (dobre kompensuje złe); ELECTRE = niekompensacyjna pyt31 TD komp_vs_niekomp +Dystrybuanta F(x) (CDF)? P(X ≤ x); rośnie od 0 do 1 pyt32 TD CDF_def +Funkcja wklęsła (concave) — warunek? U''(x) ≤ 0; malejąca użyteczność krańcowa; np. U(x) = √x pyt32 TD concave +Funkcja wypukła (convex) — warunek? U''(x) ≥ 0; modeluje risk seeking pyt32 TD convex +Stochastyczna — etymologia? Gr. „stochastos” = zdolny do celowania; „stochazein” = mierzyć/celować pyt32 TD stochastic_etym +Ubezpieczenia + dominacja stochastyczna? Fair ubezpieczenie SSD-dominuje brak ubezpieczenia (dla risk-averse) pyt32 TD insurance_SSD diff --git a/pytania/print_questions.sh b/pytania/print_questions.sh new file mode 100755 index 0000000..23c2b69 --- /dev/null +++ b/pytania/print_questions.sh @@ -0,0 +1,267 @@ +#!/usr/bin/env bash +# +# print_questions.sh — Convert and print exam questions from OBRONA_MAGISTERSKA_ODPOWIEDZI.md +# +# Usage: +# ./print_questions.sh [OPTIONS] [QUESTION_NUMBERS...] +# +# Examples: +# ./print_questions.sh # Generate PDF of ALL questions +# ./print_questions.sh 1 # Generate PDF of question 1 +# ./print_questions.sh 1 3 7 # Generate PDF of questions 1, 3, 7 +# ./print_questions.sh 1-5 # Generate PDF of questions 1 through 5 +# ./print_questions.sh 1 3-5 8 # Mix of individual and ranges +# ./print_questions.sh --print 1 3 # Generate PDF AND print questions 1, 3 +# ./print_questions.sh --print # Generate PDF AND print ALL questions +# ./print_questions.sh --list # List available questions +# +# Options: +# --print, -p Send to printer after generating PDF +# --printer NAME Printer name (default: Brother_HL-1110_series) +# --list, -l List available questions and exit +# --output, -o FILE Output PDF path (default: auto-generated in /tmp) +# --keep, -k Keep intermediate files (for debugging) +# --help, -h Show this help +# + +set -euo pipefail + +# ── Configuration ────────────────────────────────────────────────────────────── +SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" +SOURCE_MD="${SCRIPT_DIR}/OBRONA_MAGISTERSKA_ODPOWIEDZI.md" +PRINTER="Brother_HL-1110_series" +DO_PRINT=false +LIST_ONLY=false +KEEP_TMP=false +OUTPUT_PDF="" +QUESTIONS=() + +# ── Parse arguments ─────────────────────────────────────────────────────────── +while [[ $# -gt 0 ]]; do + case "$1" in + --print|-p) + DO_PRINT=true + shift + ;; + --printer) + PRINTER="$2" + shift 2 + ;; + --list|-l) + LIST_ONLY=true + shift + ;; + --output|-o) + OUTPUT_PDF="$2" + shift 2 + ;; + --keep|-k) + KEEP_TMP=true + shift + ;; + --help|-h) + head -28 "$0" | tail -26 + exit 0 + ;; + *) + # Parse question numbers and ranges (e.g., "1", "3-5", "13/27") + if [[ "$1" =~ ^[0-9]+(\/[0-9]+)?(-[0-9]+(\/[0-9]+)?)?$ ]]; then + if [[ "$1" == *-* ]]; then + # Range: extract start-end + range_start="${1%%-*}" + range_end="${1##*-}" + for ((i=range_start; i<=range_end; i++)); do + QUESTIONS+=("$i") + done + else + QUESTIONS+=("$1") + fi + else + echo "Error: Unknown argument '$1'. Use --help for usage." >&2 + exit 1 + fi + shift + ;; + esac +done + +# ── Verify source file ─────────────────────────────────────────────────────── +if [[ ! -f "$SOURCE_MD" ]]; then + echo "Error: Source file not found: $SOURCE_MD" >&2 + exit 1 +fi + +# ── List questions ──────────────────────────────────────────────────────────── +list_questions() { + echo "Available questions in $(basename "$SOURCE_MD"):" + echo "" + grep "^## PYTANIE" "$SOURCE_MD" | while IFS= read -r line; do + # Extract question number and title + num=$(echo "$line" | sed 's/^## PYTANIE \([0-9/]*\):.*/\1/') + title=$(echo "$line" | sed 's/^## PYTANIE [0-9/]*: //') + printf " %6s %s\n" "$num" "$title" + done + echo "" + echo "Total: $(grep -c "^## PYTANIE" "$SOURCE_MD") questions" +} + +if $LIST_ONLY; then + list_questions + exit 0 +fi + +# ── Extract questions ───────────────────────────────────────────────────────── +extract_questions() { + local md_file="$1" + shift + local selected=("$@") + + if [[ ${#selected[@]} -eq 0 ]]; then + # All questions — output entire file + cat "$md_file" + return + fi + + local tmpfile + tmpfile=$(mktemp) + local in_question=false + local current_num="" + local line_num=0 + + # Build a grep pattern to find question headers with their line numbers + # Then extract the relevant sections + local question_starts=() + local question_labels=() + + while IFS= read -r line; do + ((line_num++)) || true + if [[ "$line" =~ ^##\ PYTANIE\ ([0-9]+(/[0-9]+)?): ]]; then + question_starts+=("$line_num") + question_labels+=("${BASH_REMATCH[1]}") + fi + done < "$md_file" + + # Total lines in file + local total_lines + total_lines=$(wc -l < "$md_file") + + # For each selected question, find its start and end lines + local first=true + for sel in "${selected[@]}"; do + for i in "${!question_labels[@]}"; do + local label="${question_labels[$i]}" + # Match: exact number, or either side of a slash (e.g., "13" matches "13/27") + local match=false + if [[ "$label" == "$sel" ]]; then + match=true + elif [[ "$label" == */* ]]; then + local left="${label%%/*}" + local right="${label##*/}" + if [[ "$sel" == "$left" || "$sel" == "$right" ]]; then + match=true + fi + fi + + if $match; then + local start="${question_starts[$i]}" + local end="$total_lines" + + # End = next question start - 1, or EOF + local next=$((i + 1)) + if [[ $next -lt ${#question_starts[@]} ]]; then + end=$(( ${question_starts[$next]} - 1 )) + fi + + # Strip trailing blank lines and \newpage + if ! $first; then + echo "" + echo "\\newpage" + echo "" + fi + first=false + + sed -n "${start},${end}p" "$md_file" | sed '/^\\newpage$/d' | sed -e :a -e '/^\s*$/{ $d; N; ba; }' + break + fi + done + done + + rm -f "$tmpfile" +} + +# ── Generate output filename ───────────────────────────────────────────────── +if [[ -z "$OUTPUT_PDF" ]]; then + if [[ ${#QUESTIONS[@]} -eq 0 ]]; then + OUTPUT_PDF="/tmp/obrona_all_questions.pdf" + elif [[ ${#QUESTIONS[@]} -eq 1 ]]; then + OUTPUT_PDF="/tmp/obrona_q${QUESTIONS[0]}.pdf" + else + joined=$(IFS=_; echo "${QUESTIONS[*]}") + OUTPUT_PDF="/tmp/obrona_q${joined}.pdf" + fi +fi + +# ── Create temporary markdown ──────────────────────────────────────────────── +TMP_DIR=$(mktemp -d) +TMP_MD="${TMP_DIR}/questions.md" + +extract_questions "$SOURCE_MD" "${QUESTIONS[@]}" > "$TMP_MD" + +# Count extracted questions +extracted=$(grep -c "^## PYTANIE" "$TMP_MD" || echo "0") +if [[ "$extracted" -eq 0 ]]; then + echo "Error: No matching questions found for: ${QUESTIONS[*]}" >&2 + echo "Use --list to see available questions." >&2 + rm -rf "$TMP_DIR" + exit 1 +fi + +# ── Convert to PDF via pandoc + xelatex ─────────────────────────────────────── +echo "Converting $extracted question(s) to PDF..." + +pandoc "$TMP_MD" \ + -o "$OUTPUT_PDF" \ + --pdf-engine=xelatex \ + -V geometry:a4paper \ + -V geometry:margin=1.8cm \ + -V fontsize=12pt \ + -V mainfont="DejaVu Sans" \ + -V sansfont="DejaVu Sans" \ + -V monofont="DejaVu Sans Mono" \ + -V linestretch=1.15 \ + -V colorlinks=false \ + --highlight-style=monochrome \ + -V header-includes='\usepackage{fancyhdr}\pagestyle{fancy}\fancyhead[L]{\small Obrona magisterska}\fancyhead[R]{\small\thepage}\fancyfoot{}' \ + -V header-includes='\usepackage{enumitem}\setlist{nosep,leftmargin=*}' \ + -V header-includes='\renewcommand{\arraystretch}{1.3}' \ + -V header-includes='\usepackage{booktabs}' \ + 2>/dev/null + +echo "PDF generated: $OUTPUT_PDF" +echo " Pages: $(pdfinfo "$OUTPUT_PDF" 2>/dev/null | grep Pages | awk '{print $2}' || echo "?")" + +# ── Print ───────────────────────────────────────────────────────────────────── +if $DO_PRINT; then + if ! lpstat -p "$PRINTER" &>/dev/null; then + echo "Error: Printer '$PRINTER' not found." >&2 + echo "Available printers:" >&2 + lpstat -p 2>/dev/null | awk '{print " " $2}' >&2 + rm -rf "$TMP_DIR" + exit 1 + fi + + echo "Printing to $PRINTER..." + lp -d "$PRINTER" \ + -o media=A4 \ + -o sides=one-sided \ + -o fit-to-page \ + "$OUTPUT_PDF" + echo "Print job submitted." +fi + +# ── Cleanup ─────────────────────────────────────────────────────────────────── +if $KEEP_TMP; then + echo "Temporary files kept in: $TMP_DIR" +else + rm -rf "$TMP_DIR" +fi