Simulace.info - User contributions [en]

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-17T17:35:19Z

Turd01: /* Model */

== Zadání ==

'''Název simulace''': Simulace optímálneho počtu výčapov piva na štadióne

'''Autor''': Bc. Dominik Turák, turd01

'''Typ modelu''': Diskrétni simulace

'''Modelovací nástroj''': [http://simprocess.com/products/products.html SIMPROCESS]

== Popis Modelu ==

Na hokejových alebo futbalových zápasoch sa často stáva, že človek musí čakať na pivo v dlhom rade celú večnosť. Navyše, ak sa poblízku štadióna nachádza podnik, v ktorom tiež čapujú pivo, ľudia sa mnohokrát rozhodnú ísť si radšej načapovať pivo tam, pretože je to pre nich mnohokrát výhodnejšie, najmä z finančného hľadiska. Štadión tým pádom stráca potencionálny zisk a naopak, pri malom počte ľudí zbytočne prepláca pracujúcich výčapníkov.

Divák vie, že na štadióne trvá čapovanie piva priemerne 2 minúty. Taktiež má zmeranú cestu do krčmy, ktorá trvá tam a späť 10 minút ( + v krčme čapujú pivo v priemere 3 minúty ). Ak je teda v rade na 1 výčapníka priemerne viac ako 6 ľudí, oplatí sa mu zájsť si po pivo do krčmy, pretože ušetrí minútu času. Ďalším faktorom by mohla byť cena piva, čo však v tejto simulácií nie je zakomponované.

== Cíl simulace ==

Nájsť otpimálny počet výčapov prihľiadnúc na počet ľudí na štadióne tak, aby sa minimalizovali straty od nedočkavých ľudí, ktorí si radšej zvolia konkurenčný výčap, avšak zachovať počet píp na čo najnižšom možnom čísle.

= Metóda =

Nasledujúce tabuľky približuje chovanie modelu a opisujú význam vybraných vstupných dát.

{| class="wikitable"
|+ align="top" | ''' Generovaní divákov '''
!| Názov entity || Názov schedule || Typ distribúcie || jednotka času || start/end
|-
| Fan || First real fans || Poi(20.0) || 1 minúta || 16:00 - 16:30
|-
| Fan || Normal real fans || Poi(30.0) || 1 minúta || 16:30 - 17:00
|-
| Beer guy || First Beer guys || Poi(15.0) || 1 minúta || 16:00 - 16:30
|-
| Beer guy || Normal Beer fans || Poi(10.0) || 1 minúta || 16:30 - 17:00
|-
|}

Pri generovaní fanúšikov som použil Poison Distribúciu, keďže entity sa generujú v krátkom časovom intervale, čo najlepšie vyhovuje mojmu prípadu, kedy sa snažím čo najrealistickejšie vystihnúť príchod fanúšikov na štadión.

{| class="wikitable"
|+ align="top" | ''' Vlastnosti divákov '''
!| Názov entity || Pravdepodobnosť zakúpenia piva ihneď po príchode || Dlžka sledovania zápasu do dalšieho piva (v minútach)
|-
| Fan || 0% || Tri(40,55,80)
|-
| Beer guy || 40% || Tri(30,40,60)
|-
|}

Hlavné rozdiely medzi pivármi a obyčajnými fanúšikmi je túžba po pive. Zatiaľ čo obyčajný fanúšik si nikdy pri vstupe nedá pivo, u pivára je až 40% šanca, že sa tak rozhodne. Na delay označujúci sledovanie zápasu som tentokrát použil Triangulovú distribúciu, čo je v tomto prípade lepšie ako Exponenciálna distribúcia, ktorá by tak dobre nevystihovala realitu, pretože v momentálnom modeli každí dostane chuť na pivo niekedy inokedy, a nie takmer všetci ľudia naraz ( v poradí ako prichádzali na štadión ) , ako by to bolo pri Exponenciálnej distribúcii.

=Model=

[[File:MainProcessHockeyMatchesBeersOptimalization.png]]

Hlavná obrazovka obsahuje hlavne Dynamic Labels, ktoré zjednodušujú pozorovanie simulácie. Generovanie fanúšika(Generate) je proces vysvetlený v tabuľke vyššie , Užívanie si zápasu(Process) je hlavný proces obsahujúci všetko potrebné na simulovanie hokejového zápasu a požiadaviek na pivo a Odchod domov(Dispose) simuluje odchod entity zo štadióna. Celá simulácia simuluje dátum 12.12.2018 s časom trvania 16:00 - 19:30 a približný výskyt divákov na zápase prvej slovenskej ligy v meste Prešov.

[[File:WatchTheGameProcessHockeyMatchesBeersOptimalization.png]]

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - DELAY '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Kupovanie lístkov''' || Delay || Exp(2.0)/Minutes || akcia entity kupovania lístkov, priemerná doba predaja sa nelíši podľa druhu fanúšika, takže pani pri okienku vybaví priemerna za 2 minútu 1 diváka || X
|-
| '''Čapovanie piva na štadióne''' || Delay || Exp(2.0)/Minutes || priemerná doba načapovania a predania jedného piva na štadióne ||
* Accept Entity : inkrementuje o 1 globálnu premenu modelu PeopleInQueue použitú pri rozhodvaní, kde si dá pivo
* Release Entity : dekrementuje o 1 globálnu premenu modelu PeopleInQueue a inkrementuje pomocnú premennú BeerSold
|-
| '''Čapovanie piva v krčme''' || Delay || Exp(3.0)/Minutes || priemerná doba načapovania a predania jedného piva v krčme trvá o minútu dlhšie ako na štadióne ||
* Release Entity : dekrementuje o 1 pomocnú premennú BeerLost
|-
| '''Sledovanie zápasu pivára''' || Delay || Tri(25,40,60)/Minutes || pivár si dá pivo v priemere každých 40 minút, avšak niekedy si ide po ďalšie pivo skôr, už po 25 minutách, no na druhej strane viac ako 60 minút nevydrží určite || X
|-
| '''Sledovanie zápasu fanúšika''' || Delay || Tri(40,60,80)/Minutes || divák si dá pivo v priemere každých 60 minút, avšak niekedy si ide po ďalšie pivo skôr, po 40 minutách, no na druhej strane viac ako 80 minút nevydrží určite || X
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - BRANCH '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Dám si pivo?''' || Branch || Entity type || prvá križovatka typu Entity type, čo znamená, že pre každý vychádzajúci konektor ( Connector) musí byť zvolený typ entity, obyčajný fanúšik si po príchode dá pivo s 0% pravdepodobnosťou, zatiaľ čo pivár stále váha || X
|-
| '''Rozhodujem sa...''' || Branch|| Probability || Beer Guy si buď dá pivo na 40%, alebo sa rozhodne ísť sa usadiť na miesto || X
|-
| '''Kde si dám pivo?''' || Branch|| Attribute || bez ohľadu na typ entity sa divák rozhoduje, či si dá pivo na štadióne, alebo si pôjde dať pivo do vedľajšieho pivovaru (výhoda krčmového pivovaru je popísaná v úvode) || X
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
| '''Idem domov?''' || Branch || Priority || divák sa rozhoduje, či si ešte dá pivo, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:05, čo znamená, že ak divák výjde na chodbu po 19:05, urobí tak pretože chce opustiť štadión a na pivo už neide, keďže zápas sa konči o pár minút
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - CONNECTOR '''
!| Názov || Názov nástroja || Typ distribúcie || Popis
|-
| '''Zatiaľ nie''' || Connector || Exp(4.0)/Minutes|| odpoveď určená pre entitu Fan, ktorej cestovanie (Travel Duration) trvá priemerne 4 minúty
|-
| '''Som pivár, obyčajný pivár''' || Connector || X || odpoveď určená pre entitu Beer Guy na otázku z Branche '''Dám si pivo?''', slúži iba ako pomocný konektor do ďalšej Branche
|-
| '''Jo!''' || Connector || Exp(5.0)/Minutes || kladná odpoveď na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 40%)
|-
| '''Nedám''' || Connector || Exp(4.0)/Minutes || negatívna odpoveď určená na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 60%)
|-
| '''Dám si ho tu!''' || Connector || Exp(30.0)/Seconds || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí počkať si v rade na pivo na štadióne
|-
| '''Idem do krčmy''' || Connector || Exp(5.0)/Minutes || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí ísť na pivo do konkurenčnej krčmy, ktorá je vzdialená priemerne 5 minút chôdze
|-
| '''Odchádzam''' || Connector || X || divákovi sa s načapovaným pivom neoplatí vracať po 19:00 (odpoveď v Branchi '''Oplatí sa mi ešte vracať?''')
|-
| '''Idem domov''' || Connector || X || divák ktorý vyšiel na chodbu po 19:00 už neide na pivo, ale domov (odpoveď v Branchi '''Idem domov?''')
|-
| '''Jedno ešte stíham :)''' || Connector || Exp(3.0)/Minutes || divák ktorý sa dostane na chodbu pred 19:00, si ide dať určite pivo (odpoveď v Branchi '''Idem domov?''')
|-
|}

=Výsledky=

Výsledky ukazujú 4 rôzne simulácie, ktoré boli spustené s nasledujúcimi nastaveniami

* ''' Počet píp : 40 '''
* ''' Max ľudí vo fronte : 40 '''

[[File:40accepted40pipes.png]]

----

* ''' Počet píp : 30 '''
* ''' Max ľudí vo fronte : 200 '''
[[File:200accepted30pipes.png]]

----

* ''' Počet píp : 30 '''
* ''' Max ľudí vo fronte : 500 '''
[[File:500accepted30pipes.png]]

----

* ''' Počet píp : 60 '''
* ''' Max ľudí vo fronte : 420 '''
[[File:420accepted60pipes.png]]

* ''' Počet píp : 55 '''
* ''' Max ľudí vo fronte : 385'''
[[File:385accepted55pipes.png]]

----

Ako môžeme vidieť, pri zmene píp a maximálneho počtu ľudí vo fronte ( čo v reále znamená že človeku sa z časového hľadiska oplatí ísť do krčmy, ak počet čakajúcich ľudí vo fronte je vyšší ako '''Max ľudí vo fronte''' / '''Počet píp''') nám stále uniká dosť veľký počet pív. Umelé zvyšovanie maximálneho počtu čakajúcich ľudí nám nepomôže, aj keď simulácia naozaj počíta s extrémnym prípadom, kedy by každý na štadióne vypil viac ako 1 pivo za zápas. Zároveň nezahrňuje ani možnosť objednávať viac pív naraz, čo tiež nie je veľmi praktické. Tento model teda obsahuje možnosti rozšírenia, no takáto profesionálna simulácia by si vyžiadala podstatne viac času. Pri súčasnom nastavení všetkých podmienok a experimentovaní iba s 2 parametrami je pre štadión optimálne riešenie, ak by mal aspoň 53 píp, kedy by sa ľuďom z časového hľadiska takmer nikdy neoplatilo ísť si po pivo do krčmy.

=Závěr=

Simulácia by sa dala rozšíriť o množstvo ďalších rozhodnutí, ako je napríklad potreba ísť na WC alebo zahrnúť skutočnosť, že by si ľudia v bufere mohli kúpiť aj niečo iné ako pivo. Pri mojom nastavení ani 40 píp na čapovanie nestačilo na to, aby štadíón nestrácal zisky (čo sa týka predaného piva, výčapníci a ich hodinová mzda v modeli zatiaľ chýba tiež) z divákov, ktorí chcú pivo v rovnaký čas. Naopak, otpimalizáciu prihľiadnúc na tento fakt by som považoval nasadenie 20 píp, kde by ale pracovníci nemali takmer žiaden oddych. Som rád, že som si nakoniec vybral Simprocess, pretože tento nástroj môže byť v budúcnosti veľmi žiadaný.

=Kód=
[[File:HockeyMatchesBeersOptimalization.spm]]

=Reference=
http://simprocess.com/Documentation/Windows_Manuals/SIMPROCESS_Getting_Started_Manual.pdf
http://simprocess.com/Documentation/SIMPROCESS_Expression_Demo_Models.pdf

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-17T17:33:17Z

Turd01: /* Výsledky */

== Zadání ==

'''Název simulace''': Simulace optímálneho počtu výčapov piva na štadióne

'''Autor''': Bc. Dominik Turák, turd01

'''Typ modelu''': Diskrétni simulace

'''Modelovací nástroj''': [http://simprocess.com/products/products.html SIMPROCESS]

== Popis Modelu ==

Na hokejových alebo futbalových zápasoch sa často stáva, že človek musí čakať na pivo v dlhom rade celú večnosť. Navyše, ak sa poblízku štadióna nachádza podnik, v ktorom tiež čapujú pivo, ľudia sa mnohokrát rozhodnú ísť si radšej načapovať pivo tam, pretože je to pre nich mnohokrát výhodnejšie, najmä z finančného hľadiska. Štadión tým pádom stráca potencionálny zisk a naopak, pri malom počte ľudí zbytočne prepláca pracujúcich výčapníkov.

Divák vie, že na štadióne trvá čapovanie piva priemerne 2 minúty. Taktiež má zmeranú cestu do krčmy, ktorá trvá tam a späť 10 minút ( + v krčme čapujú pivo v priemere 3 minúty ). Ak je teda v rade na 1 výčapníka priemerne viac ako 6 ľudí, oplatí sa mu zájsť si po pivo do krčmy, pretože ušetrí minútu času. Ďalším faktorom by mohla byť cena piva, čo však v tejto simulácií nie je zakomponované.

== Cíl simulace ==

Nájsť otpimálny počet výčapov prihľiadnúc na počet ľudí na štadióne tak, aby sa minimalizovali straty od nedočkavých ľudí, ktorí si radšej zvolia konkurenčný výčap, avšak zachovať počet píp na čo najnižšom možnom čísle.

= Metóda =

Nasledujúce tabuľky približuje chovanie modelu a opisujú význam vybraných vstupných dát.

{| class="wikitable"
|+ align="top" | ''' Generovaní divákov '''
!| Názov entity || Názov schedule || Typ distribúcie || jednotka času || start/end
|-
| Fan || First real fans || Poi(20.0) || 1 minúta || 16:00 - 16:30
|-
| Fan || Normal real fans || Poi(30.0) || 1 minúta || 16:30 - 17:00
|-
| Beer guy || First Beer guys || Poi(15.0) || 1 minúta || 16:00 - 16:30
|-
| Beer guy || Normal Beer fans || Poi(10.0) || 1 minúta || 16:30 - 17:00
|-
|}

Pri generovaní fanúšikov som použil Poison Distribúciu, keďže entity sa generujú v krátkom časovom intervale, čo najlepšie vyhovuje mojmu prípadu, kedy sa snažím čo najrealistickejšie vystihnúť príchod fanúšikov na štadión.

{| class="wikitable"
|+ align="top" | ''' Vlastnosti divákov '''
!| Názov entity || Pravdepodobnosť zakúpenia piva ihneď po príchode || Dlžka sledovania zápasu do dalšieho piva (v minútach)
|-
| Fan || 0% || Tri(40,55,80)
|-
| Beer guy || 40% || Tri(30,40,60)
|-
|}

Hlavné rozdiely medzi pivármi a obyčajnými fanúšikmi je túžba po pive. Zatiaľ čo obyčajný fanúšik si nikdy pri vstupe nedá pivo, u pivára je až 40% šanca, že sa tak rozhodne. Na delay označujúci sledovanie zápasu som tentokrát použil Triangulovú distribúciu, čo je v tomto prípade lepšie ako Exponenciálna distribúcia, ktorá by tak dobre nevystihovala realitu, pretože v momentálnom modeli každí dostane chuť na pivo niekedy inokedy, a nie takmer všetci ľudia naraz ( v poradí ako prichádzali na štadión ) , ako by to bolo pri Exponenciálnej distribúcii.

=Model=

[[File:MainProcessHockeyMatchesBeersOptimalization.png]]

Hlavná obrazovka obsahuje hlavne Dynamic Labels, ktoré zjednodušujú pozorovanie simulácie. Generovanie fanúšika(Generate) je proces vysvetlený v tabuľke vyššie , Užívanie si zápasu(Process) je hlavný proces obsahujúci všetko potrebné na simulovanie hokejového zápasu a požiadaviek na pivo a Odchod domov(Dispose) simuluje odchod entity zo štadióna. Celá simulácia simuluje dátum 12.12.2018 s časom trvania 16:00 - 19:30 a približný výskyt divákov na zápase prvej slovenskej ligy v meste Prešov.

[[File:WatchTheGameProcessHockeyMatchesBeersOptimalization.png]]

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - DELAY '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Kupovanie lístkov''' || Delay || Exp(2.0)/Minutes || akcia entity kupovania lístkov, priemerná doba predaja sa nelíši podľa druhu fanúšika, takže pani pri okienku vybaví priemerna za 1 minútu 1 diváka || X
|-
| '''Čapovanie piva na štadióne''' || Delay || Exp(2.0)/Minutes || priemerná doba načapovania a predania jedného piva na štadióne ||
* Accept Entity : inkrementuje o 1 globálnu premenu modelu PeopleInQueue použitú pri rozhodvaní, kde si dá pivo
* Release Entity : dekrementuje o 1 globálnu premenu modelu PeopleInQueue a inkrementuje pomocnú premennú BeerSold
|-
| '''Čapovanie piva v krčme''' || Delay || Exp(3.0)/Minutes || priemerná doba načapovania a predania jedného piva v krčme trvá o minútu dlhšie ako na štadióne ||
* Release Entity : dekrementuje o 1 pomocnú premennú BeerLost
|-
| '''Sledovanie zápasu pivára''' || Delay || Tri(25,40,60)/Minutes || pivár si dá pivo v priemere každých 40 minút, avšak niekedy si ide po ďalšie pivo skôr, už po 25 minutách, no na druhej strane viac ako 60 minút nevydrží určite || X
|-
| '''Sledovanie zápasu fanúšika''' || Delay || Tri(40,60,80)/Minutes || divák si dá pivo v priemere každých 60 minút, avšak niekedy si ide po ďalšie pivo skôr, po 40 minutách, no na druhej strane viac ako 80 minút nevydrží určite || X
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - BRANCH '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Dám si pivo?''' || Branch || Entity type || prvá križovatka typu Entity type, čo znamená, že pre každý vychádzajúci konektor ( Connector) musí byť zvolený typ entity, obyčajný fanúšik si po príchode dá pivo s 0% pravdepodobnosťou, zatiaľ čo pivár stále váha || X
|-
| '''Rozhodujem sa...''' || Branch|| Probability || Beer Guy si buď dá pivo na 40%, alebo sa rozhodne ísť sa usadiť na miesto || X
|-
| '''Kde si dám pivo?''' || Branch|| Attribute || bez ohľadu na typ entity sa divák rozhoduje, či si dá pivo na štadióne, alebo si pôjde dať pivo do vedľajšieho pivovaru (výhoda krčmového pivovaru je popísaná v úvode) || X
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
| '''Idem domov?''' || Branch || Priority || divák sa rozhoduje, či si ešte dá pivo, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:05, čo znamená, že ak divák výjde na chodbu po 19:05, urobí tak pretože chce opustiť štadión a na pivo už neide, keďže zápas sa konči o pár minút
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - CONNECTOR '''
!| Názov || Názov nástroja || Typ distribúcie || Popis
|-
| '''Zatiaľ nie''' || Connector || Exp(4.0)/Minutes|| odpoveď určená pre entitu Fan, ktorej cestovanie (Travel Duration) trvá priemerne 4 minúty
|-
| '''Som pivár, obyčajný pivár''' || Connector || X || odpoveď určená pre entitu Beer Guy na otázku z Branche '''Dám si pivo?''', slúži iba ako pomocný konektor do ďalšej Branche
|-
| '''Jo!''' || Connector || Exp(5.0)/Minutes || kladná odpoveď na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 40%)
|-
| '''Nedám''' || Connector || Exp(4.0)/Minutes || negatívna odpoveď určená na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 60%)
|-
| '''Dám si ho tu!''' || Connector || Exp(30.0)/Seconds || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí počkať si v rade na pivo na štadióne
|-
| '''Idem do krčmy''' || Connector || Exp(5.0)/Minutes || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí ísť na pivo do konkurenčnej krčmy, ktorá je vzdialená priemerne 5 minút chôdze
|-
| '''Odchádzam''' || Connector || X || divákovi sa s načapovaným pivom neoplatí vracať po 19:00 (odpoveď v Branchi '''Oplatí sa mi ešte vracať?''')
|-
| '''Idem domov''' || Connector || X || divák ktorý vyšiel na chodbu po 19:00 už neide na pivo, ale domov (odpoveď v Branchi '''Idem domov?''')
|-
| '''Jedno ešte stíham :)''' || Connector || Exp(3.0)/Minutes || divák ktorý sa dostane na chodbu pred 19:00, si ide dať určite pivo (odpoveď v Branchi '''Idem domov?''')
|-
|}

=Výsledky=

Výsledky ukazujú 4 rôzne simulácie, ktoré boli spustené s nasledujúcimi nastaveniami

* ''' Počet píp : 40 '''
* ''' Max ľudí vo fronte : 40 '''

[[File:40accepted40pipes.png]]

----

* ''' Počet píp : 30 '''
* ''' Max ľudí vo fronte : 200 '''
[[File:200accepted30pipes.png]]

----

* ''' Počet píp : 30 '''
* ''' Max ľudí vo fronte : 500 '''
[[File:500accepted30pipes.png]]

----

* ''' Počet píp : 60 '''
* ''' Max ľudí vo fronte : 420 '''
[[File:420accepted60pipes.png]]

* ''' Počet píp : 55 '''
* ''' Max ľudí vo fronte : 385'''
[[File:385accepted55pipes.png]]

----

Ako môžeme vidieť, pri zmene píp a maximálneho počtu ľudí vo fronte ( čo v reále znamená že človeku sa z časového hľadiska oplatí ísť do krčmy, ak počet čakajúcich ľudí vo fronte je vyšší ako '''Max ľudí vo fronte''' / '''Počet píp''') nám stále uniká dosť veľký počet pív. Umelé zvyšovanie maximálneho počtu čakajúcich ľudí nám nepomôže, aj keď simulácia naozaj počíta s extrémnym prípadom, kedy by každý na štadióne vypil viac ako 1 pivo za zápas. Zároveň nezahrňuje ani možnosť objednávať viac pív naraz, čo tiež nie je veľmi praktické. Tento model teda obsahuje možnosti rozšírenia, no takáto profesionálna simulácia by si vyžiadala podstatne viac času. Pri súčasnom nastavení všetkých podmienok a experimentovaní iba s 2 parametrami je pre štadión optimálne riešenie, ak by mal aspoň 53 píp, kedy by sa ľuďom z časového hľadiska takmer nikdy neoplatilo ísť si po pivo do krčmy.

=Závěr=

Simulácia by sa dala rozšíriť o množstvo ďalších rozhodnutí, ako je napríklad potreba ísť na WC alebo zahrnúť skutočnosť, že by si ľudia v bufere mohli kúpiť aj niečo iné ako pivo. Pri mojom nastavení ani 40 píp na čapovanie nestačilo na to, aby štadíón nestrácal zisky (čo sa týka predaného piva, výčapníci a ich hodinová mzda v modeli zatiaľ chýba tiež) z divákov, ktorí chcú pivo v rovnaký čas. Naopak, otpimalizáciu prihľiadnúc na tento fakt by som považoval nasadenie 20 píp, kde by ale pracovníci nemali takmer žiaden oddych. Som rád, že som si nakoniec vybral Simprocess, pretože tento nástroj môže byť v budúcnosti veľmi žiadaný.

=Kód=
[[File:HockeyMatchesBeersOptimalization.spm]]

=Reference=
http://simprocess.com/Documentation/Windows_Manuals/SIMPROCESS_Getting_Started_Manual.pdf
http://simprocess.com/Documentation/SIMPROCESS_Expression_Demo_Models.pdf

File:385accepted55pipes.png

2019-06-17T17:33:13Z

Turd01:

File:420accepted60pipes.png

2019-06-17T17:11:38Z

Turd01:

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-17T17:08:30Z

Turd01: /* Výsledky */

== Zadání ==

'''Název simulace''': Simulace optímálneho počtu výčapov piva na štadióne

'''Autor''': Bc. Dominik Turák, turd01

'''Typ modelu''': Diskrétni simulace

'''Modelovací nástroj''': [http://simprocess.com/products/products.html SIMPROCESS]

== Popis Modelu ==

Na hokejových alebo futbalových zápasoch sa často stáva, že človek musí čakať na pivo v dlhom rade celú večnosť. Navyše, ak sa poblízku štadióna nachádza podnik, v ktorom tiež čapujú pivo, ľudia sa mnohokrát rozhodnú ísť si radšej načapovať pivo tam, pretože je to pre nich mnohokrát výhodnejšie, najmä z finančného hľadiska. Štadión tým pádom stráca potencionálny zisk a naopak, pri malom počte ľudí zbytočne prepláca pracujúcich výčapníkov.

Divák vie, že na štadióne trvá čapovanie piva priemerne 2 minúty. Taktiež má zmeranú cestu do krčmy, ktorá trvá tam a späť 10 minút ( + v krčme čapujú pivo v priemere 3 minúty ). Ak je teda v rade na 1 výčapníka priemerne viac ako 6 ľudí, oplatí sa mu zájsť si po pivo do krčmy, pretože ušetrí minútu času. Ďalším faktorom by mohla byť cena piva, čo však v tejto simulácií nie je zakomponované.

== Cíl simulace ==

Nájsť otpimálny počet výčapov prihľiadnúc na počet ľudí na štadióne tak, aby sa minimalizovali straty od nedočkavých ľudí, ktorí si radšej zvolia konkurenčný výčap, avšak zachovať počet píp na čo najnižšom možnom čísle.

= Metóda =

Nasledujúce tabuľky približuje chovanie modelu a opisujú význam vybraných vstupných dát.

{| class="wikitable"
|+ align="top" | ''' Generovaní divákov '''
!| Názov entity || Názov schedule || Typ distribúcie || jednotka času || start/end
|-
| Fan || First real fans || Poi(20.0) || 1 minúta || 16:00 - 16:30
|-
| Fan || Normal real fans || Poi(30.0) || 1 minúta || 16:30 - 17:00
|-
| Beer guy || First Beer guys || Poi(15.0) || 1 minúta || 16:00 - 16:30
|-
| Beer guy || Normal Beer fans || Poi(10.0) || 1 minúta || 16:30 - 17:00
|-
|}

Pri generovaní fanúšikov som použil Poison Distribúciu, keďže entity sa generujú v krátkom časovom intervale, čo najlepšie vyhovuje mojmu prípadu, kedy sa snažím čo najrealistickejšie vystihnúť príchod fanúšikov na štadión.

{| class="wikitable"
|+ align="top" | ''' Vlastnosti divákov '''
!| Názov entity || Pravdepodobnosť zakúpenia piva ihneď po príchode || Dlžka sledovania zápasu do dalšieho piva (v minútach)
|-
| Fan || 0% || Tri(40,55,80)
|-
| Beer guy || 40% || Tri(30,40,60)
|-
|}

Hlavné rozdiely medzi pivármi a obyčajnými fanúšikmi je túžba po pive. Zatiaľ čo obyčajný fanúšik si nikdy pri vstupe nedá pivo, u pivára je až 40% šanca, že sa tak rozhodne. Na delay označujúci sledovanie zápasu som tentokrát použil Triangulovú distribúciu, čo je v tomto prípade lepšie ako Exponenciálna distribúcia, ktorá by tak dobre nevystihovala realitu, pretože v momentálnom modeli každí dostane chuť na pivo niekedy inokedy, a nie takmer všetci ľudia naraz ( v poradí ako prichádzali na štadión ) , ako by to bolo pri Exponenciálnej distribúcii.

=Model=

[[File:MainProcessHockeyMatchesBeersOptimalization.png]]

Hlavná obrazovka obsahuje hlavne Dynamic Labels, ktoré zjednodušujú pozorovanie simulácie. Generovanie fanúšika(Generate) je proces vysvetlený v tabuľke vyššie , Užívanie si zápasu(Process) je hlavný proces obsahujúci všetko potrebné na simulovanie hokejového zápasu a požiadaviek na pivo a Odchod domov(Dispose) simuluje odchod entity zo štadióna. Celá simulácia simuluje dátum 12.12.2018 s časom trvania 16:00 - 19:30 a približný výskyt divákov na zápase prvej slovenskej ligy v meste Prešov.

[[File:WatchTheGameProcessHockeyMatchesBeersOptimalization.png]]

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - DELAY '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Kupovanie lístkov''' || Delay || Exp(2.0)/Minutes || akcia entity kupovania lístkov, priemerná doba predaja sa nelíši podľa druhu fanúšika, takže pani pri okienku vybaví priemerna za 1 minútu 1 diváka || X
|-
| '''Čapovanie piva na štadióne''' || Delay || Exp(2.0)/Minutes || priemerná doba načapovania a predania jedného piva na štadióne ||
* Accept Entity : inkrementuje o 1 globálnu premenu modelu PeopleInQueue použitú pri rozhodvaní, kde si dá pivo
* Release Entity : dekrementuje o 1 globálnu premenu modelu PeopleInQueue a inkrementuje pomocnú premennú BeerSold
|-
| '''Čapovanie piva v krčme''' || Delay || Exp(3.0)/Minutes || priemerná doba načapovania a predania jedného piva v krčme trvá o minútu dlhšie ako na štadióne ||
* Release Entity : dekrementuje o 1 pomocnú premennú BeerLost
|-
| '''Sledovanie zápasu pivára''' || Delay || Tri(25,40,60)/Minutes || pivár si dá pivo v priemere každých 40 minút, avšak niekedy si ide po ďalšie pivo skôr, už po 25 minutách, no na druhej strane viac ako 60 minút nevydrží určite || X
|-
| '''Sledovanie zápasu fanúšika''' || Delay || Tri(40,60,80)/Minutes || divák si dá pivo v priemere každých 60 minút, avšak niekedy si ide po ďalšie pivo skôr, po 40 minutách, no na druhej strane viac ako 80 minút nevydrží určite || X
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - BRANCH '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Dám si pivo?''' || Branch || Entity type || prvá križovatka typu Entity type, čo znamená, že pre každý vychádzajúci konektor ( Connector) musí byť zvolený typ entity, obyčajný fanúšik si po príchode dá pivo s 0% pravdepodobnosťou, zatiaľ čo pivár stále váha || X
|-
| '''Rozhodujem sa...''' || Branch|| Probability || Beer Guy si buď dá pivo na 40%, alebo sa rozhodne ísť sa usadiť na miesto || X
|-
| '''Kde si dám pivo?''' || Branch|| Attribute || bez ohľadu na typ entity sa divák rozhoduje, či si dá pivo na štadióne, alebo si pôjde dať pivo do vedľajšieho pivovaru (výhoda krčmového pivovaru je popísaná v úvode) || X
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
| '''Idem domov?''' || Branch || Priority || divák sa rozhoduje, či si ešte dá pivo, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:05, čo znamená, že ak divák výjde na chodbu po 19:05, urobí tak pretože chce opustiť štadión a na pivo už neide, keďže zápas sa konči o pár minút
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - CONNECTOR '''
!| Názov || Názov nástroja || Typ distribúcie || Popis
|-
| '''Zatiaľ nie''' || Connector || Exp(4.0)/Minutes|| odpoveď určená pre entitu Fan, ktorej cestovanie (Travel Duration) trvá priemerne 4 minúty
|-
| '''Som pivár, obyčajný pivár''' || Connector || X || odpoveď určená pre entitu Beer Guy na otázku z Branche '''Dám si pivo?''', slúži iba ako pomocný konektor do ďalšej Branche
|-
| '''Jo!''' || Connector || Exp(5.0)/Minutes || kladná odpoveď na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 40%)
|-
| '''Nedám''' || Connector || Exp(4.0)/Minutes || negatívna odpoveď určená na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 60%)
|-
| '''Dám si ho tu!''' || Connector || Exp(30.0)/Seconds || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí počkať si v rade na pivo na štadióne
|-
| '''Idem do krčmy''' || Connector || Exp(5.0)/Minutes || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí ísť na pivo do konkurenčnej krčmy, ktorá je vzdialená priemerne 5 minút chôdze
|-
| '''Odchádzam''' || Connector || X || divákovi sa s načapovaným pivom neoplatí vracať po 19:00 (odpoveď v Branchi '''Oplatí sa mi ešte vracať?''')
|-
| '''Idem domov''' || Connector || X || divák ktorý vyšiel na chodbu po 19:00 už neide na pivo, ale domov (odpoveď v Branchi '''Idem domov?''')
|-
| '''Jedno ešte stíham :)''' || Connector || Exp(3.0)/Minutes || divák ktorý sa dostane na chodbu pred 19:00, si ide dať určite pivo (odpoveď v Branchi '''Idem domov?''')
|-
|}

=Výsledky=

Výsledky ukazujú 4 rôzne simulácie, ktoré boli spustené s nasledujúcimi nastaveniami

* ''' Počet píp : 40 '''
* ''' Max ľudí vo fronte : 40 '''

[[File:40accepted40pipes.png]]

----

* ''' Počet píp : 30 '''
* ''' Max ľudí vo fronte : 200 '''
[[File:200accepted30pipes.png]]

----

* ''' Počet píp : 30 '''
* ''' Max ľudí vo fronte : 500 '''
[[File:500accepted30pipes.png]]

----

* ''' Počet píp : 60 '''
* ''' Max ľudí vo fronte : 420 '''
[[File:420accepted60pipes.png]]

* ''' Počet píp : 55 '''
* ''' Max ľudí vo fronte : 385'''
[[File:420accepted60pipes.png]]

----

Ako môžeme vidieť, pri zmene píp a maximálneho počtu ľudí vo fronte ( čo v reále znamená že človeku sa z časového hľadiska oplatí ísť do krčmy, ak počet čakajúcich ľudí vo fronte je vyšší ako '''Max ľudí vo fronte''' / '''Počet píp''') nám stále uniká dosť veľký počet pív. Umelé zvyšovanie maximálneho počtu čakajúcich ľudí nám nepomôže, aj keď simulácia naozaj počíta s extrémnym prípadom, kedy by každý na štadióne vypil viac ako 1 pivo za zápas. Zároveň nezahrňuje ani možnosť objednávať viac pív naraz, čo tiež nie je veľmi praktické. Tento model teda obsahuje možnosti rozšírenia, no takáto profesionálna simulácia by si vyžiadala podstatne viac času. Pri súčasnom nastavení všetkých podmienok a experimentovaní iba s 2 parametrami je pre štadión optimálne riešenie, ak by mal okolo 60 píp, kedy by sa ľuďom z časového hľadiska takmer vôbec neoplatilo chodiť po pivo do krčmy.

=Závěr=

Simulácia by sa dala rozšíriť o množstvo ďalších rozhodnutí, ako je napríklad potreba ísť na WC alebo zahrnúť skutočnosť, že by si ľudia v bufere mohli kúpiť aj niečo iné ako pivo. Pri mojom nastavení ani 40 píp na čapovanie nestačilo na to, aby štadíón nestrácal zisky (čo sa týka predaného piva, výčapníci a ich hodinová mzda v modeli zatiaľ chýba tiež) z divákov, ktorí chcú pivo v rovnaký čas. Naopak, otpimalizáciu prihľiadnúc na tento fakt by som považoval nasadenie 20 píp, kde by ale pracovníci nemali takmer žiaden oddych. Som rád, že som si nakoniec vybral Simprocess, pretože tento nástroj môže byť v budúcnosti veľmi žiadaný.

=Kód=
[[File:HockeyMatchesBeersOptimalization.spm]]

=Reference=
http://simprocess.com/Documentation/Windows_Manuals/SIMPROCESS_Getting_Started_Manual.pdf
http://simprocess.com/Documentation/SIMPROCESS_Expression_Demo_Models.pdf

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-17T16:48:16Z

Turd01: /* Výsledky */

== Zadání ==

'''Název simulace''': Simulace optímálneho počtu výčapov piva na štadióne

'''Autor''': Bc. Dominik Turák, turd01

'''Typ modelu''': Diskrétni simulace

'''Modelovací nástroj''': [http://simprocess.com/products/products.html SIMPROCESS]

== Popis Modelu ==

Na hokejových alebo futbalových zápasoch sa často stáva, že človek musí čakať na pivo v dlhom rade celú večnosť. Navyše, ak sa poblízku štadióna nachádza podnik, v ktorom tiež čapujú pivo, ľudia sa mnohokrát rozhodnú ísť si radšej načapovať pivo tam, pretože je to pre nich mnohokrát výhodnejšie, najmä z finančného hľadiska. Štadión tým pádom stráca potencionálny zisk a naopak, pri malom počte ľudí zbytočne prepláca pracujúcich výčapníkov.

Divák vie, že na štadióne trvá čapovanie piva priemerne 2 minúty. Taktiež má zmeranú cestu do krčmy, ktorá trvá tam a späť 10 minút ( + v krčme čapujú pivo v priemere 3 minúty ). Ak je teda v rade na 1 výčapníka priemerne viac ako 6 ľudí, oplatí sa mu zájsť si po pivo do krčmy, pretože ušetrí minútu času. Ďalším faktorom by mohla byť cena piva, čo však v tejto simulácií nie je zakomponované.

== Cíl simulace ==

Nájsť otpimálny počet výčapov prihľiadnúc na počet ľudí na štadióne tak, aby sa minimalizovali straty od nedočkavých ľudí, ktorí si radšej zvolia konkurenčný výčap, avšak zachovať počet píp na čo najnižšom možnom čísle.

= Metóda =

Nasledujúce tabuľky približuje chovanie modelu a opisujú význam vybraných vstupných dát.

{| class="wikitable"
|+ align="top" | ''' Generovaní divákov '''
!| Názov entity || Názov schedule || Typ distribúcie || jednotka času || start/end
|-
| Fan || First real fans || Poi(20.0) || 1 minúta || 16:00 - 16:30
|-
| Fan || Normal real fans || Poi(30.0) || 1 minúta || 16:30 - 17:00
|-
| Beer guy || First Beer guys || Poi(15.0) || 1 minúta || 16:00 - 16:30
|-
| Beer guy || Normal Beer fans || Poi(10.0) || 1 minúta || 16:30 - 17:00
|-
|}

Pri generovaní fanúšikov som použil Poison Distribúciu, keďže entity sa generujú v krátkom časovom intervale, čo najlepšie vyhovuje mojmu prípadu, kedy sa snažím čo najrealistickejšie vystihnúť príchod fanúšikov na štadión.

{| class="wikitable"
|+ align="top" | ''' Vlastnosti divákov '''
!| Názov entity || Pravdepodobnosť zakúpenia piva ihneď po príchode || Dlžka sledovania zápasu do dalšieho piva (v minútach)
|-
| Fan || 0% || Tri(40,55,80)
|-
| Beer guy || 40% || Tri(30,40,60)
|-
|}

Hlavné rozdiely medzi pivármi a obyčajnými fanúšikmi je túžba po pive. Zatiaľ čo obyčajný fanúšik si nikdy pri vstupe nedá pivo, u pivára je až 40% šanca, že sa tak rozhodne. Na delay označujúci sledovanie zápasu som tentokrát použil Triangulovú distribúciu, čo je v tomto prípade lepšie ako Exponenciálna distribúcia, ktorá by tak dobre nevystihovala realitu, pretože v momentálnom modeli každí dostane chuť na pivo niekedy inokedy, a nie takmer všetci ľudia naraz ( v poradí ako prichádzali na štadión ) , ako by to bolo pri Exponenciálnej distribúcii.

=Model=

[[File:MainProcessHockeyMatchesBeersOptimalization.png]]

Hlavná obrazovka obsahuje hlavne Dynamic Labels, ktoré zjednodušujú pozorovanie simulácie. Generovanie fanúšika(Generate) je proces vysvetlený v tabuľke vyššie , Užívanie si zápasu(Process) je hlavný proces obsahujúci všetko potrebné na simulovanie hokejového zápasu a požiadaviek na pivo a Odchod domov(Dispose) simuluje odchod entity zo štadióna. Celá simulácia simuluje dátum 12.12.2018 s časom trvania 16:00 - 19:30 a približný výskyt divákov na zápase prvej slovenskej ligy v meste Prešov.

[[File:WatchTheGameProcessHockeyMatchesBeersOptimalization.png]]

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - DELAY '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Kupovanie lístkov''' || Delay || Exp(2.0)/Minutes || akcia entity kupovania lístkov, priemerná doba predaja sa nelíši podľa druhu fanúšika, takže pani pri okienku vybaví priemerna za 1 minútu 1 diváka || X
|-
| '''Čapovanie piva na štadióne''' || Delay || Exp(2.0)/Minutes || priemerná doba načapovania a predania jedného piva na štadióne ||
* Accept Entity : inkrementuje o 1 globálnu premenu modelu PeopleInQueue použitú pri rozhodvaní, kde si dá pivo
* Release Entity : dekrementuje o 1 globálnu premenu modelu PeopleInQueue a inkrementuje pomocnú premennú BeerSold
|-
| '''Čapovanie piva v krčme''' || Delay || Exp(3.0)/Minutes || priemerná doba načapovania a predania jedného piva v krčme trvá o minútu dlhšie ako na štadióne ||
* Release Entity : dekrementuje o 1 pomocnú premennú BeerLost
|-
| '''Sledovanie zápasu pivára''' || Delay || Tri(25,40,60)/Minutes || pivár si dá pivo v priemere každých 40 minút, avšak niekedy si ide po ďalšie pivo skôr, už po 25 minutách, no na druhej strane viac ako 60 minút nevydrží určite || X
|-
| '''Sledovanie zápasu fanúšika''' || Delay || Tri(40,60,80)/Minutes || divák si dá pivo v priemere každých 60 minút, avšak niekedy si ide po ďalšie pivo skôr, po 40 minutách, no na druhej strane viac ako 80 minút nevydrží určite || X
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - BRANCH '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Dám si pivo?''' || Branch || Entity type || prvá križovatka typu Entity type, čo znamená, že pre každý vychádzajúci konektor ( Connector) musí byť zvolený typ entity, obyčajný fanúšik si po príchode dá pivo s 0% pravdepodobnosťou, zatiaľ čo pivár stále váha || X
|-
| '''Rozhodujem sa...''' || Branch|| Probability || Beer Guy si buď dá pivo na 40%, alebo sa rozhodne ísť sa usadiť na miesto || X
|-
| '''Kde si dám pivo?''' || Branch|| Attribute || bez ohľadu na typ entity sa divák rozhoduje, či si dá pivo na štadióne, alebo si pôjde dať pivo do vedľajšieho pivovaru (výhoda krčmového pivovaru je popísaná v úvode) || X
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
| '''Idem domov?''' || Branch || Priority || divák sa rozhoduje, či si ešte dá pivo, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:05, čo znamená, že ak divák výjde na chodbu po 19:05, urobí tak pretože chce opustiť štadión a na pivo už neide, keďže zápas sa konči o pár minút
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - CONNECTOR '''
!| Názov || Názov nástroja || Typ distribúcie || Popis
|-
| '''Zatiaľ nie''' || Connector || Exp(4.0)/Minutes|| odpoveď určená pre entitu Fan, ktorej cestovanie (Travel Duration) trvá priemerne 4 minúty
|-
| '''Som pivár, obyčajný pivár''' || Connector || X || odpoveď určená pre entitu Beer Guy na otázku z Branche '''Dám si pivo?''', slúži iba ako pomocný konektor do ďalšej Branche
|-
| '''Jo!''' || Connector || Exp(5.0)/Minutes || kladná odpoveď na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 40%)
|-
| '''Nedám''' || Connector || Exp(4.0)/Minutes || negatívna odpoveď určená na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 60%)
|-
| '''Dám si ho tu!''' || Connector || Exp(30.0)/Seconds || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí počkať si v rade na pivo na štadióne
|-
| '''Idem do krčmy''' || Connector || Exp(5.0)/Minutes || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí ísť na pivo do konkurenčnej krčmy, ktorá je vzdialená priemerne 5 minút chôdze
|-
| '''Odchádzam''' || Connector || X || divákovi sa s načapovaným pivom neoplatí vracať po 19:00 (odpoveď v Branchi '''Oplatí sa mi ešte vracať?''')
|-
| '''Idem domov''' || Connector || X || divák ktorý vyšiel na chodbu po 19:00 už neide na pivo, ale domov (odpoveď v Branchi '''Idem domov?''')
|-
| '''Jedno ešte stíham :)''' || Connector || Exp(3.0)/Minutes || divák ktorý sa dostane na chodbu pred 19:00, si ide dať určite pivo (odpoveď v Branchi '''Idem domov?''')
|-
|}

=Výsledky=

Výsledky ukazujú 4 rôzne simulácie, ktoré boli spustené s nasledujúcimi nastaveniami

* ''' Počet píp : 40 '''
* ''' Max ľudí vo fronte : 40 '''

[[File:40accepted40pipes.png]]

----

* ''' Počet píp : 30 '''
* ''' Max ľudí vo fronte : 200 '''
[[File:200accepted30pipes.png]]

----

* ''' Počet píp : 30 '''
* ''' Max ľudí vo fronte : 500 '''
[[File:500accepted30pipes.png]]

----

* ''' Počet píp : 60 '''
* ''' Max ľudí vo fronte : 420 '''
[[File:420accepted50pipes.png]]

----

Ako môžeme vidieť, pri zmene píp a maximálneho počtu ľudí vo fronte ( čo v reále znamená že človeku sa z časového hľadiska oplatí ísť do krčmy, ak počet čakajúcich ľudí vo fronte je vyšší ako '''Max ľudí vo fronte''' / '''Počet píp''') nám stále uniká dosť veľký počet pív. Umelé zvyšovanie maximálneho počtu čakajúcich ľudí nám nepomôže, aj keď simulácia naozaj počíta s extrémnym prípadom, kedy by každý na štadióne vypil viac ako 1 pivo za zápas. Zároveň nezahrňuje ani možnosť objednávať viac pív naraz, čo tiež nie je veľmi praktické. Tento model teda obsahuje možnosti rozšírenia, no takáto profesionálna simulácia by si vyžiadala podstatne viac času. Pri súčasnom nastavení všetkých podmienok a experimentovaní iba s 2 parametrami je pre štadión optimálne riešenie, ak by mal okolo 60 píp, kedy by sa ľuďom z časového hľadiska vôbec neoplatilo chodiť po pivo do krčmy.

=Závěr=

Simulácia by sa dala rozšíriť o množstvo ďalších rozhodnutí, ako je napríklad potreba ísť na WC alebo zahrnúť skutočnosť, že by si ľudia v bufere mohli kúpiť aj niečo iné ako pivo. Pri mojom nastavení ani 40 píp na čapovanie nestačilo na to, aby štadíón nestrácal zisky (čo sa týka predaného piva, výčapníci a ich hodinová mzda v modeli zatiaľ chýba tiež) z divákov, ktorí chcú pivo v rovnaký čas. Naopak, otpimalizáciu prihľiadnúc na tento fakt by som považoval nasadenie 20 píp, kde by ale pracovníci nemali takmer žiaden oddych. Som rád, že som si nakoniec vybral Simprocess, pretože tento nástroj môže byť v budúcnosti veľmi žiadaný.

=Kód=
[[File:HockeyMatchesBeersOptimalization.spm]]

=Reference=
http://simprocess.com/Documentation/Windows_Manuals/SIMPROCESS_Getting_Started_Manual.pdf
http://simprocess.com/Documentation/SIMPROCESS_Expression_Demo_Models.pdf

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-17T16:47:57Z

Turd01: /* Výsledky */

== Zadání ==

'''Název simulace''': Simulace optímálneho počtu výčapov piva na štadióne

'''Autor''': Bc. Dominik Turák, turd01

'''Typ modelu''': Diskrétni simulace

'''Modelovací nástroj''': [http://simprocess.com/products/products.html SIMPROCESS]

== Popis Modelu ==

Na hokejových alebo futbalových zápasoch sa často stáva, že človek musí čakať na pivo v dlhom rade celú večnosť. Navyše, ak sa poblízku štadióna nachádza podnik, v ktorom tiež čapujú pivo, ľudia sa mnohokrát rozhodnú ísť si radšej načapovať pivo tam, pretože je to pre nich mnohokrát výhodnejšie, najmä z finančného hľadiska. Štadión tým pádom stráca potencionálny zisk a naopak, pri malom počte ľudí zbytočne prepláca pracujúcich výčapníkov.

Divák vie, že na štadióne trvá čapovanie piva priemerne 2 minúty. Taktiež má zmeranú cestu do krčmy, ktorá trvá tam a späť 10 minút ( + v krčme čapujú pivo v priemere 3 minúty ). Ak je teda v rade na 1 výčapníka priemerne viac ako 6 ľudí, oplatí sa mu zájsť si po pivo do krčmy, pretože ušetrí minútu času. Ďalším faktorom by mohla byť cena piva, čo však v tejto simulácií nie je zakomponované.

== Cíl simulace ==

Nájsť otpimálny počet výčapov prihľiadnúc na počet ľudí na štadióne tak, aby sa minimalizovali straty od nedočkavých ľudí, ktorí si radšej zvolia konkurenčný výčap, avšak zachovať počet píp na čo najnižšom možnom čísle.

= Metóda =

Nasledujúce tabuľky približuje chovanie modelu a opisujú význam vybraných vstupných dát.

{| class="wikitable"
|+ align="top" | ''' Generovaní divákov '''
!| Názov entity || Názov schedule || Typ distribúcie || jednotka času || start/end
|-
| Fan || First real fans || Poi(20.0) || 1 minúta || 16:00 - 16:30
|-
| Fan || Normal real fans || Poi(30.0) || 1 minúta || 16:30 - 17:00
|-
| Beer guy || First Beer guys || Poi(15.0) || 1 minúta || 16:00 - 16:30
|-
| Beer guy || Normal Beer fans || Poi(10.0) || 1 minúta || 16:30 - 17:00
|-
|}

Pri generovaní fanúšikov som použil Poison Distribúciu, keďže entity sa generujú v krátkom časovom intervale, čo najlepšie vyhovuje mojmu prípadu, kedy sa snažím čo najrealistickejšie vystihnúť príchod fanúšikov na štadión.

{| class="wikitable"
|+ align="top" | ''' Vlastnosti divákov '''
!| Názov entity || Pravdepodobnosť zakúpenia piva ihneď po príchode || Dlžka sledovania zápasu do dalšieho piva (v minútach)
|-
| Fan || 0% || Tri(40,55,80)
|-
| Beer guy || 40% || Tri(30,40,60)
|-
|}

Hlavné rozdiely medzi pivármi a obyčajnými fanúšikmi je túžba po pive. Zatiaľ čo obyčajný fanúšik si nikdy pri vstupe nedá pivo, u pivára je až 40% šanca, že sa tak rozhodne. Na delay označujúci sledovanie zápasu som tentokrát použil Triangulovú distribúciu, čo je v tomto prípade lepšie ako Exponenciálna distribúcia, ktorá by tak dobre nevystihovala realitu, pretože v momentálnom modeli každí dostane chuť na pivo niekedy inokedy, a nie takmer všetci ľudia naraz ( v poradí ako prichádzali na štadión ) , ako by to bolo pri Exponenciálnej distribúcii.

=Model=

[[File:MainProcessHockeyMatchesBeersOptimalization.png]]

Hlavná obrazovka obsahuje hlavne Dynamic Labels, ktoré zjednodušujú pozorovanie simulácie. Generovanie fanúšika(Generate) je proces vysvetlený v tabuľke vyššie , Užívanie si zápasu(Process) je hlavný proces obsahujúci všetko potrebné na simulovanie hokejového zápasu a požiadaviek na pivo a Odchod domov(Dispose) simuluje odchod entity zo štadióna. Celá simulácia simuluje dátum 12.12.2018 s časom trvania 16:00 - 19:30 a približný výskyt divákov na zápase prvej slovenskej ligy v meste Prešov.

[[File:WatchTheGameProcessHockeyMatchesBeersOptimalization.png]]

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - DELAY '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Kupovanie lístkov''' || Delay || Exp(2.0)/Minutes || akcia entity kupovania lístkov, priemerná doba predaja sa nelíši podľa druhu fanúšika, takže pani pri okienku vybaví priemerna za 1 minútu 1 diváka || X
|-
| '''Čapovanie piva na štadióne''' || Delay || Exp(2.0)/Minutes || priemerná doba načapovania a predania jedného piva na štadióne ||
* Accept Entity : inkrementuje o 1 globálnu premenu modelu PeopleInQueue použitú pri rozhodvaní, kde si dá pivo
* Release Entity : dekrementuje o 1 globálnu premenu modelu PeopleInQueue a inkrementuje pomocnú premennú BeerSold
|-
| '''Čapovanie piva v krčme''' || Delay || Exp(3.0)/Minutes || priemerná doba načapovania a predania jedného piva v krčme trvá o minútu dlhšie ako na štadióne ||
* Release Entity : dekrementuje o 1 pomocnú premennú BeerLost
|-
| '''Sledovanie zápasu pivára''' || Delay || Tri(25,40,60)/Minutes || pivár si dá pivo v priemere každých 40 minút, avšak niekedy si ide po ďalšie pivo skôr, už po 25 minutách, no na druhej strane viac ako 60 minút nevydrží určite || X
|-
| '''Sledovanie zápasu fanúšika''' || Delay || Tri(40,60,80)/Minutes || divák si dá pivo v priemere každých 60 minút, avšak niekedy si ide po ďalšie pivo skôr, po 40 minutách, no na druhej strane viac ako 80 minút nevydrží určite || X
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - BRANCH '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Dám si pivo?''' || Branch || Entity type || prvá križovatka typu Entity type, čo znamená, že pre každý vychádzajúci konektor ( Connector) musí byť zvolený typ entity, obyčajný fanúšik si po príchode dá pivo s 0% pravdepodobnosťou, zatiaľ čo pivár stále váha || X
|-
| '''Rozhodujem sa...''' || Branch|| Probability || Beer Guy si buď dá pivo na 40%, alebo sa rozhodne ísť sa usadiť na miesto || X
|-
| '''Kde si dám pivo?''' || Branch|| Attribute || bez ohľadu na typ entity sa divák rozhoduje, či si dá pivo na štadióne, alebo si pôjde dať pivo do vedľajšieho pivovaru (výhoda krčmového pivovaru je popísaná v úvode) || X
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
| '''Idem domov?''' || Branch || Priority || divák sa rozhoduje, či si ešte dá pivo, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:05, čo znamená, že ak divák výjde na chodbu po 19:05, urobí tak pretože chce opustiť štadión a na pivo už neide, keďže zápas sa konči o pár minút
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - CONNECTOR '''
!| Názov || Názov nástroja || Typ distribúcie || Popis
|-
| '''Zatiaľ nie''' || Connector || Exp(4.0)/Minutes|| odpoveď určená pre entitu Fan, ktorej cestovanie (Travel Duration) trvá priemerne 4 minúty
|-
| '''Som pivár, obyčajný pivár''' || Connector || X || odpoveď určená pre entitu Beer Guy na otázku z Branche '''Dám si pivo?''', slúži iba ako pomocný konektor do ďalšej Branche
|-
| '''Jo!''' || Connector || Exp(5.0)/Minutes || kladná odpoveď na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 40%)
|-
| '''Nedám''' || Connector || Exp(4.0)/Minutes || negatívna odpoveď určená na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 60%)
|-
| '''Dám si ho tu!''' || Connector || Exp(30.0)/Seconds || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí počkať si v rade na pivo na štadióne
|-
| '''Idem do krčmy''' || Connector || Exp(5.0)/Minutes || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí ísť na pivo do konkurenčnej krčmy, ktorá je vzdialená priemerne 5 minút chôdze
|-
| '''Odchádzam''' || Connector || X || divákovi sa s načapovaným pivom neoplatí vracať po 19:00 (odpoveď v Branchi '''Oplatí sa mi ešte vracať?''')
|-
| '''Idem domov''' || Connector || X || divák ktorý vyšiel na chodbu po 19:00 už neide na pivo, ale domov (odpoveď v Branchi '''Idem domov?''')
|-
| '''Jedno ešte stíham :)''' || Connector || Exp(3.0)/Minutes || divák ktorý sa dostane na chodbu pred 19:00, si ide dať určite pivo (odpoveď v Branchi '''Idem domov?''')
|-
|}

=Výsledky=

Výsledky ukazujú 4 rôzne simulácie, ktoré boli spustené s nasledujúcimi nastaveniami

* ''' Počet píp : 40 '''
* ''' Max ľudí vo fronte : 40 '''

[[File:40accepted40pipes.png]]

----

* ''' Počet píp : 30 '''
* ''' Max ľudí vo fronte : 200 '''
[[File:200accepted30pipes.png]]

----

* ''' Počet píp : 30 '''
* ''' Max ľudí vo fronte : 500 '''
[[File:500accepted30pipes.png]]

----

* ''' Počet píp : 60 '''
* ''' Max ľudí vo fronte : 450 '''
[[File:420accepted50pipes.png]]

----

Ako môžeme vidieť, pri zmene píp a maximálneho počtu ľudí vo fronte ( čo v reále znamená že človeku sa z časového hľadiska oplatí ísť do krčmy, ak počet čakajúcich ľudí vo fronte je vyšší ako '''Max ľudí vo fronte''' / '''Počet píp''') nám stále uniká dosť veľký počet pív. Umelé zvyšovanie maximálneho počtu čakajúcich ľudí nám nepomôže, aj keď simulácia naozaj počíta s extrémnym prípadom, kedy by každý na štadióne vypil viac ako 1 pivo za zápas. Zároveň nezahrňuje ani možnosť objednávať viac pív naraz, čo tiež nie je veľmi praktické. Tento model teda obsahuje možnosti rozšírenia, no takáto profesionálna simulácia by si vyžiadala podstatne viac času. Pri súčasnom nastavení všetkých podmienok a experimentovaní iba s 2 parametrami je pre štadión optimálne riešenie, ak by mal okolo 60 píp, kedy by sa ľuďom z časového hľadiska vôbec neoplatilo chodiť po pivo do krčmy.

=Závěr=

Simulácia by sa dala rozšíriť o množstvo ďalších rozhodnutí, ako je napríklad potreba ísť na WC alebo zahrnúť skutočnosť, že by si ľudia v bufere mohli kúpiť aj niečo iné ako pivo. Pri mojom nastavení ani 40 píp na čapovanie nestačilo na to, aby štadíón nestrácal zisky (čo sa týka predaného piva, výčapníci a ich hodinová mzda v modeli zatiaľ chýba tiež) z divákov, ktorí chcú pivo v rovnaký čas. Naopak, otpimalizáciu prihľiadnúc na tento fakt by som považoval nasadenie 20 píp, kde by ale pracovníci nemali takmer žiaden oddych. Som rád, že som si nakoniec vybral Simprocess, pretože tento nástroj môže byť v budúcnosti veľmi žiadaný.

=Kód=
[[File:HockeyMatchesBeersOptimalization.spm]]

=Reference=
http://simprocess.com/Documentation/Windows_Manuals/SIMPROCESS_Getting_Started_Manual.pdf
http://simprocess.com/Documentation/SIMPROCESS_Expression_Demo_Models.pdf

File:500accepted30pipes.png

2019-06-17T16:32:08Z

Turd01:

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-17T16:30:05Z

Turd01: /* Výsledky */

== Zadání ==

'''Název simulace''': Simulace optímálneho počtu výčapov piva na štadióne

'''Autor''': Bc. Dominik Turák, turd01

'''Typ modelu''': Diskrétni simulace

'''Modelovací nástroj''': [http://simprocess.com/products/products.html SIMPROCESS]

== Popis Modelu ==

Na hokejových alebo futbalových zápasoch sa často stáva, že človek musí čakať na pivo v dlhom rade celú večnosť. Navyše, ak sa poblízku štadióna nachádza podnik, v ktorom tiež čapujú pivo, ľudia sa mnohokrát rozhodnú ísť si radšej načapovať pivo tam, pretože je to pre nich mnohokrát výhodnejšie, najmä z finančného hľadiska. Štadión tým pádom stráca potencionálny zisk a naopak, pri malom počte ľudí zbytočne prepláca pracujúcich výčapníkov.

Divák vie, že na štadióne trvá čapovanie piva priemerne 2 minúty. Taktiež má zmeranú cestu do krčmy, ktorá trvá tam a späť 10 minút ( + v krčme čapujú pivo v priemere 3 minúty ). Ak je teda v rade na 1 výčapníka priemerne viac ako 6 ľudí, oplatí sa mu zájsť si po pivo do krčmy, pretože ušetrí minútu času. Ďalším faktorom by mohla byť cena piva, čo však v tejto simulácií nie je zakomponované.

== Cíl simulace ==

Nájsť otpimálny počet výčapov prihľiadnúc na počet ľudí na štadióne tak, aby sa minimalizovali straty od nedočkavých ľudí, ktorí si radšej zvolia konkurenčný výčap, avšak zachovať počet píp na čo najnižšom možnom čísle.

= Metóda =

Nasledujúce tabuľky približuje chovanie modelu a opisujú význam vybraných vstupných dát.

{| class="wikitable"
|+ align="top" | ''' Generovaní divákov '''
!| Názov entity || Názov schedule || Typ distribúcie || jednotka času || start/end
|-
| Fan || First real fans || Poi(20.0) || 1 minúta || 16:00 - 16:30
|-
| Fan || Normal real fans || Poi(30.0) || 1 minúta || 16:30 - 17:00
|-
| Beer guy || First Beer guys || Poi(15.0) || 1 minúta || 16:00 - 16:30
|-
| Beer guy || Normal Beer fans || Poi(10.0) || 1 minúta || 16:30 - 17:00
|-
|}

Pri generovaní fanúšikov som použil Poison Distribúciu, keďže entity sa generujú v krátkom časovom intervale, čo najlepšie vyhovuje mojmu prípadu, kedy sa snažím čo najrealistickejšie vystihnúť príchod fanúšikov na štadión.

{| class="wikitable"
|+ align="top" | ''' Vlastnosti divákov '''
!| Názov entity || Pravdepodobnosť zakúpenia piva ihneď po príchode || Dlžka sledovania zápasu do dalšieho piva (v minútach)
|-
| Fan || 0% || Tri(40,55,80)
|-
| Beer guy || 40% || Tri(30,40,60)
|-
|}

Hlavné rozdiely medzi pivármi a obyčajnými fanúšikmi je túžba po pive. Zatiaľ čo obyčajný fanúšik si nikdy pri vstupe nedá pivo, u pivára je až 40% šanca, že sa tak rozhodne. Na delay označujúci sledovanie zápasu som tentokrát použil Triangulovú distribúciu, čo je v tomto prípade lepšie ako Exponenciálna distribúcia, ktorá by tak dobre nevystihovala realitu, pretože v momentálnom modeli každí dostane chuť na pivo niekedy inokedy, a nie takmer všetci ľudia naraz ( v poradí ako prichádzali na štadión ) , ako by to bolo pri Exponenciálnej distribúcii.

=Model=

[[File:MainProcessHockeyMatchesBeersOptimalization.png]]

Hlavná obrazovka obsahuje hlavne Dynamic Labels, ktoré zjednodušujú pozorovanie simulácie. Generovanie fanúšika(Generate) je proces vysvetlený v tabuľke vyššie , Užívanie si zápasu(Process) je hlavný proces obsahujúci všetko potrebné na simulovanie hokejového zápasu a požiadaviek na pivo a Odchod domov(Dispose) simuluje odchod entity zo štadióna. Celá simulácia simuluje dátum 12.12.2018 s časom trvania 16:00 - 19:30 a približný výskyt divákov na zápase prvej slovenskej ligy v meste Prešov.

[[File:WatchTheGameProcessHockeyMatchesBeersOptimalization.png]]

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - DELAY '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Kupovanie lístkov''' || Delay || Exp(2.0)/Minutes || akcia entity kupovania lístkov, priemerná doba predaja sa nelíši podľa druhu fanúšika, takže pani pri okienku vybaví priemerna za 1 minútu 1 diváka || X
|-
| '''Čapovanie piva na štadióne''' || Delay || Exp(2.0)/Minutes || priemerná doba načapovania a predania jedného piva na štadióne ||
* Accept Entity : inkrementuje o 1 globálnu premenu modelu PeopleInQueue použitú pri rozhodvaní, kde si dá pivo
* Release Entity : dekrementuje o 1 globálnu premenu modelu PeopleInQueue a inkrementuje pomocnú premennú BeerSold
|-
| '''Čapovanie piva v krčme''' || Delay || Exp(3.0)/Minutes || priemerná doba načapovania a predania jedného piva v krčme trvá o minútu dlhšie ako na štadióne ||
* Release Entity : dekrementuje o 1 pomocnú premennú BeerLost
|-
| '''Sledovanie zápasu pivára''' || Delay || Tri(25,40,60)/Minutes || pivár si dá pivo v priemere každých 40 minút, avšak niekedy si ide po ďalšie pivo skôr, už po 25 minutách, no na druhej strane viac ako 60 minút nevydrží určite || X
|-
| '''Sledovanie zápasu fanúšika''' || Delay || Tri(40,60,80)/Minutes || divák si dá pivo v priemere každých 60 minút, avšak niekedy si ide po ďalšie pivo skôr, po 40 minutách, no na druhej strane viac ako 80 minút nevydrží určite || X
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - BRANCH '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Dám si pivo?''' || Branch || Entity type || prvá križovatka typu Entity type, čo znamená, že pre každý vychádzajúci konektor ( Connector) musí byť zvolený typ entity, obyčajný fanúšik si po príchode dá pivo s 0% pravdepodobnosťou, zatiaľ čo pivár stále váha || X
|-
| '''Rozhodujem sa...''' || Branch|| Probability || Beer Guy si buď dá pivo na 40%, alebo sa rozhodne ísť sa usadiť na miesto || X
|-
| '''Kde si dám pivo?''' || Branch|| Attribute || bez ohľadu na typ entity sa divák rozhoduje, či si dá pivo na štadióne, alebo si pôjde dať pivo do vedľajšieho pivovaru (výhoda krčmového pivovaru je popísaná v úvode) || X
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
| '''Idem domov?''' || Branch || Priority || divák sa rozhoduje, či si ešte dá pivo, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:05, čo znamená, že ak divák výjde na chodbu po 19:05, urobí tak pretože chce opustiť štadión a na pivo už neide, keďže zápas sa konči o pár minút
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - CONNECTOR '''
!| Názov || Názov nástroja || Typ distribúcie || Popis
|-
| '''Zatiaľ nie''' || Connector || Exp(4.0)/Minutes|| odpoveď určená pre entitu Fan, ktorej cestovanie (Travel Duration) trvá priemerne 4 minúty
|-
| '''Som pivár, obyčajný pivár''' || Connector || X || odpoveď určená pre entitu Beer Guy na otázku z Branche '''Dám si pivo?''', slúži iba ako pomocný konektor do ďalšej Branche
|-
| '''Jo!''' || Connector || Exp(5.0)/Minutes || kladná odpoveď na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 40%)
|-
| '''Nedám''' || Connector || Exp(4.0)/Minutes || negatívna odpoveď určená na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 60%)
|-
| '''Dám si ho tu!''' || Connector || Exp(30.0)/Seconds || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí počkať si v rade na pivo na štadióne
|-
| '''Idem do krčmy''' || Connector || Exp(5.0)/Minutes || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí ísť na pivo do konkurenčnej krčmy, ktorá je vzdialená priemerne 5 minút chôdze
|-
| '''Odchádzam''' || Connector || X || divákovi sa s načapovaným pivom neoplatí vracať po 19:00 (odpoveď v Branchi '''Oplatí sa mi ešte vracať?''')
|-
| '''Idem domov''' || Connector || X || divák ktorý vyšiel na chodbu po 19:00 už neide na pivo, ale domov (odpoveď v Branchi '''Idem domov?''')
|-
| '''Jedno ešte stíham :)''' || Connector || Exp(3.0)/Minutes || divák ktorý sa dostane na chodbu pred 19:00, si ide dať určite pivo (odpoveď v Branchi '''Idem domov?''')
|-
|}

=Výsledky=

Výsledky ukazujú 4 rôzne simulácie, ktoré boli spustené s nasledujúcimi nastaveniami

* ''' Počet píp : 40 '''
* ''' Max ľudí vo fronte : 40 '''
[[File:40accepted40pipes.png]]

* ''' Počet píp : 30 '''
* ''' Max ľudí vo fronte : 200 '''
[[File:200accepted30pipes.png]]

* ''' Počet píp : 30 '''
* ''' Max ľudí vo fronte : 500 '''
[[File:200accepted30pipes.png]]

* ''' Počet píp : 50 '''
* ''' Max ľudí vo fronte : 350 '''
[[File:200accepted30pipes.png]]

=Závěr=

Simulácia by sa dala rozšíriť o množstvo ďalších rozhodnutí, ako je napríklad potreba ísť na WC alebo zahrnúť skutočnosť, že by si ľudia v bufere mohli kúpiť aj niečo iné ako pivo. Pri mojom nastavení ani 40 píp na čapovanie nestačilo na to, aby štadíón nestrácal zisky (čo sa týka predaného piva, výčapníci a ich hodinová mzda v modeli zatiaľ chýba tiež) z divákov, ktorí chcú pivo v rovnaký čas. Naopak, otpimalizáciu prihľiadnúc na tento fakt by som považoval nasadenie 20 píp, kde by ale pracovníci nemali takmer žiaden oddych. Som rád, že som si nakoniec vybral Simprocess, pretože tento nástroj môže byť v budúcnosti veľmi žiadaný.

=Kód=
[[File:HockeyMatchesBeersOptimalization.spm]]

=Reference=
http://simprocess.com/Documentation/Windows_Manuals/SIMPROCESS_Getting_Started_Manual.pdf
http://simprocess.com/Documentation/SIMPROCESS_Expression_Demo_Models.pdf

File:200accepted30pipes.png

2019-06-17T16:28:00Z

Turd01:

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-17T16:25:59Z

Turd01: /* Výsledky */

== Zadání ==

'''Název simulace''': Simulace optímálneho počtu výčapov piva na štadióne

'''Autor''': Bc. Dominik Turák, turd01

'''Typ modelu''': Diskrétni simulace

'''Modelovací nástroj''': [http://simprocess.com/products/products.html SIMPROCESS]

== Popis Modelu ==

Na hokejových alebo futbalových zápasoch sa často stáva, že človek musí čakať na pivo v dlhom rade celú večnosť. Navyše, ak sa poblízku štadióna nachádza podnik, v ktorom tiež čapujú pivo, ľudia sa mnohokrát rozhodnú ísť si radšej načapovať pivo tam, pretože je to pre nich mnohokrát výhodnejšie, najmä z finančného hľadiska. Štadión tým pádom stráca potencionálny zisk a naopak, pri malom počte ľudí zbytočne prepláca pracujúcich výčapníkov.

Divák vie, že na štadióne trvá čapovanie piva priemerne 2 minúty. Taktiež má zmeranú cestu do krčmy, ktorá trvá tam a späť 10 minút ( + v krčme čapujú pivo v priemere 3 minúty ). Ak je teda v rade na 1 výčapníka priemerne viac ako 6 ľudí, oplatí sa mu zájsť si po pivo do krčmy, pretože ušetrí minútu času. Ďalším faktorom by mohla byť cena piva, čo však v tejto simulácií nie je zakomponované.

== Cíl simulace ==

Nájsť otpimálny počet výčapov prihľiadnúc na počet ľudí na štadióne tak, aby sa minimalizovali straty od nedočkavých ľudí, ktorí si radšej zvolia konkurenčný výčap, avšak zachovať počet píp na čo najnižšom možnom čísle.

= Metóda =

Nasledujúce tabuľky približuje chovanie modelu a opisujú význam vybraných vstupných dát.

{| class="wikitable"
|+ align="top" | ''' Generovaní divákov '''
!| Názov entity || Názov schedule || Typ distribúcie || jednotka času || start/end
|-
| Fan || First real fans || Poi(20.0) || 1 minúta || 16:00 - 16:30
|-
| Fan || Normal real fans || Poi(30.0) || 1 minúta || 16:30 - 17:00
|-
| Beer guy || First Beer guys || Poi(15.0) || 1 minúta || 16:00 - 16:30
|-
| Beer guy || Normal Beer fans || Poi(10.0) || 1 minúta || 16:30 - 17:00
|-
|}

Pri generovaní fanúšikov som použil Poison Distribúciu, keďže entity sa generujú v krátkom časovom intervale, čo najlepšie vyhovuje mojmu prípadu, kedy sa snažím čo najrealistickejšie vystihnúť príchod fanúšikov na štadión.

{| class="wikitable"
|+ align="top" | ''' Vlastnosti divákov '''
!| Názov entity || Pravdepodobnosť zakúpenia piva ihneď po príchode || Dlžka sledovania zápasu do dalšieho piva (v minútach)
|-
| Fan || 0% || Tri(40,55,80)
|-
| Beer guy || 40% || Tri(30,40,60)
|-
|}

Hlavné rozdiely medzi pivármi a obyčajnými fanúšikmi je túžba po pive. Zatiaľ čo obyčajný fanúšik si nikdy pri vstupe nedá pivo, u pivára je až 40% šanca, že sa tak rozhodne. Na delay označujúci sledovanie zápasu som tentokrát použil Triangulovú distribúciu, čo je v tomto prípade lepšie ako Exponenciálna distribúcia, ktorá by tak dobre nevystihovala realitu, pretože v momentálnom modeli každí dostane chuť na pivo niekedy inokedy, a nie takmer všetci ľudia naraz ( v poradí ako prichádzali na štadión ) , ako by to bolo pri Exponenciálnej distribúcii.

=Model=

[[File:MainProcessHockeyMatchesBeersOptimalization.png]]

Hlavná obrazovka obsahuje hlavne Dynamic Labels, ktoré zjednodušujú pozorovanie simulácie. Generovanie fanúšika(Generate) je proces vysvetlený v tabuľke vyššie , Užívanie si zápasu(Process) je hlavný proces obsahujúci všetko potrebné na simulovanie hokejového zápasu a požiadaviek na pivo a Odchod domov(Dispose) simuluje odchod entity zo štadióna. Celá simulácia simuluje dátum 12.12.2018 s časom trvania 16:00 - 19:30 a približný výskyt divákov na zápase prvej slovenskej ligy v meste Prešov.

[[File:WatchTheGameProcessHockeyMatchesBeersOptimalization.png]]

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - DELAY '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Kupovanie lístkov''' || Delay || Exp(2.0)/Minutes || akcia entity kupovania lístkov, priemerná doba predaja sa nelíši podľa druhu fanúšika, takže pani pri okienku vybaví priemerna za 1 minútu 1 diváka || X
|-
| '''Čapovanie piva na štadióne''' || Delay || Exp(2.0)/Minutes || priemerná doba načapovania a predania jedného piva na štadióne ||
* Accept Entity : inkrementuje o 1 globálnu premenu modelu PeopleInQueue použitú pri rozhodvaní, kde si dá pivo
* Release Entity : dekrementuje o 1 globálnu premenu modelu PeopleInQueue a inkrementuje pomocnú premennú BeerSold
|-
| '''Čapovanie piva v krčme''' || Delay || Exp(3.0)/Minutes || priemerná doba načapovania a predania jedného piva v krčme trvá o minútu dlhšie ako na štadióne ||
* Release Entity : dekrementuje o 1 pomocnú premennú BeerLost
|-
| '''Sledovanie zápasu pivára''' || Delay || Tri(25,40,60)/Minutes || pivár si dá pivo v priemere každých 40 minút, avšak niekedy si ide po ďalšie pivo skôr, už po 25 minutách, no na druhej strane viac ako 60 minút nevydrží určite || X
|-
| '''Sledovanie zápasu fanúšika''' || Delay || Tri(40,60,80)/Minutes || divák si dá pivo v priemere každých 60 minút, avšak niekedy si ide po ďalšie pivo skôr, po 40 minutách, no na druhej strane viac ako 80 minút nevydrží určite || X
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - BRANCH '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Dám si pivo?''' || Branch || Entity type || prvá križovatka typu Entity type, čo znamená, že pre každý vychádzajúci konektor ( Connector) musí byť zvolený typ entity, obyčajný fanúšik si po príchode dá pivo s 0% pravdepodobnosťou, zatiaľ čo pivár stále váha || X
|-
| '''Rozhodujem sa...''' || Branch|| Probability || Beer Guy si buď dá pivo na 40%, alebo sa rozhodne ísť sa usadiť na miesto || X
|-
| '''Kde si dám pivo?''' || Branch|| Attribute || bez ohľadu na typ entity sa divák rozhoduje, či si dá pivo na štadióne, alebo si pôjde dať pivo do vedľajšieho pivovaru (výhoda krčmového pivovaru je popísaná v úvode) || X
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
| '''Idem domov?''' || Branch || Priority || divák sa rozhoduje, či si ešte dá pivo, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:05, čo znamená, že ak divák výjde na chodbu po 19:05, urobí tak pretože chce opustiť štadión a na pivo už neide, keďže zápas sa konči o pár minút
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - CONNECTOR '''
!| Názov || Názov nástroja || Typ distribúcie || Popis
|-
| '''Zatiaľ nie''' || Connector || Exp(4.0)/Minutes|| odpoveď určená pre entitu Fan, ktorej cestovanie (Travel Duration) trvá priemerne 4 minúty
|-
| '''Som pivár, obyčajný pivár''' || Connector || X || odpoveď určená pre entitu Beer Guy na otázku z Branche '''Dám si pivo?''', slúži iba ako pomocný konektor do ďalšej Branche
|-
| '''Jo!''' || Connector || Exp(5.0)/Minutes || kladná odpoveď na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 40%)
|-
| '''Nedám''' || Connector || Exp(4.0)/Minutes || negatívna odpoveď určená na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 60%)
|-
| '''Dám si ho tu!''' || Connector || Exp(30.0)/Seconds || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí počkať si v rade na pivo na štadióne
|-
| '''Idem do krčmy''' || Connector || Exp(5.0)/Minutes || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí ísť na pivo do konkurenčnej krčmy, ktorá je vzdialená priemerne 5 minút chôdze
|-
| '''Odchádzam''' || Connector || X || divákovi sa s načapovaným pivom neoplatí vracať po 19:00 (odpoveď v Branchi '''Oplatí sa mi ešte vracať?''')
|-
| '''Idem domov''' || Connector || X || divák ktorý vyšiel na chodbu po 19:00 už neide na pivo, ale domov (odpoveď v Branchi '''Idem domov?''')
|-
| '''Jedno ešte stíham :)''' || Connector || Exp(3.0)/Minutes || divák ktorý sa dostane na chodbu pred 19:00, si ide dať určite pivo (odpoveď v Branchi '''Idem domov?''')
|-
|}

=Výsledky=

Výsledky ukazujú 4 rôzne simulácie, ktoré boli spustené s nasledujúcimi nastaveniami

* ''' Počet píp : 40 '''
* ''' Max ľudí vo fronte : 40 '''
[[File:40accepted40pipes.png]]

=Závěr=

Simulácia by sa dala rozšíriť o množstvo ďalších rozhodnutí, ako je napríklad potreba ísť na WC alebo zahrnúť skutočnosť, že by si ľudia v bufere mohli kúpiť aj niečo iné ako pivo. Pri mojom nastavení ani 40 píp na čapovanie nestačilo na to, aby štadíón nestrácal zisky (čo sa týka predaného piva, výčapníci a ich hodinová mzda v modeli zatiaľ chýba tiež) z divákov, ktorí chcú pivo v rovnaký čas. Naopak, otpimalizáciu prihľiadnúc na tento fakt by som považoval nasadenie 20 píp, kde by ale pracovníci nemali takmer žiaden oddych. Som rád, že som si nakoniec vybral Simprocess, pretože tento nástroj môže byť v budúcnosti veľmi žiadaný.

=Kód=
[[File:HockeyMatchesBeersOptimalization.spm]]

=Reference=
http://simprocess.com/Documentation/Windows_Manuals/SIMPROCESS_Getting_Started_Manual.pdf
http://simprocess.com/Documentation/SIMPROCESS_Expression_Demo_Models.pdf

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-17T16:25:49Z

Turd01: /* Výsledky */

== Zadání ==

'''Název simulace''': Simulace optímálneho počtu výčapov piva na štadióne

'''Autor''': Bc. Dominik Turák, turd01

'''Typ modelu''': Diskrétni simulace

'''Modelovací nástroj''': [http://simprocess.com/products/products.html SIMPROCESS]

== Popis Modelu ==

Na hokejových alebo futbalových zápasoch sa často stáva, že človek musí čakať na pivo v dlhom rade celú večnosť. Navyše, ak sa poblízku štadióna nachádza podnik, v ktorom tiež čapujú pivo, ľudia sa mnohokrát rozhodnú ísť si radšej načapovať pivo tam, pretože je to pre nich mnohokrát výhodnejšie, najmä z finančného hľadiska. Štadión tým pádom stráca potencionálny zisk a naopak, pri malom počte ľudí zbytočne prepláca pracujúcich výčapníkov.

Divák vie, že na štadióne trvá čapovanie piva priemerne 2 minúty. Taktiež má zmeranú cestu do krčmy, ktorá trvá tam a späť 10 minút ( + v krčme čapujú pivo v priemere 3 minúty ). Ak je teda v rade na 1 výčapníka priemerne viac ako 6 ľudí, oplatí sa mu zájsť si po pivo do krčmy, pretože ušetrí minútu času. Ďalším faktorom by mohla byť cena piva, čo však v tejto simulácií nie je zakomponované.

== Cíl simulace ==

Nájsť otpimálny počet výčapov prihľiadnúc na počet ľudí na štadióne tak, aby sa minimalizovali straty od nedočkavých ľudí, ktorí si radšej zvolia konkurenčný výčap, avšak zachovať počet píp na čo najnižšom možnom čísle.

= Metóda =

Nasledujúce tabuľky približuje chovanie modelu a opisujú význam vybraných vstupných dát.

{| class="wikitable"
|+ align="top" | ''' Generovaní divákov '''
!| Názov entity || Názov schedule || Typ distribúcie || jednotka času || start/end
|-
| Fan || First real fans || Poi(20.0) || 1 minúta || 16:00 - 16:30
|-
| Fan || Normal real fans || Poi(30.0) || 1 minúta || 16:30 - 17:00
|-
| Beer guy || First Beer guys || Poi(15.0) || 1 minúta || 16:00 - 16:30
|-
| Beer guy || Normal Beer fans || Poi(10.0) || 1 minúta || 16:30 - 17:00
|-
|}

Pri generovaní fanúšikov som použil Poison Distribúciu, keďže entity sa generujú v krátkom časovom intervale, čo najlepšie vyhovuje mojmu prípadu, kedy sa snažím čo najrealistickejšie vystihnúť príchod fanúšikov na štadión.

{| class="wikitable"
|+ align="top" | ''' Vlastnosti divákov '''
!| Názov entity || Pravdepodobnosť zakúpenia piva ihneď po príchode || Dlžka sledovania zápasu do dalšieho piva (v minútach)
|-
| Fan || 0% || Tri(40,55,80)
|-
| Beer guy || 40% || Tri(30,40,60)
|-
|}

Hlavné rozdiely medzi pivármi a obyčajnými fanúšikmi je túžba po pive. Zatiaľ čo obyčajný fanúšik si nikdy pri vstupe nedá pivo, u pivára je až 40% šanca, že sa tak rozhodne. Na delay označujúci sledovanie zápasu som tentokrát použil Triangulovú distribúciu, čo je v tomto prípade lepšie ako Exponenciálna distribúcia, ktorá by tak dobre nevystihovala realitu, pretože v momentálnom modeli každí dostane chuť na pivo niekedy inokedy, a nie takmer všetci ľudia naraz ( v poradí ako prichádzali na štadión ) , ako by to bolo pri Exponenciálnej distribúcii.

=Model=

[[File:MainProcessHockeyMatchesBeersOptimalization.png]]

Hlavná obrazovka obsahuje hlavne Dynamic Labels, ktoré zjednodušujú pozorovanie simulácie. Generovanie fanúšika(Generate) je proces vysvetlený v tabuľke vyššie , Užívanie si zápasu(Process) je hlavný proces obsahujúci všetko potrebné na simulovanie hokejového zápasu a požiadaviek na pivo a Odchod domov(Dispose) simuluje odchod entity zo štadióna. Celá simulácia simuluje dátum 12.12.2018 s časom trvania 16:00 - 19:30 a približný výskyt divákov na zápase prvej slovenskej ligy v meste Prešov.

[[File:WatchTheGameProcessHockeyMatchesBeersOptimalization.png]]

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - DELAY '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Kupovanie lístkov''' || Delay || Exp(2.0)/Minutes || akcia entity kupovania lístkov, priemerná doba predaja sa nelíši podľa druhu fanúšika, takže pani pri okienku vybaví priemerna za 1 minútu 1 diváka || X
|-
| '''Čapovanie piva na štadióne''' || Delay || Exp(2.0)/Minutes || priemerná doba načapovania a predania jedného piva na štadióne ||
* Accept Entity : inkrementuje o 1 globálnu premenu modelu PeopleInQueue použitú pri rozhodvaní, kde si dá pivo
* Release Entity : dekrementuje o 1 globálnu premenu modelu PeopleInQueue a inkrementuje pomocnú premennú BeerSold
|-
| '''Čapovanie piva v krčme''' || Delay || Exp(3.0)/Minutes || priemerná doba načapovania a predania jedného piva v krčme trvá o minútu dlhšie ako na štadióne ||
* Release Entity : dekrementuje o 1 pomocnú premennú BeerLost
|-
| '''Sledovanie zápasu pivára''' || Delay || Tri(25,40,60)/Minutes || pivár si dá pivo v priemere každých 40 minút, avšak niekedy si ide po ďalšie pivo skôr, už po 25 minutách, no na druhej strane viac ako 60 minút nevydrží určite || X
|-
| '''Sledovanie zápasu fanúšika''' || Delay || Tri(40,60,80)/Minutes || divák si dá pivo v priemere každých 60 minút, avšak niekedy si ide po ďalšie pivo skôr, po 40 minutách, no na druhej strane viac ako 80 minút nevydrží určite || X
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - BRANCH '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Dám si pivo?''' || Branch || Entity type || prvá križovatka typu Entity type, čo znamená, že pre každý vychádzajúci konektor ( Connector) musí byť zvolený typ entity, obyčajný fanúšik si po príchode dá pivo s 0% pravdepodobnosťou, zatiaľ čo pivár stále váha || X
|-
| '''Rozhodujem sa...''' || Branch|| Probability || Beer Guy si buď dá pivo na 40%, alebo sa rozhodne ísť sa usadiť na miesto || X
|-
| '''Kde si dám pivo?''' || Branch|| Attribute || bez ohľadu na typ entity sa divák rozhoduje, či si dá pivo na štadióne, alebo si pôjde dať pivo do vedľajšieho pivovaru (výhoda krčmového pivovaru je popísaná v úvode) || X
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
| '''Idem domov?''' || Branch || Priority || divák sa rozhoduje, či si ešte dá pivo, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:05, čo znamená, že ak divák výjde na chodbu po 19:05, urobí tak pretože chce opustiť štadión a na pivo už neide, keďže zápas sa konči o pár minút
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - CONNECTOR '''
!| Názov || Názov nástroja || Typ distribúcie || Popis
|-
| '''Zatiaľ nie''' || Connector || Exp(4.0)/Minutes|| odpoveď určená pre entitu Fan, ktorej cestovanie (Travel Duration) trvá priemerne 4 minúty
|-
| '''Som pivár, obyčajný pivár''' || Connector || X || odpoveď určená pre entitu Beer Guy na otázku z Branche '''Dám si pivo?''', slúži iba ako pomocný konektor do ďalšej Branche
|-
| '''Jo!''' || Connector || Exp(5.0)/Minutes || kladná odpoveď na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 40%)
|-
| '''Nedám''' || Connector || Exp(4.0)/Minutes || negatívna odpoveď určená na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 60%)
|-
| '''Dám si ho tu!''' || Connector || Exp(30.0)/Seconds || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí počkať si v rade na pivo na štadióne
|-
| '''Idem do krčmy''' || Connector || Exp(5.0)/Minutes || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí ísť na pivo do konkurenčnej krčmy, ktorá je vzdialená priemerne 5 minút chôdze
|-
| '''Odchádzam''' || Connector || X || divákovi sa s načapovaným pivom neoplatí vracať po 19:00 (odpoveď v Branchi '''Oplatí sa mi ešte vracať?''')
|-
| '''Idem domov''' || Connector || X || divák ktorý vyšiel na chodbu po 19:00 už neide na pivo, ale domov (odpoveď v Branchi '''Idem domov?''')
|-
| '''Jedno ešte stíham :)''' || Connector || Exp(3.0)/Minutes || divák ktorý sa dostane na chodbu pred 19:00, si ide dať určite pivo (odpoveď v Branchi '''Idem domov?''')
|-
|}

=Výsledky=

Výsledky ukazujú 4 rôzne simulácie, ktoré boli spustené s nasledujúcimi nastaveniami

* ''' Počet píp : 40 '''
* ''' Max ľudí vo fronte : 40 '''
[[File:40accepted40pipes.png.png]]

=Závěr=

Simulácia by sa dala rozšíriť o množstvo ďalších rozhodnutí, ako je napríklad potreba ísť na WC alebo zahrnúť skutočnosť, že by si ľudia v bufere mohli kúpiť aj niečo iné ako pivo. Pri mojom nastavení ani 40 píp na čapovanie nestačilo na to, aby štadíón nestrácal zisky (čo sa týka predaného piva, výčapníci a ich hodinová mzda v modeli zatiaľ chýba tiež) z divákov, ktorí chcú pivo v rovnaký čas. Naopak, otpimalizáciu prihľiadnúc na tento fakt by som považoval nasadenie 20 píp, kde by ale pracovníci nemali takmer žiaden oddych. Som rád, že som si nakoniec vybral Simprocess, pretože tento nástroj môže byť v budúcnosti veľmi žiadaný.

=Kód=
[[File:HockeyMatchesBeersOptimalization.spm]]

=Reference=
http://simprocess.com/Documentation/Windows_Manuals/SIMPROCESS_Getting_Started_Manual.pdf
http://simprocess.com/Documentation/SIMPROCESS_Expression_Demo_Models.pdf

File:40accepted40pipes.png

2019-06-17T16:25:27Z

Turd01:

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-17T16:23:11Z

Turd01: /* Výsledky */

== Zadání ==

'''Název simulace''': Simulace optímálneho počtu výčapov piva na štadióne

'''Autor''': Bc. Dominik Turák, turd01

'''Typ modelu''': Diskrétni simulace

'''Modelovací nástroj''': [http://simprocess.com/products/products.html SIMPROCESS]

== Popis Modelu ==

Na hokejových alebo futbalových zápasoch sa často stáva, že človek musí čakať na pivo v dlhom rade celú večnosť. Navyše, ak sa poblízku štadióna nachádza podnik, v ktorom tiež čapujú pivo, ľudia sa mnohokrát rozhodnú ísť si radšej načapovať pivo tam, pretože je to pre nich mnohokrát výhodnejšie, najmä z finančného hľadiska. Štadión tým pádom stráca potencionálny zisk a naopak, pri malom počte ľudí zbytočne prepláca pracujúcich výčapníkov.

Divák vie, že na štadióne trvá čapovanie piva priemerne 2 minúty. Taktiež má zmeranú cestu do krčmy, ktorá trvá tam a späť 10 minút ( + v krčme čapujú pivo v priemere 3 minúty ). Ak je teda v rade na 1 výčapníka priemerne viac ako 6 ľudí, oplatí sa mu zájsť si po pivo do krčmy, pretože ušetrí minútu času. Ďalším faktorom by mohla byť cena piva, čo však v tejto simulácií nie je zakomponované.

== Cíl simulace ==

Nájsť otpimálny počet výčapov prihľiadnúc na počet ľudí na štadióne tak, aby sa minimalizovali straty od nedočkavých ľudí, ktorí si radšej zvolia konkurenčný výčap, avšak zachovať počet píp na čo najnižšom možnom čísle.

= Metóda =

Nasledujúce tabuľky približuje chovanie modelu a opisujú význam vybraných vstupných dát.

{| class="wikitable"
|+ align="top" | ''' Generovaní divákov '''
!| Názov entity || Názov schedule || Typ distribúcie || jednotka času || start/end
|-
| Fan || First real fans || Poi(20.0) || 1 minúta || 16:00 - 16:30
|-
| Fan || Normal real fans || Poi(30.0) || 1 minúta || 16:30 - 17:00
|-
| Beer guy || First Beer guys || Poi(15.0) || 1 minúta || 16:00 - 16:30
|-
| Beer guy || Normal Beer fans || Poi(10.0) || 1 minúta || 16:30 - 17:00
|-
|}

Pri generovaní fanúšikov som použil Poison Distribúciu, keďže entity sa generujú v krátkom časovom intervale, čo najlepšie vyhovuje mojmu prípadu, kedy sa snažím čo najrealistickejšie vystihnúť príchod fanúšikov na štadión.

{| class="wikitable"
|+ align="top" | ''' Vlastnosti divákov '''
!| Názov entity || Pravdepodobnosť zakúpenia piva ihneď po príchode || Dlžka sledovania zápasu do dalšieho piva (v minútach)
|-
| Fan || 0% || Tri(40,55,80)
|-
| Beer guy || 40% || Tri(30,40,60)
|-
|}

Hlavné rozdiely medzi pivármi a obyčajnými fanúšikmi je túžba po pive. Zatiaľ čo obyčajný fanúšik si nikdy pri vstupe nedá pivo, u pivára je až 40% šanca, že sa tak rozhodne. Na delay označujúci sledovanie zápasu som tentokrát použil Triangulovú distribúciu, čo je v tomto prípade lepšie ako Exponenciálna distribúcia, ktorá by tak dobre nevystihovala realitu, pretože v momentálnom modeli každí dostane chuť na pivo niekedy inokedy, a nie takmer všetci ľudia naraz ( v poradí ako prichádzali na štadión ) , ako by to bolo pri Exponenciálnej distribúcii.

=Model=

[[File:MainProcessHockeyMatchesBeersOptimalization.png]]

Hlavná obrazovka obsahuje hlavne Dynamic Labels, ktoré zjednodušujú pozorovanie simulácie. Generovanie fanúšika(Generate) je proces vysvetlený v tabuľke vyššie , Užívanie si zápasu(Process) je hlavný proces obsahujúci všetko potrebné na simulovanie hokejového zápasu a požiadaviek na pivo a Odchod domov(Dispose) simuluje odchod entity zo štadióna. Celá simulácia simuluje dátum 12.12.2018 s časom trvania 16:00 - 19:30 a približný výskyt divákov na zápase prvej slovenskej ligy v meste Prešov.

[[File:WatchTheGameProcessHockeyMatchesBeersOptimalization.png]]

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - DELAY '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Kupovanie lístkov''' || Delay || Exp(2.0)/Minutes || akcia entity kupovania lístkov, priemerná doba predaja sa nelíši podľa druhu fanúšika, takže pani pri okienku vybaví priemerna za 1 minútu 1 diváka || X
|-
| '''Čapovanie piva na štadióne''' || Delay || Exp(2.0)/Minutes || priemerná doba načapovania a predania jedného piva na štadióne ||
* Accept Entity : inkrementuje o 1 globálnu premenu modelu PeopleInQueue použitú pri rozhodvaní, kde si dá pivo
* Release Entity : dekrementuje o 1 globálnu premenu modelu PeopleInQueue a inkrementuje pomocnú premennú BeerSold
|-
| '''Čapovanie piva v krčme''' || Delay || Exp(3.0)/Minutes || priemerná doba načapovania a predania jedného piva v krčme trvá o minútu dlhšie ako na štadióne ||
* Release Entity : dekrementuje o 1 pomocnú premennú BeerLost
|-
| '''Sledovanie zápasu pivára''' || Delay || Tri(25,40,60)/Minutes || pivár si dá pivo v priemere každých 40 minút, avšak niekedy si ide po ďalšie pivo skôr, už po 25 minutách, no na druhej strane viac ako 60 minút nevydrží určite || X
|-
| '''Sledovanie zápasu fanúšika''' || Delay || Tri(40,60,80)/Minutes || divák si dá pivo v priemere každých 60 minút, avšak niekedy si ide po ďalšie pivo skôr, po 40 minutách, no na druhej strane viac ako 80 minút nevydrží určite || X
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - BRANCH '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Dám si pivo?''' || Branch || Entity type || prvá križovatka typu Entity type, čo znamená, že pre každý vychádzajúci konektor ( Connector) musí byť zvolený typ entity, obyčajný fanúšik si po príchode dá pivo s 0% pravdepodobnosťou, zatiaľ čo pivár stále váha || X
|-
| '''Rozhodujem sa...''' || Branch|| Probability || Beer Guy si buď dá pivo na 40%, alebo sa rozhodne ísť sa usadiť na miesto || X
|-
| '''Kde si dám pivo?''' || Branch|| Attribute || bez ohľadu na typ entity sa divák rozhoduje, či si dá pivo na štadióne, alebo si pôjde dať pivo do vedľajšieho pivovaru (výhoda krčmového pivovaru je popísaná v úvode) || X
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
| '''Idem domov?''' || Branch || Priority || divák sa rozhoduje, či si ešte dá pivo, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:05, čo znamená, že ak divák výjde na chodbu po 19:05, urobí tak pretože chce opustiť štadión a na pivo už neide, keďže zápas sa konči o pár minút
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - CONNECTOR '''
!| Názov || Názov nástroja || Typ distribúcie || Popis
|-
| '''Zatiaľ nie''' || Connector || Exp(4.0)/Minutes|| odpoveď určená pre entitu Fan, ktorej cestovanie (Travel Duration) trvá priemerne 4 minúty
|-
| '''Som pivár, obyčajný pivár''' || Connector || X || odpoveď určená pre entitu Beer Guy na otázku z Branche '''Dám si pivo?''', slúži iba ako pomocný konektor do ďalšej Branche
|-
| '''Jo!''' || Connector || Exp(5.0)/Minutes || kladná odpoveď na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 40%)
|-
| '''Nedám''' || Connector || Exp(4.0)/Minutes || negatívna odpoveď určená na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 60%)
|-
| '''Dám si ho tu!''' || Connector || Exp(30.0)/Seconds || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí počkať si v rade na pivo na štadióne
|-
| '''Idem do krčmy''' || Connector || Exp(5.0)/Minutes || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí ísť na pivo do konkurenčnej krčmy, ktorá je vzdialená priemerne 5 minút chôdze
|-
| '''Odchádzam''' || Connector || X || divákovi sa s načapovaným pivom neoplatí vracať po 19:00 (odpoveď v Branchi '''Oplatí sa mi ešte vracať?''')
|-
| '''Idem domov''' || Connector || X || divák ktorý vyšiel na chodbu po 19:00 už neide na pivo, ale domov (odpoveď v Branchi '''Idem domov?''')
|-
| '''Jedno ešte stíham :)''' || Connector || Exp(3.0)/Minutes || divák ktorý sa dostane na chodbu pred 19:00, si ide dať určite pivo (odpoveď v Branchi '''Idem domov?''')
|-
|}

=Výsledky=

Výsledky ukazujú 4 rôzne simulácie, ktoré boli spustené s nasledujúcimi nastaveniami

''' Počet píp : 40 '''
''' Max ľudí vo fronte : 40 '''

=Závěr=

Simulácia by sa dala rozšíriť o množstvo ďalších rozhodnutí, ako je napríklad potreba ísť na WC alebo zahrnúť skutočnosť, že by si ľudia v bufere mohli kúpiť aj niečo iné ako pivo. Pri mojom nastavení ani 40 píp na čapovanie nestačilo na to, aby štadíón nestrácal zisky (čo sa týka predaného piva, výčapníci a ich hodinová mzda v modeli zatiaľ chýba tiež) z divákov, ktorí chcú pivo v rovnaký čas. Naopak, otpimalizáciu prihľiadnúc na tento fakt by som považoval nasadenie 20 píp, kde by ale pracovníci nemali takmer žiaden oddych. Som rád, že som si nakoniec vybral Simprocess, pretože tento nástroj môže byť v budúcnosti veľmi žiadaný.

=Kód=
[[File:HockeyMatchesBeersOptimalization.spm]]

=Reference=
http://simprocess.com/Documentation/Windows_Manuals/SIMPROCESS_Getting_Started_Manual.pdf
http://simprocess.com/Documentation/SIMPROCESS_Expression_Demo_Models.pdf

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-17T15:48:40Z

Turd01: /* Popis Modelu */

== Zadání ==

'''Název simulace''': Simulace optímálneho počtu výčapov piva na štadióne

'''Autor''': Bc. Dominik Turák, turd01

'''Typ modelu''': Diskrétni simulace

'''Modelovací nástroj''': [http://simprocess.com/products/products.html SIMPROCESS]

== Popis Modelu ==

Na hokejových alebo futbalových zápasoch sa často stáva, že človek musí čakať na pivo v dlhom rade celú večnosť. Navyše, ak sa poblízku štadióna nachádza podnik, v ktorom tiež čapujú pivo, ľudia sa mnohokrát rozhodnú ísť si radšej načapovať pivo tam, pretože je to pre nich mnohokrát výhodnejšie, najmä z finančného hľadiska. Štadión tým pádom stráca potencionálny zisk a naopak, pri malom počte ľudí zbytočne prepláca pracujúcich výčapníkov.

Divák vie, že na štadióne trvá čapovanie piva priemerne 2 minúty. Taktiež má zmeranú cestu do krčmy, ktorá trvá tam a späť 10 minút ( + v krčme čapujú pivo v priemere 3 minúty ). Ak je teda v rade na 1 výčapníka priemerne viac ako 6 ľudí, oplatí sa mu zájsť si po pivo do krčmy, pretože ušetrí minútu času. Ďalším faktorom by mohla byť cena piva, čo však v tejto simulácií nie je zakomponované.

== Cíl simulace ==

Nájsť otpimálny počet výčapov prihľiadnúc na počet ľudí na štadióne tak, aby sa minimalizovali straty od nedočkavých ľudí, ktorí si radšej zvolia konkurenčný výčap, avšak zachovať počet píp na čo najnižšom možnom čísle.

= Metóda =

Nasledujúce tabuľky približuje chovanie modelu a opisujú význam vybraných vstupných dát.

{| class="wikitable"
|+ align="top" | ''' Generovaní divákov '''
!| Názov entity || Názov schedule || Typ distribúcie || jednotka času || start/end
|-
| Fan || First real fans || Poi(20.0) || 1 minúta || 16:00 - 16:30
|-
| Fan || Normal real fans || Poi(30.0) || 1 minúta || 16:30 - 17:00
|-
| Beer guy || First Beer guys || Poi(15.0) || 1 minúta || 16:00 - 16:30
|-
| Beer guy || Normal Beer fans || Poi(10.0) || 1 minúta || 16:30 - 17:00
|-
|}

Pri generovaní fanúšikov som použil Poison Distribúciu, keďže entity sa generujú v krátkom časovom intervale, čo najlepšie vyhovuje mojmu prípadu, kedy sa snažím čo najrealistickejšie vystihnúť príchod fanúšikov na štadión.

{| class="wikitable"
|+ align="top" | ''' Vlastnosti divákov '''
!| Názov entity || Pravdepodobnosť zakúpenia piva ihneď po príchode || Dlžka sledovania zápasu do dalšieho piva (v minútach)
|-
| Fan || 0% || Tri(40,55,80)
|-
| Beer guy || 40% || Tri(30,40,60)
|-
|}

Hlavné rozdiely medzi pivármi a obyčajnými fanúšikmi je túžba po pive. Zatiaľ čo obyčajný fanúšik si nikdy pri vstupe nedá pivo, u pivára je až 40% šanca, že sa tak rozhodne. Na delay označujúci sledovanie zápasu som tentokrát použil Triangulovú distribúciu, čo je v tomto prípade lepšie ako Exponenciálna distribúcia, ktorá by tak dobre nevystihovala realitu, pretože v momentálnom modeli každí dostane chuť na pivo niekedy inokedy, a nie takmer všetci ľudia naraz ( v poradí ako prichádzali na štadión ) , ako by to bolo pri Exponenciálnej distribúcii.

=Model=

[[File:MainProcessHockeyMatchesBeersOptimalization.png]]

Hlavná obrazovka obsahuje hlavne Dynamic Labels, ktoré zjednodušujú pozorovanie simulácie. Generovanie fanúšika(Generate) je proces vysvetlený v tabuľke vyššie , Užívanie si zápasu(Process) je hlavný proces obsahujúci všetko potrebné na simulovanie hokejového zápasu a požiadaviek na pivo a Odchod domov(Dispose) simuluje odchod entity zo štadióna. Celá simulácia simuluje dátum 12.12.2018 s časom trvania 16:00 - 19:30 a približný výskyt divákov na zápase prvej slovenskej ligy v meste Prešov.

[[File:WatchTheGameProcessHockeyMatchesBeersOptimalization.png]]

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - DELAY '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Kupovanie lístkov''' || Delay || Exp(2.0)/Minutes || akcia entity kupovania lístkov, priemerná doba predaja sa nelíši podľa druhu fanúšika, takže pani pri okienku vybaví priemerna za 1 minútu 1 diváka || X
|-
| '''Čapovanie piva na štadióne''' || Delay || Exp(2.0)/Minutes || priemerná doba načapovania a predania jedného piva na štadióne ||
* Accept Entity : inkrementuje o 1 globálnu premenu modelu PeopleInQueue použitú pri rozhodvaní, kde si dá pivo
* Release Entity : dekrementuje o 1 globálnu premenu modelu PeopleInQueue a inkrementuje pomocnú premennú BeerSold
|-
| '''Čapovanie piva v krčme''' || Delay || Exp(3.0)/Minutes || priemerná doba načapovania a predania jedného piva v krčme trvá o minútu dlhšie ako na štadióne ||
* Release Entity : dekrementuje o 1 pomocnú premennú BeerLost
|-
| '''Sledovanie zápasu pivára''' || Delay || Tri(25,40,60)/Minutes || pivár si dá pivo v priemere každých 40 minút, avšak niekedy si ide po ďalšie pivo skôr, už po 25 minutách, no na druhej strane viac ako 60 minút nevydrží určite || X
|-
| '''Sledovanie zápasu fanúšika''' || Delay || Tri(40,60,80)/Minutes || divák si dá pivo v priemere každých 60 minút, avšak niekedy si ide po ďalšie pivo skôr, po 40 minutách, no na druhej strane viac ako 80 minút nevydrží určite || X
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - BRANCH '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Dám si pivo?''' || Branch || Entity type || prvá križovatka typu Entity type, čo znamená, že pre každý vychádzajúci konektor ( Connector) musí byť zvolený typ entity, obyčajný fanúšik si po príchode dá pivo s 0% pravdepodobnosťou, zatiaľ čo pivár stále váha || X
|-
| '''Rozhodujem sa...''' || Branch|| Probability || Beer Guy si buď dá pivo na 40%, alebo sa rozhodne ísť sa usadiť na miesto || X
|-
| '''Kde si dám pivo?''' || Branch|| Attribute || bez ohľadu na typ entity sa divák rozhoduje, či si dá pivo na štadióne, alebo si pôjde dať pivo do vedľajšieho pivovaru (výhoda krčmového pivovaru je popísaná v úvode) || X
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
| '''Idem domov?''' || Branch || Priority || divák sa rozhoduje, či si ešte dá pivo, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:05, čo znamená, že ak divák výjde na chodbu po 19:05, urobí tak pretože chce opustiť štadión a na pivo už neide, keďže zápas sa konči o pár minút
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - CONNECTOR '''
!| Názov || Názov nástroja || Typ distribúcie || Popis
|-
| '''Zatiaľ nie''' || Connector || Exp(4.0)/Minutes|| odpoveď určená pre entitu Fan, ktorej cestovanie (Travel Duration) trvá priemerne 4 minúty
|-
| '''Som pivár, obyčajný pivár''' || Connector || X || odpoveď určená pre entitu Beer Guy na otázku z Branche '''Dám si pivo?''', slúži iba ako pomocný konektor do ďalšej Branche
|-
| '''Jo!''' || Connector || Exp(5.0)/Minutes || kladná odpoveď na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 40%)
|-
| '''Nedám''' || Connector || Exp(4.0)/Minutes || negatívna odpoveď určená na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 60%)
|-
| '''Dám si ho tu!''' || Connector || Exp(30.0)/Seconds || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí počkať si v rade na pivo na štadióne
|-
| '''Idem do krčmy''' || Connector || Exp(5.0)/Minutes || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí ísť na pivo do konkurenčnej krčmy, ktorá je vzdialená priemerne 5 minút chôdze
|-
| '''Odchádzam''' || Connector || X || divákovi sa s načapovaným pivom neoplatí vracať po 19:00 (odpoveď v Branchi '''Oplatí sa mi ešte vracať?''')
|-
| '''Idem domov''' || Connector || X || divák ktorý vyšiel na chodbu po 19:00 už neide na pivo, ale domov (odpoveď v Branchi '''Idem domov?''')
|-
| '''Jedno ešte stíham :)''' || Connector || Exp(3.0)/Minutes || divák ktorý sa dostane na chodbu pred 19:00, si ide dať určite pivo (odpoveď v Branchi '''Idem domov?''')
|-
|}

=Výsledky=
[[File:ResultsHockeyMatchesBeersOptimalization.png]]

=Závěr=

Simulácia by sa dala rozšíriť o množstvo ďalších rozhodnutí, ako je napríklad potreba ísť na WC alebo zahrnúť skutočnosť, že by si ľudia v bufere mohli kúpiť aj niečo iné ako pivo. Pri mojom nastavení ani 40 píp na čapovanie nestačilo na to, aby štadíón nestrácal zisky (čo sa týka predaného piva, výčapníci a ich hodinová mzda v modeli zatiaľ chýba tiež) z divákov, ktorí chcú pivo v rovnaký čas. Naopak, otpimalizáciu prihľiadnúc na tento fakt by som považoval nasadenie 20 píp, kde by ale pracovníci nemali takmer žiaden oddych. Som rád, že som si nakoniec vybral Simprocess, pretože tento nástroj môže byť v budúcnosti veľmi žiadaný.

=Kód=
[[File:HockeyMatchesBeersOptimalization.spm]]

=Reference=
http://simprocess.com/Documentation/Windows_Manuals/SIMPROCESS_Getting_Started_Manual.pdf
http://simprocess.com/Documentation/SIMPROCESS_Expression_Demo_Models.pdf

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-17T15:32:04Z

Turd01: /* Model */

== Zadání ==

'''Název simulace''': Simulace optímálneho počtu výčapov piva na štadióne

'''Autor''': Bc. Dominik Turák, turd01

'''Typ modelu''': Diskrétni simulace

'''Modelovací nástroj''': [http://simprocess.com/products/products.html SIMPROCESS]

== Popis Modelu ==

Na hokejových alebo futbalových zápasoch sa často stáva, že človek musí čakať na pivo v dlhom rade celú večnosť. Navyše, ak sa poblízku štadióna nachádza podnik, v ktorom tiež čapujú pivo, ľudia sa mnohokrát rozhodnú ísť si radšej načapovať pivo tam, pretože je to pre nich mnohokrát výhodnejšie, najmä z finančného hľadiska. Štadión tým pádom stráca potencionálny zisk a naopak, pri malom počte ľudí zbytočne prepláca pracujúcich výčapníkov.

== Cíl simulace ==

Nájsť otpimálny počet výčapov prihľiadnúc na počet ľudí na štadióne tak, aby sa minimalizovali straty od nedočkavých ľudí, ktorí si radšej zvolia konkurenčný výčap, avšak zachovať počet píp na čo najnižšom možnom čísle.

= Metóda =

Nasledujúce tabuľky približuje chovanie modelu a opisujú význam vybraných vstupných dát.

{| class="wikitable"
|+ align="top" | ''' Generovaní divákov '''
!| Názov entity || Názov schedule || Typ distribúcie || jednotka času || start/end
|-
| Fan || First real fans || Poi(20.0) || 1 minúta || 16:00 - 16:30
|-
| Fan || Normal real fans || Poi(30.0) || 1 minúta || 16:30 - 17:00
|-
| Beer guy || First Beer guys || Poi(15.0) || 1 minúta || 16:00 - 16:30
|-
| Beer guy || Normal Beer fans || Poi(10.0) || 1 minúta || 16:30 - 17:00
|-
|}

Pri generovaní fanúšikov som použil Poison Distribúciu, keďže entity sa generujú v krátkom časovom intervale, čo najlepšie vyhovuje mojmu prípadu, kedy sa snažím čo najrealistickejšie vystihnúť príchod fanúšikov na štadión.

{| class="wikitable"
|+ align="top" | ''' Vlastnosti divákov '''
!| Názov entity || Pravdepodobnosť zakúpenia piva ihneď po príchode || Dlžka sledovania zápasu do dalšieho piva (v minútach)
|-
| Fan || 0% || Tri(40,55,80)
|-
| Beer guy || 40% || Tri(30,40,60)
|-
|}

Hlavné rozdiely medzi pivármi a obyčajnými fanúšikmi je túžba po pive. Zatiaľ čo obyčajný fanúšik si nikdy pri vstupe nedá pivo, u pivára je až 40% šanca, že sa tak rozhodne. Na delay označujúci sledovanie zápasu som tentokrát použil Triangulovú distribúciu, čo je v tomto prípade lepšie ako Exponenciálna distribúcia, ktorá by tak dobre nevystihovala realitu, pretože v momentálnom modeli každí dostane chuť na pivo niekedy inokedy, a nie takmer všetci ľudia naraz ( v poradí ako prichádzali na štadión ) , ako by to bolo pri Exponenciálnej distribúcii.

=Model=

[[File:MainProcessHockeyMatchesBeersOptimalization.png]]

Hlavná obrazovka obsahuje hlavne Dynamic Labels, ktoré zjednodušujú pozorovanie simulácie. Generovanie fanúšika(Generate) je proces vysvetlený v tabuľke vyššie , Užívanie si zápasu(Process) je hlavný proces obsahujúci všetko potrebné na simulovanie hokejového zápasu a požiadaviek na pivo a Odchod domov(Dispose) simuluje odchod entity zo štadióna. Celá simulácia simuluje dátum 12.12.2018 s časom trvania 16:00 - 19:30 a približný výskyt divákov na zápase prvej slovenskej ligy v meste Prešov.

[[File:WatchTheGameProcessHockeyMatchesBeersOptimalization.png]]

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - DELAY '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Kupovanie lístkov''' || Delay || Exp(2.0)/Minutes || akcia entity kupovania lístkov, priemerná doba predaja sa nelíši podľa druhu fanúšika, takže pani pri okienku vybaví priemerna za 1 minútu 1 diváka || X
|-
| '''Čapovanie piva na štadióne''' || Delay || Exp(2.0)/Minutes || priemerná doba načapovania a predania jedného piva na štadióne ||
* Accept Entity : inkrementuje o 1 globálnu premenu modelu PeopleInQueue použitú pri rozhodvaní, kde si dá pivo
* Release Entity : dekrementuje o 1 globálnu premenu modelu PeopleInQueue a inkrementuje pomocnú premennú BeerSold
|-
| '''Čapovanie piva v krčme''' || Delay || Exp(3.0)/Minutes || priemerná doba načapovania a predania jedného piva v krčme trvá o minútu dlhšie ako na štadióne ||
* Release Entity : dekrementuje o 1 pomocnú premennú BeerLost
|-
| '''Sledovanie zápasu pivára''' || Delay || Tri(25,40,60)/Minutes || pivár si dá pivo v priemere každých 40 minút, avšak niekedy si ide po ďalšie pivo skôr, už po 25 minutách, no na druhej strane viac ako 60 minút nevydrží určite || X
|-
| '''Sledovanie zápasu fanúšika''' || Delay || Tri(40,60,80)/Minutes || divák si dá pivo v priemere každých 60 minút, avšak niekedy si ide po ďalšie pivo skôr, po 40 minutách, no na druhej strane viac ako 80 minút nevydrží určite || X
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - BRANCH '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Dám si pivo?''' || Branch || Entity type || prvá križovatka typu Entity type, čo znamená, že pre každý vychádzajúci konektor ( Connector) musí byť zvolený typ entity, obyčajný fanúšik si po príchode dá pivo s 0% pravdepodobnosťou, zatiaľ čo pivár stále váha || X
|-
| '''Rozhodujem sa...''' || Branch|| Probability || Beer Guy si buď dá pivo na 40%, alebo sa rozhodne ísť sa usadiť na miesto || X
|-
| '''Kde si dám pivo?''' || Branch|| Attribute || bez ohľadu na typ entity sa divák rozhoduje, či si dá pivo na štadióne, alebo si pôjde dať pivo do vedľajšieho pivovaru (výhoda krčmového pivovaru je popísaná v úvode) || X
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
| '''Idem domov?''' || Branch || Priority || divák sa rozhoduje, či si ešte dá pivo, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:05, čo znamená, že ak divák výjde na chodbu po 19:05, urobí tak pretože chce opustiť štadión a na pivo už neide, keďže zápas sa konči o pár minút
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - CONNECTOR '''
!| Názov || Názov nástroja || Typ distribúcie || Popis
|-
| '''Zatiaľ nie''' || Connector || Exp(4.0)/Minutes|| odpoveď určená pre entitu Fan, ktorej cestovanie (Travel Duration) trvá priemerne 4 minúty
|-
| '''Som pivár, obyčajný pivár''' || Connector || X || odpoveď určená pre entitu Beer Guy na otázku z Branche '''Dám si pivo?''', slúži iba ako pomocný konektor do ďalšej Branche
|-
| '''Jo!''' || Connector || Exp(5.0)/Minutes || kladná odpoveď na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 40%)
|-
| '''Nedám''' || Connector || Exp(4.0)/Minutes || negatívna odpoveď určená na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 60%)
|-
| '''Dám si ho tu!''' || Connector || Exp(30.0)/Seconds || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí počkať si v rade na pivo na štadióne
|-
| '''Idem do krčmy''' || Connector || Exp(5.0)/Minutes || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí ísť na pivo do konkurenčnej krčmy, ktorá je vzdialená priemerne 5 minút chôdze
|-
| '''Odchádzam''' || Connector || X || divákovi sa s načapovaným pivom neoplatí vracať po 19:00 (odpoveď v Branchi '''Oplatí sa mi ešte vracať?''')
|-
| '''Idem domov''' || Connector || X || divák ktorý vyšiel na chodbu po 19:00 už neide na pivo, ale domov (odpoveď v Branchi '''Idem domov?''')
|-
| '''Jedno ešte stíham :)''' || Connector || Exp(3.0)/Minutes || divák ktorý sa dostane na chodbu pred 19:00, si ide dať určite pivo (odpoveď v Branchi '''Idem domov?''')
|-
|}

=Výsledky=
[[File:ResultsHockeyMatchesBeersOptimalization.png]]

=Závěr=

Simulácia by sa dala rozšíriť o množstvo ďalších rozhodnutí, ako je napríklad potreba ísť na WC alebo zahrnúť skutočnosť, že by si ľudia v bufere mohli kúpiť aj niečo iné ako pivo. Pri mojom nastavení ani 40 píp na čapovanie nestačilo na to, aby štadíón nestrácal zisky (čo sa týka predaného piva, výčapníci a ich hodinová mzda v modeli zatiaľ chýba tiež) z divákov, ktorí chcú pivo v rovnaký čas. Naopak, otpimalizáciu prihľiadnúc na tento fakt by som považoval nasadenie 20 píp, kde by ale pracovníci nemali takmer žiaden oddych. Som rád, že som si nakoniec vybral Simprocess, pretože tento nástroj môže byť v budúcnosti veľmi žiadaný.

=Kód=
[[File:HockeyMatchesBeersOptimalization.spm]]

=Reference=
http://simprocess.com/Documentation/Windows_Manuals/SIMPROCESS_Getting_Started_Manual.pdf
http://simprocess.com/Documentation/SIMPROCESS_Expression_Demo_Models.pdf

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-17T15:23:20Z

Turd01: /* Model */

== Zadání ==

'''Název simulace''': Simulace optímálneho počtu výčapov piva na štadióne

'''Autor''': Bc. Dominik Turák, turd01

'''Typ modelu''': Diskrétni simulace

'''Modelovací nástroj''': [http://simprocess.com/products/products.html SIMPROCESS]

== Popis Modelu ==

Na hokejových alebo futbalových zápasoch sa často stáva, že človek musí čakať na pivo v dlhom rade celú večnosť. Navyše, ak sa poblízku štadióna nachádza podnik, v ktorom tiež čapujú pivo, ľudia sa mnohokrát rozhodnú ísť si radšej načapovať pivo tam, pretože je to pre nich mnohokrát výhodnejšie, najmä z finančného hľadiska. Štadión tým pádom stráca potencionálny zisk a naopak, pri malom počte ľudí zbytočne prepláca pracujúcich výčapníkov.

== Cíl simulace ==

Nájsť otpimálny počet výčapov prihľiadnúc na počet ľudí na štadióne tak, aby sa minimalizovali straty od nedočkavých ľudí, ktorí si radšej zvolia konkurenčný výčap, avšak zachovať počet píp na čo najnižšom možnom čísle.

= Metóda =

Nasledujúce tabuľky približuje chovanie modelu a opisujú význam vybraných vstupných dát.

{| class="wikitable"
|+ align="top" | ''' Generovaní divákov '''
!| Názov entity || Názov schedule || Typ distribúcie || jednotka času || start/end
|-
| Fan || First real fans || Poi(20.0) || 1 minúta || 16:00 - 16:30
|-
| Fan || Normal real fans || Poi(30.0) || 1 minúta || 16:30 - 17:00
|-
| Beer guy || First Beer guys || Poi(15.0) || 1 minúta || 16:00 - 16:30
|-
| Beer guy || Normal Beer fans || Poi(10.0) || 1 minúta || 16:30 - 17:00
|-
|}

Pri generovaní fanúšikov som použil Poison Distribúciu, keďže entity sa generujú v krátkom časovom intervale, čo najlepšie vyhovuje mojmu prípadu, kedy sa snažím čo najrealistickejšie vystihnúť príchod fanúšikov na štadión.

{| class="wikitable"
|+ align="top" | ''' Vlastnosti divákov '''
!| Názov entity || Pravdepodobnosť zakúpenia piva ihneď po príchode || Dlžka sledovania zápasu do dalšieho piva (v minútach)
|-
| Fan || 0% || Tri(40,55,80)
|-
| Beer guy || 40% || Tri(30,40,60)
|-
|}

Hlavné rozdiely medzi pivármi a obyčajnými fanúšikmi je túžba po pive. Zatiaľ čo obyčajný fanúšik si nikdy pri vstupe nedá pivo, u pivára je až 40% šanca, že sa tak rozhodne. Na delay označujúci sledovanie zápasu som tentokrát použil Triangulovú distribúciu, čo je v tomto prípade lepšie ako Exponenciálna distribúcia, ktorá by tak dobre nevystihovala realitu, pretože v momentálnom modeli každí dostane chuť na pivo niekedy inokedy, a nie takmer všetci ľudia naraz ( v poradí ako prichádzali na štadión ) , ako by to bolo pri Exponenciálnej distribúcii.

=Model=

[[File:MainProcessHockeyMatchesBeersOptimalization.png]]

Hlavná obrazovka obsahuje hlavne Dynamic Labels, ktoré zjednodušujú pozorovanie simulácie. Generovanie fanúšika(Generate) je proces vysvetlený v tabuľke vyššie , Užívanie si zápasu(Process) je hlavný proces obsahujúci všetko potrebné na simulovanie hokejového zápasu a požiadaviek na pivo a Odchod domov(Dispose) simuluje odchod entity zo štadióna. Celá simulácia simuluje dátum 12.12.2018 s časom trvania 16:00 - 19:30 a približný výskyt divákov na zápase prvej slovenskej ligy v meste Prešov.

[[File:WatchTheGameProcessHockeyMatchesBeersOptimalization.png]]

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - DELAY '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Kupovanie lístkov''' || Delay || Exp(2.0)/Minutes || akcia entity kupovania lístkov, priemerná doba predaja sa nelíši podľa druhu fanúšika, takže pani pri okienku vybaví priemerna za 1 minútu 1 diváka || X
|-
| '''Čapovanie piva na štadióne''' || Delay || Exp(2.0)/Minutes || priemerná doba načapovania a predania jedného piva na štadióne ||
* Accept Entity : inkrementuje o 1 globálnu premenu modelu PeopleInQueue použitú pri rozhodvaní, kde si dá pivo
* Release Entity : dekrementuje o 1 globálnu premenu modelu PeopleInQueue a inkrementuje pomocnú premennú BeerSold
|-
| '''Čapovanie piva v krčme''' || Delay || Exp(3.0)/Minutes || priemerná doba načapovania a predania jedného piva v krčme trvá o minútu dlhšie ako na štadióne ||
* Release Entity : dekrementuje o 1 pomocnú premennú BeerLost
|-
| '''Sledovanie zápasu pivára''' || Delay || Tri(25,40,60)/Minutes || pivár si dá pivo v priemere každých 40 minút, avšak niekedy si ide po ďalšie pivo skôr, už po 25 minutách, no na druhej strane viac ako 60 minút nevydrží určite || X
|-
| '''Sledovanie zápasu fanúšika''' || Delay || Tri(40,60,80)/Minutes || divák si dá pivo v priemere každých 60 minút, avšak niekedy si ide po ďalšie pivo skôr, po 40 minutách, no na druhej strane viac ako 80 minút nevydrží určite || X
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - BRANCH '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Dám si pivo?''' || Branch || Entity type || prvá križovatka typu Entity type, čo znamená, že pre každý vychádzajúci konektor ( Connector) musí byť zvolený typ entity, obyčajný fanúšik si po príchode dá pivo s 0% pravdepodobnosťou, zatiaľ čo pivár stále váha || X
|-
| '''Rozhodujem sa...''' || Branch|| Probability || Beer Guy si buď dá pivo na 40%, alebo sa rozhodne ísť sa usadiť na miesto || X
|-
| '''Kde si dám pivo?''' || Branch|| Attribute || bez ohľadu na typ entity sa divák rozhoduje, či si dá pivo na štadióne, alebo si pôjde dať pivo do vedľajšieho pivovaru (výhoda krčmového pivovaru je popísaná v úvode) || X
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
| '''Idem domov?''' || Branch || Priority || divák sa rozhoduje, či si ešte dá pivo, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:05, čo znamená, že ak divák výjde na chodbu po 19:05, urobí tak pretože chce opustiť štadión a na pivo už neide, keďže zápas sa konči o pár minút
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - CONNECTOR '''
!| Názov || Názov nástroja || Typ distribúcie || Popis
|-
| '''Zatiaľ nie''' || Connector || Exp(4.0)/Minutes|| odpoveď určená pre entitu Fan, ktorej cestovanie (Travel Duration) trvá priemerne 4 minúty
|-
| '''Som pivár, obyčajný pivár''' || Connector || X || odpoveď určená pre entitu Beer Guy na otázku z Branche '''Dám si pivo?''', slúži iba ako pomocný konektor do ďalšej Branche
|-
| '''Jo!''' || Connector || Exp(5.0)/Minutes || kladná odpoveď na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 40%)
|-
| '''Nedám''' || Connector || Exp(4.0)/Minutes || negatívna odpoveď určená na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 60%)
|-
| '''Dám si ho tu!''' || Connector || Exp(30.0)/Seconds || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí počkať si v rade na pivo na štadióne
|-
| '''Idem do krčmy''' || Connector || Exp(5.0)/Minutes || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí ísť na pivo do konkurenčnej krčmy, ktorá je vzdialená priemerne 5 minút chôdze
|-
| '''Odchádzam''' || Connector || X || divákovi sa s načapovaným pivom neoplatí vracať po 19:00 (odpoveď v Branchi '''Oplatí sa mi ešte vracať?''')
|-
| '''Idem domov''' || Connector || X || divák ktorý vyšiel na chodbu po 19:00 už neide na pivo, ale domov (odpoveď v Branchi '''Idem domov?''')
|-
| '''Jedno ešte stíham :)''' || Connector || X || divák ktorý sa dostane na chodbu pred 19:00 si ide dať určite pivo (odpoveď v Branchi '''Idem domov?''')
|-
|}

=Výsledky=
[[File:ResultsHockeyMatchesBeersOptimalization.png]]

=Závěr=

Simulácia by sa dala rozšíriť o množstvo ďalších rozhodnutí, ako je napríklad potreba ísť na WC alebo zahrnúť skutočnosť, že by si ľudia v bufere mohli kúpiť aj niečo iné ako pivo. Pri mojom nastavení ani 40 píp na čapovanie nestačilo na to, aby štadíón nestrácal zisky (čo sa týka predaného piva, výčapníci a ich hodinová mzda v modeli zatiaľ chýba tiež) z divákov, ktorí chcú pivo v rovnaký čas. Naopak, otpimalizáciu prihľiadnúc na tento fakt by som považoval nasadenie 20 píp, kde by ale pracovníci nemali takmer žiaden oddych. Som rád, že som si nakoniec vybral Simprocess, pretože tento nástroj môže byť v budúcnosti veľmi žiadaný.

=Kód=
[[File:HockeyMatchesBeersOptimalization.spm]]

=Reference=
http://simprocess.com/Documentation/Windows_Manuals/SIMPROCESS_Getting_Started_Manual.pdf
http://simprocess.com/Documentation/SIMPROCESS_Expression_Demo_Models.pdf

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-17T15:22:39Z

Turd01: /* Model */

== Zadání ==

'''Název simulace''': Simulace optímálneho počtu výčapov piva na štadióne

'''Autor''': Bc. Dominik Turák, turd01

'''Typ modelu''': Diskrétni simulace

'''Modelovací nástroj''': [http://simprocess.com/products/products.html SIMPROCESS]

== Popis Modelu ==

Na hokejových alebo futbalových zápasoch sa často stáva, že človek musí čakať na pivo v dlhom rade celú večnosť. Navyše, ak sa poblízku štadióna nachádza podnik, v ktorom tiež čapujú pivo, ľudia sa mnohokrát rozhodnú ísť si radšej načapovať pivo tam, pretože je to pre nich mnohokrát výhodnejšie, najmä z finančného hľadiska. Štadión tým pádom stráca potencionálny zisk a naopak, pri malom počte ľudí zbytočne prepláca pracujúcich výčapníkov.

== Cíl simulace ==

Nájsť otpimálny počet výčapov prihľiadnúc na počet ľudí na štadióne tak, aby sa minimalizovali straty od nedočkavých ľudí, ktorí si radšej zvolia konkurenčný výčap, avšak zachovať počet píp na čo najnižšom možnom čísle.

= Metóda =

Nasledujúce tabuľky približuje chovanie modelu a opisujú význam vybraných vstupných dát.

{| class="wikitable"
|+ align="top" | ''' Generovaní divákov '''
!| Názov entity || Názov schedule || Typ distribúcie || jednotka času || start/end
|-
| Fan || First real fans || Poi(20.0) || 1 minúta || 16:00 - 16:30
|-
| Fan || Normal real fans || Poi(30.0) || 1 minúta || 16:30 - 17:00
|-
| Beer guy || First Beer guys || Poi(15.0) || 1 minúta || 16:00 - 16:30
|-
| Beer guy || Normal Beer fans || Poi(10.0) || 1 minúta || 16:30 - 17:00
|-
|}

Pri generovaní fanúšikov som použil Poison Distribúciu, keďže entity sa generujú v krátkom časovom intervale, čo najlepšie vyhovuje mojmu prípadu, kedy sa snažím čo najrealistickejšie vystihnúť príchod fanúšikov na štadión.

{| class="wikitable"
|+ align="top" | ''' Vlastnosti divákov '''
!| Názov entity || Pravdepodobnosť zakúpenia piva ihneď po príchode || Dlžka sledovania zápasu do dalšieho piva (v minútach)
|-
| Fan || 0% || Tri(40,55,80)
|-
| Beer guy || 40% || Tri(30,40,60)
|-
|}

Hlavné rozdiely medzi pivármi a obyčajnými fanúšikmi je túžba po pive. Zatiaľ čo obyčajný fanúšik si nikdy pri vstupe nedá pivo, u pivára je až 40% šanca, že sa tak rozhodne. Na delay označujúci sledovanie zápasu som tentokrát použil Triangulovú distribúciu, čo je v tomto prípade lepšie ako Exponenciálna distribúcia, ktorá by tak dobre nevystihovala realitu, pretože v momentálnom modeli každí dostane chuť na pivo niekedy inokedy, a nie takmer všetci ľudia naraz ( v poradí ako prichádzali na štadión ) , ako by to bolo pri Exponenciálnej distribúcii.

=Model=

[[File:MainProcessHockeyMatchesBeersOptimalization.png]]

Hlavná obrazovka obsahuje hlavne Dynamic Labels, ktoré zjednodušujú pozorovanie simulácie. Generovanie fanúšika(Generate) je proces vysvetlený v tabuľke vyššie , Užívanie si zápasu(Process) je hlavný proces obsahujúci všetko potrebné na simulovanie hokejového zápasu a požiadaviek na pivo a Odchod domov(Dispose) simuluje odchod entity zo štadióna. Celá simulácia simuluje dátum 12.12.2018 s časom trvania 16:00 - 19:30 a približný výskyt divákov na zápase prvej slovenskej ligy v meste Prešov.

[[File:WatchTheGameProcessHockeyMatchesBeersOptimalization.png]]

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - DELAY '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Kupovanie lístkov''' || Delay || Exp(2.0)/Minutes || akcia entity kupovania lístkov, priemerná doba predaja sa nelíši podľa druhu fanúšika, takže pani pri okienku vybaví priemerna za 1 minútu 1 diváka || X
|-
| '''Čapovanie piva na štadióne''' || Delay || Exp(2.0)/Minutes || priemerná doba načapovania a predania jedného piva na štadióne ||
* Accept Entity : inkrementuje o 1 globálnu premenu modelu PeopleInQueue použitú pri rozhodvaní, kde si dá pivo
* Release Entity : dekrementuje o 1 globálnu premenu modelu PeopleInQueue a inkrementuje pomocnú premennú BeerSold
|-
| '''Čapovanie piva v krčme''' || Delay || Exp(3.0)/Minutes || priemerná doba načapovania a predania jedného piva v krčme trvá o minútu dlhšie ako na štadióne ||
* Release Entity : dekrementuje o 1 pomocnú premennú BeerLost
|-
| '''Sledovanie zápasu pivára''' || Delay || Tri(25,40,60)/Minutes || pivár si dá pivo v priemere každých 40 minút, avšak niekedy si ide po ďalšie pivo skôr, už po 25 minutách, no na druhej strane viac ako 60 minút nevydrží určite || X
|-
| '''Sledovanie zápasu fanúšika''' || Delay || Tri(40,60,80)/Minutes || divák si dá pivo v priemere každých 60 minút, avšak niekedy si ide po ďalšie pivo skôr, po 40 minutách, no na druhej strane viac ako 80 minút nevydrží určite || X
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - BRANCH '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Dám si pivo?''' || Branch || Entity type || prvá križovatka typu Entity type, čo znamená, že pre každý vychádzajúci konektor ( Connector) musí byť zvolený typ entity, obyčajný fanúšik si po príchode dá pivo s 0% pravdepodobnosťou, zatiaľ čo pivár stále váha || X
|-
| '''Rozhodujem sa...''' || Branch|| Probability || Beer Guy si buď dá pivo na 40%, alebo sa rozhodne ísť sa usadiť na miesto || X
|-
| '''Kde si dám pivo?''' || Branch|| Attribute || bez ohľadu na typ entity sa divák rozhoduje, či si dá pivo na štadióne, alebo si pôjde dať pivo do vedľajšieho pivovaru (výhoda krčmového pivovaru je popísaná v úvode) || X
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
| '''Idem domov?''' || Branch || Priority || divák sa rozhoduje, či si ešte dá pivo, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:05, čo znamená, že ak divák výjde na chodbu po 19:05, urobí tak pretože chce opustiť štadión a na pivo už neide, keďže zápas sa konči o pár minút
|-
| '''Oplatí sa mi ešte vracať?''' || Branch || Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
|}

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov - CONNECTOR '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Zatiaľ nie''' || Connector || Exp(4.0)/Minutes|| odpoveď určená pre entitu Fan, ktorej cestovanie (Travel Duration) trvá priemerne 4 minúty || X
|-
| '''Som pivár, obyčajný pivár''' || Connector || X || odpoveď určená pre entitu Beer Guy na otázku z Branche '''Dám si pivo?''', slúži iba ako pomocný konektor do ďalšej Branche || X
|-
| '''Jo!''' || Connector || Exp(5.0)/Minutes || kladná odpoveď na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 40%) || X
|-
| '''Nedám''' || Connector || Exp(4.0)/Minutes || negatívna odpoveď určená na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 60%) || X
|-
| '''Dám si ho tu!''' || Connector || Exp(30.0)/Seconds || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí počkať si v rade na pivo na štadióne || X
|-
| '''Idem do krčmy''' || Connector || Exp(5.0)/Minutes || divák vyhodnotil (odpoveď v Branchi '''Kde si dám pivo?'''), že sa mu oplatí ísť na pivo do konkurenčnej krčmy, ktorá je vzdialená priemerne 5 minút chôdze || X
|-
| '''Odchádzam''' || Connector || X || divákovi sa s načapovaným pivom neoplatí vracať po 19:00 (odpoveď v Branchi '''Oplatí sa mi ešte vracať?''') || X
|-
| '''Idem domov''' || Connector || X || divák ktorý vyšiel na chodbu po 19:00 už neide na pivo, ale domov (odpoveď v Branchi '''Idem domov?''') || X
|-
| '''Jedno ešte stíham :)''' || Connector || X || divák ktorý sa dostane na chodbu pred 19:00 si ide dať určite pivo (odpoveď v Branchi '''Idem domov?''') || X
|-
|}

