From 54337a662e7be1b18bb721025f401e93ac932630 Mon Sep 17 00:00:00 2001 From: Krzysztof kuhy Rudnicki Date: Fri, 28 Aug 2026 17:41:11 +0200 Subject: [PATCH] Organise markdown into the four namespaces and add CLAUDE.md Five files were outside README / CLAUDE* / DOCS* / TODO*, and two were over the 250-line cap. Both gates now pass repo-wide. Renames: the two lowercase readme.md files, and three documents into DOCS-*. The AIS requirements doc split at its own boundary into functional (101) and non-functional (174). The WDWR report split into six numbered sections behind an index that keeps the original filename, 38-235 lines each; 753 lines of body plus the 18-line header account for all 771 original lines, so nothing was dropped. That WDWR file needed checking before splitting: it sits next to main.tex and main.pdf and looked like a conversion of them. It is not -- main.tex is project 25406 and the markdown is project 18402, a different document. So it is authored content and the split is real work, not churn on a build artifact. Filled the three empty READMEs and replaced ECOTE's, which was a stale copy of the root README still claiming the group projects were excluded -- they were merged in by subtree some time ago. EOPSY/lab1 turned out not to be the code-free directory the survey suggested: it has modify.sh and modify_examples.sh. The oddly-named empty files beside them are the exercise's OUTPUT, committed so the before/after state is visible, and its README now says so rather than leaving them looking like junk. CLAUDE.md follows the testsAndMisc structure. Writing it caught a nice one: the md-naming marker is a biconditional, so quoting the literal removal string in a non-TODO file fails the gate. The gate was right; the text is rephrased. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_0172dj34FDpao6wsix8ZuCzE --- CLAUDE.md | 105 +++ ...down_images.md => DOCS-markdown-images.md} | 0 .../draft/DOCS-wymagania-funkcjonalne.md | 101 +++ ...e.md => DOCS-wymagania-niefunkcjonalne.md} | 96 --- Programming/ECOTE/README.md | 26 +- .../EOOP/Warehouse/{readme.md => README.md} | 0 Programming/EOPSY/lab1/README.md | 14 + .../WDWR/projekt/doc/DOCS-01-tresc-zadania.md | 38 + .../doc/DOCS-02-model-jednokryterialny.md | 83 ++ .../doc/DOCS-03-model-dwukryterialny.md | 90 ++ .../doc/DOCS-04-parametry-t-studenta.md | 235 ++++++ .../WDWR/projekt/doc/DOCS-05-pliki-ampl.md | 188 +++++ .../WDWR/projekt/doc/DOCS-06-wyniki.md | 119 +++ .../projekt/doc/DOCS-combined-document.md | 30 + .../WDWR/projekt/doc/combined_document.md | 771 ------------------ .../projekt/old_code/{readme.md => README.md} | 0 Programming/WDWR/projekt/wdwr/README.md | 17 +- Programming/twm_4/README.md | 12 + 18 files changed, 1048 insertions(+), 877 deletions(-) create mode 100644 CLAUDE.md rename Programming/AIS/report/draft/{markdown_images.md => DOCS-markdown-images.md} (100%) create mode 100644 Programming/AIS/report/draft/DOCS-wymagania-funkcjonalne.md rename Programming/AIS/report/draft/{AIS Wymagania funkcjonalne.md => DOCS-wymagania-niefunkcjonalne.md} (61%) rename Programming/EOOP/Warehouse/{readme.md => README.md} (100%) create mode 100644 Programming/WDWR/projekt/doc/DOCS-01-tresc-zadania.md create mode 100644 Programming/WDWR/projekt/doc/DOCS-02-model-jednokryterialny.md create mode 100644 Programming/WDWR/projekt/doc/DOCS-03-model-dwukryterialny.md create mode 100644 Programming/WDWR/projekt/doc/DOCS-04-parametry-t-studenta.md create mode 100644 Programming/WDWR/projekt/doc/DOCS-05-pliki-ampl.md create mode 100644 Programming/WDWR/projekt/doc/DOCS-06-wyniki.md create mode 100644 Programming/WDWR/projekt/doc/DOCS-combined-document.md delete mode 100644 Programming/WDWR/projekt/doc/combined_document.md rename Programming/WDWR/projekt/old_code/{readme.md => README.md} (100%) diff --git a/CLAUDE.md b/CLAUDE.md new file mode 100644 index 00000000..eb9860b6 --- /dev/null +++ b/CLAUDE.md @@ -0,0 +1,105 @@ +# WUT_Computer_Science + +Archive of university coursework from Warsaw University of Technology. +44 course directories, 12 languages, ~28k lines of authored code plus the +submitted reports, figures and datasets. It is an **archive**: the code is +finished, and the value is that it still builds, runs and is readable. + +## Repository Layout + +| Path | What it is | +|---|---| +| `Programming/` | 25 course dirs with real code (Python, C/C++, Java, TS/Angular, C#, Unity, MATLAB-adjacent). | +| `NotProgramming/` | 19 course dirs that are mostly LaTeX reports, PDFs and EDA schematics. Exceptions: `ENUME` (MATLAB), `STUP/makieta` (Angular), `EDABA-LAB` (SQL). | +| `gates/` | Machine-readable gate inputs. `vendored.txt` is the source of truth for "not my code". | +| `scripts/` | Repo-local gates. Shims that `exec` into `~/utils` live here too. | + +Two structural facts that surprise people: + +- **`Programming/PSD/zin3/third/` and `Programming/psd_project/` are the same + services under different names**, and `WDWR/project/` vs `WDWR/projekt/`, + `SDM` vs `SDM2`, and `EMISY/componentSchematic/` vs `EMISY/schematic/` are + likewise near-duplicates. They are **not** de-duplicated: each is a separate + submitted deliverable, and merging them would rewrite the academic record. +- **`Programming/EOPSY/lab{3,4}/task*/work/` is not student code.** It is the + extraction target of `make setup` from the tarballs in the sibling `ftp/`. + Verified byte-identical, 14/14 files. Do not edit or split it. + +## Git Workflow + +Work directly on `main`; commit and push straight there. + +```bash +./install.sh # deps + pre-commit hooks, then verifies and fails loudly +./run.sh check # the full local gate +./run.sh status # probe every course dir, regenerate DOCS-runnability.md +``` + +Never `--no-verify`. If a gate fails, fix the cause. + +## Development Workflow + +- Confirm a change works by **running the thing** and reading its output, not + by running tests. Tests come after. +- `git rm --cached`, never bare `git rm`, when removing build output — it must + stay on disk so a mis-classification is recoverable. +- After touching `.gitignore` or `.binary-allowlist`, re-run: + ```bash + git ls-files | git check-ignore --stdin --no-index + ``` + It must print nothing. A file that is both tracked and ignored fails + **silently** on `git add`: not an error, the edit just never lands. This + repo had 130 such files. + +## Code Conventions + +Anything a hook already enforces is omitted here — read +`.pre-commit-config.yaml` for that list. What follows is what a linter cannot +check. + +### Everything + +- **Every file is at most 250 lines, source and prose alike**, enforced by the + shared gate in `~/utils`. There is deliberately no baseline and no + allowlist: split the file. For a LaTeX report that means `\input{}` per + section; for a markdown report, sibling `DOCS-*.md` files behind an index. +- Do not "fix" coursework to be better than it was submitted. Correct what is + broken, keep what is merely old-fashioned. The archive should still show + what was actually handed in. + +### Vendored content + +`gates/vendored.txt` is the only place a path becomes exempt from lint, +coverage and the cap. Every entry carries a reason **and how it was +verified** — an unverified entry is a suppression wearing a costume. The list +is mirrored into `~/utils/file_length/_tables.py`, `[tool.ruff] exclude` and +`[tool.coverage.run] omit`; edit the manifest, never a mirror. + +### Python + +- `ruff` runs with `select = ["ALL"]` and mypy with `strict = true`. +- No `# noqa`, no `# type: ignore`. A pre-commit hook rejects both outright. +- Notebooks: outputs are stripped on commit, lint via `nbqa`. Real logic + belongs in a sibling importable module — a notebook cannot be covered. + +### LaTeX + +Build output is ignored, not committed: `.aux`, `.fls`, `.fdb_latexmk`, +`.xdv`, `-eps-converted-to.pdf` and friends. The submitted `.pdf` **is** +committed, because it is the deliverable. + +### Shell + +`set -euo pipefail`, quoted expansions, `main "$@"` last. Never embed another +language's logic inline — put it in its own file so that language's tooling +applies. + +## Key Files + +| Path | Why it matters | +|---|---| +| `gates/vendored.txt` | What is not my code, and how each entry was verified. | +| `gates/coverage.tsv` | Per-directory coverage floors. Floors may only rise. | +| `.binary-allowlist` | Path-scoped: deliverables allowed under the two course trees, compiled output allowed nowhere. | +| `DOCS-runnability.md` | Per-course run status, recorded separately for `local` and `ci`. | +| `TODO-*.md` | Open decisions. Each carries the removal marker and is deleted when the work lands. | diff --git a/Programming/AIS/report/draft/markdown_images.md b/Programming/AIS/report/draft/DOCS-markdown-images.md similarity index 100% rename from Programming/AIS/report/draft/markdown_images.md rename to Programming/AIS/report/draft/DOCS-markdown-images.md diff --git a/Programming/AIS/report/draft/DOCS-wymagania-funkcjonalne.md b/Programming/AIS/report/draft/DOCS-wymagania-funkcjonalne.md new file mode 100644 index 00000000..79316c52 --- /dev/null +++ b/Programming/AIS/report/draft/DOCS-wymagania-funkcjonalne.md @@ -0,0 +1,101 @@ +[https://github.com/Artur-Romaniuk/ais](https://github.com/Artur-Romaniuk/ais) +[https://www.overleaf.com/project/67e843e5c78b52b01a88211a](https://www.overleaf.com/project/67e843e5c78b52b01a88211a) + +System e-Toll do zbierania danych na temat ruchu pojazdów po polskich drogach i naliczania należności za przejazdy. + +Rezultatem projektu powinien być dokument PDF, zawierający następujące elementy: + +1. Wymagania funkcjonalne. + * pogrupowana lista wymagań + * zidentyfikować jeden kluczowy proces biznesowy i szczegółowo ten proces zdefiniować. Definicja procesu to po prostu: + * cel procesu + * stan początkowy + * stan końcowy + * kroki procesu, z uwzględnieniem sytuacji wyjątkowych. +2. Wymagania niefunkcjonalne. + * geograficzna skala działania + * liczba obsługiwanych klientów + * liczba obsługiwanych zdarzeń biznesowych w określonym czasie (na godzinę/dziennie/miesięcznie etc.) + * wymagania wydajnościowe + * wymagania niezawodnościowe + * wymagania bezpieczeństwa + * .... +3. Projekt systemu w postaci modelu C4 (https://c4model.com/) + * wystarczą 3 pierwsze poziomy : context, containers, components, nie wymagam poziomu code + * diagram dynamiczny(dynamic diagram) realizujący opisany w wymaganiach proces biznesowy + * diagram wdrożenia (deploymen diagram) +4. Dyskusja zastosowanych wzorców i/lub taktyk architektonicznych \- w celu wyboru odpowiednich rozwiązań należy się odwołać do wymagań funkcjonalnych i niefunkcjonalnych. +5. Decyzje architektoniczne w postaci modelu MAD 2.0 + +# Wymagania funkcjonalne + +\# Wymagania funkcjonalne dla Systemu e-Toll + +\#\# Kluczowy proces biznesowy: Naliczanie i pobieranie opłat za przejazd + +\#\#\# 1\. Cel procesu + +1) Wykrywanie pojazdów na płatnych odcinkach dróg +2) Naliczanie należności zgodnie z taryfami +3) Pobieranie opłat od użytkowników + +\#\#\# 2\. Stan początkowy +Pojazd niezarejestrowany w systemie jako znajdujący się na płatnym odcinku drogi, z kontem użytkownika posiadającym określony stan środków (prepaid) lub limitem kredytowym (postpaid). + +\#\#\# 3\. Stan końcowy +Prawidłowo naliczona i pobrana opłata za przejazd, zaksięgowana w systemie finansowym, z wygenerowanym potwierdzeniem dla użytkownika oraz aktualizacją stanu konta. + +\#\#\# 4\. Kroki procesu +1\. Identyfikacja pojazdu wjeżdżającego na płatny odcinek (poprzez urządzenie OBU, aplikację mobilną lub kamery ANPR) \[Dla redundancji, im więcej systemów tym większa szansa na identyfikację) +2\. Zebranie danych o pojeździe (kategoria, klasa emisji spalin, masa) +3\. Rozpoczęcie śledzenia przejazdu i rejestracja czasu wjazdu +4\. Monitorowanie trasy przejazdu przez punkty kontrolne +5\. Identyfikacja zjazdu z płatnego odcinka +6\. Obliczenie należności na podstawie przebytej trasy i charakterystyki pojazdu +7\. Weryfikacja dostępności środków na koncie użytkownika +8\. Pobranie opłaty z konta użytkownika +9\. Wygenerowanie potwierdzenia transakcji +10\. Aktualizacja salda konta użytkownika + +\*\*Obsługa sytuacji wyjątkowych:\*\* +\- Jeśli identyfikacja pojazdu nie jest możliwa: uruchomienie procedury rejestracji incydentu z dokumentacją wizualną (zdjęcia niezidentyfikowanego pojazdu) +\- W przypadku niewystarczających środków na koncie: + +1) Zablokowanie konta do momentu zapłacenia +2) W przypadku braku zapłaty w określonym czasie, uruchomienie procedury windykacyjnej + +\- Przy awarii urządzenia OBU: automatyczne przełączenie na identyfikację przez system kamer ANPR +\- W razie przerwy w komunikacji: lokalne buforowanie danych i synchronizacja po przywróceniu łączności +\- Jeśli zidentyfikowano omijanie bramek: + +1. Poinformowanie użytkownika +2. uruchomienie procedury kontrolnej +3. naliczenie kary + +\#\# Wymagania funkcjonalne + +1\. \*\*System rejestracji użytkowników\*\* \- System musi umożliwiać rejestrację nowych użytkowników z weryfikacją tożsamości, zbieraniem danych o pojazdach (w tym masa, klasa emisji, kategoria) oraz wyborem metody płatności (prepaid lub postpaid). + +2\. \*\*Moduł geolokalizacji pojazdów\*\* \- System musi określać pozycję pojazdów z dokładnością do 10 metrów, wykorzystując dane GPS z urządzeń OBU lub aplikacji mobilnej, aktualizowane nie rzadziej niż co 30 sekund podczas przejazdu. + +3\. \*\*System rozpoznawania tablic rejestracyjnych (ANPR)\*\* \- System musi identyfikować pojazdy poprzez kamery ANPR z dokładnością co najmniej 98% w różnych warunkach pogodowych i oświetleniowych, jako dopełnienie jeśli wszystkie systemy działają poprawnie lub alternatywa dla urządzeń OBU w razie awarii.. + +4\. \*\*Elastyczny system taryfowy\*\* \- System musi obsługiwać zróżnicowane taryfy opłat w zależności od: typu pojazdu, masy całkowitej, klasy emisji spalin, pory dnia, dnia tygodnia oraz stopnia zatłoczenia drogi. + +5\. \*\*Moduł rozliczeń i płatności\*\* \- System musi obsługiwać różne metody płatności (karty płatnicze, przelewy, płatności mobilne, blik) z możliwością automatycznego doładowania konta prepaid oraz wystawiania faktur elektronicznych zgodnych z przepisami prawa. + +6\. \*\*System powiadomień dla użytkowników\*\* \- System musi wysyłać automatyczne powiadomienia do użytkowników (aplikacja, mail \+ sms) o: niskim stanie konta, zbliżającym się terminie płatności, dokonanych transakcjach oraz zmianach w taryfach i regulaminie. + +7\. \*\*Moduł raportowania i analityki\*\* \- System musi generować raporty dotyczące natężenia ruchu, generowanych przychodów, incydentów oraz efektywności egzekwowania opłat, z możliwością eksportu danych w formatach CSV i PDF. + +8\. \*\*System wykrywania naruszeń\*\* \- System musi identyfikować próby obejścia opłat (np. manipulacja urządzeniem OBU, podawanie fałszywych danych o pojeździe) i automatycznie uruchamiać procedury weryfikacyjne. + +9\. \*\*Portal samoobsługowy dla użytkowników\*\* \- System musi udostępniać portal internetowy oraz aplikację mobilną umożliwiającą użytkownikom zarządzanie kontem, przeglądanie historii przejazdów i opłat, generowanie raportów oraz aktualizację danych pojazdu. + +10\. System musi umożliwiać ręczną korektę naliczonej opłaty przez operatora w przypadku zgłoszenia błędu przez użytkownika. Zakładając, że system źle naliczył opłatę np. Użytkownik został obciążony za trasę, której nie przejechał lub przypisano niewłaściwą kategorię pojazdu. Użytkownik zgłasza błąd do obsługi systemu. W takim przypadku operator musi mieć możliwość ręcznej korekty naliczonej opłaty np. Anulowanie opłaty, zmniejszenie jej lub ponowne przeliczenie, jeżeli zgłoszenie użytkownika okaże się zasadne. Zasadność zgłoszenia musi być weryfikowalna poprzez fizyczne zdjęcia pojazdu + + +--- + +[Wymagania niefunkcjonalne](DOCS-wymagania-niefunkcjonalne.md) zostały +wydzielone do osobnego pliku, aby zmieścić się w limicie 250 wierszy. diff --git a/Programming/AIS/report/draft/AIS Wymagania funkcjonalne.md b/Programming/AIS/report/draft/DOCS-wymagania-niefunkcjonalne.md similarity index 61% rename from Programming/AIS/report/draft/AIS Wymagania funkcjonalne.md rename to Programming/AIS/report/draft/DOCS-wymagania-niefunkcjonalne.md index 7d055a4e..a475e4b8 100644 --- a/Programming/AIS/report/draft/AIS Wymagania funkcjonalne.md +++ b/Programming/AIS/report/draft/DOCS-wymagania-niefunkcjonalne.md @@ -1,99 +1,3 @@ -[https://github.com/Artur-Romaniuk/ais](https://github.com/Artur-Romaniuk/ais) -[https://www.overleaf.com/project/67e843e5c78b52b01a88211a](https://www.overleaf.com/project/67e843e5c78b52b01a88211a) - -System e-Toll do zbierania danych na temat ruchu pojazdów po polskich drogach i naliczania należności za przejazdy. - -Rezultatem projektu powinien być dokument PDF, zawierający następujące elementy: - -1. Wymagania funkcjonalne. - * pogrupowana lista wymagań - * zidentyfikować jeden kluczowy proces biznesowy i szczegółowo ten proces zdefiniować. Definicja procesu to po prostu: - * cel procesu - * stan początkowy - * stan końcowy - * kroki procesu, z uwzględnieniem sytuacji wyjątkowych. -2. Wymagania niefunkcjonalne. - * geograficzna skala działania - * liczba obsługiwanych klientów - * liczba obsługiwanych zdarzeń biznesowych w określonym czasie (na godzinę/dziennie/miesięcznie etc.) - * wymagania wydajnościowe - * wymagania niezawodnościowe - * wymagania bezpieczeństwa - * .... -3. Projekt systemu w postaci modelu C4 (https://c4model.com/) - * wystarczą 3 pierwsze poziomy : context, containers, components, nie wymagam poziomu code - * diagram dynamiczny(dynamic diagram) realizujący opisany w wymaganiach proces biznesowy - * diagram wdrożenia (deploymen diagram) -4. Dyskusja zastosowanych wzorców i/lub taktyk architektonicznych \- w celu wyboru odpowiednich rozwiązań należy się odwołać do wymagań funkcjonalnych i niefunkcjonalnych. -5. Decyzje architektoniczne w postaci modelu MAD 2.0 - -# Wymagania funkcjonalne - -\# Wymagania funkcjonalne dla Systemu e-Toll - -\#\# Kluczowy proces biznesowy: Naliczanie i pobieranie opłat za przejazd - -\#\#\# 1\. Cel procesu - -1) Wykrywanie pojazdów na płatnych odcinkach dróg -2) Naliczanie należności zgodnie z taryfami -3) Pobieranie opłat od użytkowników - -\#\#\# 2\. Stan początkowy -Pojazd niezarejestrowany w systemie jako znajdujący się na płatnym odcinku drogi, z kontem użytkownika posiadającym określony stan środków (prepaid) lub limitem kredytowym (postpaid). - -\#\#\# 3\. Stan końcowy -Prawidłowo naliczona i pobrana opłata za przejazd, zaksięgowana w systemie finansowym, z wygenerowanym potwierdzeniem dla użytkownika oraz aktualizacją stanu konta. - -\#\#\# 4\. Kroki procesu -1\. Identyfikacja pojazdu wjeżdżającego na płatny odcinek (poprzez urządzenie OBU, aplikację mobilną lub kamery ANPR) \[Dla redundancji, im więcej systemów tym większa szansa na identyfikację) -2\. Zebranie danych o pojeździe (kategoria, klasa emisji spalin, masa) -3\. Rozpoczęcie śledzenia przejazdu i rejestracja czasu wjazdu -4\. Monitorowanie trasy przejazdu przez punkty kontrolne -5\. Identyfikacja zjazdu z płatnego odcinka -6\. Obliczenie należności na podstawie przebytej trasy i charakterystyki pojazdu -7\. Weryfikacja dostępności środków na koncie użytkownika -8\. Pobranie opłaty z konta użytkownika -9\. Wygenerowanie potwierdzenia transakcji -10\. Aktualizacja salda konta użytkownika - -\*\*Obsługa sytuacji wyjątkowych:\*\* -\- Jeśli identyfikacja pojazdu nie jest możliwa: uruchomienie procedury rejestracji incydentu z dokumentacją wizualną (zdjęcia niezidentyfikowanego pojazdu) -\- W przypadku niewystarczających środków na koncie: - -1) Zablokowanie konta do momentu zapłacenia -2) W przypadku braku zapłaty w określonym czasie, uruchomienie procedury windykacyjnej - -\- Przy awarii urządzenia OBU: automatyczne przełączenie na identyfikację przez system kamer ANPR -\- W razie przerwy w komunikacji: lokalne buforowanie danych i synchronizacja po przywróceniu łączności -\- Jeśli zidentyfikowano omijanie bramek: - -1. Poinformowanie użytkownika -2. uruchomienie procedury kontrolnej -3. naliczenie kary - -\#\# Wymagania funkcjonalne - -1\. \*\*System rejestracji użytkowników\*\* \- System musi umożliwiać rejestrację nowych użytkowników z weryfikacją tożsamości, zbieraniem danych o pojazdach (w tym masa, klasa emisji, kategoria) oraz wyborem metody płatności (prepaid lub postpaid). - -2\. \*\*Moduł geolokalizacji pojazdów\*\* \- System musi określać pozycję pojazdów z dokładnością do 10 metrów, wykorzystując dane GPS z urządzeń OBU lub aplikacji mobilnej, aktualizowane nie rzadziej niż co 30 sekund podczas przejazdu. - -3\. \*\*System rozpoznawania tablic rejestracyjnych (ANPR)\*\* \- System musi identyfikować pojazdy poprzez kamery ANPR z dokładnością co najmniej 98% w różnych warunkach pogodowych i oświetleniowych, jako dopełnienie jeśli wszystkie systemy działają poprawnie lub alternatywa dla urządzeń OBU w razie awarii.. - -4\. \*\*Elastyczny system taryfowy\*\* \- System musi obsługiwać zróżnicowane taryfy opłat w zależności od: typu pojazdu, masy całkowitej, klasy emisji spalin, pory dnia, dnia tygodnia oraz stopnia zatłoczenia drogi. - -5\. \*\*Moduł rozliczeń i płatności\*\* \- System musi obsługiwać różne metody płatności (karty płatnicze, przelewy, płatności mobilne, blik) z możliwością automatycznego doładowania konta prepaid oraz wystawiania faktur elektronicznych zgodnych z przepisami prawa. - -6\. \*\*System powiadomień dla użytkowników\*\* \- System musi wysyłać automatyczne powiadomienia do użytkowników (aplikacja, mail \+ sms) o: niskim stanie konta, zbliżającym się terminie płatności, dokonanych transakcjach oraz zmianach w taryfach i regulaminie. - -7\. \*\*Moduł raportowania i analityki\*\* \- System musi generować raporty dotyczące natężenia ruchu, generowanych przychodów, incydentów oraz efektywności egzekwowania opłat, z możliwością eksportu danych w formatach CSV i PDF. - -8\. \*\*System wykrywania naruszeń\*\* \- System musi identyfikować próby obejścia opłat (np. manipulacja urządzeniem OBU, podawanie fałszywych danych o pojeździe) i automatycznie uruchamiać procedury weryfikacyjne. - -9\. \*\*Portal samoobsługowy dla użytkowników\*\* \- System musi udostępniać portal internetowy oraz aplikację mobilną umożliwiającą użytkownikom zarządzanie kontem, przeglądanie historii przejazdów i opłat, generowanie raportów oraz aktualizację danych pojazdu. - -10\. System musi umożliwiać ręczną korektę naliczonej opłaty przez operatora w przypadku zgłoszenia błędu przez użytkownika. Zakładając, że system źle naliczył opłatę np. Użytkownik został obciążony za trasę, której nie przejechał lub przypisano niewłaściwą kategorię pojazdu. Użytkownik zgłasza błąd do obsługi systemu. W takim przypadku operator musi mieć możliwość ręcznej korekty naliczonej opłaty np. Anulowanie opłaty, zmniejszenie jej lub ponowne przeliczenie, jeżeli zgłoszenie użytkownika okaże się zasadne. Zasadność zgłoszenia musi być weryfikowalna poprzez fizyczne zdjęcia pojazdu - # Wymagania niefunkcjonalne 1\. \*\*Wydajność systemu\*\* \- System musi obsługiwać jednoczesne przetwarzanie danych z co [najmniej 200,000 pojazdów w godzinach szczytu](https://forsal.pl/transport/drogi/artykuly/8295957,najbardziej-obciazone-drogi-w-polsce-s8-s2-a4-s86-mapa.html), z czasem odpowiedzi dla transakcji poniżej 1s oraz przetwarzaniem danych geolokalizacyjnych w czasie rzeczywistym. diff --git a/Programming/ECOTE/README.md b/Programming/ECOTE/README.md index e0b519c1..4043df0a 100644 --- a/Programming/ECOTE/README.md +++ b/Programming/ECOTE/README.md @@ -1,9 +1,17 @@ -# WUT_Computer_Science -This repository aims to consolidate every single project I did solo during my Computer Science course on Warsaw University of Technology
-It does not contain multiple projects that I did in a group like:
-https://github.com/PolishPigeon/E-PSYOPS - Unity Game used to pass last 3 laboratories of EOPSY course
-https://github.com/BartDrown/polygon-21z - Unity Game for my third Polygon Project
-https://gitlab.com/Maciekxdabu/polygon-22l-samochdzik - Unity Game for my fourth Polygon Project
-https://github.com/kuchyx/ECRYPT_PROJECT - ECRYPT project done in 2 persons group, creating and testing sieve of erastothenes python program
-https://github.com/kuchyx/EDABA-LAB - EDABA project where a database concept, design and implementation was created in two persons group
-And tens of reports from laboratories done either solo or in group. +# ECOTE — Compilation Techniques + +A translator that converts LaTeX `tabular` environments into HTML tables, +written for the ECOTE (Compilation Techniques) course. + +| Path | What it is | +|---|---| +| `program/code/` | The translator. Entry point is `main.py`. | +| `program/unit_tests/test_code/` | 17 pytest modules covering the lexer, parser and emitter. | +| `preliminaryReport/` | The design document submitted before implementation. | +| `finalReport/` | The final report. | + +See `program/README.md` for how to run it and the test suite. + +> This file previously held a stale copy of the repository root README, +> describing the group projects as *not* included. They have been merged in +> since (see the root `README.md`), and this directory is about ECOTE. diff --git a/Programming/EOOP/Warehouse/readme.md b/Programming/EOOP/Warehouse/README.md similarity index 100% rename from Programming/EOOP/Warehouse/readme.md rename to Programming/EOOP/Warehouse/README.md diff --git a/Programming/EOPSY/lab1/README.md b/Programming/EOPSY/lab1/README.md index e69de29b..f67313b3 100644 --- a/Programming/EOPSY/lab1/README.md +++ b/Programming/EOPSY/lab1/README.md @@ -0,0 +1,14 @@ +# EOPSY — lab 1: shell scripting + +A shell-scripting exercise: recursively rename files and directories to +lower case, and drive `sed` over a tree. + +| Path | What it is | +|---|---| +| `modify.sh` | The submitted solution. | +| `modify_examples.sh` | Worked examples used while developing it. | +| `A`, `b`, `RECURSEFILE`, `sed`, `recurselowerfile`, `LOWERCASEFOLDERMAIN`, ... | Fixture and result files. | + +The oddly-named empty files are not junk and are not source: they are the +*output* of running the scripts, committed so the before/after state of the +exercise is visible. Their names are the point. diff --git a/Programming/WDWR/projekt/doc/DOCS-01-tresc-zadania.md b/Programming/WDWR/projekt/doc/DOCS-01-tresc-zadania.md new file mode 100644 index 00000000..77f5701b --- /dev/null +++ b/Programming/WDWR/projekt/doc/DOCS-01-tresc-zadania.md @@ -0,0 +1,38 @@ +## **WDWR 18402** + +Rozważamy następujące zagadnienie planowania produkcji: + +• Przedsiębiorstwo wytwarza 4 produkty P1,. . . ,P4 na następujących maszynach: 4 szlifierkach, 2 wiertarkach pionowych, 3 wiertarkach poziomych, 1 frezarce i 1 tokarce. Wymagane czasy produkcji 1 sztuki produktu (w godzinach) w danym procesie obróbki zostały przedstawione w poniższej tabeli: + +| | P1 | P2 | P3 | P4 | +|-------------------|------|------|------|------| +| Szlifowanie | 0,4 | 0,6 | — | — | +| Wiercenie pionowe | 0,2 | 0,1 | — | 0,6 | +| Wiercenie poziome | 0,1 | — | 0,7 | — | +| Frezowanie | 0,06 | 0,04 | — | 0,05 | +| Toczenie | — | 0,05 | 0,02 | — | + +• Dochody ze sprzedaży produktów (w zł/sztukę) określają składowe wektora losowego **R** = (*R*1*, . . . , R*4) *T* . Wektor losowy **R** opisuje 4-wymiarowy rozkład *t*-Studenta z 5 stopniami swobody, którego wartości składowych zostały zawężone do przedziału [5; 12]. Parametry *µ* oraz **Σ** niezawężonego rozkładu *t*-Studenta są następujące: + +$$ +\mu = \begin{pmatrix} 9 \\ 8 \\ 7 \\ 6 \end{pmatrix}, \qquad \Sigma = \begin{pmatrix} 16 & -2 & -1 & -3 \\ -2 & 9 & -4 & -1 \\ -1 & -4 & 4 & 1 \\ -3 & -1 & 1 & 1 \end{pmatrix}. +$$ + +• Istnieją ograniczenia rynkowe na liczbę sprzedawanych produktów w danym miesiącu: + +| | P1 | P2 | P3 | P4 | +|---------|-----|-----|-----|-----| +| Styczeń | 200 | 0 | 100 | 200 | +| Luty | 300 | 100 | 200 | 200 | +| Marzec | 0 | 300 | 100 | 200 | + +- Jeżeli w danym miesiącu jest sprzedawany produkt P1 lub P2, to musi być również sprzedawany produkt P4 w ilości nie mniejszej niż suma sprzedawanych produktów P1 i P2. +- Istnieje możliwość składowania do 200 sztuk każdego produktu w danym czasie w cenie 1 zł/sztukę za miesiąc. Aktualnie firma nie posiada żadnych zapasów, ale jest pożądane mieć po 50 sztuk każdego produktu pod koniec marca. +- Przedsiębiorstwo pracuje 6 dni w tygodniu w systemie dwóch zmian. Każda zmiana trwa 8 godzin. Można założyć, że każdy miesiąc składa się z 24 dni roboczych. +- 1. Zaproponować jednokryterialny model wyboru w warunkach ryzyka z wartością oczekiwaną jako miarą zysku. Wyznaczyć rozwiązanie optymalne. +- 2. Jako rozszerzenie powyższego zaproponować dwukryterialny model zysku i ryzyka z wartością oczekiwaną jako miarą zysku i odchyleniem maksymalnym jako miarą ryzyka. Dla decyzji **x** *∈ Q* odchylenie maksymalne jest definiowane jako *D*(**x**) = max*t*=1*,...,T |µ*(**x**) *− rt*(**x**)*|*, gdzie *µ*(**x**) oznacza wartość oczekiwaną, *rt*(**x**) realizację dla scenariusza *t*. + - a. Wyznaczyć obraz zbioru rozwiązań efektywnych w przestrzeni ryzyko–zysk. + - b. Wskazać rozwiązania efektywne minimalnego ryzyka i maksymalnego zysku. Jakie odpowiadają im wartości w przestrzeni ryzyko–zysk? + - c. Wybrać trzy dowolne rozwiązania efektywne. Sprawdzić czy zachodzi pomiędzy nimi relacja dominacji stochastycznej pierwszego rzędu. Wyniki skomentować, odnieść do ogólnego przypadku. + + diff --git a/Programming/WDWR/projekt/doc/DOCS-02-model-jednokryterialny.md b/Programming/WDWR/projekt/doc/DOCS-02-model-jednokryterialny.md new file mode 100644 index 00000000..605439a7 --- /dev/null +++ b/Programming/WDWR/projekt/doc/DOCS-02-model-jednokryterialny.md @@ -0,0 +1,83 @@ +## **2 Jednokryterialny model wyboru w warunkach ryzyka z wartością oczekiwaną jako miarą zysku** + +W celu rozwiązania postawionego zadania dokonano sformułowania modelu programowania liniowego całkowitoliczbowego. Poniżej przedstawiono zapis matematyczny modelu. + +## **2.1 Zbiory indeksowe** + +| Zbiór | Opis | +|-------------------|------------------------------------------------------| +| P =
P1, , P4 | Zbiór wytwarzanych produktów | +| T =
T1, , T5 | Zbiór typów narzędzi wykorzystywanych przy produkcji | +| M =
M1, M2, M3 | Zbiór kolejnych miesięcy produkcji | + +## **2.2 Parametry** + +| Parametr | Opis | +|----------------------------|-----------------------------------------------------------------------| +| tct | Liczba narzędzi typu t [szt] | +| eppup | Oczekiwany zysk ze sprzedaży jednej sztuki produktu
p [zł] | +| ttputp | Czas wykorzystania maszyny typu
t przy produkcji jednej sztuki pro | +| | duktu
p [godz] | +| smlmp | Limit sprzedaży produktu
p w miesiącu
m [szt] | +| stlp | Limit pojemności magazynu na produkt
p [szt] | +| stcpu | Koszt magazynowania jednej sztuki dowolnego produktu [zł] | +| st0p | Początkowy stan magazynowy produktu
p [szt] | +| dstp | Porządany końcowy stan magazynowy produktu
p [szt] | +| dpm | Liczba dni roboczych w każdym miesiącu [d] | +| spd | Liczba zmian w każdym dniu roboczym [j] | +| whps | Liczba godzin roboczych w ciągu każdej zmiany [godz] | +| whpm =
dpm · spd · hps | Liczba godzin roboczych w ciągu każdego miesiąca [godz] | +| =
attt
tct
∗ whpm | Dostępna liczba godzin roboczych maszyn typu
t w ciągu każdego | +| | miesiąca [godz] | + + +## **2.3 Zmienne** + +| Zmienna | Opis | +|----------------------------------------------------|--------------------------------------------------------------------| +| pmp | Liczba sztuk produktu
p wyprodukowanych w miesiącu
m [szt] | +| smp | Liczba sztuk produktu
p sprzedanych w miesiącu
m [szt] | +| X
=
tsp
smp | Całkowita liczba sprzedanych sztuk produktu
p | +| m∈M | | +| =
stdmp
pmp
− smp | Liczba sztuk produktu
p zmagazynowanych w miesiącu
m [szt] | +| Xm
=
st0p
+
stgmp
stdm2p
m2=1 | Stan magazynowy produktu
p na koniec miesiąca
m [szt] | +| X
uttmt
=
pmp
∗ ttputp
p∈P | Wykorzystanie czasu pracy maszyny typu
t w miesiącu
m [godz] | +| X
X
tstc =
stcpu ·
stgmp
m∈M
p∈P | Całkowity koszt wykorzystania magazynów [zł] | +| ep = (X
tsp
· eppup)
− tstc | Wartość zysku całkowitego dla wartości oczekiwanych zysku ze | +| p∈P | sprzedaży produktów [zł] | + +## **2.4 Ograniczenia** + +Ograniczenie rynkowe sprzedawanych produktów: + +*smp* 6 *smlmp, ∀m ∈ M, ∀p ∈ P* + +Ograniczenie sprzedaży produktów w pierszym miesiącu: + +$$s\_{1p} \leqslant p\_{1p}, \quad \forall p \in P$$ + +Ograniczenie sprzedaży produktów w kolejnych miesiącach: + +$$s\_{mp} \leqslant p\_{mp} + stg\_{mp}, \quad \forall m \in M \backslash \{1\}$$ + +Ograniczenie na powiązanie sprzedaży produktu 4 ze sprzedażą produktów 1 i 2: + +*sm*4 > *sm*1 + *sm*2*, ∀m ∈ M* + +Ograniczenie pojemności magazynów: + +$$stg\_{mp} \leqslant stl\_p, \quad \forall p \in P$$ + +Ograniczenie na pożądany stan magazynowy na koniec miesiąca 3: + +$$stg\_{3p} \geqslant dst\_p, \quad \forall p \in P$$ + +Ograniczenie wykorzystania czasu pracy narzędzi w danym miesiącu: + +*uttmt* 6 *attt , ∀t ∈ T, ∀m ∈ M* + +## **2.5 Funkcja celu** + +Jako funkcję celu przyjęto maksymalizację wartości oczekiwanej zysku: *maximize ep* + + diff --git a/Programming/WDWR/projekt/doc/DOCS-03-model-dwukryterialny.md b/Programming/WDWR/projekt/doc/DOCS-03-model-dwukryterialny.md new file mode 100644 index 00000000..bb9dd2f2 --- /dev/null +++ b/Programming/WDWR/projekt/doc/DOCS-03-model-dwukryterialny.md @@ -0,0 +1,90 @@ +# **3 Dwukryterialny model zysku i ryzyka z wartoscią oczekiwaną jako miarą zysku i odchyleniem maksymalnym jako miarą ryzyka** + +Model ten został zrealizowany jako rozszerzenie modelu jednokryterialnego o dodatkowe zbiory, parametry, zmienne, ograniczenia i nową funkcję celu. + +#### **3.1 Zbiory indeksowe** + +| Zbiór | Opis | +|--------------------|--------------------------------------------------------| +| S =
S1, , S1000 | Zbiór scenariuszy wygenerowanych z rozkładu t-Studenta | + +### **3.2 Parametry** + +| Parametr | Opis | +|----------|-----------------------------------------------------------------------| +| sppups | Zysk ze sprzedaży jednej sztuki produktu
p w scenariuszu
s [zł] | + +### **3.3 Zmienne** + +| Zmienna | Opis | +|-------------------------------------------|------------------------------------------------------------------------| +| = (X
· sppups)
sps
tsp
− tstc | Wartość zysku całkowitego dla scenariusza
s zysku ze sprzedaży | +| p∈P | produktów [zł] | +| devs
=
ep − sps | Odchylenie zysku w danym scenariuszu [zł]. Jako, że funkcja | +| | wartości bezwzględnej jest nieliniowa zmienna została poddana | +| | linearyzacji z użyciem zmiennych
ldevs,
Ps,
Qs | +| =
ldevs
ep − sps | Zmienna pomocnicza wykorzystana w linearyzacji odchylenia | +| | zysku w scenariuszu
s | +| Ps | Zmienna pomocnicza wykorzystana w linearyzacji zmiennejk | +| | devs | +| Qs | Zmienna pomocnicza wykorzystana w linearyzacji zmiennej
devs | +| mdev = maxs∈S
devs | Maksymalne odchylenie zysu [zł]. Jako, że funkcja max jest nie | +| | liniowa, zmienna została poddana linearyzacji z użyciem zmien | +| | nych
M,
Zs | +| M | Zmienna
pomocnicza
wykorzystana
w
linearyzacji
zmiennej | +| | mdev | +| Zs | Zmienna
pomocnicza
binarna
wykorzystana
w
linearyzacji | +| | zmiennej
mdev | +| r =
mdev | Miara ryzyka, równa maksymalnemu odchyleniu zysku | + +## **3.4 Ograniczenia** + +Ograniczenie związane z linearyzacją zmiennej *devs*: + +$$lde v\_{s1} - lde v\_{s2} + P\_{s1} - Q\_{s2} = 0, \quad \forall s\_1, s\_2 \in S$$ + +Ograniczenie związane z linearyzację zmiennej *mdev*: + + +$$mdev \geqslant dev\_s, \quad \forall s \in S$$ + +$$mdev \leqslant dev\_s + M(1 - Z\_s), \quad \forall s \in S$$ + +$$\sum\_{s \in S} Z\_s = 1$$ + +## **3.5 Metoda punktu odniesienia** + +Jako model preferencji dla modelu dwukryterialnego została wybrana metoda punktu odniesienia. Wprowadza ona zestaw dodatkowych parametrów i zmiennych: + +| Parametr | Opis | +|-----------|---------------------------------------------------------------------------------| +| aspep | Poziom aspiracji oczekiwanego zysku | +| aspr | Poziom aspiracji ryzyka | +| λep, λr | Współczynniki normalizujące, odpowiednio dla zysku i ryzyka. Ze względu na ogól | +| | ne sformułowanie metody punktu odniesienia jako problemu maksymalizacji,
λep | +| | przyjmie wartość dodatnią, a
ujemną.
λr | +| β | Współczynnik pomniejszający wartość ocen wykraczających powyżej poziomu aspi | +| | racji | +| ε | Współczynnik składnika regularyzacyjnego | +| Zmienne | Opis | +| ocep, ocr | Wartości indywidualnych funkcji osiągnięć dla zysku i ryzyka | +| v | Zmienna pomocnicza metody punktu odniesienia | + +Ograniczenia zmiennej *v* przez wartości indywidualnych funkcji osiągnięć: + +*v* 6 *ocep* oraz *v* 6 *ocr* + +Ograniczenia indywidualnych funkcji osiągnięć: + +$$oc\_r \leqslant \lambda\_r (r - asp\_r)$$ + +$$oc\_r \leqslant \beta \lambda\_r (r - asp\_r)$$ + +$$oc\_{ep} \leqslant \lambda\_p (ep - asp\_{ep})$$ + +$$oc\_{ep} \leqslant \beta \lambda\_p (ep - asp\_{ep})$$ + +Funkcja celu metody punktu odniesienia w postaci dla programowania liniowego: + +$$\max \quad v + \varepsilon (oc\_{ep} + oc\_r)$$ + diff --git a/Programming/WDWR/projekt/doc/DOCS-04-parametry-t-studenta.md b/Programming/WDWR/projekt/doc/DOCS-04-parametry-t-studenta.md new file mode 100644 index 00000000..62de63dc --- /dev/null +++ b/Programming/WDWR/projekt/doc/DOCS-04-parametry-t-studenta.md @@ -0,0 +1,235 @@ +## **4 Wyznaczenie parametrów zadania z rozkładu t-Studenta** + +W celu wyznaczenia wartości oczekiwanej wektora *R* (odpowiadającą parametrowi modelu *eppup*) wykorzystano następującą zależność: + +$$E(R) = \mu + \sigma \cdot \frac{\Gamma(\frac{\nu - 1}{2})((\nu + a^2)^{-\frac{\nu - 1}{2}} - (\nu + b^2)^{\frac{\nu - 1}{2}})\nu^{\frac{\nu}{2}}}{2(F\_{\nu}(b) - F\_{\nu}(a))\Gamma(\frac{\nu}{2})\Gamma(\frac{1}{2})}$$ + +gdzie: + + +- *µ* wartość oczekiwana dla *R*, +- Γ funkcja gamma Eulera, +- *ν* liczba stopni swobody, +- *F* dystrybuanta standardowego rozkładu t-Studenta *t*(0*,* 1; *ν*) z *ν* stopniami swobody, +- *a* = *α−µ σ* , gdzie *α* to lewy kraniec przedziału, +- *b* = *β−µ σ* , gdzie *β*to prawy kraniec przedziału. + +Otrzymano wartości: + +*E*(*R*) *T* = [8*.*5094*,* 8*.*4710*,* 8*.*1319*,* 6*.*3944] + +Do obliczenia wartości oczekiwanej oraz wyznaczenia scenariuszy wykorzystano skrypt napisany w języku *R*. Wygenerowano 1000 scenariuszy testowtych. Użyty skrypt przedstawia Listing 1. + +Listing 1: Skrypt w języku *R* do obliczania wartości oczekiwanej wektora *R* i generowania scenariuszy z rozkładu t-Studenta. + +``` +1 library ( tmvtnorm ) +2 +3 # t- Stutdet parameters +4 Mu = c(9 , 8 , 7 , 6) +5 Sigma = matrix (c(16 , -2 , -1 , -3 , +6 -2 , 9 , -4 , -1 , +7 -1 , -4 , 4 , 1 , +8 -3 , -1 , 1 , 1) , +9 nrow =4 , ncol =4) +10 lower _ bound = 5 +11 upper _ bound = 12 +12 +13 # Generate scenarios +14 data <- rtmvt ( n =10000 , mean = mu , sigma = sigma , df =5 , lower =rep ( lower _←- + bound , 4) , upper =rep ( upper _bound , 4) ) +15 write . table ( format (data , digits =15 , drop0trailing = F ) , " data10000 .txt"←- + , quote =F , sep ="\t", eol ="\n\t", col . names = F , row . names = T ) +16 mean <- colMeans ( data ) +17 +18 E <- function ( idx , Mu , Sigma , v , alfa , beta ) { +19 mu = Mu [ idx ] +20 sigma = Sigma [ idx , idx ] +21 a = ( alfa - mu )/ sigma +22 b = ( beta - mu )/ sigma +23 nom = gamma (( v -1)/2) * +24 (( v + a ^2) ^( -1*(v -1) /2) - +25 ( v + b ^2) ^( -1*(v -1)/2) ) * +26 v ^( v/2) +27 den = 2 * (pt(b , v ) - pt(a , v ) ) * gamma ( v/2) * gamma (1/2) +28 return ( mu + sigma *( nom /den ) ) +29 } +30 +31 ER1 <- E (1 , Mu , Sigma , 5 , 5 , 12) +32 ER2 <- E (2 , Mu , Sigma , 5 , 5 , 12) +33 ER3 <- E (3 , Mu , Sigma , 5 , 5 , 12) +34 ER4 <- E (4 , Mu , Sigma , 5 , 5 , 12) +``` + + +``` +45 +46 # Aktualny stan magazynowy [szt] +47 param startingStorage { PRODUCTS } >= 0; +48 +49 # Pozadany stan magazynowy na koniec symulacji [szt] +50 param desiredEndStorage { PRODUCTS } >= 0; +51 +52 # Liczba dni roboczych w miesiacu [d] +53 param daysPerMonth >= 1; +54 +55 # Liczba zmian w ciagu jednego dnia roboczego +56 param shiftsPerDay >= 1; +57 +58 # Dlugosc zmiany [ godz ] +59 param hoursPerShift >= 1; +60 +61 # Liczba roboczogodzin w miesiacu [ godz ] +62 param workHoursPerMonth = daysPerMonth * shiftsPerDay * hoursPerShift ; +63 +64 # Czas pracy narzedzi w danym miesiacu +65 param availableToolTime { t in TOOLS } = toolCount [ t ]* workHoursPerMonth←- + ; +66 +67 # ########## +68 # Zmienne # +69 # ########## +70 # Produkcja produktow +71 var produced { MONTHS , PRODUCTS } >= 0 integer ; +72 +73 # Sprzedaz produktow w danym miesiacu +74 var sold { MONTHS , PRODUCTS } >= 0 integer ; +75 var totalSold { p in PRODUCTS } = sum { m in MONTHS } sold [m , p ]; +76 +77 # Ilosc produktow przekazanych do magazynu w danym miesiacu +78 var stored { m in MONTHS , p in PRODUCTS } = produced [m , p ] - sold [m , p←- + ]; +79 +80 # Stan magazynowy na koniec danego miesiaca +81 var storage { m in MONTHS , p in PRODUCTS } = +82 startingStorage [ p ] + sum { m2 in MONTHS : ord( m2 ) <= ord( m ) } ←- + stored [ m2 , p ]; +83 +84 # Wykorzystany czas pracy +85 var usedToolTime { m in MONTHS , t in TOOLS } = +86 sum { p in PRODUCTS } produced [m , p ]* toolTimePerUnit [t , p ]; +87 +88 # Koszt magazynowania +89 var monthlyStorageCost { m in MONTHS } = +90 (sum { p in PRODUCTS } storage [m , p ]) * storageUnitCost ; +91 var totalStorageCost = sum { m in MONTHS } monthlyStorageCost [ m ]; +92 +93 # Zysk dla wartosci oczekiwanej +94 var expectedSalesProfit = +95 sum { p in PRODUCTS } totalSold [ p ]* expectedProfitPerUnit [ p ]; +96 var expectedNetProfit = +97 expectedSalesProfit - totalStorageCost ; +``` + + +``` +98 +99 # Zysk w danym scenariuszu +100 var scenarioSalesProfit { s in SCENARIOS } = +101 sum { p in PRODUCTS } totalSold [ p ]* scenarioProfitPerUnit [s , p ]; +102 var scenarioNetProfit { s in SCENARIOS } = +103 scenarioSalesProfit [ s ] - totalStorageCost ; +104 +105 # Odchylenie jako miara ryzyka - zlinearyzowana wartosc bezwzgledna +106 var deviation { s in SCENARIOS } = +107 expectedNetProfit - scenarioNetProfit [ s ]; +108 var P { SCENARIOS } >= 0; +109 var Q { SCENARIOS } >= 0; +110 subject to deviationLimit { s1 in SCENARIOS , s2 in SCENARIOS }: +111 deviation [ s1 ] - deviation [ s2 ]+ P [ s1 ] - Q [ s2 ] = 0; +112 +113 #var maxDeviation = max {s in SCENARIOS } deviation [s]; +114 var maxDeviation ; +115 # Linearyzacja maksymalnego odchylenia jako miary ryzyka +116 param M = 10000; +117 var Z { SCENARIOS } binary ; +118 subject to mdLimit { s in SCENARIOS }: +119 maxDeviation >= deviation [ s ]; +120 subject to mdWhere { s in SCENARIOS }: +121 maxDeviation <= deviation [ s ] + M *(1 - Z [ s ]) ; +122 subject to mdOS : +123 sum { s in SCENARIOS } Z [ s ] = 1; +124 +125 # Aliasy dla ocenianych wartosci +126 var profit = expectedNetProfit ; +127 var risk = maxDeviation ; +128 +129 # ###################### +130 # Ograniczenia modelu # +131 # ###################### +132 +133 # Ograniczenie rynkowe sprzedazy produktow +134 subject to SalesMarketLimit { m in MONTHS , p in PRODUCTS }: +135 sold [m , p ] <= salesMarketLimit [m , p ]; +136 # Ograniczenie magazynowe sprzedazy produktow +137 subject to SalesLimit1 { p in PRODUCTS }: +138 sold [ first ( MONTHS ) , p ] <= produced [ first ( MONTHS ) , p ]; +139 subject to SalesLimit2 { m in MONTHS , p in PRODUCTS : m != first ( MONTHS←- + ) }: +140 sold [m , p ] <= produced [m , p ] + storage [m , p ]; +141 # Powiazanie sprzedazy produktu P4 ze sprzedaza produktow P1 i P2 +142 subject to P4SalesConstraint { m in MONTHS }: +143 sold [m , "P4"] >= sold [m , "P1"] + sold [m , "P2"]; +144 # Ograniczenie pojemnosci magazynowej +145 subject to StorageLimit { m in MONTHS , p in PRODUCTS }: +146 storage [m , p ] <= storageLimit [ p ]; +147 # Ograniczenie na pozadany stan magazynowy na koniec marca +148 subject to DesiredStorage { p in PRODUCTS }: +149 storage [ last ( MONTHS ) , p ] >= desiredEndStorage [ p ]; +150 # Ograniczenie czasu pracy narzedzi w miesiacu +151 subject to ToolWorkTime { m in MONTHS , t in TOOLS }: +152 usedToolTime [m , t ] <= availableToolTime [ t ]; +``` + + +``` +153 +154 # ############################ +155 # Metoda punktu odniesienia # +156 # ############################ +157 # Skladniki wektora oceny +158 set RATED = {" PROFIT ", " RISK "}; +159 # Wektor oceny +160 var value { r in RATED } = +161 if r == " PROFIT " then profit +162 else if r == " RISK " then risk ; +163 # Wektor aspiracji +164 param aspiration { RATED }; +165 # Wartosci utopii i nadiru +166 param utopia { RATED }; +167 param nadir { RATED }; +168 # Wspolczynniki normalizujace +169 param lambda { r in RATED } = +170 1 / ( utopia [r] - nadir [r]); +171 # Wspolczynnik skladnika regularyzacyjnego +172 param epsilon ; +173 # Wspolczynnik pomniejszenia wartosci ocen ponad poziomem aspiracji +174 param beta ; +175 # Indywidualne funkcje osiagniec +176 var individualRating { RATED }; +177 # Zmienna pomocnicza metody punktu odniesienia +178 var v; +179 # Skalaryzujaca funkcja osiagniecia +180 var rating = v + epsilon * (sum {r in RATED } individualRating [r]); +181 # Odleglosc od punktu odniesienia +182 var distance {r in RATED } = value [r] - aspiration [r]; +183 # Znormalizowana odleglosc od punktu odniesienia +184 var normalizedDistance {r in RATED } = lambda [r]* distance [r]; +185 # Ograniczenia zmiennej v przez indywidualne funkcje osiagniec +186 subject to VSubject {r in RATED }: +187 v <= individualRating [r]; +188 # Ograniczenia indywidualnych funkcji osiagniec +189 subject to IndividualRatingSubjectBeta {r in RATED }: +190 individualRating [r] <= beta * normalizedDistance [r]; +191 subject to IndividualRatingSubject {r in RATED }: +192 individualRating [r] <= normalizedDistance [r]; +193 +194 ################ +195 # Funkcje celu # +196 ################ +197 minimize MinimizeProfit : profit ; +198 maximize MaximizeProfit : profit ; +199 minimize MinimizeRisk : risk ; +200 maximize MaximizeRisk : risk ; +201 maximize RPM: rating ; +``` diff --git a/Programming/WDWR/projekt/doc/DOCS-05-pliki-ampl.md b/Programming/WDWR/projekt/doc/DOCS-05-pliki-ampl.md new file mode 100644 index 00000000..c7c849ea --- /dev/null +++ b/Programming/WDWR/projekt/doc/DOCS-05-pliki-ampl.md @@ -0,0 +1,188 @@ +**5.2 Plik z danymi (**.dat**)** + + +``` +załączniku. +1 # ########################################################## +2 # WDWR 25406 # +3 # Planowanie produkcj w warunkach ryzyka. # +4 # DANE # +5 # Autor : Jan Kumor # +6 # ########################################################## +7 +8 # Narzedzia +9 set TOOLS := GRINDER VDRILL HDRILL MILLER LATHE ; +10 +11 # Miesiace +12 set MONTHS := JAN FEB MAR ; +13 +14 # Liczba narzedzi +15 param toolCount := +16 GRINDER 4 +17 VDRILL 2 +18 HDRILL 3 +19 MILLER 1 +20 LATHE 1 +21 ; +22 +23 # Czasy produkcji h +24 param toolTimePerUnit : +25 P1 P2 P3←- + P4 := +26 GRINDER 0 .4 0 .6 0 ←- + 0 +27 VDRILL 0 .2 0 .1 0 ←- + 0 .6 +28 HDRILL 0 .1 0 0 .7 ←- + 0 +29 MILLER 0 .06 0 .04 0 0 .05 +30 LATHE 0 0 .05 0 .02 0 +31 ; +32 +33 # Ograniczenia rynkowe liczby sprzedawanych produktow pcs +34 param salesMarketLimit : +35 P1 P2 P3 ←- + P4 := +36 JAN 200 0 100 ←- + 200 +37 FEB 300 100 200 ←- + 200 +38 MAR 0 300 100 ←- + 200 +39 ; +40 +41 # Ograniczeine liczby magazynowanych produktow pcs +42 param storageLimit := +43 P1 200 +44 P2 200 +45 P3 200 +46 P4 200 +``` +Listing 3: Dane dla modelu AMPL - pominięto scenariusze, pełny zestaw danych dostępny w + + +``` +47 ; +48 +49 # Koszt magazynowania produktow pln/pcs per month +50 param storageUnitCost := 1; +51 +52 # Aktualny stan magazynowy pcs +53 param startingStorage := +54 P1 0 +55 P2 0 +56 P3 0 +57 P4 0 +58 ; +59 +60 # Pozadany stan magazynowy na koniec marca pcs +61 param desiredEndStorage := +62 P1 50 +63 P2 50 +64 P3 50 +65 P4 50 +66 ; +67 +68 # Liczba dni roboczych w miesiacu d +69 param daysPerMonth := 24; +70 +71 # Liczba zmian w ciagu jednego dnia roboczego +72 param shiftsPerDay := 2; +73 +74 # Dlugosc zmiany h +75 param hoursPerShift := 8; +76 +77 # Zyski wartosc oczekiwana +78 param expectedProfitPerUnit := +79 P1 8 .50944172786882 +80 P2 8 .47100593224391 +81 P3 8 .1319049712769 +82 P4 6 .39446520538826 +83 ; +84 +85 # Metoda punktu odniesienia +86 param epsilon = 0 .000025 ; +87 +88 param beta = 0 .001 ; +89 +90 param utopia := +91 PROFIT 11987 +92 RISK 1000 +93 ; +94 +95 param nadir := +96 PROFIT -2400 +97 RISK 2815 +98 ; +99 +100 param aspiration := +101 PROFIT 10000 +102 RISK 0 +``` + + +*smp* oraz wartość wyznaczonego rozwiązania optymalnego: + +*ep* = 11987*.*42[*z*] + +Listing 7: Wynik działania skryptu wyznaczającego rozwiązanie optymalne modelu jednokryterialnego. + +| 1 | | | # ################################################ | | | | | | | | | | | | | +|----|------------------------------------------------------------------------|------------------------------------|----------------------------------------------------|---------|--|---------|--|------------|--|--|-----------|--------------|--|--|--| +| 2 | ###
Maximize
profit
for
expected
profit
value
### | | | | | | | | | | | | | | | +| 3 | # ################################################ | | | | | | | | | | | | | | | +| 4 | CPLEX | | 12 .8.0.0 : | optimal | | integer | | solution ; | | | objective | 11987 .41899 | | | | +| 5 | | 11
MIP
simplex
iterations | | | | | | | | | | | | | | +| 6 | | 0
branch -and - bound
nodes | | | | | | | | | | | | | | +| 7 | | produced | := | | | | | | | | | | | | | +| 8 | JAN | P1 | 200 | | | | | | | | | | | | | +| 9 | JAN | P2 | 0 | | | | | | | | | | | | | +| 10 | JAN | P3 | 100 | | | | | | | | | | | | | +| 11 | JAN | P4 | 200 | | | | | | | | | | | | | +| 12 | FEB | P1 | 200 | | | | | | | | | | | | | +| 13 | FEB | P2 | 0 | | | | | | | | | | | | | +| 14 | FEB | P3 | 200 | | | | | | | | | | | | | +| 15 | FEB | P4 | 200 | | | | | | | | | | | | | +| 16 | MAR | P1 | 50 | | | | | | | | | | | | | +| 17 | MAR | P2 | 250 | | | | | | | | | | | | | +| 18 | MAR | P3 | 150 | | | | | | | | | | | | | +| 19 | MAR | P4 | 250 | | | | | | | | | | | | | +| 20 | ; | | | | | | | | | | | | | | | +| 21 | | | | | | | | | | | | | | | | +| 22 | sold | := | | | | | | | | | | | | | | +| 23 | JAN | P1 | 200 | | | | | | | | | | | | | +| 24 | JAN | P2 | 0 | | | | | | | | | | | | | +| 25 | JAN | P3 | 100 | | | | | | | | | | | | | +| 26 | JAN | P4 | 200 | | | | | | | | | | | | | +| 27 | FEB | P1 | 200 | | | | | | | | | | | | | +| 28 | FEB | P2 | 0 | | | | | | | | | | | | | +| 29 | FEB | P3 | 200 | | | | | | | | | | | | | +| 30 | FEB | P4 | 200 | | | | | | | | | | | | | +| 31 | MAR | P1 | 0 | | | | | | | | | | | | | +| 32 | MAR | P2 | 200 | | | | | | | | | | | | | +| 33 | MAR | P3 | 100 | | | | | | | | | | | | | +| 34 | MAR | P4 | 200 | | | | | | | | | | | | | +| 35 | ; | | | | | | | | | | | | | | | +| 36 | | | | | | | | | | | | | | | | +| 37 | stored | := | | | | | | | | | | | | | | +| 38 | JAN | P1 | 0 | | | | | | | | | | | | | +| 39 | JAN | P2 | 0 | | | | | | | | | | | | | +| 40 | JAN | P3 | 0 | | | | | | | | | | | | | +| 41 | JAN | P4 | 0 | | | | | | | | | | | | | +| 42 | FEB | P1 | 0 | | | | | | | | | | | | | +| 43 | FEB | P2 | 0 | | | | | | | | | | | | | +| 44 | FEB | P3 | 0 | | | | | | | | | | | | | +| 45 | FEB | P4 | 0 | | | | | | | | | | | | | +| 46 | MAR | P1 | 50 | | | | | | | | | | | | | +| 47 | MAR | P2 | 50 | | | | | | | | | | | | | +| 48 | MAR | P3 | 50 | | | | | | | | | | | | | +| 49 | MAR | P4 | 50 | | | | | | | | | | | | | + + +52 Profit: 11987.418989 + + +![](_page_0_Figure_0.jpeg) + +Rysunek 1: Obraz zbioru rozwiązań efektywnych w przestrzeni ryzyko-zysk + diff --git a/Programming/WDWR/projekt/doc/DOCS-06-wyniki.md b/Programming/WDWR/projekt/doc/DOCS-06-wyniki.md new file mode 100644 index 00000000..a9e46cdb --- /dev/null +++ b/Programming/WDWR/projekt/doc/DOCS-06-wyniki.md @@ -0,0 +1,119 @@ +## **6.2 Wyniki dla modelu dwukryterialnego** + +## **6.2.1 Obraz zbioru rozwiązań efektywnych w przestrzeni ryzyko-zysk** + +Obraz zbioru rozwiązań efektywnch w przestrzeni ryzyko-zysk został uzyskany poprzez rozwiązanie zadania metody punktu odniesienia dla różnych wartości aspiracji dla zysku oraz ryzyka. Do wykonania obliczeń posłużono się skryptem przedstawionym na [Listing 7.](#page--1-0) Obliczenia przeprowadzono ustalając poziomy aspiracji w wyznaczonych granicach zmienności zysku i ryzyka (wektory nadiru i utopii wyznaczone w kolejnej sekcji). Dla każdego poziomu aspiracji wykorzystano po 10 równoodległych wartości znajdujących się w przedziałach definiowanych przez wektory nadiru i utopii. + +Ze względu na duży rozmiar zadania, a przez długi czas obliczeń przy 1000 scenariuszach, zdecydowano się ograniczyć ich liczbę do 50. Niestety nie jest to liczba wystarczająca do przeprowadzenia dokładnych obliczeń, jednak uzyskane wyniki powinny być wystarczające do przedstawienia działania metody. + +Fragment wyników działania skryptu obliczeniowego przedstawia [Listing 8.](#page-0-0) Obraz zbioru rozwiązań efektywnych w przestrzeni ryzyko-zysk pokazuje [Rysunek 1.](#page-0-1) + +Listing 8: Skrypt obliczający wartości do wyznaczenia obrazu zbioru rozwiązań efektywnych w przestrzeni ryzyko-zysk. Pełne wyniki dostępne w załączniku. + +``` +1 ### 39: Solving model for aspirations : 2395 .666667 , 312 .777778 +2 CPLEX 12 .8.0.0 : optimal integer solution within mipgap or absmipgap ; ←- + objective 5 .427722957e -07 +3 39 MIP simplex iterations +4 0 branch -and - bound nodes +5 absmipgap = 7 .81092e -07 , relmipgap = 1 .43881 +``` + + +``` +6 Profit : 2417 .827519 +7 Risk : 311 .250020 +8 RPM : 0 .000001 +9 ### 40: Solving model for aspirations : 2395 .666667 , 0 .000000 +10 CPLEX 12 .8.0.0 : +11 < BREAK > ( cplex ) +12 CPLEX solution status 13 with fixed integers : +13 aborted in phase II +14 aborted , integer solution exists ; objective -0 .06697476417 +15 116486 MIP simplex iterations +16 103313 branch -and - bound nodes +17 absmipgap = 6 .93933e -05 , relmipgap = 0 .00103611 +18 Profit : 1432 .148909 +19 Risk : 188 .510726 +20 RPM : -0 .066975 +``` +Rozwiązania efektywne minimalnego ryzyka i maksymalnego zysku + +Rozwiązania efektywne dla minimalnego ryzyka i maksymalnego zysku wyznaczono wykorzystując skrypt przedstawiony na listingu [Listing 4.](#page--1-0) Na podstwaie wyników jego działania, które przedstawia [Listing 9](#page-0-0) można podać następujące rozwiązania: + +- Minimalne ryzyko: *ep* = *−*1000, przy *r* = 0, +- Maksymalny zysk: *ep* = 11987, przy *r* = 2569 + +Dodatkowo poza zakresem zadania wyznaczonon pozostałe elementy potrzebne do wyznaczenia wektorów nadiru i utopii: + +- Maksymalne ryzyko: *ep* = 9193, przy *r* = 2815, +- Minimalny zysk: *ep* = *−*2400*.*00, przy *r* = 0*.*00 + +``` +Wektor nadiru: (−2400, 2815) +``` +Wektor utopii: (0*,* 11987) + +Listing 9: Skrypt wyznaczający rozwiązania optymalne modelu dwukryterialnego. + +``` +1 # ######################## +2 ### Minimizing profit ### +3 # ######################## +4 CPLEX 12 .8.0.0 : optimal integer solution ; objective -2400 +5 7 MIP simplex iterations +6 0 branch -and - bound nodes +7 Profit : -2400 +8 Risk : 0 +9 +10 # ######################## +11 ### Maximizing profit ### +12 # ######################## +13 CPLEX 12 .8.0.0 : optimal integer solution ; objective 11987 .41899 +14 32 MIP simplex iterations +15 0 branch -and - bound nodes +16 Profit : 11987 +17 Risk : 2569 +18 +``` + + +``` +19 # ###################### +20 ### Minimizing risk ### +21 # ###################### +22 CPLEX 12 .8.0.0 : optimal integer solution ; objective 0 +23 0 MIP simplex iterations +24 0 branch -and - bound nodes +25 Profit : -1000 +26 Risk : 0 +27 +28 # ####################### +29 ### Maximizing risk k### +30 # ####################### +31 CPLEX 12 .8.0.0 : optimal integer solution ; objective 2815 .995263 +32 21837 MIP simplex iterations +33 705 branch -and - bound nodes +34 Profit : 9193 +35 Risk : 2815 +``` +## **6.2.2 Analiza relacji dominacji stochastycznej dla trzech wybranych rozwiązań efektywnych** + +Do analizy wybrano następujące scenariusze: + +- 1. Maksymalny zysk *ep* = 11987*.*42, +- 2. Poziomy aspiracji *aspep* = 8789*.*89 oraz *aspr* = 1876*.*67, +- 3. Poziomy aspiracji *aspep* = 10388*.*44 oraz *aspr* = 938*.*33. + +Dane do analizy zostały wygenerowane w trakcie przeprowadzania obliczeń do poprzednich podpunktów i są dostępne w załącznikach. + +Dystrybuanty zysku przedstawia [Rysunek 2.](#page--1-0) + +Na podstawie wykresów możemy stwierdzić, że rozwiązanie dla scenariusza z maksymalnym zyskiem dominuje w sensie FSD pozostałe rozwiązania. Dodatkowo widzimy, że rozwiązanie ze scenariusza 3 dominuje w sensie FSD rozwiązanie scenariusza 2. + + +![](_page_0_Figure_0.jpeg) + +Rysunek 2: Wykres dystrybuant zysku dla poszczególnych rozwiązań + + diff --git a/Programming/WDWR/projekt/doc/DOCS-combined-document.md b/Programming/WDWR/projekt/doc/DOCS-combined-document.md new file mode 100644 index 00000000..4c9c2281 --- /dev/null +++ b/Programming/WDWR/projekt/doc/DOCS-combined-document.md @@ -0,0 +1,30 @@ +## **Politechnika Warszawska Instytut Automatyki i Informatyki Stosowanej** + +**Sprawozdanie z projektu na przedmiot Wspomaganie Decyzji w Warunkach Ryzyka** + +Krzysztof Rudnicki 307585 + + +## **Spis treści** + +| 1 | Treść zadania | 2 | +|---|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------| +| 2 | Jednokryterialny model wyboru w warunkach ryzyka z wartością oczekiwaną jako miarą
zysku
2.1
Zbiory indeksowe
.
2.2
Parametry
2.3
Zmienne
2.4
Ograniczenia
.
2.5
Funkcja celu | 3
3
3
4
4
4 | +| 3 | Dwukryterialny model zysku i ryzyka z wartoscią oczekiwaną jako miarą zysku i od
chyleniem maksymalnym jako miarą ryzyka
3.1
Zbiory indeksowe
.
3.2
Parametry
3.3
Zmienne
3.4
Ograniczenia
.
3.5
Metoda punktu odniesienia
. | 5
5
5
5
5
6 | +| 4 | Wyznaczenie parametrów zadania z rozkładu t-Studenta | 6 | +| 5 | Model dla programu AMPL
5.1
Plik z modelem (.mod)
5.2
Plik z danymi (.dat)
5.3
Skrypty uruchomieniowe (.run) | 8
8
11
14 | +| 6 | Rozwiązanie zadania optymalizacji
6.1
Wyniki dla modelu jednokryterialnego
.
6.2
Wyniki dla modelu dwukryterialnego
6.2.1
Obraz zbioru rozwiązań efektywnych w przestrzeni ryzyko-zysk
.
6.2.2
Analiza relacji dominacji stochastycznej dla trzech wybranych rozwiązań efek
tywnych | 16
16
19
19
21 | + + + +--- + +Ten raport został podzielony na sekcje, aby każdy plik mieścił się w limicie +250 wierszy obowiązującym w tym repozytorium. Treść jest niezmieniona. + +- [1. Treść zadania](DOCS-01-tresc-zadania.md) +- [2. Jednokryterialny model wyboru](DOCS-02-model-jednokryterialny.md) +- [3. Dwukryterialny model zysku i ryzyka](DOCS-03-model-dwukryterialny.md) +- [4. Wyznaczenie parametrów z rozkładu t-Studenta](DOCS-04-parametry-t-studenta.md) +- [5. Pliki modelu i danych (AMPL)](DOCS-05-pliki-ampl.md) +- [6. Wyniki](DOCS-06-wyniki.md) diff --git a/Programming/WDWR/projekt/doc/combined_document.md b/Programming/WDWR/projekt/doc/combined_document.md deleted file mode 100644 index 533fa94f..00000000 --- a/Programming/WDWR/projekt/doc/combined_document.md +++ /dev/null @@ -1,771 +0,0 @@ -## **Politechnika Warszawska Instytut Automatyki i Informatyki Stosowanej** - -**Sprawozdanie z projektu na przedmiot Wspomaganie Decyzji w Warunkach Ryzyka** - -Krzysztof Rudnicki 307585 - - -## **Spis treści** - -| 1 | Treść zadania | 2 | -|---|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------| -| 2 | Jednokryterialny model wyboru w warunkach ryzyka z wartością oczekiwaną jako miarą
zysku
2.1
Zbiory indeksowe
.
2.2
Parametry
2.3
Zmienne
2.4
Ograniczenia
.
2.5
Funkcja celu | 3
3
3
4
4
4 | -| 3 | Dwukryterialny model zysku i ryzyka z wartoscią oczekiwaną jako miarą zysku i od
chyleniem maksymalnym jako miarą ryzyka
3.1
Zbiory indeksowe
.
3.2
Parametry
3.3
Zmienne
3.4
Ograniczenia
.
3.5
Metoda punktu odniesienia
. | 5
5
5
5
5
6 | -| 4 | Wyznaczenie parametrów zadania z rozkładu t-Studenta | 6 | -| 5 | Model dla programu AMPL
5.1
Plik z modelem (.mod)
5.2
Plik z danymi (.dat)
5.3
Skrypty uruchomieniowe (.run) | 8
8
11
14 | -| 6 | Rozwiązanie zadania optymalizacji
6.1
Wyniki dla modelu jednokryterialnego
.
6.2
Wyniki dla modelu dwukryterialnego
6.2.1
Obraz zbioru rozwiązań efektywnych w przestrzeni ryzyko-zysk
.
6.2.2
Analiza relacji dominacji stochastycznej dla trzech wybranych rozwiązań efek
tywnych | 16
16
19
19
21 | - - -## **WDWR 18402** - -Rozważamy następujące zagadnienie planowania produkcji: - -• Przedsiębiorstwo wytwarza 4 produkty P1,. . . ,P4 na następujących maszynach: 4 szlifierkach, 2 wiertarkach pionowych, 3 wiertarkach poziomych, 1 frezarce i 1 tokarce. Wymagane czasy produkcji 1 sztuki produktu (w godzinach) w danym procesie obróbki zostały przedstawione w poniższej tabeli: - -| | P1 | P2 | P3 | P4 | -|-------------------|------|------|------|------| -| Szlifowanie | 0,4 | 0,6 | — | — | -| Wiercenie pionowe | 0,2 | 0,1 | — | 0,6 | -| Wiercenie poziome | 0,1 | — | 0,7 | — | -| Frezowanie | 0,06 | 0,04 | — | 0,05 | -| Toczenie | — | 0,05 | 0,02 | — | - -• Dochody ze sprzedaży produktów (w zł/sztukę) określają składowe wektora losowego **R** = (*R*1*, . . . , R*4) *T* . Wektor losowy **R** opisuje 4-wymiarowy rozkład *t*-Studenta z 5 stopniami swobody, którego wartości składowych zostały zawężone do przedziału [5; 12]. Parametry *µ* oraz **Σ** niezawężonego rozkładu *t*-Studenta są następujące: - -$$ -\mu = \begin{pmatrix} 9 \\ 8 \\ 7 \\ 6 \end{pmatrix}, \qquad \Sigma = \begin{pmatrix} 16 & -2 & -1 & -3 \\ -2 & 9 & -4 & -1 \\ -1 & -4 & 4 & 1 \\ -3 & -1 & 1 & 1 \end{pmatrix}. -$$ - -• Istnieją ograniczenia rynkowe na liczbę sprzedawanych produktów w danym miesiącu: - -| | P1 | P2 | P3 | P4 | -|---------|-----|-----|-----|-----| -| Styczeń | 200 | 0 | 100 | 200 | -| Luty | 300 | 100 | 200 | 200 | -| Marzec | 0 | 300 | 100 | 200 | - -- Jeżeli w danym miesiącu jest sprzedawany produkt P1 lub P2, to musi być również sprzedawany produkt P4 w ilości nie mniejszej niż suma sprzedawanych produktów P1 i P2. -- Istnieje możliwość składowania do 200 sztuk każdego produktu w danym czasie w cenie 1 zł/sztukę za miesiąc. Aktualnie firma nie posiada żadnych zapasów, ale jest pożądane mieć po 50 sztuk każdego produktu pod koniec marca. -- Przedsiębiorstwo pracuje 6 dni w tygodniu w systemie dwóch zmian. Każda zmiana trwa 8 godzin. Można założyć, że każdy miesiąc składa się z 24 dni roboczych. -- 1. Zaproponować jednokryterialny model wyboru w warunkach ryzyka z wartością oczekiwaną jako miarą zysku. Wyznaczyć rozwiązanie optymalne. -- 2. Jako rozszerzenie powyższego zaproponować dwukryterialny model zysku i ryzyka z wartością oczekiwaną jako miarą zysku i odchyleniem maksymalnym jako miarą ryzyka. Dla decyzji **x** *∈ Q* odchylenie maksymalne jest definiowane jako *D*(**x**) = max*t*=1*,...,T |µ*(**x**) *− rt*(**x**)*|*, gdzie *µ*(**x**) oznacza wartość oczekiwaną, *rt*(**x**) realizację dla scenariusza *t*. - - a. Wyznaczyć obraz zbioru rozwiązań efektywnych w przestrzeni ryzyko–zysk. - - b. Wskazać rozwiązania efektywne minimalnego ryzyka i maksymalnego zysku. Jakie odpowiadają im wartości w przestrzeni ryzyko–zysk? - - c. Wybrać trzy dowolne rozwiązania efektywne. Sprawdzić czy zachodzi pomiędzy nimi relacja dominacji stochastycznej pierwszego rzędu. Wyniki skomentować, odnieść do ogólnego przypadku. - - -## **2 Jednokryterialny model wyboru w warunkach ryzyka z wartością oczekiwaną jako miarą zysku** - -W celu rozwiązania postawionego zadania dokonano sformułowania modelu programowania liniowego całkowitoliczbowego. Poniżej przedstawiono zapis matematyczny modelu. - -## **2.1 Zbiory indeksowe** - -| Zbiór | Opis | -|-------------------|------------------------------------------------------| -| P =
P1, , P4 | Zbiór wytwarzanych produktów | -| T =
T1, , T5 | Zbiór typów narzędzi wykorzystywanych przy produkcji | -| M =
M1, M2, M3 | Zbiór kolejnych miesięcy produkcji | - -## **2.2 Parametry** - -| Parametr | Opis | -|----------------------------|-----------------------------------------------------------------------| -| tct | Liczba narzędzi typu t [szt] | -| eppup | Oczekiwany zysk ze sprzedaży jednej sztuki produktu
p [zł] | -| ttputp | Czas wykorzystania maszyny typu
t przy produkcji jednej sztuki pro | -| | duktu
p [godz] | -| smlmp | Limit sprzedaży produktu
p w miesiącu
m [szt] | -| stlp | Limit pojemności magazynu na produkt
p [szt] | -| stcpu | Koszt magazynowania jednej sztuki dowolnego produktu [zł] | -| st0p | Początkowy stan magazynowy produktu
p [szt] | -| dstp | Porządany końcowy stan magazynowy produktu
p [szt] | -| dpm | Liczba dni roboczych w każdym miesiącu [d] | -| spd | Liczba zmian w każdym dniu roboczym [j] | -| whps | Liczba godzin roboczych w ciągu każdej zmiany [godz] | -| whpm =
dpm · spd · hps | Liczba godzin roboczych w ciągu każdego miesiąca [godz] | -| =
attt
tct
∗ whpm | Dostępna liczba godzin roboczych maszyn typu
t w ciągu każdego | -| | miesiąca [godz] | - - -## **2.3 Zmienne** - -| Zmienna | Opis | -|----------------------------------------------------|--------------------------------------------------------------------| -| pmp | Liczba sztuk produktu
p wyprodukowanych w miesiącu
m [szt] | -| smp | Liczba sztuk produktu
p sprzedanych w miesiącu
m [szt] | -| X
=
tsp
smp | Całkowita liczba sprzedanych sztuk produktu
p | -| m∈M | | -| =
stdmp
pmp
− smp | Liczba sztuk produktu
p zmagazynowanych w miesiącu
m [szt] | -| Xm
=
st0p
+
stgmp
stdm2p
m2=1 | Stan magazynowy produktu
p na koniec miesiąca
m [szt] | -| X
uttmt
=
pmp
∗ ttputp
p∈P | Wykorzystanie czasu pracy maszyny typu
t w miesiącu
m [godz] | -| X
X
tstc =
stcpu ·
stgmp
m∈M
p∈P | Całkowity koszt wykorzystania magazynów [zł] | -| ep = (X
tsp
· eppup)
− tstc | Wartość zysku całkowitego dla wartości oczekiwanych zysku ze | -| p∈P | sprzedaży produktów [zł] | - -## **2.4 Ograniczenia** - -Ograniczenie rynkowe sprzedawanych produktów: - -*smp* 6 *smlmp, ∀m ∈ M, ∀p ∈ P* - -Ograniczenie sprzedaży produktów w pierszym miesiącu: - -$$s\_{1p} \leqslant p\_{1p}, \quad \forall p \in P$$ - -Ograniczenie sprzedaży produktów w kolejnych miesiącach: - -$$s\_{mp} \leqslant p\_{mp} + stg\_{mp}, \quad \forall m \in M \backslash \{1\}$$ - -Ograniczenie na powiązanie sprzedaży produktu 4 ze sprzedażą produktów 1 i 2: - -*sm*4 &gt; *sm*1 + *sm*2*, ∀m ∈ M* - -Ograniczenie pojemności magazynów: - -$$stg\_{mp} \leqslant stl\_p, \quad \forall p \in P$$ - -Ograniczenie na pożądany stan magazynowy na koniec miesiąca 3: - -$$stg\_{3p} \geqslant dst\_p, \quad \forall p \in P$$ - -Ograniczenie wykorzystania czasu pracy narzędzi w danym miesiącu: - -*uttmt* 6 *attt , ∀t ∈ T, ∀m ∈ M* - -## **2.5 Funkcja celu** - -Jako funkcję celu przyjęto maksymalizację wartości oczekiwanej zysku: *maximize ep* - - -# **3 Dwukryterialny model zysku i ryzyka z wartoscią oczekiwaną jako miarą zysku i odchyleniem maksymalnym jako miarą ryzyka** - -Model ten został zrealizowany jako rozszerzenie modelu jednokryterialnego o dodatkowe zbiory, parametry, zmienne, ograniczenia i nową funkcję celu. - -#### **3.1 Zbiory indeksowe** - -| Zbiór | Opis | -|--------------------|--------------------------------------------------------| -| S =
S1, , S1000 | Zbiór scenariuszy wygenerowanych z rozkładu t-Studenta | - -### **3.2 Parametry** - -| Parametr | Opis | -|----------|-----------------------------------------------------------------------| -| sppups | Zysk ze sprzedaży jednej sztuki produktu
p w scenariuszu
s [zł] | - -### **3.3 Zmienne** - -| Zmienna | Opis | -|-------------------------------------------|------------------------------------------------------------------------| -| = (X
· sppups)
sps
tsp
− tstc | Wartość zysku całkowitego dla scenariusza
s zysku ze sprzedaży | -| p∈P | produktów [zł] | -| devs
=
ep − sps | Odchylenie zysku w danym scenariuszu [zł]. Jako, że funkcja | -| | wartości bezwzględnej jest nieliniowa zmienna została poddana | -| | linearyzacji z użyciem zmiennych
ldevs,
Ps,
Qs | -| =
ldevs
ep − sps | Zmienna pomocnicza wykorzystana w linearyzacji odchylenia | -| | zysku w scenariuszu
s | -| Ps | Zmienna pomocnicza wykorzystana w linearyzacji zmiennejk | -| | devs | -| Qs | Zmienna pomocnicza wykorzystana w linearyzacji zmiennej
devs | -| mdev = maxs∈S
devs | Maksymalne odchylenie zysu [zł]. Jako, że funkcja max jest nie | -| | liniowa, zmienna została poddana linearyzacji z użyciem zmien | -| | nych
M,
Zs | -| M | Zmienna
pomocnicza
wykorzystana
w
linearyzacji
zmiennej | -| | mdev | -| Zs | Zmienna
pomocnicza
binarna
wykorzystana
w
linearyzacji | -| | zmiennej
mdev | -| r =
mdev | Miara ryzyka, równa maksymalnemu odchyleniu zysku | - -## **3.4 Ograniczenia** - -Ograniczenie związane z linearyzacją zmiennej *devs*: - -$$lde v\_{s1} - lde v\_{s2} + P\_{s1} - Q\_{s2} = 0, \quad \forall s\_1, s\_2 \in S$$ - -Ograniczenie związane z linearyzację zmiennej *mdev*: - - -$$mdev \geqslant dev\_s, \quad \forall s \in S$$ - -$$mdev \leqslant dev\_s + M(1 - Z\_s), \quad \forall s \in S$$ - -$$\sum\_{s \in S} Z\_s = 1$$ - -## **3.5 Metoda punktu odniesienia** - -Jako model preferencji dla modelu dwukryterialnego została wybrana metoda punktu odniesienia. Wprowadza ona zestaw dodatkowych parametrów i zmiennych: - -| Parametr | Opis | -|-----------|---------------------------------------------------------------------------------| -| aspep | Poziom aspiracji oczekiwanego zysku | -| aspr | Poziom aspiracji ryzyka | -| λep, λr | Współczynniki normalizujące, odpowiednio dla zysku i ryzyka. Ze względu na ogól | -| | ne sformułowanie metody punktu odniesienia jako problemu maksymalizacji,
λep | -| | przyjmie wartość dodatnią, a
ujemną.
λr | -| β | Współczynnik pomniejszający wartość ocen wykraczających powyżej poziomu aspi | -| | racji | -| ε | Współczynnik składnika regularyzacyjnego | -| Zmienne | Opis | -| ocep, ocr | Wartości indywidualnych funkcji osiągnięć dla zysku i ryzyka | -| v | Zmienna pomocnicza metody punktu odniesienia | - -Ograniczenia zmiennej *v* przez wartości indywidualnych funkcji osiągnięć: - -*v* 6 *ocep* oraz *v* 6 *ocr* - -Ograniczenia indywidualnych funkcji osiągnięć: - -$$oc\_r \leqslant \lambda\_r (r - asp\_r)$$ - -$$oc\_r \leqslant \beta \lambda\_r (r - asp\_r)$$ - -$$oc\_{ep} \leqslant \lambda\_p (ep - asp\_{ep})$$ - -$$oc\_{ep} \leqslant \beta \lambda\_p (ep - asp\_{ep})$$ - -Funkcja celu metody punktu odniesienia w postaci dla programowania liniowego: - -$$\max \quad v + \varepsilon (oc\_{ep} + oc\_r)$$ - -## **4 Wyznaczenie parametrów zadania z rozkładu t-Studenta** - -W celu wyznaczenia wartości oczekiwanej wektora *R* (odpowiadającą parametrowi modelu *eppup*) wykorzystano następującą zależność: - -$$E(R) = \mu + \sigma \cdot \frac{\Gamma(\frac{\nu - 1}{2})((\nu + a^2)^{-\frac{\nu - 1}{2}} - (\nu + b^2)^{\frac{\nu - 1}{2}})\nu^{\frac{\nu}{2}}}{2(F\_{\nu}(b) - F\_{\nu}(a))\Gamma(\frac{\nu}{2})\Gamma(\frac{1}{2})}$$ - -gdzie: - - -- *µ* wartość oczekiwana dla *R*, -- Γ funkcja gamma Eulera, -- *ν* liczba stopni swobody, -- *F* dystrybuanta standardowego rozkładu t-Studenta *t*(0*,* 1; *ν*) z *ν* stopniami swobody, -- *a* = *α−µ σ* , gdzie *α* to lewy kraniec przedziału, -- *b* = *β−µ σ* , gdzie *β*to prawy kraniec przedziału. - -Otrzymano wartości: - -*E*(*R*) *T* = [8*.*5094*,* 8*.*4710*,* 8*.*1319*,* 6*.*3944] - -Do obliczenia wartości oczekiwanej oraz wyznaczenia scenariuszy wykorzystano skrypt napisany w języku *R*. Wygenerowano 1000 scenariuszy testowtych. Użyty skrypt przedstawia Listing 1. - -Listing 1: Skrypt w języku *R* do obliczania wartości oczekiwanej wektora *R* i generowania scenariuszy z rozkładu t-Studenta. - -``` -1 library ( tmvtnorm ) -2 -3 # t- Stutdet parameters -4 Mu = c(9 , 8 , 7 , 6) -5 Sigma = matrix (c(16 , -2 , -1 , -3 , -6 -2 , 9 , -4 , -1 , -7 -1 , -4 , 4 , 1 , -8 -3 , -1 , 1 , 1) , -9 nrow =4 , ncol =4) -10 lower _ bound = 5 -11 upper _ bound = 12 -12 -13 # Generate scenarios -14 data <- rtmvt ( n =10000 , mean = mu , sigma = sigma , df =5 , lower =rep ( lower _←- - bound , 4) , upper =rep ( upper _bound , 4) ) -15 write . table ( format (data , digits =15 , drop0trailing = F ) , " data10000 .txt"←- - , quote =F , sep ="\t", eol ="\n\t", col . names = F , row . names = T ) -16 mean <- colMeans ( data ) -17 -18 E <- function ( idx , Mu , Sigma , v , alfa , beta ) { -19 mu = Mu [ idx ] -20 sigma = Sigma [ idx , idx ] -21 a = ( alfa - mu )/ sigma -22 b = ( beta - mu )/ sigma -23 nom = gamma (( v -1)/2) * -24 (( v + a ^2) ^( -1*(v -1) /2) - -25 ( v + b ^2) ^( -1*(v -1)/2) ) * -26 v ^( v/2) -27 den = 2 * (pt(b , v ) - pt(a , v ) ) * gamma ( v/2) * gamma (1/2) -28 return ( mu + sigma *( nom /den ) ) -29 } -30 -31 ER1 <- E (1 , Mu , Sigma , 5 , 5 , 12) -32 ER2 <- E (2 , Mu , Sigma , 5 , 5 , 12) -33 ER3 <- E (3 , Mu , Sigma , 5 , 5 , 12) -34 ER4 <- E (4 , Mu , Sigma , 5 , 5 , 12) -``` - - -``` -45 -46 # Aktualny stan magazynowy [szt] -47 param startingStorage { PRODUCTS } >= 0; -48 -49 # Pozadany stan magazynowy na koniec symulacji [szt] -50 param desiredEndStorage { PRODUCTS } >= 0; -51 -52 # Liczba dni roboczych w miesiacu [d] -53 param daysPerMonth >= 1; -54 -55 # Liczba zmian w ciagu jednego dnia roboczego -56 param shiftsPerDay >= 1; -57 -58 # Dlugosc zmiany [ godz ] -59 param hoursPerShift >= 1; -60 -61 # Liczba roboczogodzin w miesiacu [ godz ] -62 param workHoursPerMonth = daysPerMonth * shiftsPerDay * hoursPerShift ; -63 -64 # Czas pracy narzedzi w danym miesiacu -65 param availableToolTime { t in TOOLS } = toolCount [ t ]* workHoursPerMonth←- - ; -66 -67 # ########## -68 # Zmienne # -69 # ########## -70 # Produkcja produktow -71 var produced { MONTHS , PRODUCTS } >= 0 integer ; -72 -73 # Sprzedaz produktow w danym miesiacu -74 var sold { MONTHS , PRODUCTS } >= 0 integer ; -75 var totalSold { p in PRODUCTS } = sum { m in MONTHS } sold [m , p ]; -76 -77 # Ilosc produktow przekazanych do magazynu w danym miesiacu -78 var stored { m in MONTHS , p in PRODUCTS } = produced [m , p ] - sold [m , p←- - ]; -79 -80 # Stan magazynowy na koniec danego miesiaca -81 var storage { m in MONTHS , p in PRODUCTS } = -82 startingStorage [ p ] + sum { m2 in MONTHS : ord( m2 ) <= ord( m ) } ←- - stored [ m2 , p ]; -83 -84 # Wykorzystany czas pracy -85 var usedToolTime { m in MONTHS , t in TOOLS } = -86 sum { p in PRODUCTS } produced [m , p ]* toolTimePerUnit [t , p ]; -87 -88 # Koszt magazynowania -89 var monthlyStorageCost { m in MONTHS } = -90 (sum { p in PRODUCTS } storage [m , p ]) * storageUnitCost ; -91 var totalStorageCost = sum { m in MONTHS } monthlyStorageCost [ m ]; -92 -93 # Zysk dla wartosci oczekiwanej -94 var expectedSalesProfit = -95 sum { p in PRODUCTS } totalSold [ p ]* expectedProfitPerUnit [ p ]; -96 var expectedNetProfit = -97 expectedSalesProfit - totalStorageCost ; -``` - - -``` -98 -99 # Zysk w danym scenariuszu -100 var scenarioSalesProfit { s in SCENARIOS } = -101 sum { p in PRODUCTS } totalSold [ p ]* scenarioProfitPerUnit [s , p ]; -102 var scenarioNetProfit { s in SCENARIOS } = -103 scenarioSalesProfit [ s ] - totalStorageCost ; -104 -105 # Odchylenie jako miara ryzyka - zlinearyzowana wartosc bezwzgledna -106 var deviation { s in SCENARIOS } = -107 expectedNetProfit - scenarioNetProfit [ s ]; -108 var P { SCENARIOS } >= 0; -109 var Q { SCENARIOS } >= 0; -110 subject to deviationLimit { s1 in SCENARIOS , s2 in SCENARIOS }: -111 deviation [ s1 ] - deviation [ s2 ]+ P [ s1 ] - Q [ s2 ] = 0; -112 -113 #var maxDeviation = max {s in SCENARIOS } deviation [s]; -114 var maxDeviation ; -115 # Linearyzacja maksymalnego odchylenia jako miary ryzyka -116 param M = 10000; -117 var Z { SCENARIOS } binary ; -118 subject to mdLimit { s in SCENARIOS }: -119 maxDeviation >= deviation [ s ]; -120 subject to mdWhere { s in SCENARIOS }: -121 maxDeviation <= deviation [ s ] + M *(1 - Z [ s ]) ; -122 subject to mdOS : -123 sum { s in SCENARIOS } Z [ s ] = 1; -124 -125 # Aliasy dla ocenianych wartosci -126 var profit = expectedNetProfit ; -127 var risk = maxDeviation ; -128 -129 # ###################### -130 # Ograniczenia modelu # -131 # ###################### -132 -133 # Ograniczenie rynkowe sprzedazy produktow -134 subject to SalesMarketLimit { m in MONTHS , p in PRODUCTS }: -135 sold [m , p ] <= salesMarketLimit [m , p ]; -136 # Ograniczenie magazynowe sprzedazy produktow -137 subject to SalesLimit1 { p in PRODUCTS }: -138 sold [ first ( MONTHS ) , p ] <= produced [ first ( MONTHS ) , p ]; -139 subject to SalesLimit2 { m in MONTHS , p in PRODUCTS : m != first ( MONTHS←- - ) }: -140 sold [m , p ] <= produced [m , p ] + storage [m , p ]; -141 # Powiazanie sprzedazy produktu P4 ze sprzedaza produktow P1 i P2 -142 subject to P4SalesConstraint { m in MONTHS }: -143 sold [m , "P4"] >= sold [m , "P1"] + sold [m , "P2"]; -144 # Ograniczenie pojemnosci magazynowej -145 subject to StorageLimit { m in MONTHS , p in PRODUCTS }: -146 storage [m , p ] <= storageLimit [ p ]; -147 # Ograniczenie na pozadany stan magazynowy na koniec marca -148 subject to DesiredStorage { p in PRODUCTS }: -149 storage [ last ( MONTHS ) , p ] >= desiredEndStorage [ p ]; -150 # Ograniczenie czasu pracy narzedzi w miesiacu -151 subject to ToolWorkTime { m in MONTHS , t in TOOLS }: -152 usedToolTime [m , t ] <= availableToolTime [ t ]; -``` - - -``` -153 -154 # ############################ -155 # Metoda punktu odniesienia # -156 # ############################ -157 # Skladniki wektora oceny -158 set RATED = {" PROFIT ", " RISK "}; -159 # Wektor oceny -160 var value { r in RATED } = -161 if r == " PROFIT " then profit -162 else if r == " RISK " then risk ; -163 # Wektor aspiracji -164 param aspiration { RATED }; -165 # Wartosci utopii i nadiru -166 param utopia { RATED }; -167 param nadir { RATED }; -168 # Wspolczynniki normalizujace -169 param lambda { r in RATED } = -170 1 / ( utopia [r] - nadir [r]); -171 # Wspolczynnik skladnika regularyzacyjnego -172 param epsilon ; -173 # Wspolczynnik pomniejszenia wartosci ocen ponad poziomem aspiracji -174 param beta ; -175 # Indywidualne funkcje osiagniec -176 var individualRating { RATED }; -177 # Zmienna pomocnicza metody punktu odniesienia -178 var v; -179 # Skalaryzujaca funkcja osiagniecia -180 var rating = v + epsilon * (sum {r in RATED } individualRating [r]); -181 # Odleglosc od punktu odniesienia -182 var distance {r in RATED } = value [r] - aspiration [r]; -183 # Znormalizowana odleglosc od punktu odniesienia -184 var normalizedDistance {r in RATED } = lambda [r]* distance [r]; -185 # Ograniczenia zmiennej v przez indywidualne funkcje osiagniec -186 subject to VSubject {r in RATED }: -187 v <= individualRating [r]; -188 # Ograniczenia indywidualnych funkcji osiagniec -189 subject to IndividualRatingSubjectBeta {r in RATED }: -190 individualRating [r] <= beta * normalizedDistance [r]; -191 subject to IndividualRatingSubject {r in RATED }: -192 individualRating [r] <= normalizedDistance [r]; -193 -194 ################ -195 # Funkcje celu # -196 ################ -197 minimize MinimizeProfit : profit ; -198 maximize MaximizeProfit : profit ; -199 minimize MinimizeRisk : risk ; -200 maximize MaximizeRisk : risk ; -201 maximize RPM: rating ; -``` -**5.2 Plik z danymi (**.dat**)** - - -``` -załączniku. -1 # ########################################################## -2 # WDWR 25406 # -3 # Planowanie produkcj w warunkach ryzyka. # -4 # DANE # -5 # Autor : Jan Kumor # -6 # ########################################################## -7 -8 # Narzedzia -9 set TOOLS := GRINDER VDRILL HDRILL MILLER LATHE ; -10 -11 # Miesiace -12 set MONTHS := JAN FEB MAR ; -13 -14 # Liczba narzedzi -15 param toolCount := -16 GRINDER 4 -17 VDRILL 2 -18 HDRILL 3 -19 MILLER 1 -20 LATHE 1 -21 ; -22 -23 # Czasy produkcji h -24 param toolTimePerUnit : -25 P1 P2 P3←- - P4 := -26 GRINDER 0 .4 0 .6 0 ←- - 0 -27 VDRILL 0 .2 0 .1 0 ←- - 0 .6 -28 HDRILL 0 .1 0 0 .7 ←- - 0 -29 MILLER 0 .06 0 .04 0 0 .05 -30 LATHE 0 0 .05 0 .02 0 -31 ; -32 -33 # Ograniczenia rynkowe liczby sprzedawanych produktow pcs -34 param salesMarketLimit : -35 P1 P2 P3 ←- - P4 := -36 JAN 200 0 100 ←- - 200 -37 FEB 300 100 200 ←- - 200 -38 MAR 0 300 100 ←- - 200 -39 ; -40 -41 # Ograniczeine liczby magazynowanych produktow pcs -42 param storageLimit := -43 P1 200 -44 P2 200 -45 P3 200 -46 P4 200 -``` -Listing 3: Dane dla modelu AMPL - pominięto scenariusze, pełny zestaw danych dostępny w - - -``` -47 ; -48 -49 # Koszt magazynowania produktow pln/pcs per month -50 param storageUnitCost := 1; -51 -52 # Aktualny stan magazynowy pcs -53 param startingStorage := -54 P1 0 -55 P2 0 -56 P3 0 -57 P4 0 -58 ; -59 -60 # Pozadany stan magazynowy na koniec marca pcs -61 param desiredEndStorage := -62 P1 50 -63 P2 50 -64 P3 50 -65 P4 50 -66 ; -67 -68 # Liczba dni roboczych w miesiacu d -69 param daysPerMonth := 24; -70 -71 # Liczba zmian w ciagu jednego dnia roboczego -72 param shiftsPerDay := 2; -73 -74 # Dlugosc zmiany h -75 param hoursPerShift := 8; -76 -77 # Zyski wartosc oczekiwana -78 param expectedProfitPerUnit := -79 P1 8 .50944172786882 -80 P2 8 .47100593224391 -81 P3 8 .1319049712769 -82 P4 6 .39446520538826 -83 ; -84 -85 # Metoda punktu odniesienia -86 param epsilon = 0 .000025 ; -87 -88 param beta = 0 .001 ; -89 -90 param utopia := -91 PROFIT 11987 -92 RISK 1000 -93 ; -94 -95 param nadir := -96 PROFIT -2400 -97 RISK 2815 -98 ; -99 -100 param aspiration := -101 PROFIT 10000 -102 RISK 0 -``` - - -*smp* oraz wartość wyznaczonego rozwiązania optymalnego: - -*ep* = 11987*.*42[*z*] - -Listing 7: Wynik działania skryptu wyznaczającego rozwiązanie optymalne modelu jednokryterialnego. - -| 1 | | | # ################################################ | | | | | | | | | | | | | -|----|------------------------------------------------------------------------|------------------------------------|----------------------------------------------------|---------|--|---------|--|------------|--|--|-----------|--------------|--|--|--| -| 2 | ###
Maximize
profit
for
expected
profit
value
### | | | | | | | | | | | | | | | -| 3 | # ################################################ | | | | | | | | | | | | | | | -| 4 | CPLEX | | 12 .8.0.0 : | optimal | | integer | | solution ; | | | objective | 11987 .41899 | | | | -| 5 | | 11
MIP
simplex
iterations | | | | | | | | | | | | | | -| 6 | | 0
branch -and - bound
nodes | | | | | | | | | | | | | | -| 7 | | produced | := | | | | | | | | | | | | | -| 8 | JAN | P1 | 200 | | | | | | | | | | | | | -| 9 | JAN | P2 | 0 | | | | | | | | | | | | | -| 10 | JAN | P3 | 100 | | | | | | | | | | | | | -| 11 | JAN | P4 | 200 | | | | | | | | | | | | | -| 12 | FEB | P1 | 200 | | | | | | | | | | | | | -| 13 | FEB | P2 | 0 | | | | | | | | | | | | | -| 14 | FEB | P3 | 200 | | | | | | | | | | | | | -| 15 | FEB | P4 | 200 | | | | | | | | | | | | | -| 16 | MAR | P1 | 50 | | | | | | | | | | | | | -| 17 | MAR | P2 | 250 | | | | | | | | | | | | | -| 18 | MAR | P3 | 150 | | | | | | | | | | | | | -| 19 | MAR | P4 | 250 | | | | | | | | | | | | | -| 20 | ; | | | | | | | | | | | | | | | -| 21 | | | | | | | | | | | | | | | | -| 22 | sold | := | | | | | | | | | | | | | | -| 23 | JAN | P1 | 200 | | | | | | | | | | | | | -| 24 | JAN | P2 | 0 | | | | | | | | | | | | | -| 25 | JAN | P3 | 100 | | | | | | | | | | | | | -| 26 | JAN | P4 | 200 | | | | | | | | | | | | | -| 27 | FEB | P1 | 200 | | | | | | | | | | | | | -| 28 | FEB | P2 | 0 | | | | | | | | | | | | | -| 29 | FEB | P3 | 200 | | | | | | | | | | | | | -| 30 | FEB | P4 | 200 | | | | | | | | | | | | | -| 31 | MAR | P1 | 0 | | | | | | | | | | | | | -| 32 | MAR | P2 | 200 | | | | | | | | | | | | | -| 33 | MAR | P3 | 100 | | | | | | | | | | | | | -| 34 | MAR | P4 | 200 | | | | | | | | | | | | | -| 35 | ; | | | | | | | | | | | | | | | -| 36 | | | | | | | | | | | | | | | | -| 37 | stored | := | | | | | | | | | | | | | | -| 38 | JAN | P1 | 0 | | | | | | | | | | | | | -| 39 | JAN | P2 | 0 | | | | | | | | | | | | | -| 40 | JAN | P3 | 0 | | | | | | | | | | | | | -| 41 | JAN | P4 | 0 | | | | | | | | | | | | | -| 42 | FEB | P1 | 0 | | | | | | | | | | | | | -| 43 | FEB | P2 | 0 | | | | | | | | | | | | | -| 44 | FEB | P3 | 0 | | | | | | | | | | | | | -| 45 | FEB | P4 | 0 | | | | | | | | | | | | | -| 46 | MAR | P1 | 50 | | | | | | | | | | | | | -| 47 | MAR | P2 | 50 | | | | | | | | | | | | | -| 48 | MAR | P3 | 50 | | | | | | | | | | | | | -| 49 | MAR | P4 | 50 | | | | | | | | | | | | | - - -52 Profit: 11987.418989 - - -![](_page_0_Figure_0.jpeg) - -Rysunek 1: Obraz zbioru rozwiązań efektywnych w przestrzeni ryzyko-zysk - -## **6.2 Wyniki dla modelu dwukryterialnego** - -## **6.2.1 Obraz zbioru rozwiązań efektywnych w przestrzeni ryzyko-zysk** - -Obraz zbioru rozwiązań efektywnch w przestrzeni ryzyko-zysk został uzyskany poprzez rozwiązanie zadania metody punktu odniesienia dla różnych wartości aspiracji dla zysku oraz ryzyka. Do wykonania obliczeń posłużono się skryptem przedstawionym na [Listing 7.](#page--1-0) Obliczenia przeprowadzono ustalając poziomy aspiracji w wyznaczonych granicach zmienności zysku i ryzyka (wektory nadiru i utopii wyznaczone w kolejnej sekcji). Dla każdego poziomu aspiracji wykorzystano po 10 równoodległych wartości znajdujących się w przedziałach definiowanych przez wektory nadiru i utopii. - -Ze względu na duży rozmiar zadania, a przez długi czas obliczeń przy 1000 scenariuszach, zdecydowano się ograniczyć ich liczbę do 50. Niestety nie jest to liczba wystarczająca do przeprowadzenia dokładnych obliczeń, jednak uzyskane wyniki powinny być wystarczające do przedstawienia działania metody. - -Fragment wyników działania skryptu obliczeniowego przedstawia [Listing 8.](#page-0-0) Obraz zbioru rozwiązań efektywnych w przestrzeni ryzyko-zysk pokazuje [Rysunek 1.](#page-0-1) - -Listing 8: Skrypt obliczający wartości do wyznaczenia obrazu zbioru rozwiązań efektywnych w przestrzeni ryzyko-zysk. Pełne wyniki dostępne w załączniku. - -``` -1 ### 39: Solving model for aspirations : 2395 .666667 , 312 .777778 -2 CPLEX 12 .8.0.0 : optimal integer solution within mipgap or absmipgap ; ←- - objective 5 .427722957e -07 -3 39 MIP simplex iterations -4 0 branch -and - bound nodes -5 absmipgap = 7 .81092e -07 , relmipgap = 1 .43881 -``` - - -``` -6 Profit : 2417 .827519 -7 Risk : 311 .250020 -8 RPM : 0 .000001 -9 ### 40: Solving model for aspirations : 2395 .666667 , 0 .000000 -10 CPLEX 12 .8.0.0 : -11 < BREAK > ( cplex ) -12 CPLEX solution status 13 with fixed integers : -13 aborted in phase II -14 aborted , integer solution exists ; objective -0 .06697476417 -15 116486 MIP simplex iterations -16 103313 branch -and - bound nodes -17 absmipgap = 6 .93933e -05 , relmipgap = 0 .00103611 -18 Profit : 1432 .148909 -19 Risk : 188 .510726 -20 RPM : -0 .066975 -``` -Rozwiązania efektywne minimalnego ryzyka i maksymalnego zysku - -Rozwiązania efektywne dla minimalnego ryzyka i maksymalnego zysku wyznaczono wykorzystując skrypt przedstawiony na listingu [Listing 4.](#page--1-0) Na podstwaie wyników jego działania, które przedstawia [Listing 9](#page-0-0) można podać następujące rozwiązania: - -- Minimalne ryzyko: *ep* = *−*1000, przy *r* = 0, -- Maksymalny zysk: *ep* = 11987, przy *r* = 2569 - -Dodatkowo poza zakresem zadania wyznaczonon pozostałe elementy potrzebne do wyznaczenia wektorów nadiru i utopii: - -- Maksymalne ryzyko: *ep* = 9193, przy *r* = 2815, -- Minimalny zysk: *ep* = *−*2400*.*00, przy *r* = 0*.*00 - -``` -Wektor nadiru: (−2400, 2815) -``` -Wektor utopii: (0*,* 11987) - -Listing 9: Skrypt wyznaczający rozwiązania optymalne modelu dwukryterialnego. - -``` -1 # ######################## -2 ### Minimizing profit ### -3 # ######################## -4 CPLEX 12 .8.0.0 : optimal integer solution ; objective -2400 -5 7 MIP simplex iterations -6 0 branch -and - bound nodes -7 Profit : -2400 -8 Risk : 0 -9 -10 # ######################## -11 ### Maximizing profit ### -12 # ######################## -13 CPLEX 12 .8.0.0 : optimal integer solution ; objective 11987 .41899 -14 32 MIP simplex iterations -15 0 branch -and - bound nodes -16 Profit : 11987 -17 Risk : 2569 -18 -``` - - -``` -19 # ###################### -20 ### Minimizing risk ### -21 # ###################### -22 CPLEX 12 .8.0.0 : optimal integer solution ; objective 0 -23 0 MIP simplex iterations -24 0 branch -and - bound nodes -25 Profit : -1000 -26 Risk : 0 -27 -28 # ####################### -29 ### Maximizing risk k### -30 # ####################### -31 CPLEX 12 .8.0.0 : optimal integer solution ; objective 2815 .995263 -32 21837 MIP simplex iterations -33 705 branch -and - bound nodes -34 Profit : 9193 -35 Risk : 2815 -``` -## **6.2.2 Analiza relacji dominacji stochastycznej dla trzech wybranych rozwiązań efektywnych** - -Do analizy wybrano następujące scenariusze: - -- 1. Maksymalny zysk *ep* = 11987*.*42, -- 2. Poziomy aspiracji *aspep* = 8789*.*89 oraz *aspr* = 1876*.*67, -- 3. Poziomy aspiracji *aspep* = 10388*.*44 oraz *aspr* = 938*.*33. - -Dane do analizy zostały wygenerowane w trakcie przeprowadzania obliczeń do poprzednich podpunktów i są dostępne w załącznikach. - -Dystrybuanty zysku przedstawia [Rysunek 2.](#page--1-0) - -Na podstawie wykresów możemy stwierdzić, że rozwiązanie dla scenariusza z maksymalnym zyskiem dominuje w sensie FSD pozostałe rozwiązania. Dodatkowo widzimy, że rozwiązanie ze scenariusza 3 dominuje w sensie FSD rozwiązanie scenariusza 2. - - -![](_page_0_Figure_0.jpeg) - -Rysunek 2: Wykres dystrybuant zysku dla poszczególnych rozwiązań - - diff --git a/Programming/WDWR/projekt/old_code/readme.md b/Programming/WDWR/projekt/old_code/README.md similarity index 100% rename from Programming/WDWR/projekt/old_code/readme.md rename to Programming/WDWR/projekt/old_code/README.md diff --git a/Programming/WDWR/projekt/wdwr/README.md b/Programming/WDWR/projekt/wdwr/README.md index 6d0ec7ee..375521d0 100644 --- a/Programming/WDWR/projekt/wdwr/README.md +++ b/Programming/WDWR/projekt/wdwr/README.md @@ -1 +1,16 @@ -/home/kuhy/.wine/drive_c/Program\ Files/IBM/ILOG/CPLEX_Studio2211/opl/oplide/oplide.exe_ \ No newline at end of file +# WDWR — project working directory + +Solver runs for the WDWR (decision support under risk) project. Everything +here is AMPL/CPLEX input and output rather than source. + +| Path | What it is | +|---|---| +| `KRZYSZTOF_RUDNICKI_307585_WDWR_PROJEKT/` | The submitted bundle, kept exactly as handed in. | +| `KRZYSZTOF_RUDNICKI_307585_WDWR_PROJEKT.zip` | The same bundle, archived. | +| `old_data/` | Earlier data sets, superseded. | +| `result*.txt`, `solution*.txt` | Solver output for the model variants. | + +The submitted directory duplicates files from its parent on purpose. It is a +record of what was submitted, so it is not de-duplicated. + +The model and report live in `../doc/` and `../R/`. diff --git a/Programming/twm_4/README.md b/Programming/twm_4/README.md index e69de29b..73cf0e7e 100644 --- a/Programming/twm_4/README.md +++ b/Programming/twm_4/README.md @@ -0,0 +1,12 @@ +# TWM — lab 4: introduction to Keras + +Coursework for TWM (Techniki Wizyjne / machine vision), lab 4. + +| Path | What it is | +|---|---| +| `TWM_KerasIntro.ipynb` | The submitted notebook — the deliverable. | +| `TWM_KerasIntro.py` | An `nbconvert` export of that notebook. Derived, not edited by hand. | +| `twm.py` | Helper code used by the notebook. | + +The `.py` export is kept because it is what makes the notebook's code +reviewable and diffable; edit the notebook, then re-export.