=Výsledky=
[[File:ResultsHockeyMatchesBeersOptimalization.png]]

=Závěr=

Simulácia by sa dala rozšíriť o množstvo ďalších rozhodnutí, ako je napríklad potreba ísť na WC alebo zahrnúť skutočnosť, že by si ľudia v bufere mohli kúpiť aj niečo iné ako pivo. Pri mojom nastavení ani 40 píp na čapovanie nestačilo na to, aby štadíón nestrácal zisky (čo sa týka predaného piva, výčapníci a ich hodinová mzda v modeli zatiaľ chýba tiež) z divákov, ktorí chcú pivo v rovnaký čas. Naopak, otpimalizáciu prihľiadnúc na tento fakt by som považoval nasadenie 20 píp, kde by ale pracovníci nemali takmer žiaden oddych. Som rád, že som si nakoniec vybral Simprocess, pretože tento nástroj môže byť v budúcnosti veľmi žiadaný.

=Kód=
[[File:HockeyMatchesBeersOptimalization.spm]]

=Reference=
http://simprocess.com/Documentation/Windows_Manuals/SIMPROCESS_Getting_Started_Manual.pdf
http://simprocess.com/Documentation/SIMPROCESS_Expression_Demo_Models.pdf

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-17T15:13:48Z

Turd01: /* Model */

== Zadání ==

'''Název simulace''': Simulace optímálneho počtu výčapov piva na štadióne

'''Autor''': Bc. Dominik Turák, turd01

'''Typ modelu''': Diskrétni simulace

'''Modelovací nástroj''': [http://simprocess.com/products/products.html SIMPROCESS]

== Popis Modelu ==

Na hokejových alebo futbalových zápasoch sa často stáva, že človek musí čakať na pivo v dlhom rade celú večnosť. Navyše, ak sa poblízku štadióna nachádza podnik, v ktorom tiež čapujú pivo, ľudia sa mnohokrát rozhodnú ísť si radšej načapovať pivo tam, pretože je to pre nich mnohokrát výhodnejšie, najmä z finančného hľadiska. Štadión tým pádom stráca potencionálny zisk a naopak, pri malom počte ľudí zbytočne prepláca pracujúcich výčapníkov.

== Cíl simulace ==

Nájsť otpimálny počet výčapov prihľiadnúc na počet ľudí na štadióne tak, aby sa minimalizovali straty od nedočkavých ľudí, ktorí si radšej zvolia konkurenčný výčap, avšak zachovať počet píp na čo najnižšom možnom čísle.

= Metóda =

Nasledujúce tabuľky približuje chovanie modelu a opisujú význam vybraných vstupných dát.

{| class="wikitable"
|+ align="top" | ''' Generovaní divákov '''
!| Názov entity || Názov schedule || Typ distribúcie || jednotka času || start/end
|-
| Fan || First real fans || Poi(20.0) || 1 minúta || 16:00 - 16:30
|-
| Fan || Normal real fans || Poi(30.0) || 1 minúta || 16:30 - 17:00
|-
| Beer guy || First Beer guys || Poi(15.0) || 1 minúta || 16:00 - 16:30
|-
| Beer guy || Normal Beer fans || Poi(10.0) || 1 minúta || 16:30 - 17:00
|-
|}

Pri generovaní fanúšikov som použil Poison Distribúciu, keďže entity sa generujú v krátkom časovom intervale, čo najlepšie vyhovuje mojmu prípadu, kedy sa snažím čo najrealistickejšie vystihnúť príchod fanúšikov na štadión.

{| class="wikitable"
|+ align="top" | ''' Vlastnosti divákov '''
!| Názov entity || Pravdepodobnosť zakúpenia piva ihneď po príchode || Dlžka sledovania zápasu do dalšieho piva (v minútach)
|-
| Fan || 0% || Tri(40,55,80)
|-
| Beer guy || 40% || Tri(30,40,60)
|-
|}

Hlavné rozdiely medzi pivármi a obyčajnými fanúšikmi je túžba po pive. Zatiaľ čo obyčajný fanúšik si nikdy pri vstupe nedá pivo, u pivára je až 40% šanca, že sa tak rozhodne. Na delay označujúci sledovanie zápasu som tentokrát použil Triangulovú distribúciu, čo je v tomto prípade lepšie ako Exponenciálna distribúcia, ktorá by tak dobre nevystihovala realitu, pretože v momentálnom modeli každí dostane chuť na pivo niekedy inokedy, a nie takmer všetci ľudia naraz ( v poradí ako prichádzali na štadión ) , ako by to bolo pri Exponenciálnej distribúcii.

=Model=

[[File:MainProcessHockeyMatchesBeersOptimalization.png]]

Hlavná obrazovka obsahuje hlavne Dynamic Labels, ktoré zjednodušujú pozorovanie simulácie. Generovanie fanúšika(Generate) je proces vysvetlený v tabuľke vyššie , Užívanie si zápasu(Process) je hlavný proces obsahujúci všetko potrebné na simulovanie hokejového zápasu a požiadaviek na pivo a Odchod domov(Dispose) simuluje odchod entity zo štadióna. Celá simulácia simuluje dátum 12.12.2018 s časom trvania 16:00 - 19:30 a približný výskyt divákov na zápase prvej slovenskej ligy v meste Prešov.

[[File:WatchTheGameProcessHockeyMatchesBeersOptimalization.png]]

{| class="wikitable"
|+ align="top" | ''' Popis použitých nástrojov '''
!| Názov || Názov nástroja || Typ distribúcie || Popis || Expressions
|-
| '''Kupovanie lístkov''' || Delay || Exp(2.0)/Minutes || akcia entity kupovania lístkov, priemerná doba predaja sa nelíši podľa druhu fanúšika, takže pani pri okienku vybaví priemerna za 1 minútu 1 diváka || X
|-
| '''Čapovanie piva na štadióne''' || Delay || Exp(2.0)/Minutes || priemerná doba načapovania a predania jedného piva na štadióne ||
* Accept Entity : inkrementuje o 1 globálnu premenu modelu PeopleInQueue použitú pri rozhodvaní, kde si dá pivo
* Release Entity : dekrementuje o 1 globálnu premenu modelu PeopleInQueue a inkrementuje pomocnú premennú BeerSold
|-
| '''Čapovanie piva v krčme''' || Delay || Exp(3.0)/Minutes || priemerná doba načapovania a predania jedného piva v krčme trvá o minútu dlhšie ako na štadióne ||
* Release Entity : dekrementuje o 1 pomocnú premennú BeerLost
|-
| '''Sledovanie zápasu pivára''' || Delay || Tri(25,40,60)/Minutes || pivár si dá pivo v priemere každých 40 minút, avšak niekedy si ide po ďalšie pivo skôr, už po 25 minutách, no na druhej strane viac ako 60 minút nevydrží určite || X
|-
| '''Sledovanie zápasu fanúšika''' || Delay || Tri(40,60,80)/Minutes || divák si dá pivo v priemere každých 60 minút, avšak niekedy si ide po ďalšie pivo skôr, po 40 minutách, no na druhej strane viac ako 80 minút nevydrží určite || X
|-
| '''Dám si pivo?''' || Branch || Entity type || prvá križovatka typu Entity type, čo znamená, že pre každý vychádzajúci konektor ( Connector) musí byť zvolený typ entity, obyčajný fanúšik si po príchode dá pivo s 0% pravdepodobnosťou, zatiaľ čo pivár stále váha || X
|-
| '''Rozhodujem sa...''' || Branch|| Probability || Beer Guy si buď dá pivo na 40%, alebo sa rozhodne ísť sa usadiť na miesto || X
|-
| '''Kde si dám pivo?''' || Branch|| Attribute || bez ohľadu na typ entity sa divák rozhoduje, či si dá pivo na štadióne, alebo si pôjde dať pivo do vedľajšieho pivovaru (výhoda krčmového pivovaru je popísaná v úvode) || X
|-
| '''Oplatí sa mi ešte vracať?''' || Branch|| Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
| '''Idem domov?''' || Branch|| Priority || divák sa rozhoduje, či si ešte dá pivo, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:05, čo znamená, že ak divák výjde na chodbu po 19:05, urobí tak pretože chce opustiť štadión a na pivo už neide, keďže zápas sa konči o pár minút
|-
| '''Oplatí sa mi ešte vracať?''' || Branch|| Priority || divák sa rozhodne, či sa ešte vráti na miesto, alebo už opustí štadión ||
*Release entity : podmienka porovnania súčasného stavu simulácie s časom 19:00, čo znamená že ak divákovi načapujú pivo po 19:00, na zápas sa už nevráti a ide domov
|-
| '''Zatiaľ nie''' || Connector || Exp(4.0)/Minutes|| odpoveď určená pre entitu Fan, ktorej cestovanie (Travel Duration) trvá priemerne 4 minúty || X
|-
| '''Som pivár, obyčajný pivár''' || Connector || X || odpoveď určená pre entitu Beer Guy na otázku z Branche '''Dám si pivo?''', slúži iba ako pomocný konektor do ďalšej Branche || X
|-
| '''Jo!''' || Connector || Exp(5.0)/Minutes || kladná odpoveď na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 40%) || X
|-
| '''Nedám''' || Connector || Exp(4.0)/Minutes || negatívna odpoveď určená na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 60%) || X
|-
| '''Dám si ho tu''' || Connector || Exp(30.0)/Seconds || divák vyhodnotil, že sa mu oplatí počkať si v rade na pivo na štadióne || X
|-
| '''Idem do krčmy''' || Connector || Exp(5.0)/Minutes || divák vyhodnotil, že sa mu oplatí ísť na pivo do konkurenčnej krčmy, ktorá je vzdialená priemerne 5 minút chôdze || X
|-
| '''Odchádzam''' || Connector || X || kladná odpoveď na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 40%) || X
|-
| '''Jo!''' || Connector || Exp(5.0)/Minutes || kladná odpoveď na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 40%) || X
|-
| '''Jo!''' || Connector || Exp(5.0)/Minutes || kladná odpoveď na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 40%) || X
|-
| '''Jo!''' || Connector || Exp(5.0)/Minutes || kladná odpoveď na otázku, či si dá pivár pivo hneď po príchode na štadión (pravdepodobnosť 40%) || X
|-

|}

=Výsledky=
[[File:ResultsHockeyMatchesBeersOptimalization.png]]

=Závěr=

Simulácia by sa dala rozšíriť o množstvo ďalších rozhodnutí, ako je napríklad potreba ísť na WC alebo zahrnúť skutočnosť, že by si ľudia v bufere mohli kúpiť aj niečo iné ako pivo. Pri mojom nastavení ani 40 píp na čapovanie nestačilo na to, aby štadíón nestrácal zisky (čo sa týka predaného piva, výčapníci a ich hodinová mzda v modeli zatiaľ chýba tiež) z divákov, ktorí chcú pivo v rovnaký čas. Naopak, otpimalizáciu prihľiadnúc na tento fakt by som považoval nasadenie 20 píp, kde by ale pracovníci nemali takmer žiaden oddych. Som rád, že som si nakoniec vybral Simprocess, pretože tento nástroj môže byť v budúcnosti veľmi žiadaný.

=Kód=
[[File:HockeyMatchesBeersOptimalization.spm]]

=Reference=
http://simprocess.com/Documentation/Windows_Manuals/SIMPROCESS_Getting_Started_Manual.pdf
http://simprocess.com/Documentation/SIMPROCESS_Expression_Demo_Models.pdf

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-17T14:40:37Z

Turd01: /* Model */

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-17T14:37:41Z

Turd01: /* Model */

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-17T13:48:53Z

Turd01: /* Model */

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-17T13:40:52Z

Turd01: /* Cíl simulace */

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-16T21:57:32Z

Turd01: /* Kód */

File:HockeyMatchesBeersOptimalization.spm

2019-06-16T21:57:14Z

Turd01:

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-16T21:56:45Z

Turd01: /* Výsledky */

File:ResultsHockeyMatchesBeersOptimalization.png

2019-06-16T21:56:17Z

Turd01:

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-16T21:50:33Z

Turd01: /* Závěr */

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-16T21:45:00Z

Turd01: /* Reference */

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-16T21:44:13Z

Turd01: /* Model */

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-16T21:38:57Z

Turd01: /* Model */

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-16T21:31:59Z

Turd01: /* Model */ Prvá polovica procesov

File:WatchTheGameProcessHockeyMatchesBeersOptimalization.png

2019-06-16T21:11:55Z

Turd01:

File:MainProcessHockeyMatchesBeersOptimalization.png

2019-06-16T21:06:59Z

Turd01: Turd01 načetl novou verzi File:MainProcessHockeyMatchesBeersOptimalization.png

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-16T20:57:35Z

Turd01: vlozeni prveho obrazku

File:MainProcessHockeyMatchesBeersOptimalization.png

2019-06-16T20:57:09Z

Turd01:

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-16T20:53:44Z

Turd01: /* Metóda */

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-16T20:50:59Z

Turd01: /* Metóda */

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-16T20:50:40Z

Turd01: /* Metóda */

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-16T20:42:02Z

Turd01: /* Vstupní data */ - Vlastnosti divákov

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-16T20:31:00Z

Turd01: /* Metoda */ - vytvorenie tabulky vstupnych dat

Optimalizace počtu výčapov piva na štadióne (Simprocess)

2019-06-16T20:17:17Z

Turd01: /* Popis Modelu */

Fuzzy logic/cs

2019-06-12T21:44:40Z

Turd01: /* Úlohy na precvičenie Fuzzy logiky */

{{DISPLAYTITLE:Fuzzy logika v agentním rozhodování}}

= Úvod =

[[File:Zadeh.gif|thumb|right|L.A. Zadeh]]
'''Fuzzy Logika''' vznikla v kontexte teórie Fuzzy množín, ktorú prvý krát predstavil '''L. A. Zadeh''' v roku 1965. Fuzzy množina priradí stupeň členstva (reálne číslo z intervalu [0,1]) elementom vesmíru, pričom fuzzy logika vzniká až priradením stupňov pravdy k týmto vzniknutým elementom. Vzťahuje sa na rodinu [https://plato.stanford.edu/archives/win2017/entries/logic-manyvalued viachodnotových logík], takže je určená na modelovanie logických úvah s neurčitými alebo nepresnými údajmi. Stanovuje, že hodnota pravdy (v tomto prípade pravdivostný stupeň) logicky zloženého návrhu (napr. "Peter je bohatý a Ivan je vysoký.") je určená pravdivosťou jeho komponentov, inak povedané, nepočíta iba s 2 možnými hodnotami pravdy. <ref name="fuzzyBasic"> Cintula, Petr, Fermüller, Christian G. and Noguera, Carles, "Fuzzy Logic", The Stanford Encyclopedia of Philosophy (Fall 2017 Edition), Edward N. Zalta (ed.), Dostupné z : https://plato.stanford.edu/archives/fall2017/entries/logic-fuzzy/</ref>.

Pri použití Fuzzy logiky na štandardnej škále oboru hodnôt [0,1] potom :
* '''"úplná nepravda"''' je reprezentovaná hraničnou hodnotou '''0'''
* '''"úplná pravda"''' je reprezentovaná hraničnou hodnotou '''1'''
* '''"čiastočná pravda"''' je reprezentovaná všetkými ostatnými hodnotami (nazývané aj '''stredné stupne pravdy''')

Viac o agentoch sa môžete dočítať v [http://www.simulace.info/index.php/Agents/cs kapitole na to určenej]. Pre nás bude užitočná najmä podkapitola o [http://www.simulace.info/index.php/Agents/cs#Deliberativn.C3.AD_agenty Deliberatívnych agentoch], v ktorej sa píše aj o teórií '''BDI''', ktorá tvorí sofistikovaný prístup k architektúre agenta a skladá sa z troch základných pojmov :
* Beliefs(domnienky)
* Desires(túžby)
* Intentions(zámery)

Na základe týchto 3 faktorov, a teda domnienok, túžob a prianí agent uvažuje o svete a teda o svojom rozhodovaní, ktorému je tento učební text venovaný.

----

= Fuzzy logika z každodenného života =

Pre lepšie pochopenie fuzzy logiky si uvedieme 2 príklady z bežného života:
* spotrebič, ktorý fuzzy logiku využíva
* činnosť, pri ktorom fuzzy logiku využívame automaticky bez toho, aby sme si vôbec uvedomovali, že sa nejaké rozhodovanie v mozgu uskutočňuje.

== Fuzzy logika v práčkach Samsung ==

[[File:fuzzyInWashingMachine.png|250px|left|Slovo FUZZY použité ako značka práčky Samsung a graf znázorňujúci procesy a ich následnosť]]
Trend integrovania '''Fuzzy logiky''' do práčiek Sasmung sa v posledných rokoch teší väčšej popularite. Senzory kontinuálne monitorujú premenlivé podmienky vo vnútri práčky a starostlivo vyberajú a nastavujú operácie pre dosiahnutie najlepších čiastiacich výsledkov.

Fuzzy logika má na starosti okrem iného kontrolu prívodu vody, teploty vody, času prania,kvality žmýkania alebo rýchlosť bubna. Viac sofistikované práčky vedia zvážiť hmotnosť oblečenia( takže zabraňujú preťaženiu práčky), poradia odporúčané množstvo čistiaceho prostriedku alebo vedia skontrolovať, či je čistiaci prostriedok v práškovom alebo tekutom stave. Niektoré sa dokonca vedia učiť z predošlých skúseností, zapamätávať si programy a regulovať činnosť práčky pre minimalizovanie nákladov na jej fungovanie.

== Ahoj vs. Dobrý deň ==

Ľudia by sa podľa veku mohli deliť na viacero kategórií. Pre jednoduchosť si ich rozdelíme iba do dvoch kategórií - starí a mladí. Podľa etikety slušného správania starí ľudia mladím zväčša tikajú a mladí naopak starím vykajú. Existujú samozrejme aj výnimky, napríklad vnúčata dnes bežne svojím starím rodičom tikajú. Alebo si niekedy medzi sebou vykajú aj dvaja mladí ľudia, keď napríklad vybavujú nejakú formálnu záležitosť. Ľudia dodržujúci zásady slušného správania by sa teda mali správať podľa nejakého vzoru etického správania, čo je príkladom fuzzy rozhodovania a priradenia '''(prekonvertovania)''' množín možných vstupov '''(stretnutí)''' s rozličnými vlastnosťtami '''(starý vs. mladý, stretnutie v krčme vs. stretnutie v banke, blízka vs. cudzia osoba, ...)''' na množinu možných výstupov '''(dobrý deň, ahoj, nazdar, ...)'''.

=== Návrh modelu ===

Pre jednoduchosť si fuzzy logiku vysvetlíme iba na základe jednej vlastnosti - veku (tá sa samozrejme môže meniť na základe určenia priorít, to ale komplikuje vysvetlovanie a táto komplikácia je vysvetlená v [http://www.simulace.info/index.php/Fuzzy_logic/cs#Fuzzy_rule-based_syst.C3.A9my kapitole nižšie]). Neberieme teda do úvahy žiadne iné vlastnosti agentov, ktoré by mohli zmeniť ich správanie.

[[File:fuzzyAgesAndGreetings.png|350px|center]]

Samozrejme, výsledná matica pozdravov nie je finálna, no ak by fuzzy logika obsahovala iba jedinnú premennú '''vek''' a 3 ľudí vo veku 10, 40 a 60 rokov, mohla by vyzerať nejak podobne. Dôležitý je predovšetkým výpočet faktoru veku, ktorý je v tomto prípade počítaný ako podiel '''vek/X''', kde X = 100 (tieto hodnoty môžeme vidieť na obrázku vyššie a je iba na nás, čo dosadíme za X).

Čo teda vieme z modelu vyčítať:
* 2 kategórie: '''Starí''' a '''Mladí''' s hraničným bodom delenia 50 (limit)
* prirodzená úcta k starším (mladší ľudia starším ľuďom vykajú)
* množinu vstupov ľudí '''{10,40,60}''' obsahujúcich vlastnosť veku
* množinou pozdravov '''{"Dobrý deň", "Ahoj"}'''

=== Výsledná fuzzy množina a možné rozšírenie úlohy ===

Ak by sme teda zaradzovali daných ľudí len do 2 kategórií na základe jedného pravidla, ktoré by spočívalo v porovnávaní faktoru veku s konštantou limit, dostali by sme maticu '''3x2''' možných pozdravov. Nie je teda vôbec doležité, ako nastavíme konštantu limit, pri jej zmene sa iba zmenia určené pozdravy, nie však počet prvkov matice a teda všetky možné kombinácie stretnutí majú vždy jasne danú reakciu z oboch strán.

Pri stretnutí dvoch rovesníkov som trochu načŕtol možné rozšírenie úlohy, keď som neurčil, či bude pozdrav "Ahoj" alebo "Dobrý deň". Samozrejme, ak platia pravidlá vyššie (pri dvoch malých chlapcoch som si ale dovolil spraviť výnimku, málokedy vidíme zdraviť sa ich pozdravom "Dobrý deň"), pri stretuntí dvoch '''40''' by mal byť pozdrav "Ahoj" (keďže obaja spĺňajú podmienku "mladosti") a dvoch '''60''' ročných pánov v klobúku "Dobrý deň".

Výnimka však potvrdzuje pravidlo a v prípade 10 ročného kráľa by sme aj 60 ročného starca videli pozdraviť ho pozdravom "Dobrý deň"(ak tam samozrejme nie sú ďalšie pravidlá, ktorú môžu túto logiku upravovať, ako napríklad príbuzenský vzťah a podobne). Možnosť voľby z dvoch pozdravov pri '''40''' a '''60''' ročných mužoch teda malo načŕtnuť pointu fuzzy logiky a možnosti jej rozšírenia, aj keď táto možnosť výberu sa vyskytne až po zaradení ďalších pravidiel.

=== Úlohy na precvičenie Fuzzy logiky ===

3 úlohy na záver (odpovede sa nachádzajú ako posledná kapitola):
'''1.''' Ako by vyzeral výsledný počet možných výstupov, ak by sme do množiny pozdravov v príklade vyššie pridali pozdrav "Nazdar"?
'''2.''' Aké by mohli byť ďalšie vlasnosti, ktoré by menili faktor veku?
'''3.''' Ako by vyzeral pozdrav pri stretnutí 60 ročného starca (zmena faktoru veku z príkladu vyššie), ak do modelu pridáme nasledujúce vlasnosti :
'''3.a)''' Hodnosť kráľa znásobuje súčasný váhu 100 krát?
'''3.b)''' Hodnosť kňaza znásobuje súčasný váhu 20 krát?
'''3.c)''' O koľko rokov kňaz začne oslovovať kráľa "Dobrý deň"?

----

= Fuzzy logika v agentovo-orientovaných počítačových hrách <ref name="book"> Li, Yifan & Musilek, Petr & Wyard-Scott, L. (2004).Fuzzy logic in agent-based game design. 734 - 739 Vol.2. 10.1109/NAFIPS.2004.1337393. Dostupné z : https://www.researchgate.net/publication/4092875_Fuzzy_logic_in_agent-based_game_design</ref>=

[[File:fuzzyBattleCity.png|thumb|right|Prevedenie možného použitia fuzyy logiky v známej arkádovej hre BattleCity. Kružnice znázorňujú rôzne vstupy, na základe ktorých sa agenti rozhodujú o svojej ďalšej akcii]]
Umelá inteligencia v počítačových hrách sa vďaka rastúcim požiadavkám hráčov musí neustále zlepšovať. Inteligentní agenti môžu spolu s fuzzy logikou vylepšiť najdôležitejší prvok hier - '''interakciu'''. Agenti ponúkajú lepšie možnosti flexibilnej interakcie v rámci architektúry herného dizajnu, pričom fuzzy logika umožňuje lepšie kontrolovať správanie pre vytvorenie najrôznejších foriem umelých inteligencií.

== Porovnanie s inými technikami ==

Vo svete hier neznamená '''fuzzy kontrola''' iba ďalšiu metódu pre správanie agentov. Kontrolovanie agentov pomocou fuzzy logiky je zárukou '''generovania "správneho" správania'''. Toto prirodzené správanie agentov potom pomáha zvyšovať vnímanú zložitosť a dôveryhodnosť virtuálneho prostredia. V porovnaní s niektorými inými technikami návrhu inteligentných systémov sú systémy založené na fuzzy pravidlách jednoduché na návrh aj implementáciu. Klasické '''rule-based''' systémy pritom často nedokážu dosiahnuť prirodzenosť, akú ponúkajú '''fuzzy systémy''', pričom tie spotrebujú omnoho nižšie výpočtové náklady.

== Fuzzy rule-based systémy ==

Systémy založené na fuzzy pravidlách sa vo všeobecnosti skladajú z 4 komponentov:
* '''fuzzifier''' konvertuje sparsované vstupy z klienta do fuzzy množín
* základňa pravidiel ('''rule-base''') uchováva všetky vzťahy medzi vstupmi a očakávanými výstupmi v kolekcií '''IF-THEN''' pravidiel
* '''uvažujúca jednotka''' použije vstupy a aplikuje na nich konkrétne pravidlá
* '''defuzzifier''' prekonvertuje výsledok rozhodovania a sparsované výstupy pošle späť na klienta

V prípade viacerých vstupov sú fuzzy pravidlá väčšinou prepojené logickým spojením (konektorom) AND, pričom '''rule-base''' musí pokrývať každú možnú kombináciu všetkých výrazov z definičného oboru vstupnej premennej. Táto požiadavka úplnosti ale vedie k tzv. '''rule explosion problém'''-u, kde pre systém s n vstupmi, ktorý má každý m možných stavov potrebujeme celkovo '''m^n''' pravidiel! Toto pravidlo výbuchu predstavuje vážny problém a komplikuje implementovanie fuzzy kontrolovania vďaka vysokým nárokom na CPU zdroje. Combs navrhol [https://en.wikipedia.org/wiki/Combs_method URC (Union Rule Configuration)] na zmiernenie tohto problému, kedy sa zložitosť výpočtu zníži na '''m*n''' pravidiel.

== Zhrnutie ==

Agentovo-orientovaný prístup pri vývoji hier ponúka mnoho výhod počas celého vývojového cyklu. Poskytuje prirodzený spôsob modelovania herných postáv a veľmi felxibilnú softwérovú architektúru umožňujúcu rozkvet správania agentov za použitia minimálneho počtu spojení. Navyše, pomocou nového prístupu k dizajnu ich môžu programátori ľahko integrovať do starších herných vývojových prostredí.

Fuzzy logika je ďalšou inteligentnou technikou, ktorá by mohla byť použitá na zlepšenie výkonu počítačových hier. Zvláda totiž komplexné problémy ovládania správania za použitia minimálnych nárokov na výpočetnú techniku. Kontrolovanie správania pomocou fuzzy logiky sa dá určite použiť na hry akejkoľvek architektúry.

= Odpovede na otázky =
'''1.''' Nezmenil by sa. Pri 1 pravidle sú odpovede jednoznačné, takže matica bude mať rovnaký počet výstupov aj v prípade, ak by množina s pozdravmi obsahovala iba 1 prvok.
'''2.''' Príbuzenský vzťah, hierarchické postavenie (môže sa týkať napríklad štátnej moci alebo aj postavenia vo firme), miesto stretnutia atď.
'''3.a)''' Starec by pozdravil chlapca kráľa "Dobrý deň". [(hodnosť kráľa)100 * 0.1 = '''10 > 0.6''']
'''3.b)''' Starec kňaz by pozdravil chlapca kráľa "Ahoj". [ (hodnosť kráľa)100 * 0.1 = '''10 < 12''' = 0.6 * 20 (hodnosť kňaza)]
'''3.c)''' Starec kňaz pozdraví chlapca kráľa pozdravom "Dobrý deň" o 3 roky [100 * 0.13 = '''13 > 12.6''' = 0.63 * 20]

= Zdroje =

<references/>
* https://www.samsung.com/in/support/home-appliances/what-is-fuzzy-logic-in-a-washing-machine/

Fuzzy logic/cs

2019-06-12T21:43:22Z

Turd01: /* Návrh modelu */

{{DISPLAYTITLE:Fuzzy logika v agentním rozhodování}}

= Úvod =

[[File:Zadeh.gif|thumb|right|L.A. Zadeh]]
'''Fuzzy Logika''' vznikla v kontexte teórie Fuzzy množín, ktorú prvý krát predstavil '''L. A. Zadeh''' v roku 1965. Fuzzy množina priradí stupeň členstva (reálne číslo z intervalu [0,1]) elementom vesmíru, pričom fuzzy logika vzniká až priradením stupňov pravdy k týmto vzniknutým elementom. Vzťahuje sa na rodinu [https://plato.stanford.edu/archives/win2017/entries/logic-manyvalued viachodnotových logík], takže je určená na modelovanie logických úvah s neurčitými alebo nepresnými údajmi. Stanovuje, že hodnota pravdy (v tomto prípade pravdivostný stupeň) logicky zloženého návrhu (napr. "Peter je bohatý a Ivan je vysoký.") je určená pravdivosťou jeho komponentov, inak povedané, nepočíta iba s 2 možnými hodnotami pravdy. <ref name="fuzzyBasic"> Cintula, Petr, Fermüller, Christian G. and Noguera, Carles, "Fuzzy Logic", The Stanford Encyclopedia of Philosophy (Fall 2017 Edition), Edward N. Zalta (ed.), Dostupné z : https://plato.stanford.edu/archives/fall2017/entries/logic-fuzzy/</ref>.

Pri použití Fuzzy logiky na štandardnej škále oboru hodnôt [0,1] potom :
* '''"úplná nepravda"''' je reprezentovaná hraničnou hodnotou '''0'''
* '''"úplná pravda"''' je reprezentovaná hraničnou hodnotou '''1'''
* '''"čiastočná pravda"''' je reprezentovaná všetkými ostatnými hodnotami (nazývané aj '''stredné stupne pravdy''')

Viac o agentoch sa môžete dočítať v [http://www.simulace.info/index.php/Agents/cs kapitole na to určenej]. Pre nás bude užitočná najmä podkapitola o [http://www.simulace.info/index.php/Agents/cs#Deliberativn.C3.AD_agenty Deliberatívnych agentoch], v ktorej sa píše aj o teórií '''BDI''', ktorá tvorí sofistikovaný prístup k architektúre agenta a skladá sa z troch základných pojmov :
* Beliefs(domnienky)
* Desires(túžby)
* Intentions(zámery)

Na základe týchto 3 faktorov, a teda domnienok, túžob a prianí agent uvažuje o svete a teda o svojom rozhodovaní, ktorému je tento učební text venovaný.

----

= Fuzzy logika z každodenného života =

Pre lepšie pochopenie fuzzy logiky si uvedieme 2 príklady z bežného života:
* spotrebič, ktorý fuzzy logiku využíva
* činnosť, pri ktorom fuzzy logiku využívame automaticky bez toho, aby sme si vôbec uvedomovali, že sa nejaké rozhodovanie v mozgu uskutočňuje.

== Fuzzy logika v práčkach Samsung ==

[[File:fuzzyInWashingMachine.png|250px|left|Slovo FUZZY použité ako značka práčky Samsung a graf znázorňujúci procesy a ich následnosť]]
Trend integrovania '''Fuzzy logiky''' do práčiek Sasmung sa v posledných rokoch teší väčšej popularite. Senzory kontinuálne monitorujú premenlivé podmienky vo vnútri práčky a starostlivo vyberajú a nastavujú operácie pre dosiahnutie najlepších čiastiacich výsledkov.

Fuzzy logika má na starosti okrem iného kontrolu prívodu vody, teploty vody, času prania,kvality žmýkania alebo rýchlosť bubna. Viac sofistikované práčky vedia zvážiť hmotnosť oblečenia( takže zabraňujú preťaženiu práčky), poradia odporúčané množstvo čistiaceho prostriedku alebo vedia skontrolovať, či je čistiaci prostriedok v práškovom alebo tekutom stave. Niektoré sa dokonca vedia učiť z predošlých skúseností, zapamätávať si programy a regulovať činnosť práčky pre minimalizovanie nákladov na jej fungovanie.

== Ahoj vs. Dobrý deň ==

Ľudia by sa podľa veku mohli deliť na viacero kategórií. Pre jednoduchosť si ich rozdelíme iba do dvoch kategórií - starí a mladí. Podľa etikety slušného správania starí ľudia mladím zväčša tikajú a mladí naopak starím vykajú. Existujú samozrejme aj výnimky, napríklad vnúčata dnes bežne svojím starím rodičom tikajú. Alebo si niekedy medzi sebou vykajú aj dvaja mladí ľudia, keď napríklad vybavujú nejakú formálnu záležitosť. Ľudia dodržujúci zásady slušného správania by sa teda mali správať podľa nejakého vzoru etického správania, čo je príkladom fuzzy rozhodovania a priradenia '''(prekonvertovania)''' množín možných vstupov '''(stretnutí)''' s rozličnými vlastnosťtami '''(starý vs. mladý, stretnutie v krčme vs. stretnutie v banke, blízka vs. cudzia osoba, ...)''' na množinu možných výstupov '''(dobrý deň, ahoj, nazdar, ...)'''.

=== Návrh modelu ===

Pre jednoduchosť si fuzzy logiku vysvetlíme iba na základe jednej vlastnosti - veku (tá sa samozrejme môže meniť na základe určenia priorít, to ale komplikuje vysvetlovanie a táto komplikácia je vysvetlená v [http://www.simulace.info/index.php/Fuzzy_logic/cs#Fuzzy_rule-based_syst.C3.A9my kapitole nižšie]). Neberieme teda do úvahy žiadne iné vlastnosti agentov, ktoré by mohli zmeniť ich správanie.

[[File:fuzzyAgesAndGreetings.png|350px|center]]

Samozrejme, výsledná matica pozdravov nie je finálna, no ak by fuzzy logika obsahovala iba jedinnú premennú '''vek''' a 3 ľudí vo veku 10, 40 a 60 rokov, mohla by vyzerať nejak podobne. Dôležitý je predovšetkým výpočet faktoru veku, ktorý je v tomto prípade počítaný ako podiel '''vek/X''', kde X = 100 (tieto hodnoty môžeme vidieť na obrázku vyššie a je iba na nás, čo dosadíme za X).

Čo teda vieme z modelu vyčítať:
* 2 kategórie: '''Starí''' a '''Mladí''' s hraničným bodom delenia 50 (limit)
* prirodzená úcta k starším (mladší ľudia starším ľuďom vykajú)
* množinu vstupov ľudí '''{10,40,60}''' obsahujúcich vlastnosť veku
* množinou pozdravov '''{"Dobrý deň", "Ahoj"}'''

=== Výsledná fuzzy množina a možné rozšírenie úlohy ===

Ak by sme teda zaradzovali daných ľudí len do 2 kategórií na základe jedného pravidla, ktoré by spočívalo v porovnávaní faktoru veku s konštantou limit, dostali by sme maticu '''3x2''' možných pozdravov. Nie je teda vôbec doležité, ako nastavíme konštantu limit, pri jej zmene sa iba zmenia určené pozdravy, nie však počet prvkov matice a teda všetky možné kombinácie stretnutí majú vždy jasne danú reakciu z oboch strán.

Pri stretnutí dvoch rovesníkov som trochu načŕtol možné rozšírenie úlohy, keď som neurčil, či bude pozdrav "Ahoj" alebo "Dobrý deň". Samozrejme, ak platia pravidlá vyššie (pri dvoch malých chlapcoch som si ale dovolil spraviť výnimku, málokedy vidíme zdraviť sa ich pozdravom "Dobrý deň"), pri stretuntí dvoch '''40''' by mal byť pozdrav "Ahoj" (keďže obaja spĺňajú podmienku "mladosti") a dvoch '''60''' ročných pánov v klobúku "Dobrý deň".

Výnimka však potvrdzuje pravidlo a v prípade 10 ročného kráľa by sme aj 60 ročného starca videli pozdraviť ho pozdravom "Dobrý deň"(ak tam samozrejme nie sú ďalšie pravidlá, ktorú môžu túto logiku upravovať, ako napríklad príbuzenský vzťah a podobne). Možnosť voľby z dvoch pozdravov pri '''40''' a '''60''' ročných mužoch teda malo načŕtnuť pointu fuzzy logiky a možnosti jej rozšírenia, aj keď táto možnosť výberu sa vyskytne až po zaradení ďalších pravidiel.

=== Úlohy na precvičenie Fuzzy logiky ===

3 úlohy na záver (odpovede sa nachádzajú úplne dole ako posledná kapitola):
'''1.''' Ako by vyzeral výsledný počet možných výstupov, ak by sme do množiny pozdravov v príklade vyššie pridali pozdrav "Nazdar"?
'''2.''' Aké by mohli byť ďalšie vlasnosti, ktoré by menili faktor veku?
'''3.''' Ako by vyzeral pozdrav pri stretnutí 60 ročného starca (zmena faktoru veku z príkladu vyššie), ak do modelu pridáme nasledujúce vlasnosti :
'''3.a)''' Hodnosť kráľa znásobuje súčasný váhu 100 krát?
'''3.b)''' Hodnosť kňaza znásobuje súčasný váhu 20 krát?
'''3.c)''' O koľko rokov kňaz začne oslovovať kráľa "Dobrý deň"?

----

= Fuzzy logika v agentovo-orientovaných počítačových hrách <ref name="book"> Li, Yifan & Musilek, Petr & Wyard-Scott, L. (2004).Fuzzy logic in agent-based game design. 734 - 739 Vol.2. 10.1109/NAFIPS.2004.1337393. Dostupné z : https://www.researchgate.net/publication/4092875_Fuzzy_logic_in_agent-based_game_design</ref>=

[[File:fuzzyBattleCity.png|thumb|right|Prevedenie možného použitia fuzyy logiky v známej arkádovej hre BattleCity. Kružnice znázorňujú rôzne vstupy, na základe ktorých sa agenti rozhodujú o svojej ďalšej akcii]]
Umelá inteligencia v počítačových hrách sa vďaka rastúcim požiadavkám hráčov musí neustále zlepšovať. Inteligentní agenti môžu spolu s fuzzy logikou vylepšiť najdôležitejší prvok hier - '''interakciu'''. Agenti ponúkajú lepšie možnosti flexibilnej interakcie v rámci architektúry herného dizajnu, pričom fuzzy logika umožňuje lepšie kontrolovať správanie pre vytvorenie najrôznejších foriem umelých inteligencií.

== Porovnanie s inými technikami ==

Vo svete hier neznamená '''fuzzy kontrola''' iba ďalšiu metódu pre správanie agentov. Kontrolovanie agentov pomocou fuzzy logiky je zárukou '''generovania "správneho" správania'''. Toto prirodzené správanie agentov potom pomáha zvyšovať vnímanú zložitosť a dôveryhodnosť virtuálneho prostredia. V porovnaní s niektorými inými technikami návrhu inteligentných systémov sú systémy založené na fuzzy pravidlách jednoduché na návrh aj implementáciu. Klasické '''rule-based''' systémy pritom často nedokážu dosiahnuť prirodzenosť, akú ponúkajú '''fuzzy systémy''', pričom tie spotrebujú omnoho nižšie výpočtové náklady.

== Fuzzy rule-based systémy ==

Systémy založené na fuzzy pravidlách sa vo všeobecnosti skladajú z 4 komponentov:
* '''fuzzifier''' konvertuje sparsované vstupy z klienta do fuzzy množín
* základňa pravidiel ('''rule-base''') uchováva všetky vzťahy medzi vstupmi a očakávanými výstupmi v kolekcií '''IF-THEN''' pravidiel
* '''uvažujúca jednotka''' použije vstupy a aplikuje na nich konkrétne pravidlá
* '''defuzzifier''' prekonvertuje výsledok rozhodovania a sparsované výstupy pošle späť na klienta

V prípade viacerých vstupov sú fuzzy pravidlá väčšinou prepojené logickým spojením (konektorom) AND, pričom '''rule-base''' musí pokrývať každú možnú kombináciu všetkých výrazov z definičného oboru vstupnej premennej. Táto požiadavka úplnosti ale vedie k tzv. '''rule explosion problém'''-u, kde pre systém s n vstupmi, ktorý má každý m možných stavov potrebujeme celkovo '''m^n''' pravidiel! Toto pravidlo výbuchu predstavuje vážny problém a komplikuje implementovanie fuzzy kontrolovania vďaka vysokým nárokom na CPU zdroje. Combs navrhol [https://en.wikipedia.org/wiki/Combs_method URC (Union Rule Configuration)] na zmiernenie tohto problému, kedy sa zložitosť výpočtu zníži na '''m*n''' pravidiel.

== Zhrnutie ==

Agentovo-orientovaný prístup pri vývoji hier ponúka mnoho výhod počas celého vývojového cyklu. Poskytuje prirodzený spôsob modelovania herných postáv a veľmi felxibilnú softwérovú architektúru umožňujúcu rozkvet správania agentov za použitia minimálneho počtu spojení. Navyše, pomocou nového prístupu k dizajnu ich môžu programátori ľahko integrovať do starších herných vývojových prostredí.

Fuzzy logika je ďalšou inteligentnou technikou, ktorá by mohla byť použitá na zlepšenie výkonu počítačových hier. Zvláda totiž komplexné problémy ovládania správania za použitia minimálnych nárokov na výpočetnú techniku. Kontrolovanie správania pomocou fuzzy logiky sa dá určite použiť na hry akejkoľvek architektúry.

= Odpovede na otázky =
'''1.''' Nezmenil by sa. Pri 1 pravidle sú odpovede jednoznačné, takže matica bude mať rovnaký počet výstupov aj v prípade, ak by množina s pozdravmi obsahovala iba 1 prvok.
'''2.''' Príbuzenský vzťah, hierarchické postavenie (môže sa týkať napríklad štátnej moci alebo aj postavenia vo firme), miesto stretnutia atď.
'''3.a)''' Starec by pozdravil chlapca kráľa "Dobrý deň". [(hodnosť kráľa)100 * 0.1 = '''10 > 0.6''']
'''3.b)''' Starec kňaz by pozdravil chlapca kráľa "Ahoj". [ (hodnosť kráľa)100 * 0.1 = '''10 < 12''' = 0.6 * 20 (hodnosť kňaza)]
'''3.c)''' Starec kňaz pozdraví chlapca kráľa pozdravom "Dobrý deň" o 3 roky [100 * 0.13 = '''13 > 12.6''' = 0.63 * 20]

= Zdroje =

<references/>
* https://www.samsung.com/in/support/home-appliances/what-is-fuzzy-logic-in-a-washing-machine/

Fuzzy logic/cs

2019-06-12T21:40:36Z

Turd01:

{{DISPLAYTITLE:Fuzzy logika v agentním rozhodování}}

= Úvod =

[[File:Zadeh.gif|thumb|right|L.A. Zadeh]]
'''Fuzzy Logika''' vznikla v kontexte teórie Fuzzy množín, ktorú prvý krát predstavil '''L. A. Zadeh''' v roku 1965. Fuzzy množina priradí stupeň členstva (reálne číslo z intervalu [0,1]) elementom vesmíru, pričom fuzzy logika vzniká až priradením stupňov pravdy k týmto vzniknutým elementom. Vzťahuje sa na rodinu [https://plato.stanford.edu/archives/win2017/entries/logic-manyvalued viachodnotových logík], takže je určená na modelovanie logických úvah s neurčitými alebo nepresnými údajmi. Stanovuje, že hodnota pravdy (v tomto prípade pravdivostný stupeň) logicky zloženého návrhu (napr. "Peter je bohatý a Ivan je vysoký.") je určená pravdivosťou jeho komponentov, inak povedané, nepočíta iba s 2 možnými hodnotami pravdy. <ref name="fuzzyBasic"> Cintula, Petr, Fermüller, Christian G. and Noguera, Carles, "Fuzzy Logic", The Stanford Encyclopedia of Philosophy (Fall 2017 Edition), Edward N. Zalta (ed.), Dostupné z : https://plato.stanford.edu/archives/fall2017/entries/logic-fuzzy/</ref>.

Pri použití Fuzzy logiky na štandardnej škále oboru hodnôt [0,1] potom :
* '''"úplná nepravda"''' je reprezentovaná hraničnou hodnotou '''0'''
* '''"úplná pravda"''' je reprezentovaná hraničnou hodnotou '''1'''
* '''"čiastočná pravda"''' je reprezentovaná všetkými ostatnými hodnotami (nazývané aj '''stredné stupne pravdy''')

Viac o agentoch sa môžete dočítať v [http://www.simulace.info/index.php/Agents/cs kapitole na to určenej]. Pre nás bude užitočná najmä podkapitola o [http://www.simulace.info/index.php/Agents/cs#Deliberativn.C3.AD_agenty Deliberatívnych agentoch], v ktorej sa píše aj o teórií '''BDI''', ktorá tvorí sofistikovaný prístup k architektúre agenta a skladá sa z troch základných pojmov :
* Beliefs(domnienky)
* Desires(túžby)
* Intentions(zámery)

Na základe týchto 3 faktorov, a teda domnienok, túžob a prianí agent uvažuje o svete a teda o svojom rozhodovaní, ktorému je tento učební text venovaný.

----

= Fuzzy logika z každodenného života =

Pre lepšie pochopenie fuzzy logiky si uvedieme 2 príklady z bežného života:
* spotrebič, ktorý fuzzy logiku využíva
* činnosť, pri ktorom fuzzy logiku využívame automaticky bez toho, aby sme si vôbec uvedomovali, že sa nejaké rozhodovanie v mozgu uskutočňuje.

== Fuzzy logika v práčkach Samsung ==

[[File:fuzzyInWashingMachine.png|250px|left|Slovo FUZZY použité ako značka práčky Samsung a graf znázorňujúci procesy a ich následnosť]]
Trend integrovania '''Fuzzy logiky''' do práčiek Sasmung sa v posledných rokoch teší väčšej popularite. Senzory kontinuálne monitorujú premenlivé podmienky vo vnútri práčky a starostlivo vyberajú a nastavujú operácie pre dosiahnutie najlepších čiastiacich výsledkov.

Fuzzy logika má na starosti okrem iného kontrolu prívodu vody, teploty vody, času prania,kvality žmýkania alebo rýchlosť bubna. Viac sofistikované práčky vedia zvážiť hmotnosť oblečenia( takže zabraňujú preťaženiu práčky), poradia odporúčané množstvo čistiaceho prostriedku alebo vedia skontrolovať, či je čistiaci prostriedok v práškovom alebo tekutom stave. Niektoré sa dokonca vedia učiť z predošlých skúseností, zapamätávať si programy a regulovať činnosť práčky pre minimalizovanie nákladov na jej fungovanie.

== Ahoj vs. Dobrý deň ==

Ľudia by sa podľa veku mohli deliť na viacero kategórií. Pre jednoduchosť si ich rozdelíme iba do dvoch kategórií - starí a mladí. Podľa etikety slušného správania starí ľudia mladím zväčša tikajú a mladí naopak starím vykajú. Existujú samozrejme aj výnimky, napríklad vnúčata dnes bežne svojím starím rodičom tikajú. Alebo si niekedy medzi sebou vykajú aj dvaja mladí ľudia, keď napríklad vybavujú nejakú formálnu záležitosť. Ľudia dodržujúci zásady slušného správania by sa teda mali správať podľa nejakého vzoru etického správania, čo je príkladom fuzzy rozhodovania a priradenia '''(prekonvertovania)''' množín možných vstupov '''(stretnutí)''' s rozličnými vlastnosťtami '''(starý vs. mladý, stretnutie v krčme vs. stretnutie v banke, blízka vs. cudzia osoba, ...)''' na množinu možných výstupov '''(dobrý deň, ahoj, nazdar, ...)'''.

=== Návrh modelu ===

Pre jednoduchosť si fuzzy logiku vysvetlíme iba na základe jednej vlastnosti - veku (tá sa samozrejme môže meniť na základe určenia priorít, to ale komplikuje vysvetlovanie a táto komplikácia je vysvetlená v [http://www.simulace.info/index.php/Fuzzy_logic/cs#Fuzzy_rule-based_syst.C3.A9my kapitole nižšie]). Neberieme teda do úvahy žiadne iné vlastnosti agentov, ktoré by mohli zmeniť ich správanie.

[[File:fuzzyAgesAndGreetings.png|350px|center]]

Samozrejme, výsledná matica pozdravov nie je finálna, no ak by fuzzy logika obsahovala iba jedinnú premennú '''vek''' a 3 ľudí vo veku 10, 40 a 60 rokov, mohla by vyzerať nejak podobne. Dôležitý je predovšetkým výpočet faktoru veku, ktorý je v tomto prípade počítaný ako podiel '''vek/X''', kde X = 100 (tieto hodnoty môžeme vidieť na obrázku vyššie a je iba na nás, čo dosadíme za X).

Čo teda vieme z modelu vyčítať:
* 2 kategórie: '''Starí''' a '''Mladí''' s hraničným bodom delenia 50 (limit)
* prirodzená úcta k starším (mladší ľudia starším ľuďom vykajú)
* množinu vstupov ľudí '''{10,40,50}''' obsahujúcich vlastnosť veku
* množinou pozdravov '''{"Dobrý deň", "Ahoj"}'''

=== Výsledná fuzzy množina a možné rozšírenie úlohy ===

Ak by sme teda zaradzovali daných ľudí len do 2 kategórií na základe jedného pravidla, ktoré by spočívalo v porovnávaní faktoru veku s konštantou limit, dostali by sme maticu '''3x2''' možných pozdravov. Nie je teda vôbec doležité, ako nastavíme konštantu limit, pri jej zmene sa iba zmenia určené pozdravy, nie však počet prvkov matice a teda všetky možné kombinácie stretnutí majú vždy jasne danú reakciu z oboch strán.

Pri stretnutí dvoch rovesníkov som trochu načŕtol možné rozšírenie úlohy, keď som neurčil, či bude pozdrav "Ahoj" alebo "Dobrý deň". Samozrejme, ak platia pravidlá vyššie (pri dvoch malých chlapcoch som si ale dovolil spraviť výnimku, málokedy vidíme zdraviť sa ich pozdravom "Dobrý deň"), pri stretuntí dvoch '''40''' by mal byť pozdrav "Ahoj" (keďže obaja spĺňajú podmienku "mladosti") a dvoch '''60''' ročných pánov v klobúku "Dobrý deň".

Výnimka však potvrdzuje pravidlo a v prípade 10 ročného kráľa by sme aj 60 ročného starca videli pozdraviť ho pozdravom "Dobrý deň"(ak tam samozrejme nie sú ďalšie pravidlá, ktorú môžu túto logiku upravovať, ako napríklad príbuzenský vzťah a podobne). Možnosť voľby z dvoch pozdravov pri '''40''' a '''60''' ročných mužoch teda malo načŕtnuť pointu fuzzy logiky a možnosti jej rozšírenia, aj keď táto možnosť výberu sa vyskytne až po zaradení ďalších pravidiel.

=== Úlohy na precvičenie Fuzzy logiky ===

3 úlohy na záver (odpovede sa nachádzajú úplne dole ako posledná kapitola):
'''1.''' Ako by vyzeral výsledný počet možných výstupov, ak by sme do množiny pozdravov v príklade vyššie pridali pozdrav "Nazdar"?
'''2.''' Aké by mohli byť ďalšie vlasnosti, ktoré by menili faktor veku?
'''3.''' Ako by vyzeral pozdrav pri stretnutí 60 ročného starca (zmena faktoru veku z príkladu vyššie), ak do modelu pridáme nasledujúce vlasnosti :
'''3.a)''' Hodnosť kráľa znásobuje súčasný váhu 100 krát?
'''3.b)''' Hodnosť kňaza znásobuje súčasný váhu 20 krát?
'''3.c)''' O koľko rokov kňaz začne oslovovať kráľa "Dobrý deň"?

----

= Fuzzy logika v agentovo-orientovaných počítačových hrách <ref name="book"> Li, Yifan & Musilek, Petr & Wyard-Scott, L. (2004).Fuzzy logic in agent-based game design. 734 - 739 Vol.2. 10.1109/NAFIPS.2004.1337393. Dostupné z : https://www.researchgate.net/publication/4092875_Fuzzy_logic_in_agent-based_game_design</ref>=

[[File:fuzzyBattleCity.png|thumb|right|Prevedenie možného použitia fuzyy logiky v známej arkádovej hre BattleCity. Kružnice znázorňujú rôzne vstupy, na základe ktorých sa agenti rozhodujú o svojej ďalšej akcii]]
Umelá inteligencia v počítačových hrách sa vďaka rastúcim požiadavkám hráčov musí neustále zlepšovať. Inteligentní agenti môžu spolu s fuzzy logikou vylepšiť najdôležitejší prvok hier - '''interakciu'''. Agenti ponúkajú lepšie možnosti flexibilnej interakcie v rámci architektúry herného dizajnu, pričom fuzzy logika umožňuje lepšie kontrolovať správanie pre vytvorenie najrôznejších foriem umelých inteligencií.

== Porovnanie s inými technikami ==

Vo svete hier neznamená '''fuzzy kontrola''' iba ďalšiu metódu pre správanie agentov. Kontrolovanie agentov pomocou fuzzy logiky je zárukou '''generovania "správneho" správania'''. Toto prirodzené správanie agentov potom pomáha zvyšovať vnímanú zložitosť a dôveryhodnosť virtuálneho prostredia. V porovnaní s niektorými inými technikami návrhu inteligentných systémov sú systémy založené na fuzzy pravidlách jednoduché na návrh aj implementáciu. Klasické '''rule-based''' systémy pritom často nedokážu dosiahnuť prirodzenosť, akú ponúkajú '''fuzzy systémy''', pričom tie spotrebujú omnoho nižšie výpočtové náklady.

== Fuzzy rule-based systémy ==

Systémy založené na fuzzy pravidlách sa vo všeobecnosti skladajú z 4 komponentov:
* '''fuzzifier''' konvertuje sparsované vstupy z klienta do fuzzy množín
* základňa pravidiel ('''rule-base''') uchováva všetky vzťahy medzi vstupmi a očakávanými výstupmi v kolekcií '''IF-THEN''' pravidiel
* '''uvažujúca jednotka''' použije vstupy a aplikuje na nich konkrétne pravidlá
* '''defuzzifier''' prekonvertuje výsledok rozhodovania a sparsované výstupy pošle späť na klienta

V prípade viacerých vstupov sú fuzzy pravidlá väčšinou prepojené logickým spojením (konektorom) AND, pričom '''rule-base''' musí pokrývať každú možnú kombináciu všetkých výrazov z definičného oboru vstupnej premennej. Táto požiadavka úplnosti ale vedie k tzv. '''rule explosion problém'''-u, kde pre systém s n vstupmi, ktorý má každý m možných stavov potrebujeme celkovo '''m^n''' pravidiel! Toto pravidlo výbuchu predstavuje vážny problém a komplikuje implementovanie fuzzy kontrolovania vďaka vysokým nárokom na CPU zdroje. Combs navrhol [https://en.wikipedia.org/wiki/Combs_method URC (Union Rule Configuration)] na zmiernenie tohto problému, kedy sa zložitosť výpočtu zníži na '''m*n''' pravidiel.

== Zhrnutie ==

Agentovo-orientovaný prístup pri vývoji hier ponúka mnoho výhod počas celého vývojového cyklu. Poskytuje prirodzený spôsob modelovania herných postáv a veľmi felxibilnú softwérovú architektúru umožňujúcu rozkvet správania agentov za použitia minimálneho počtu spojení. Navyše, pomocou nového prístupu k dizajnu ich môžu programátori ľahko integrovať do starších herných vývojových prostredí.

Fuzzy logika je ďalšou inteligentnou technikou, ktorá by mohla byť použitá na zlepšenie výkonu počítačových hier. Zvláda totiž komplexné problémy ovládania správania za použitia minimálnych nárokov na výpočetnú techniku. Kontrolovanie správania pomocou fuzzy logiky sa dá určite použiť na hry akejkoľvek architektúry.

= Odpovede na otázky =
'''1.''' Nezmenil by sa. Pri 1 pravidle sú odpovede jednoznačné, takže matica bude mať rovnaký počet výstupov aj v prípade, ak by množina s pozdravmi obsahovala iba 1 prvok.
'''2.''' Príbuzenský vzťah, hierarchické postavenie (môže sa týkať napríklad štátnej moci alebo aj postavenia vo firme), miesto stretnutia atď.
'''3.a)''' Starec by pozdravil chlapca kráľa "Dobrý deň". [(hodnosť kráľa)100 * 0.1 = '''10 > 0.6''']
'''3.b)''' Starec kňaz by pozdravil chlapca kráľa "Ahoj". [ (hodnosť kráľa)100 * 0.1 = '''10 < 12''' = 0.6 * 20 (hodnosť kňaza)]
'''3.c)''' Starec kňaz pozdraví chlapca kráľa pozdravom "Dobrý deň" o 3 roky [100 * 0.13 = '''13 > 12.6''' = 0.63 * 20]

= Zdroje =

<references/>
* https://www.samsung.com/in/support/home-appliances/what-is-fuzzy-logic-in-a-washing-machine/

Fuzzy logic/cs

2019-06-12T21:39:41Z

Turd01: /* Zhrnutie */

{{DISPLAYTITLE:Fuzzy logika v agentním rozhodování}}

= Úvod =

[[File:Zadeh.gif|thumb|right|L.A. Zadeh]]
'''Fuzzy Logika''' vznikla v kontexte teórie Fuzzy množín, ktorú prvý krát predstavil '''L. A. Zadeh''' v roku 1965. Fuzzy množina priradí stupeň členstva (reálne číslo z intervalu [0,1]) elementom vesmíru, pričom fuzzy logika vzniká až priradením stupňov pravdy k týmto vzniknutým elementom. Vzťahuje sa na rodinu [https://plato.stanford.edu/archives/win2017/entries/logic-manyvalued viachodnotových logík], takže je určená na modelovanie logických úvah s neurčitými alebo nepresnými údajmi. Stanovuje, že hodnota pravdy (v tomto prípade pravdivostný stupeň) logicky zloženého návrhu (napr. "Peter je bohatý a Ivan je vysoký.") je určená pravdivosťou jeho komponentov, inak povedané, nepočíta iba s 2 možnými hodnotami pravdy. <ref name="fuzzyBasic"> Cintula, Petr, Fermüller, Christian G. and Noguera, Carles, "Fuzzy Logic", The Stanford Encyclopedia of Philosophy (Fall 2017 Edition), Edward N. Zalta (ed.), Dostupné z : https://plato.stanford.edu/archives/fall2017/entries/logic-fuzzy/</ref>.

Pri použití Fuzzy logiky na štandardnej škále oboru hodnôt [0,1] potom :
* '''"úplná nepravda"''' je reprezentovaná hraničnou hodnotou '''0'''
* '''"úplná pravda"''' je reprezentovaná hraničnou hodnotou '''1'''
* '''"čiastočná pravda"''' je reprezentovaná všetkými ostatnými hodnotami (nazývané aj '''stredné stupne pravdy''')

Viac o agentoch sa môžete dočítať v [http://www.simulace.info/index.php/Agents/cs kapitole na to určenej]. Pre nás bude užitočná najmä podkapitola o [http://www.simulace.info/index.php/Agents/cs#Deliberativn.C3.AD_agenty Deliberatívnych agentoch], v ktorej sa píše aj o teórií '''BDI''', ktorá tvorí sofistikovaný prístup k architektúre agenta a skladá sa z troch základných pojmov :
* Beliefs(domnienky)
* Desires(túžby)
* Intentions(zámery)

Na základe týchto 3 faktorov, a teda domnienok, túžob a prianí agent uvažuje o svete a teda o svojom rozhodovaní, ktorému je tento učební text venovaný.

----

= Fuzzy logika z každodenného života =

Pre lepšie pochopenie fuzzy logiky si uvedieme 2 príklady z bežného života:
* spotrebič, ktorý fuzzy logiku využíva
* činnosť, pri ktorom fuzzy logiku využívame automaticky bez toho, aby sme si vôbec uvedomovali, že sa nejaké rozhodovanie v mozgu uskutočňuje.

== Fuzzy logika v práčkach Samsung ==

[[File:fuzzyInWashingMachine.png|250px|left|Slovo FUZZY použité ako značka práčky Samsung a graf znázorňujúci procesy a ich následnosť]]
Trend integrovania '''Fuzzy logiky''' do práčiek Sasmung sa v posledných rokoch teší väčšej popularite. Senzory kontinuálne monitorujú premenlivé podmienky vo vnútri práčky a starostlivo vyberajú a nastavujú operácie pre dosiahnutie najlepších čiastiacich výsledkov.

Fuzzy logika má na starosti okrem iného kontrolu prívodu vody, teploty vody, času prania,kvality žmýkania alebo rýchlosť bubna. Viac sofistikované práčky vedia zvážiť hmotnosť oblečenia( takže zabraňujú preťaženiu práčky), poradia odporúčané množstvo čistiaceho prostriedku alebo vedia skontrolovať, či je čistiaci prostriedok v práškovom alebo tekutom stave. Niektoré sa dokonca vedia učiť z predošlých skúseností, zapamätávať si programy a regulovať činnosť práčky pre minimalizovanie nákladov na jej fungovanie.

== Ahoj vs. Dobrý deň ==

Ľudia by sa podľa veku mohli deliť na viacero kategórií. Pre jednoduchosť si ich rozdelíme iba do dvoch kategórií - starí a mladí. Podľa etikety slušného správania starí ľudia mladím zväčša tikajú a mladí naopak starím vykajú. Existujú samozrejme aj výnimky, napríklad vnúčata dnes bežne svojím starím rodičom tikajú. Alebo si niekedy medzi sebou vykajú aj dvaja mladí ľudia, keď napríklad vybavujú nejakú formálnu záležitosť. Ľudia dodržujúci zásady slušného správania by sa teda mali správať podľa nejakého vzoru etického správania, čo je príkladom fuzzy rozhodovania a priradenia '''(prekonvertovania)''' množín možných vstupov '''(stretnutí)''' s rozličnými vlastnosťtami '''(starý vs. mladý, stretnutie v krčme vs. stretnutie v banke, blízka vs. cudzia osoba, ...)''' na množinu možných výstupov '''(dobrý deň, ahoj, nazdar, ...)'''.

=== Návrh modelu ===

Pre jednoduchosť si fuzzy logiku vysvetlíme iba na základe jednej vlastnosti - veku (tá sa samozrejme môže meniť na základe určenia priorít, to ale komplikuje vysvetlovanie a táto komplikácia je vysvetlená v [http://www.simulace.info/index.php/Fuzzy_logic/cs#Fuzzy_rule-based_syst.C3.A9my kapitole nižšie]). Neberieme teda do úvahy žiadne iné vlastnosti agentov, ktoré by mohli zmeniť ich správanie.

[[File:fuzzyAgesAndGreetings.png|350px|center]]

Samozrejme, výsledná matica pozdravov nie je finálna, no ak by fuzzy logika obsahovala iba jedinnú premennú '''vek''' a 3 ľudí vo veku 10, 40 a 60 rokov, mohla by vyzerať nejak podobne. Dôležitý je predovšetkým výpočet faktoru veku, ktorý je v tomto prípade počítaný ako podiel '''vek/X''', kde X = 100 (tieto hodnoty môžeme vidieť na obrázku vyššie a je iba na nás, čo dosadíme za X).

Čo teda vieme z modelu vyčítať:
* 2 kategórie: '''Starí''' a '''Mladí''' s hraničným bodom delenia 50 (limit)
* prirodzená úcta k starším (mladší ľudia starším ľuďom vykajú)
* množinu vstupov ľudí '''{10,40,50}''' obsahujúcich vlastnosť veku
* množinou pozdravov '''{"Dobrý deň", "Ahoj"}'''

=== Výsledná fuzzy množina a možné rozšírenie úlohy ===

Ak by sme teda zaradzovali daných ľudí len do 2 kategórií na základe jedného pravidla, ktoré by spočívalo v porovnávaní faktoru veku s konštantou limit, dostali by sme maticu '''3x2''' možných pozdravov. Nie je teda vôbec doležité, ako nastavíme konštantu limit, pri jej zmene sa iba zmenia určené pozdravy, nie však počet prvkov matice a teda všetky možné kombinácie stretnutí majú vždy jasne danú reakciu z oboch strán.

Pri stretnutí dvoch rovesníkov som trochu načŕtol možné rozšírenie úlohy, keď som neurčil, či bude pozdrav "Ahoj" alebo "Dobrý deň". Samozrejme, ak platia pravidlá vyššie (pri dvoch malých chlapcoch som si ale dovolil spraviť výnimku, málokedy vidíme zdraviť sa ich pozdravom "Dobrý deň"), pri stretuntí dvoch '''40''' by mal byť pozdrav "Ahoj" (keďže obaja spĺňajú podmienku "mladosti") a dvoch '''60''' ročných pánov v klobúku "Dobrý deň".

Výnimka však potvrdzuje pravidlo a v prípade 10 ročného kráľa by sme aj 60 ročného starca videli pozdraviť ho pozdravom "Dobrý deň"(ak tam samozrejme nie sú ďalšie pravidlá, ktorú môžu túto logiku upravovať, ako napríklad príbuzenský vzťah a podobne). Možnosť voľby z dvoch pozdravov pri '''40''' a '''60''' ročných mužoch teda malo načŕtnuť pointu fuzzy logiky a možnosti jej rozšírenia, aj keď táto možnosť výberu sa vyskytne až po zaradení ďalších pravidiel.

=== Úlohy na precvičenie Fuzzy logiky ===

3 úlohy na záver (odpovede sa nachádzajú úplne dole ako posledná kapitola):
'''1.''' Ako by vyzeral výsledný počet možných výstupov, ak by sme do množiny pozdravov v príklade vyššie pridali pozdrav "Nazdar"?
'''2.''' Aké by mohli byť ďalšie vlasnosti, ktoré by menili faktor veku?
'''3.''' Ako by vyzeral pozdrav pri stretnutí 60 ročného starca (zmena faktoru veku z príkladu vyššie), ak do modelu pridáme nasledujúce vlasnosti :
'''3.a)''' Hodnosť kráľa znásobuje súčasný váhu 100 krát?
'''3.b)''' Hodnosť kňaza znásobuje súčasný váhu 20 krát?
'''3.c)''' O koľko rokov kňaz začne oslovovať kráľa "Dobrý deň"?

----

= Fuzzy logika v agentovo-orientovaných počítačových hrách <ref name="book"> Li, Yifan & Musilek, Petr & Wyard-Scott, L. (2004).Fuzzy logic in agent-based game design. 734 - 739 Vol.2. 10.1109/NAFIPS.2004.1337393. Dostupné z : https://www.researchgate.net/publication/4092875_Fuzzy_logic_in_agent-based_game_design</ref>=

[[File:fuzzyBattleCity.png|thumb|right|Prevedenie možného použitia fuzyy logiky v známej arkádovej hre BattleCity. Kružnice znázorňujú rôzne vstupy, na základe ktorých sa agenti rozhodujú o svojej ďalšej akcii]]
Umelá inteligencia v počítačových hrách sa vďaka rastúcim požiadavkám hráčov musí neustále zlepšovať. Inteligentní agenti môžu spolu s fuzzy logikou vylepšiť najdôležitejší prvok hier - '''interakciu'''. Agenti ponúkajú lepšie možnosti flexibilnej interakcie v rámci architektúry herného dizajnu, pričom fuzzy logika umožňuje lepšie kontrolovať správanie pre vytvorenie najrôznejších foriem umelých inteligencií.

== Porovnanie s inými technikami ==

Vo svete hier neznamená '''fuzzy kontrola''' iba ďalšiu metódu pre správanie agentov. Kontrolovanie agentov pomocou fuzzy logiky je zárukou '''generovania "správneho" správania'''. Toto prirodzené správanie agentov potom pomáha zvyšovať vnímanú zložitosť a dôveryhodnosť virtuálneho prostredia. V porovnaní s niektorými inými technikami návrhu inteligentných systémov sú systémy založené na fuzzy pravidlách jednoduché na návrh aj implementáciu. Klasické '''rule-based''' systémy pritom často nedokážu dosiahnuť prirodzenosť, akú ponúkajú '''fuzzy systémy''', pričom tie spotrebujú omnoho nižšie výpočtové náklady.

== Fuzzy rule-based systémy ==

Systémy založené na fuzzy pravidlách sa vo všeobecnosti skladajú z 4 komponentov:
* '''fuzzifier''' konvertuje sparsované vstupy z klienta do fuzzy množín
* základňa pravidiel ('''rule-base''') uchováva všetky vzťahy medzi vstupmi a očakávanými výstupmi v kolekcií '''IF-THEN''' pravidiel
* '''uvažujúca jednotka''' použije vstupy a aplikuje na nich konkrétne pravidlá
* '''defuzzifier''' prekonvertuje výsledok rozhodovania a sparsované výstupy pošle späť na klienta

V prípade viacerých vstupov sú fuzzy pravidlá väčšinou prepojené logickým spojením (konektorom) AND, pričom '''rule-base''' musí pokrývať každú možnú kombináciu všetkých výrazov z definičného oboru vstupnej premennej. Táto požiadavka úplnosti ale vedie k tzv. '''rule explosion problém'''-u, kde pre systém s n vstupmi, ktorý má každý m možných stavov potrebujeme celkovo '''m^n''' pravidiel! Toto pravidlo výbuchu predstavuje vážny problém a komplikuje implementovanie fuzzy kontrolovania vďaka vysokým nárokom na CPU zdroje. Combs navrhol [https://en.wikipedia.org/wiki/Combs_method URC (Union Rule Configuration)] na zmiernenie tohto problému, kedy sa zložitosť výpočtu zníži na '''m*n''' pravidiel.

== Zhrnutie ==

Agentovo-orientovaný prístup pri vývoji hier ponúka mnoho výhod počas celého vývojového cyklu. Poskytuje prirodzený spôsob modelovania herných postáv a veľmi felxibilnú softwérovú architektúru umožňujúcu rozkvet správania agentov za použitia minimálneho počtu spojení. Navyše, pomocou nového prístupu k dizajnu ich môžu programátori ľahko integrovať do starších herných vývojových prostredí.

Fuzzy logika je ďalšou inteligentnou technikou, ktorá by mohla byť použitá na zlepšenie výkonu počítačových hier. Zvláda totiž komplexné problémy ovládania správania za použitia minimálnych nárokov na výpočetnú techniku. Kontrolovanie správania pomocou fuzzy logiky sa dá určite použiť na hry akejkoľvek architektúry.

= Zdroje =

<references/>
3. https://www.samsung.com/in/support/home-appliances/what-is-fuzzy-logic-in-a-washing-machine/

= Odpovede =
'''1.''' Nezmenil by sa. Pri 1 pravidle sú odpovede jednoznačné, takže matica bude mať rovnaký počet výstupov aj v prípade, ak by množina s pozdravmi obsahovala iba 1 prvok.
'''2.''' Príbuzenský vzťah, hierarchické postavenie (môže sa týkať napríklad štátnej moci alebo aj postavenia vo firme), miesto stretnutia atď.
'''3.a)''' Starec by pozdravil chlapca kráľa "Dobrý deň". [(hodnosť kráľa)100 * 0.1 = '''10 > 0.6''']
'''3.b)''' Starec kňaz by pozdravil chlapca kráľa "Ahoj". [ (hodnosť kráľa)100 * 0.1 = '''10 < 12''' = 0.6 * 20 (hodnosť kňaza)]
'''3.c)''' Starec kňaz pozdraví chlapca kráľa pozdravom "Dobrý deň" o 3 roky [100 * 0.13 = '''13 > 12.6''' = 0.63 * 20]

Fuzzy logic/cs

2019-06-12T21:27:20Z

Turd01: /* Zdroje */

{{DISPLAYTITLE:Fuzzy logika v agentním rozhodování}}

= Úvod =

[[File:Zadeh.gif|thumb|right|L.A. Zadeh]]
'''Fuzzy Logika''' vznikla v kontexte teórie Fuzzy množín, ktorú prvý krát predstavil '''L. A. Zadeh''' v roku 1965. Fuzzy množina priradí stupeň členstva (reálne číslo z intervalu [0,1]) elementom vesmíru, pričom fuzzy logika vzniká až priradením stupňov pravdy k týmto vzniknutým elementom. Vzťahuje sa na rodinu [https://plato.stanford.edu/archives/win2017/entries/logic-manyvalued viachodnotových logík], takže je určená na modelovanie logických úvah s neurčitými alebo nepresnými údajmi. Stanovuje, že hodnota pravdy (v tomto prípade pravdivostný stupeň) logicky zloženého návrhu (napr. "Peter je bohatý a Ivan je vysoký.") je určená pravdivosťou jeho komponentov, inak povedané, nepočíta iba s 2 možnými hodnotami pravdy. <ref name="fuzzyBasic"> Cintula, Petr, Fermüller, Christian G. and Noguera, Carles, "Fuzzy Logic", The Stanford Encyclopedia of Philosophy (Fall 2017 Edition), Edward N. Zalta (ed.), Dostupné z : https://plato.stanford.edu/archives/fall2017/entries/logic-fuzzy/</ref>.

Pri použití Fuzzy logiky na štandardnej škále oboru hodnôt [0,1] potom :
* '''"úplná nepravda"''' je reprezentovaná hraničnou hodnotou '''0'''
* '''"úplná pravda"''' je reprezentovaná hraničnou hodnotou '''1'''
* '''"čiastočná pravda"''' je reprezentovaná všetkými ostatnými hodnotami (nazývané aj '''stredné stupne pravdy''')

Viac o agentoch sa môžete dočítať v [http://www.simulace.info/index.php/Agents/cs kapitole na to určenej]. Pre nás bude užitočná najmä podkapitola o [http://www.simulace.info/index.php/Agents/cs#Deliberativn.C3.AD_agenty Deliberatívnych agentoch], v ktorej sa píše aj o teórií '''BDI''', ktorá tvorí sofistikovaný prístup k architektúre agenta a skladá sa z troch základných pojmov :
* Beliefs(domnienky)
* Desires(túžby)
* Intentions(zámery)

Na základe týchto 3 faktorov, a teda domnienok, túžob a prianí agent uvažuje o svete a teda o svojom rozhodovaní, ktorému je tento učební text venovaný.

----

= Fuzzy logika z každodenného života =

Pre lepšie pochopenie fuzzy logiky si uvedieme 2 príklady z bežného života:
* spotrebič, ktorý fuzzy logiku využíva
* činnosť, pri ktorom fuzzy logiku využívame automaticky bez toho, aby sme si vôbec uvedomovali, že sa nejaké rozhodovanie v mozgu uskutočňuje.

== Fuzzy logika v práčkach Samsung ==

[[File:fuzzyInWashingMachine.png|250px|left|Slovo FUZZY použité ako značka práčky Samsung a graf znázorňujúci procesy a ich následnosť]]
Trend integrovania '''Fuzzy logiky''' do práčiek Sasmung sa v posledných rokoch teší väčšej popularite. Senzory kontinuálne monitorujú premenlivé podmienky vo vnútri práčky a starostlivo vyberajú a nastavujú operácie pre dosiahnutie najlepších čiastiacich výsledkov.

Fuzzy logika má na starosti okrem iného kontrolu prívodu vody, teploty vody, času prania,kvality žmýkania alebo rýchlosť bubna. Viac sofistikované práčky vedia zvážiť hmotnosť oblečenia( takže zabraňujú preťaženiu práčky), poradia odporúčané množstvo čistiaceho prostriedku alebo vedia skontrolovať, či je čistiaci prostriedok v práškovom alebo tekutom stave. Niektoré sa dokonca vedia učiť z predošlých skúseností, zapamätávať si programy a regulovať činnosť práčky pre minimalizovanie nákladov na jej fungovanie.

== Ahoj vs. Dobrý deň ==

Ľudia by sa podľa veku mohli deliť na viacero kategórií. Pre jednoduchosť si ich rozdelíme iba do dvoch kategórií - starí a mladí. Podľa etikety slušného správania starí ľudia mladím zväčša tikajú a mladí naopak starím vykajú. Existujú samozrejme aj výnimky, napríklad vnúčata dnes bežne svojím starím rodičom tikajú. Alebo si niekedy medzi sebou vykajú aj dvaja mladí ľudia, keď napríklad vybavujú nejakú formálnu záležitosť. Ľudia dodržujúci zásady slušného správania by sa teda mali správať podľa nejakého vzoru etického správania, čo je príkladom fuzzy rozhodovania a priradenia '''(prekonvertovania)''' množín možných vstupov '''(stretnutí)''' s rozličnými vlastnosťtami '''(starý vs. mladý, stretnutie v krčme vs. stretnutie v banke, blízka vs. cudzia osoba, ...)''' na množinu možných výstupov '''(dobrý deň, ahoj, nazdar, ...)'''.

=== Návrh modelu ===

Pre jednoduchosť si fuzzy logiku vysvetlíme iba na základe jednej vlastnosti - veku (tá sa samozrejme môže meniť na základe určenia priorít, to ale komplikuje vysvetlovanie a táto komplikácia je vysvetlená v [http://www.simulace.info/index.php/Fuzzy_logic/cs#Fuzzy_rule-based_syst.C3.A9my kapitole nižšie]). Neberieme teda do úvahy žiadne iné vlastnosti agentov, ktoré by mohli zmeniť ich správanie.

[[File:fuzzyAgesAndGreetings.png|350px|center]]

Samozrejme, výsledná matica pozdravov nie je finálna, no ak by fuzzy logika obsahovala iba jedinnú premennú '''vek''' a 3 ľudí vo veku 10, 40 a 60 rokov, mohla by vyzerať nejak podobne. Dôležitý je predovšetkým výpočet faktoru veku, ktorý je v tomto prípade počítaný ako podiel '''vek/X''', kde X = 100 (tieto hodnoty môžeme vidieť na obrázku vyššie a je iba na nás, čo dosadíme za X).

Čo teda vieme z modelu vyčítať:
* 2 kategórie: '''Starí''' a '''Mladí''' s hraničným bodom delenia 50 (limit)
* prirodzená úcta k starším (mladší ľudia starším ľuďom vykajú)
* množinu vstupov ľudí '''{10,40,50}''' obsahujúcich vlastnosť veku
* množinou pozdravov '''{"Dobrý deň", "Ahoj"}'''

=== Výsledná fuzzy množina a možné rozšírenie úlohy ===

Ak by sme teda zaradzovali daných ľudí len do 2 kategórií na základe jedného pravidla, ktoré by spočívalo v porovnávaní faktoru veku s konštantou limit, dostali by sme maticu '''3x2''' možných pozdravov. Nie je teda vôbec doležité, ako nastavíme konštantu limit, pri jej zmene sa iba zmenia určené pozdravy, nie však počet prvkov matice a teda všetky možné kombinácie stretnutí majú vždy jasne danú reakciu z oboch strán.

Pri stretnutí dvoch rovesníkov som trochu načŕtol možné rozšírenie úlohy, keď som neurčil, či bude pozdrav "Ahoj" alebo "Dobrý deň". Samozrejme, ak platia pravidlá vyššie (pri dvoch malých chlapcoch som si ale dovolil spraviť výnimku, málokedy vidíme zdraviť sa ich pozdravom "Dobrý deň"), pri stretuntí dvoch '''40''' by mal byť pozdrav "Ahoj" (keďže obaja spĺňajú podmienku "mladosti") a dvoch '''60''' ročných pánov v klobúku "Dobrý deň".

Výnimka však potvrdzuje pravidlo a v prípade 10 ročného kráľa by sme aj 60 ročného starca videli pozdraviť ho pozdravom "Dobrý deň"(ak tam samozrejme nie sú ďalšie pravidlá, ktorú môžu túto logiku upravovať, ako napríklad príbuzenský vzťah a podobne). Možnosť voľby z dvoch pozdravov pri '''40''' a '''60''' ročných mužoch teda malo načŕtnuť pointu fuzzy logiky a možnosti jej rozšírenia, aj keď táto možnosť výberu sa vyskytne až po zaradení ďalších pravidiel.

=== Úlohy na precvičenie Fuzzy logiky ===

3 úlohy na záver (odpovede sa nachádzajú úplne dole ako posledná kapitola):
'''1.''' Ako by vyzeral výsledný počet možných výstupov, ak by sme do množiny pozdravov v príklade vyššie pridali pozdrav "Nazdar"?
'''2.''' Aké by mohli byť ďalšie vlasnosti, ktoré by menili faktor veku?
'''3.''' Ako by vyzeral pozdrav pri stretnutí 60 ročného starca (zmena faktoru veku z príkladu vyššie), ak do modelu pridáme nasledujúce vlasnosti :
'''3.a)''' Hodnosť kráľa znásobuje súčasný váhu 100 krát?
'''3.b)''' Hodnosť kňaza znásobuje súčasný váhu 20 krát?
'''3.c)''' O koľko rokov kňaz začne oslovovať kráľa "Dobrý deň"?

----

= Fuzzy logika v agentovo-orientovaných počítačových hrách <ref name="book"> Li, Yifan & Musilek, Petr & Wyard-Scott, L. (2004).Fuzzy logic in agent-based game design. 734 - 739 Vol.2. 10.1109/NAFIPS.2004.1337393. Dostupné z : https://www.researchgate.net/publication/4092875_Fuzzy_logic_in_agent-based_game_design</ref>=

[[File:fuzzyBattleCity.png|thumb|right|Prevedenie možného použitia fuzyy logiky v známej arkádovej hre BattleCity. Kružnice znázorňujú rôzne vstupy, na základe ktorých sa agenti rozhodujú o svojej ďalšej akcii]]
Umelá inteligencia v počítačových hrách sa vďaka rastúcim požiadavkám hráčov musí neustále zlepšovať. Inteligentní agenti môžu spolu s fuzzy logikou vylepšiť najdôležitejší prvok hier - '''interakciu'''. Agenti ponúkajú lepšie možnosti flexibilnej interakcie v rámci architektúry herného dizajnu, pričom fuzzy logika umožňuje lepšie kontrolovať správanie pre vytvorenie najrôznejších foriem umelých inteligencií.

== Porovnanie s inými technikami ==

Vo svete hier neznamená '''fuzzy kontrola''' iba ďalšiu metódu pre správanie agentov. Kontrolovanie agentov pomocou fuzzy logiky je zárukou '''generovania "správneho" správania'''. Toto prirodzené správanie agentov potom pomáha zvyšovať vnímanú zložitosť a dôveryhodnosť virtuálneho prostredia. V porovnaní s niektorými inými technikami návrhu inteligentných systémov sú systémy založené na fuzzy pravidlách jednoduché na návrh aj implementáciu. Klasické '''rule-based''' systémy pritom často nedokážu dosiahnuť prirodzenosť, akú ponúkajú '''fuzzy systémy''', pričom tie spotrebujú omnoho nižšie výpočtové náklady.

== Fuzzy rule-based systémy ==

Systémy založené na fuzzy pravidlách sa vo všeobecnosti skladajú z 4 komponentov:
* '''fuzzifier''' konvertuje sparsované vstupy z klienta do fuzzy množín
* základňa pravidiel ('''rule-base''') uchováva všetky vzťahy medzi vstupmi a očakávanými výstupmi v kolekcií '''IF-THEN''' pravidiel
* '''uvažujúca jednotka''' použije vstupy a aplikuje na nich konkrétne pravidlá
* '''defuzzifier''' prekonvertuje výsledok rozhodovania a sparsované výstupy pošle späť na klienta

V prípade viacerých vstupov sú fuzzy pravidlá väčšinou prepojené logickým spojením (konektorom) AND, pričom '''rule-base''' musí pokrývať každú možnú kombináciu všetkých výrazov z definičného oboru vstupnej premennej. Táto požiadavka úplnosti ale vedie k tzv. '''rule explosion problém'''-u, kde pre systém s n vstupmi, ktorý má každý m možných stavov potrebujeme celkovo '''m^n''' pravidiel! Toto pravidlo výbuchu predstavuje vážny problém a komplikuje implementovanie fuzzy kontrolovania vďaka vysokým nárokom na CPU zdroje. Combs navrhol [https://en.wikipedia.org/wiki/Combs_method URC (Union Rule Configuration)] na zmiernenie tohto problému, kedy sa zložitosť výpočtu zníži na '''m*n''' pravidiel.

== Zhrnutie ==

= Zdroje =

<references/>
3. https://www.samsung.com/in/support/home-appliances/what-is-fuzzy-logic-in-a-washing-machine/

= Odpovede =
'''1.''' Nezmenil by sa. Pri 1 pravidle sú odpovede jednoznačné, takže matica bude mať rovnaký počet výstupov aj v prípade, ak by množina s pozdravmi obsahovala iba 1 prvok.
'''2.''' Príbuzenský vzťah, hierarchické postavenie (môže sa týkať napríklad štátnej moci alebo aj postavenia vo firme), miesto stretnutia atď.
'''3.a)''' Starec by pozdravil chlapca kráľa "Dobrý deň". [(hodnosť kráľa)100 * 0.1 = '''10 > 0.6''']
'''3.b)''' Starec kňaz by pozdravil chlapca kráľa "Ahoj". [ (hodnosť kráľa)100 * 0.1 = '''10 < 12''' = 0.6 * 20 (hodnosť kňaza)]
'''3.c)''' Starec kňaz pozdraví chlapca kráľa pozdravom "Dobrý deň" o 3 roky [100 * 0.13 = '''13 > 12.6''' = 0.63 * 20]

Fuzzy logic/cs

2019-06-12T21:26:34Z

Turd01: /* Výsledná fuzzy množina a možné rozšírenie úlohy */

{{DISPLAYTITLE:Fuzzy logika v agentním rozhodování}}

= Úvod =

[[File:Zadeh.gif|thumb|right|L.A. Zadeh]]
'''Fuzzy Logika''' vznikla v kontexte teórie Fuzzy množín, ktorú prvý krát predstavil '''L. A. Zadeh''' v roku 1965. Fuzzy množina priradí stupeň členstva (reálne číslo z intervalu [0,1]) elementom vesmíru, pričom fuzzy logika vzniká až priradením stupňov pravdy k týmto vzniknutým elementom. Vzťahuje sa na rodinu [https://plato.stanford.edu/archives/win2017/entries/logic-manyvalued viachodnotových logík], takže je určená na modelovanie logických úvah s neurčitými alebo nepresnými údajmi. Stanovuje, že hodnota pravdy (v tomto prípade pravdivostný stupeň) logicky zloženého návrhu (napr. "Peter je bohatý a Ivan je vysoký.") je určená pravdivosťou jeho komponentov, inak povedané, nepočíta iba s 2 možnými hodnotami pravdy. <ref name="fuzzyBasic"> Cintula, Petr, Fermüller, Christian G. and Noguera, Carles, "Fuzzy Logic", The Stanford Encyclopedia of Philosophy (Fall 2017 Edition), Edward N. Zalta (ed.), Dostupné z : https://plato.stanford.edu/archives/fall2017/entries/logic-fuzzy/</ref>.

Pri použití Fuzzy logiky na štandardnej škále oboru hodnôt [0,1] potom :
* '''"úplná nepravda"''' je reprezentovaná hraničnou hodnotou '''0'''
* '''"úplná pravda"''' je reprezentovaná hraničnou hodnotou '''1'''
* '''"čiastočná pravda"''' je reprezentovaná všetkými ostatnými hodnotami (nazývané aj '''stredné stupne pravdy''')

Viac o agentoch sa môžete dočítať v [http://www.simulace.info/index.php/Agents/cs kapitole na to určenej]. Pre nás bude užitočná najmä podkapitola o [http://www.simulace.info/index.php/Agents/cs#Deliberativn.C3.AD_agenty Deliberatívnych agentoch], v ktorej sa píše aj o teórií '''BDI''', ktorá tvorí sofistikovaný prístup k architektúre agenta a skladá sa z troch základných pojmov :
* Beliefs(domnienky)
* Desires(túžby)
* Intentions(zámery)

Na základe týchto 3 faktorov, a teda domnienok, túžob a prianí agent uvažuje o svete a teda o svojom rozhodovaní, ktorému je tento učební text venovaný.

----

= Fuzzy logika z každodenného života =

Pre lepšie pochopenie fuzzy logiky si uvedieme 2 príklady z bežného života:
* spotrebič, ktorý fuzzy logiku využíva
* činnosť, pri ktorom fuzzy logiku využívame automaticky bez toho, aby sme si vôbec uvedomovali, že sa nejaké rozhodovanie v mozgu uskutočňuje.

== Fuzzy logika v práčkach Samsung ==

[[File:fuzzyInWashingMachine.png|250px|left|Slovo FUZZY použité ako značka práčky Samsung a graf znázorňujúci procesy a ich následnosť]]
Trend integrovania '''Fuzzy logiky''' do práčiek Sasmung sa v posledných rokoch teší väčšej popularite. Senzory kontinuálne monitorujú premenlivé podmienky vo vnútri práčky a starostlivo vyberajú a nastavujú operácie pre dosiahnutie najlepších čiastiacich výsledkov.

Fuzzy logika má na starosti okrem iného kontrolu prívodu vody, teploty vody, času prania,kvality žmýkania alebo rýchlosť bubna. Viac sofistikované práčky vedia zvážiť hmotnosť oblečenia( takže zabraňujú preťaženiu práčky), poradia odporúčané množstvo čistiaceho prostriedku alebo vedia skontrolovať, či je čistiaci prostriedok v práškovom alebo tekutom stave. Niektoré sa dokonca vedia učiť z predošlých skúseností, zapamätávať si programy a regulovať činnosť práčky pre minimalizovanie nákladov na jej fungovanie.

== Ahoj vs. Dobrý deň ==

Ľudia by sa podľa veku mohli deliť na viacero kategórií. Pre jednoduchosť si ich rozdelíme iba do dvoch kategórií - starí a mladí. Podľa etikety slušného správania starí ľudia mladím zväčša tikajú a mladí naopak starím vykajú. Existujú samozrejme aj výnimky, napríklad vnúčata dnes bežne svojím starím rodičom tikajú. Alebo si niekedy medzi sebou vykajú aj dvaja mladí ľudia, keď napríklad vybavujú nejakú formálnu záležitosť. Ľudia dodržujúci zásady slušného správania by sa teda mali správať podľa nejakého vzoru etického správania, čo je príkladom fuzzy rozhodovania a priradenia '''(prekonvertovania)''' množín možných vstupov '''(stretnutí)''' s rozličnými vlastnosťtami '''(starý vs. mladý, stretnutie v krčme vs. stretnutie v banke, blízka vs. cudzia osoba, ...)''' na množinu možných výstupov '''(dobrý deň, ahoj, nazdar, ...)'''.

=== Návrh modelu ===

Pre jednoduchosť si fuzzy logiku vysvetlíme iba na základe jednej vlastnosti - veku (tá sa samozrejme môže meniť na základe určenia priorít, to ale komplikuje vysvetlovanie a táto komplikácia je vysvetlená v [http://www.simulace.info/index.php/Fuzzy_logic/cs#Fuzzy_rule-based_syst.C3.A9my kapitole nižšie]). Neberieme teda do úvahy žiadne iné vlastnosti agentov, ktoré by mohli zmeniť ich správanie.

[[File:fuzzyAgesAndGreetings.png|350px|center]]

Samozrejme, výsledná matica pozdravov nie je finálna, no ak by fuzzy logika obsahovala iba jedinnú premennú '''vek''' a 3 ľudí vo veku 10, 40 a 60 rokov, mohla by vyzerať nejak podobne. Dôležitý je predovšetkým výpočet faktoru veku, ktorý je v tomto prípade počítaný ako podiel '''vek/X''', kde X = 100 (tieto hodnoty môžeme vidieť na obrázku vyššie a je iba na nás, čo dosadíme za X).

Čo teda vieme z modelu vyčítať:
* 2 kategórie: '''Starí''' a '''Mladí''' s hraničným bodom delenia 50 (limit)
* prirodzená úcta k starším (mladší ľudia starším ľuďom vykajú)
* množinu vstupov ľudí '''{10,40,50}''' obsahujúcich vlastnosť veku
* množinou pozdravov '''{"Dobrý deň", "Ahoj"}'''

=== Výsledná fuzzy množina a možné rozšírenie úlohy ===

Ak by sme teda zaradzovali daných ľudí len do 2 kategórií na základe jedného pravidla, ktoré by spočívalo v porovnávaní faktoru veku s konštantou limit, dostali by sme maticu '''3x2''' možných pozdravov. Nie je teda vôbec doležité, ako nastavíme konštantu limit, pri jej zmene sa iba zmenia určené pozdravy, nie však počet prvkov matice a teda všetky možné kombinácie stretnutí majú vždy jasne danú reakciu z oboch strán.

Pri stretnutí dvoch rovesníkov som trochu načŕtol možné rozšírenie úlohy, keď som neurčil, či bude pozdrav "Ahoj" alebo "Dobrý deň". Samozrejme, ak platia pravidlá vyššie (pri dvoch malých chlapcoch som si ale dovolil spraviť výnimku, málokedy vidíme zdraviť sa ich pozdravom "Dobrý deň"), pri stretuntí dvoch '''40''' by mal byť pozdrav "Ahoj" (keďže obaja spĺňajú podmienku "mladosti") a dvoch '''60''' ročných pánov v klobúku "Dobrý deň".

Výnimka však potvrdzuje pravidlo a v prípade 10 ročného kráľa by sme aj 60 ročného starca videli pozdraviť ho pozdravom "Dobrý deň"(ak tam samozrejme nie sú ďalšie pravidlá, ktorú môžu túto logiku upravovať, ako napríklad príbuzenský vzťah a podobne). Možnosť voľby z dvoch pozdravov pri '''40''' a '''60''' ročných mužoch teda malo načŕtnuť pointu fuzzy logiky a možnosti jej rozšírenia, aj keď táto možnosť výberu sa vyskytne až po zaradení ďalších pravidiel.

=== Úlohy na precvičenie Fuzzy logiky ===

3 úlohy na záver (odpovede sa nachádzajú úplne dole ako posledná kapitola):
'''1.''' Ako by vyzeral výsledný počet možných výstupov, ak by sme do množiny pozdravov v príklade vyššie pridali pozdrav "Nazdar"?
'''2.''' Aké by mohli byť ďalšie vlasnosti, ktoré by menili faktor veku?
'''3.''' Ako by vyzeral pozdrav pri stretnutí 60 ročného starca (zmena faktoru veku z príkladu vyššie), ak do modelu pridáme nasledujúce vlasnosti :
'''3.a)''' Hodnosť kráľa znásobuje súčasný váhu 100 krát?
'''3.b)''' Hodnosť kňaza znásobuje súčasný váhu 20 krát?
'''3.c)''' O koľko rokov kňaz začne oslovovať kráľa "Dobrý deň"?

----

= Fuzzy logika v agentovo-orientovaných počítačových hrách <ref name="book"> Li, Yifan & Musilek, Petr & Wyard-Scott, L. (2004).Fuzzy logic in agent-based game design. 734 - 739 Vol.2. 10.1109/NAFIPS.2004.1337393. Dostupné z : https://www.researchgate.net/publication/4092875_Fuzzy_logic_in_agent-based_game_design</ref>=

[[File:fuzzyBattleCity.png|thumb|right|Prevedenie možného použitia fuzyy logiky v známej arkádovej hre BattleCity. Kružnice znázorňujú rôzne vstupy, na základe ktorých sa agenti rozhodujú o svojej ďalšej akcii]]
Umelá inteligencia v počítačových hrách sa vďaka rastúcim požiadavkám hráčov musí neustále zlepšovať. Inteligentní agenti môžu spolu s fuzzy logikou vylepšiť najdôležitejší prvok hier - '''interakciu'''. Agenti ponúkajú lepšie možnosti flexibilnej interakcie v rámci architektúry herného dizajnu, pričom fuzzy logika umožňuje lepšie kontrolovať správanie pre vytvorenie najrôznejších foriem umelých inteligencií.

== Porovnanie s inými technikami ==

Vo svete hier neznamená '''fuzzy kontrola''' iba ďalšiu metódu pre správanie agentov. Kontrolovanie agentov pomocou fuzzy logiky je zárukou '''generovania "správneho" správania'''. Toto prirodzené správanie agentov potom pomáha zvyšovať vnímanú zložitosť a dôveryhodnosť virtuálneho prostredia. V porovnaní s niektorými inými technikami návrhu inteligentných systémov sú systémy založené na fuzzy pravidlách jednoduché na návrh aj implementáciu. Klasické '''rule-based''' systémy pritom často nedokážu dosiahnuť prirodzenosť, akú ponúkajú '''fuzzy systémy''', pričom tie spotrebujú omnoho nižšie výpočtové náklady.

== Fuzzy rule-based systémy ==

Systémy založené na fuzzy pravidlách sa vo všeobecnosti skladajú z 4 komponentov:
* '''fuzzifier''' konvertuje sparsované vstupy z klienta do fuzzy množín
* základňa pravidiel ('''rule-base''') uchováva všetky vzťahy medzi vstupmi a očakávanými výstupmi v kolekcií '''IF-THEN''' pravidiel
* '''uvažujúca jednotka''' použije vstupy a aplikuje na nich konkrétne pravidlá
* '''defuzzifier''' prekonvertuje výsledok rozhodovania a sparsované výstupy pošle späť na klienta

V prípade viacerých vstupov sú fuzzy pravidlá väčšinou prepojené logickým spojením (konektorom) AND, pričom '''rule-base''' musí pokrývať každú možnú kombináciu všetkých výrazov z definičného oboru vstupnej premennej. Táto požiadavka úplnosti ale vedie k tzv. '''rule explosion problém'''-u, kde pre systém s n vstupmi, ktorý má každý m možných stavov potrebujeme celkovo '''m^n''' pravidiel! Toto pravidlo výbuchu predstavuje vážny problém a komplikuje implementovanie fuzzy kontrolovania vďaka vysokým nárokom na CPU zdroje. Combs navrhol [https://en.wikipedia.org/wiki/Combs_method URC (Union Rule Configuration)] na zmiernenie tohto problému, kedy sa zložitosť výpočtu zníži na '''m*n''' pravidiel.

== Zhrnutie ==

= Zdroje =

<references/>
3. https://www.samsung.com/in/support/home-appliances/what-is-fuzzy-logic-in-a-washing-machine/

= Odpovede =
'''1.''' Nezmenil by sa. Pri 1 pravidle sú odpovede jednoznačné, takže matica bude mať rovnaký počet výstupov aj v prípade, ak by množina s pozdravmi obsahovala iba 1 prvok.
'''2.''' Príbuzenský vzťah, hierarchické postavenie (môže sa týkať napríklad štátnej moci alebo aj postavenia vo firme), miesto stretnutia atď.
'''3.a)''' Starec by pozdravil chlapca kráľa "Dobrý deň". [(hodnosť kráľa)100 * 0.1 = '''10 > 0.6''']
'''3.b)''' Starec kňaz by pozdravil chlapca kráľa "Ahoj". [ (hodnosť kráľa)100 * 0.1 = '''10 < 12''' = 0.6 * 20 (hodnosť kňaza)]
'''3.c)''' Starec kňaz pozdraví chlapca kráľa pozdravom "Dobrý deň" o 3 roky [100 * 0.13 = '''13 > 12.6''' = 0.63 * 20]

Fuzzy logic/cs

2019-06-12T21:26:05Z

Turd01: /* Ahoj vs. Dobrý deň */

{{DISPLAYTITLE:Fuzzy logika v agentním rozhodování}}

= Úvod =

[[File:Zadeh.gif|thumb|right|L.A. Zadeh]]
'''Fuzzy Logika''' vznikla v kontexte teórie Fuzzy množín, ktorú prvý krát predstavil '''L. A. Zadeh''' v roku 1965. Fuzzy množina priradí stupeň členstva (reálne číslo z intervalu [0,1]) elementom vesmíru, pričom fuzzy logika vzniká až priradením stupňov pravdy k týmto vzniknutým elementom. Vzťahuje sa na rodinu [https://plato.stanford.edu/archives/win2017/entries/logic-manyvalued viachodnotových logík], takže je určená na modelovanie logických úvah s neurčitými alebo nepresnými údajmi. Stanovuje, že hodnota pravdy (v tomto prípade pravdivostný stupeň) logicky zloženého návrhu (napr. "Peter je bohatý a Ivan je vysoký.") je určená pravdivosťou jeho komponentov, inak povedané, nepočíta iba s 2 možnými hodnotami pravdy. <ref name="fuzzyBasic"> Cintula, Petr, Fermüller, Christian G. and Noguera, Carles, "Fuzzy Logic", The Stanford Encyclopedia of Philosophy (Fall 2017 Edition), Edward N. Zalta (ed.), Dostupné z : https://plato.stanford.edu/archives/fall2017/entries/logic-fuzzy/</ref>.

Pri použití Fuzzy logiky na štandardnej škále oboru hodnôt [0,1] potom :
* '''"úplná nepravda"''' je reprezentovaná hraničnou hodnotou '''0'''
* '''"úplná pravda"''' je reprezentovaná hraničnou hodnotou '''1'''
* '''"čiastočná pravda"''' je reprezentovaná všetkými ostatnými hodnotami (nazývané aj '''stredné stupne pravdy''')

Viac o agentoch sa môžete dočítať v [http://www.simulace.info/index.php/Agents/cs kapitole na to určenej]. Pre nás bude užitočná najmä podkapitola o [http://www.simulace.info/index.php/Agents/cs#Deliberativn.C3.AD_agenty Deliberatívnych agentoch], v ktorej sa píše aj o teórií '''BDI''', ktorá tvorí sofistikovaný prístup k architektúre agenta a skladá sa z troch základných pojmov :
* Beliefs(domnienky)
* Desires(túžby)
* Intentions(zámery)

Na základe týchto 3 faktorov, a teda domnienok, túžob a prianí agent uvažuje o svete a teda o svojom rozhodovaní, ktorému je tento učební text venovaný.

----

= Fuzzy logika z každodenného života =

Pre lepšie pochopenie fuzzy logiky si uvedieme 2 príklady z bežného života:
* spotrebič, ktorý fuzzy logiku využíva
* činnosť, pri ktorom fuzzy logiku využívame automaticky bez toho, aby sme si vôbec uvedomovali, že sa nejaké rozhodovanie v mozgu uskutočňuje.

== Fuzzy logika v práčkach Samsung ==

[[File:fuzzyInWashingMachine.png|250px|left|Slovo FUZZY použité ako značka práčky Samsung a graf znázorňujúci procesy a ich následnosť]]
Trend integrovania '''Fuzzy logiky''' do práčiek Sasmung sa v posledných rokoch teší väčšej popularite. Senzory kontinuálne monitorujú premenlivé podmienky vo vnútri práčky a starostlivo vyberajú a nastavujú operácie pre dosiahnutie najlepších čiastiacich výsledkov.

Fuzzy logika má na starosti okrem iného kontrolu prívodu vody, teploty vody, času prania,kvality žmýkania alebo rýchlosť bubna. Viac sofistikované práčky vedia zvážiť hmotnosť oblečenia( takže zabraňujú preťaženiu práčky), poradia odporúčané množstvo čistiaceho prostriedku alebo vedia skontrolovať, či je čistiaci prostriedok v práškovom alebo tekutom stave. Niektoré sa dokonca vedia učiť z predošlých skúseností, zapamätávať si programy a regulovať činnosť práčky pre minimalizovanie nákladov na jej fungovanie.

== Ahoj vs. Dobrý deň ==

Ľudia by sa podľa veku mohli deliť na viacero kategórií. Pre jednoduchosť si ich rozdelíme iba do dvoch kategórií - starí a mladí. Podľa etikety slušného správania starí ľudia mladím zväčša tikajú a mladí naopak starím vykajú. Existujú samozrejme aj výnimky, napríklad vnúčata dnes bežne svojím starím rodičom tikajú. Alebo si niekedy medzi sebou vykajú aj dvaja mladí ľudia, keď napríklad vybavujú nejakú formálnu záležitosť. Ľudia dodržujúci zásady slušného správania by sa teda mali správať podľa nejakého vzoru etického správania, čo je príkladom fuzzy rozhodovania a priradenia '''(prekonvertovania)''' množín možných vstupov '''(stretnutí)''' s rozličnými vlastnosťtami '''(starý vs. mladý, stretnutie v krčme vs. stretnutie v banke, blízka vs. cudzia osoba, ...)''' na množinu možných výstupov '''(dobrý deň, ahoj, nazdar, ...)'''.

=== Návrh modelu ===

Pre jednoduchosť si fuzzy logiku vysvetlíme iba na základe jednej vlastnosti - veku (tá sa samozrejme môže meniť na základe určenia priorít, to ale komplikuje vysvetlovanie a táto komplikácia je vysvetlená v [http://www.simulace.info/index.php/Fuzzy_logic/cs#Fuzzy_rule-based_syst.C3.A9my kapitole nižšie]). Neberieme teda do úvahy žiadne iné vlastnosti agentov, ktoré by mohli zmeniť ich správanie.

[[File:fuzzyAgesAndGreetings.png|350px|center]]

Samozrejme, výsledná matica pozdravov nie je finálna, no ak by fuzzy logika obsahovala iba jedinnú premennú '''vek''' a 3 ľudí vo veku 10, 40 a 60 rokov, mohla by vyzerať nejak podobne. Dôležitý je predovšetkým výpočet faktoru veku, ktorý je v tomto prípade počítaný ako podiel '''vek/X''', kde X = 100 (tieto hodnoty môžeme vidieť na obrázku vyššie a je iba na nás, čo dosadíme za X).

Čo teda vieme z modelu vyčítať:
* 2 kategórie: '''Starí''' a '''Mladí''' s hraničným bodom delenia 50 (limit)
* prirodzená úcta k starším (mladší ľudia starším ľuďom vykajú)
* množinu vstupov ľudí '''{10,40,50}''' obsahujúcich vlastnosť veku
* množinou pozdravov '''{"Dobrý deň", "Ahoj"}'''

=== Výsledná fuzzy množina a možné rozšírenie úlohy ===

Ak by sme teda zaradzovali daných ľudí len do 2 kategórií na základe jedného pravidla, ktoré by spočívalo v porovnávaní faktoru veku s konštantou limit, dostali by sme maticu '''3x2''' možných pozdravov. Nie je teda vôbec doležité, ako nastavíme konštantu limit, pri jej zmene sa iba zmenia určené pozdravy, nie však počet prvkov matice a teda všetky možné kombinácie stretnutí majú vždy jasne danú reakciu z oboch strán.

Pri stretnutí dvoch rovesníkov som trochu načŕtol možné rozšírenie úlohy, keď som neurčil, či bude pozdrav '''Ahoj" alebo "Dobrý deň". Samozrejme, ak platia pravidlá vyššie (pri dvoch malých chlapcoch som si ale dovolil spraviť výnimku, málokedy vidíme zdraviť sa ich pozdravom "Dobrý deň"), pri stretuntí dvoch '''40''' by mal byť pozdrav "Ahoj" (keďže obaja spĺňajú podmienku "mladosti") a dvoch '''60''' ročných pánov v klobúku "Dobrý deň".

Výnimka však potvrdzuje pravidlo a v prípade 10 ročného kráľa by sme aj 60 ročného starca videli pozdraviť ho pozdravom "Dobrý deň"(ak tam samozrejme nie sú ďalšie pravidlá, ktorú môžu túto logiku upravovať, ako napríklad príbuzenský vzťah a podobne). Možnosť voľby z dvoch pozdravov pri '''40''' a '''60''' ročných mužoch teda malo načŕtnuť pointu fuzzy logiky a možnosti jej rozšírenia, aj keď táto možnosť výberu sa vyskytne až po zaradení ďalších pravidiel.

=== Úlohy na precvičenie Fuzzy logiky ===

3 úlohy na záver (odpovede sa nachádzajú úplne dole ako posledná kapitola):
'''1.''' Ako by vyzeral výsledný počet možných výstupov, ak by sme do množiny pozdravov v príklade vyššie pridali pozdrav "Nazdar"?
'''2.''' Aké by mohli byť ďalšie vlasnosti, ktoré by menili faktor veku?
'''3.''' Ako by vyzeral pozdrav pri stretnutí 60 ročného starca (zmena faktoru veku z príkladu vyššie), ak do modelu pridáme nasledujúce vlasnosti :
'''3.a)''' Hodnosť kráľa znásobuje súčasný váhu 100 krát?
'''3.b)''' Hodnosť kňaza znásobuje súčasný váhu 20 krát?
'''3.c)''' O koľko rokov kňaz začne oslovovať kráľa "Dobrý deň"?

----

= Fuzzy logika v agentovo-orientovaných počítačových hrách <ref name="book"> Li, Yifan & Musilek, Petr & Wyard-Scott, L. (2004).Fuzzy logic in agent-based game design. 734 - 739 Vol.2. 10.1109/NAFIPS.2004.1337393. Dostupné z : https://www.researchgate.net/publication/4092875_Fuzzy_logic_in_agent-based_game_design</ref>=

[[File:fuzzyBattleCity.png|thumb|right|Prevedenie možného použitia fuzyy logiky v známej arkádovej hre BattleCity. Kružnice znázorňujú rôzne vstupy, na základe ktorých sa agenti rozhodujú o svojej ďalšej akcii]]
Umelá inteligencia v počítačových hrách sa vďaka rastúcim požiadavkám hráčov musí neustále zlepšovať. Inteligentní agenti môžu spolu s fuzzy logikou vylepšiť najdôležitejší prvok hier - '''interakciu'''. Agenti ponúkajú lepšie možnosti flexibilnej interakcie v rámci architektúry herného dizajnu, pričom fuzzy logika umožňuje lepšie kontrolovať správanie pre vytvorenie najrôznejších foriem umelých inteligencií.

== Porovnanie s inými technikami ==

Vo svete hier neznamená '''fuzzy kontrola''' iba ďalšiu metódu pre správanie agentov. Kontrolovanie agentov pomocou fuzzy logiky je zárukou '''generovania "správneho" správania'''. Toto prirodzené správanie agentov potom pomáha zvyšovať vnímanú zložitosť a dôveryhodnosť virtuálneho prostredia. V porovnaní s niektorými inými technikami návrhu inteligentných systémov sú systémy založené na fuzzy pravidlách jednoduché na návrh aj implementáciu. Klasické '''rule-based''' systémy pritom často nedokážu dosiahnuť prirodzenosť, akú ponúkajú '''fuzzy systémy''', pričom tie spotrebujú omnoho nižšie výpočtové náklady.

== Fuzzy rule-based systémy ==

Systémy založené na fuzzy pravidlách sa vo všeobecnosti skladajú z 4 komponentov:
* '''fuzzifier''' konvertuje sparsované vstupy z klienta do fuzzy množín
* základňa pravidiel ('''rule-base''') uchováva všetky vzťahy medzi vstupmi a očakávanými výstupmi v kolekcií '''IF-THEN''' pravidiel
* '''uvažujúca jednotka''' použije vstupy a aplikuje na nich konkrétne pravidlá
* '''defuzzifier''' prekonvertuje výsledok rozhodovania a sparsované výstupy pošle späť na klienta

V prípade viacerých vstupov sú fuzzy pravidlá väčšinou prepojené logickým spojením (konektorom) AND, pričom '''rule-base''' musí pokrývať každú možnú kombináciu všetkých výrazov z definičného oboru vstupnej premennej. Táto požiadavka úplnosti ale vedie k tzv. '''rule explosion problém'''-u, kde pre systém s n vstupmi, ktorý má každý m možných stavov potrebujeme celkovo '''m^n''' pravidiel! Toto pravidlo výbuchu predstavuje vážny problém a komplikuje implementovanie fuzzy kontrolovania vďaka vysokým nárokom na CPU zdroje. Combs navrhol [https://en.wikipedia.org/wiki/Combs_method URC (Union Rule Configuration)] na zmiernenie tohto problému, kedy sa zložitosť výpočtu zníži na '''m*n''' pravidiel.

== Zhrnutie ==

= Zdroje =

<references/>
3. https://www.samsung.com/in/support/home-appliances/what-is-fuzzy-logic-in-a-washing-machine/

= Odpovede =
'''1.''' Nezmenil by sa. Pri 1 pravidle sú odpovede jednoznačné, takže matica bude mať rovnaký počet výstupov aj v prípade, ak by množina s pozdravmi obsahovala iba 1 prvok.
'''2.''' Príbuzenský vzťah, hierarchické postavenie (môže sa týkať napríklad štátnej moci alebo aj postavenia vo firme), miesto stretnutia atď.
'''3.a)''' Starec by pozdravil chlapca kráľa "Dobrý deň". [(hodnosť kráľa)100 * 0.1 = '''10 > 0.6''']
'''3.b)''' Starec kňaz by pozdravil chlapca kráľa "Ahoj". [ (hodnosť kráľa)100 * 0.1 = '''10 < 12''' = 0.6 * 20 (hodnosť kňaza)]
'''3.c)''' Starec kňaz pozdraví chlapca kráľa pozdravom "Dobrý deň" o 3 roky [100 * 0.13 = '''13 > 12.6''' = 0.63 * 20]

Fuzzy logic/cs

2019-06-12T21:23:42Z

Turd01: /* Úvod */

{{DISPLAYTITLE:Fuzzy logika v agentním rozhodování}}

= Úvod =

[[File:Zadeh.gif|thumb|right|L.A. Zadeh]]
'''Fuzzy Logika''' vznikla v kontexte teórie Fuzzy množín, ktorú prvý krát predstavil '''L. A. Zadeh''' v roku 1965. Fuzzy množina priradí stupeň členstva (reálne číslo z intervalu [0,1]) elementom vesmíru, pričom fuzzy logika vzniká až priradením stupňov pravdy k týmto vzniknutým elementom. Vzťahuje sa na rodinu [https://plato.stanford.edu/archives/win2017/entries/logic-manyvalued viachodnotových logík], takže je určená na modelovanie logických úvah s neurčitými alebo nepresnými údajmi. Stanovuje, že hodnota pravdy (v tomto prípade pravdivostný stupeň) logicky zloženého návrhu (napr. "Peter je bohatý a Ivan je vysoký.") je určená pravdivosťou jeho komponentov, inak povedané, nepočíta iba s 2 možnými hodnotami pravdy. <ref name="fuzzyBasic"> Cintula, Petr, Fermüller, Christian G. and Noguera, Carles, "Fuzzy Logic", The Stanford Encyclopedia of Philosophy (Fall 2017 Edition), Edward N. Zalta (ed.), Dostupné z : https://plato.stanford.edu/archives/fall2017/entries/logic-fuzzy/</ref>.

Pri použití Fuzzy logiky na štandardnej škále oboru hodnôt [0,1] potom :
* '''"úplná nepravda"''' je reprezentovaná hraničnou hodnotou '''0'''
* '''"úplná pravda"''' je reprezentovaná hraničnou hodnotou '''1'''
* '''"čiastočná pravda"''' je reprezentovaná všetkými ostatnými hodnotami (nazývané aj '''stredné stupne pravdy''')

Viac o agentoch sa môžete dočítať v [http://www.simulace.info/index.php/Agents/cs kapitole na to určenej]. Pre nás bude užitočná najmä podkapitola o [http://www.simulace.info/index.php/Agents/cs#Deliberativn.C3.AD_agenty Deliberatívnych agentoch], v ktorej sa píše aj o teórií '''BDI''', ktorá tvorí sofistikovaný prístup k architektúre agenta a skladá sa z troch základných pojmov :
* Beliefs(domnienky)
* Desires(túžby)
* Intentions(zámery)

Na základe týchto 3 faktorov, a teda domnienok, túžob a prianí agent uvažuje o svete a teda o svojom rozhodovaní, ktorému je tento učební text venovaný.

----

= Fuzzy logika z každodenného života =

Pre lepšie pochopenie fuzzy logiky si uvedieme 2 príklady z bežného života:
* spotrebič, ktorý fuzzy logiku využíva
* činnosť, pri ktorom fuzzy logiku využívame automaticky bez toho, aby sme si vôbec uvedomovali, že sa nejaké rozhodovanie v mozgu uskutočňuje.

== Fuzzy logika v práčkach Samsung ==

[[File:fuzzyInWashingMachine.png|250px|left|Slovo FUZZY použité ako značka práčky Samsung a graf znázorňujúci procesy a ich následnosť]]
Trend integrovania '''Fuzzy logiky''' do práčiek Sasmung sa v posledných rokoch teší väčšej popularite. Senzory kontinuálne monitorujú premenlivé podmienky vo vnútri práčky a starostlivo vyberajú a nastavujú operácie pre dosiahnutie najlepších čiastiacich výsledkov.

Fuzzy logika má na starosti okrem iného kontrolu prívodu vody, teploty vody, času prania,kvality žmýkania alebo rýchlosť bubna. Viac sofistikované práčky vedia zvážiť hmotnosť oblečenia( takže zabraňujú preťaženiu práčky), poradia odporúčané množstvo čistiaceho prostriedku alebo vedia skontrolovať, či je čistiaci prostriedok v práškovom alebo tekutom stave. Niektoré sa dokonca vedia učiť z predošlých skúseností, zapamätávať si programy a regulovať činnosť práčky pre minimalizovanie nákladov na jej fungovanie.

== Ahoj vs. Dobrý deň ==

Ľudia by sa podľa veku mohli deliť na viacero kategórií. Pre jednoduchosť si ich rozdelíme iba do dvoch kategórií - starí a mladí. Podľa etikety slušného správania starí ľudia mladím zväčša tikajú a mladí naopak starím vykajú. Existujú samozrejme aj výnimky, napríklad vnúčata dnes bežne svojím starím rodičom tikajú. Alebo si niekedy medzi sebou vykajú aj dvaja mladí ľudia keď napríklad vybavujú nejakú formálnu záležitosť. Ľudia dodržujúci zásady slušného správania by sa teda mali správať podľa nejakého vzoru etického správania, čo je príkladom fuzzy rozhodovania a priradenia '''(prekonvertovania)''' množín možných vstupov '''(stretnutí)''' s rozličnými vlastnosťtami '''(starý vs. mladý, stretnutie v krčme vs. stretnutie v banke, blízka vs. cudzia osoba, ...)''' na množinu možných výstupov '''(dobrý deň, ahoj, nazdar, ...)'''.

=== Návrh modelu ===

Pre jednoduchosť si fuzzy logiku vysvetlíme iba na základe jednej vlastnosti - veku (tá sa samozrejme môže meniť na základe určenia priorít, to ale komplikuje vysvetlovanie a táto komplikácia je vysvetlená v [http://www.simulace.info/index.php/Fuzzy_logic/cs#Fuzzy_rule-based_syst.C3.A9my kapitole nižšie]). Neberieme teda do úvahy žiadne iné vlastnosti agentov, ktoré by mohli zmeniť ich správanie.

[[File:fuzzyAgesAndGreetings.png|350px|center]]

Samozrejme, výsledná matica pozdravov nie je finálna, no ak by fuzzy logika obsahovala iba jedinnú premennú '''vek''' a 3 ľudí vo veku 10, 40 a 60 rokov, mohla by vyzerať nejak podobne. Dôležitý je predovšetkým výpočet faktoru veku, ktorý je v tomto prípade počítaný ako podiel '''vek/X''', kde X = 100 (tieto hodnoty môžeme vidieť na obrázku vyššie a je iba na nás, čo dosadíme za X).

Čo teda vieme z modelu vyčítať:
* 2 kategórie: '''Starí''' a '''Mladí''' s hraničným bodom delenia 50 (limit)
* prirodzená úcta k starším (mladší ľudia starším ľuďom vykajú)
* množinu vstupov ľudí '''{10,40,50}''' obsahujúcich vlastnosť veku
* množinou pozdravov '''{"Dobrý deň", "Ahoj"}'''

=== Výsledná fuzzy množina a možné rozšírenie úlohy ===

Ak by sme teda zaradzovali daných ľudí len do 2 kategórií na základe jedného pravidla, ktoré by spočívalo v porovnávaní faktoru veku s konštantou limit, dostali by sme maticu '''3x2''' možných pozdravov. Nie je teda vôbec doležité, ako nastavíme konštantu limit, pri jej zmene sa iba zmenia určené pozdravy, nie však počet prvkov matice a teda všetky možné kombinácie stretnutí majú vždy jasne danú reakciu z oboch strán.

Pri stretnutí dvoch rovesníkov som trochu načŕtol možné rozšírenie úlohy, keď som neurčil, či bude pozdrav '''Ahoj" alebo "Dobrý deň". Samozrejme, ak platia pravidlá vyššie (pri dvoch malých chlapcoch som si ale dovolil spraviť výnimku, málokedy vidíme zdraviť sa ich pozdravom "Dobrý deň"), pri stretuntí dvoch '''40''' by mal byť pozdrav "Ahoj" (keďže obaja spĺňajú podmienku "mladosti") a dvoch '''60''' ročných pánov v klobúku "Dobrý deň".

Výnimka však potvrdzuje pravidlo a v prípade 10 ročného kráľa by sme aj 60 ročného starca videli pozdraviť ho pozdravom "Dobrý deň"(ak tam samozrejme nie sú ďalšie pravidlá, ktorú môžu túto logiku upravovať, ako napríklad príbuzenský vzťah a podobne). Možnosť voľby z dvoch pozdravov pri '''40''' a '''60''' ročných mužoch teda malo načŕtnuť pointu fuzzy logiky a možnosti jej rozšírenia, aj keď táto možnosť výberu sa vyskytne až po zaradení ďalších pravidiel.

=== Úlohy na precvičenie Fuzzy logiky ===

3 úlohy na záver (odpovede sa nachádzajú úplne dole ako posledná kapitola):
'''1.''' Ako by vyzeral výsledný počet možných výstupov, ak by sme do množiny pozdravov v príklade vyššie pridali pozdrav "Nazdar"?
'''2.''' Aké by mohli byť ďalšie vlasnosti, ktoré by menili faktor veku?
'''3.''' Ako by vyzeral pozdrav pri stretnutí 60 ročného starca (zmena faktoru veku z príkladu vyššie), ak do modelu pridáme nasledujúce vlasnosti :
'''3.a)''' Hodnosť kráľa znásobuje súčasný váhu 100 krát?
'''3.b)''' Hodnosť kňaza znásobuje súčasný váhu 20 krát?
'''3.c)''' O koľko rokov kňaz začne oslovovať kráľa "Dobrý deň"?

----

= Fuzzy logika v agentovo-orientovaných počítačových hrách <ref name="book"> Li, Yifan & Musilek, Petr & Wyard-Scott, L. (2004).Fuzzy logic in agent-based game design. 734 - 739 Vol.2. 10.1109/NAFIPS.2004.1337393. Dostupné z : https://www.researchgate.net/publication/4092875_Fuzzy_logic_in_agent-based_game_design</ref>=

[[File:fuzzyBattleCity.png|thumb|right|Prevedenie možného použitia fuzyy logiky v známej arkádovej hre BattleCity. Kružnice znázorňujú rôzne vstupy, na základe ktorých sa agenti rozhodujú o svojej ďalšej akcii]]
Umelá inteligencia v počítačových hrách sa vďaka rastúcim požiadavkám hráčov musí neustále zlepšovať. Inteligentní agenti môžu spolu s fuzzy logikou vylepšiť najdôležitejší prvok hier - '''interakciu'''. Agenti ponúkajú lepšie možnosti flexibilnej interakcie v rámci architektúry herného dizajnu, pričom fuzzy logika umožňuje lepšie kontrolovať správanie pre vytvorenie najrôznejších foriem umelých inteligencií.

== Porovnanie s inými technikami ==

Vo svete hier neznamená '''fuzzy kontrola''' iba ďalšiu metódu pre správanie agentov. Kontrolovanie agentov pomocou fuzzy logiky je zárukou '''generovania "správneho" správania'''. Toto prirodzené správanie agentov potom pomáha zvyšovať vnímanú zložitosť a dôveryhodnosť virtuálneho prostredia. V porovnaní s niektorými inými technikami návrhu inteligentných systémov sú systémy založené na fuzzy pravidlách jednoduché na návrh aj implementáciu. Klasické '''rule-based''' systémy pritom často nedokážu dosiahnuť prirodzenosť, akú ponúkajú '''fuzzy systémy''', pričom tie spotrebujú omnoho nižšie výpočtové náklady.

== Fuzzy rule-based systémy ==

Systémy založené na fuzzy pravidlách sa vo všeobecnosti skladajú z 4 komponentov:
* '''fuzzifier''' konvertuje sparsované vstupy z klienta do fuzzy množín
* základňa pravidiel ('''rule-base''') uchováva všetky vzťahy medzi vstupmi a očakávanými výstupmi v kolekcií '''IF-THEN''' pravidiel
* '''uvažujúca jednotka''' použije vstupy a aplikuje na nich konkrétne pravidlá
* '''defuzzifier''' prekonvertuje výsledok rozhodovania a sparsované výstupy pošle späť na klienta

V prípade viacerých vstupov sú fuzzy pravidlá väčšinou prepojené logickým spojením (konektorom) AND, pričom '''rule-base''' musí pokrývať každú možnú kombináciu všetkých výrazov z definičného oboru vstupnej premennej. Táto požiadavka úplnosti ale vedie k tzv. '''rule explosion problém'''-u, kde pre systém s n vstupmi, ktorý má každý m možných stavov potrebujeme celkovo '''m^n''' pravidiel! Toto pravidlo výbuchu predstavuje vážny problém a komplikuje implementovanie fuzzy kontrolovania vďaka vysokým nárokom na CPU zdroje. Combs navrhol [https://en.wikipedia.org/wiki/Combs_method URC (Union Rule Configuration)] na zmiernenie tohto problému, kedy sa zložitosť výpočtu zníži na '''m*n''' pravidiel.

== Zhrnutie ==

= Zdroje =

<references/>
3. https://www.samsung.com/in/support/home-appliances/what-is-fuzzy-logic-in-a-washing-machine/

= Odpovede =
'''1.''' Nezmenil by sa. Pri 1 pravidle sú odpovede jednoznačné, takže matica bude mať rovnaký počet výstupov aj v prípade, ak by množina s pozdravmi obsahovala iba 1 prvok.
'''2.''' Príbuzenský vzťah, hierarchické postavenie (môže sa týkať napríklad štátnej moci alebo aj postavenia vo firme), miesto stretnutia atď.
'''3.a)''' Starec by pozdravil chlapca kráľa "Dobrý deň". [(hodnosť kráľa)100 * 0.1 = '''10 > 0.6''']
'''3.b)''' Starec kňaz by pozdravil chlapca kráľa "Ahoj". [ (hodnosť kráľa)100 * 0.1 = '''10 < 12''' = 0.6 * 20 (hodnosť kňaza)]
'''3.c)''' Starec kňaz pozdraví chlapca kráľa pozdravom "Dobrý deň" o 3 roky [100 * 0.13 = '''13 > 12.6''' = 0.63 * 20]