VIK Wiki - Felhasználó közreműködései [hu]

Szoftverarchitektúrák - Jegyzet

2013-10-14T16:36:44Z

Lancelot:

A régi, doktoranduszok által írt, hivatalos jegyzet [[Media:Szoftarch_jegyzet_2011_patternek.pdf | letölthető innen]].

Ennél persze több van, érdemes átnézni a tárgyhonlapot.

==I. Szolgáltatás-hozzáférési és konfigurációs minták==

===I.1. Wrapper Facade===
Nem OO API-k elé egy OO réteget húzunk, ami nyújt bizonyos szolgáltatásokat, ami felhasználja az alatta levő réteget. Így az alacsony szintű API helyett egy OO-sat hívunk, ez kényelmesebb és hordozhatóbb. Hátránya, hogy a funkcionalitás csökkenhet, valamint valószínűleg lassabb lesz a kód.

===I.2. Component Configurator===
Egy szolgáltatás interface-re több implementáció is létezhet, amelyek közül nem feltétlenül tudjuk kiválasztani fejlesztés közben a legjobbat. Ezzel a mintával elkészítjük az összes implementációt, és futási időben választjuk ki, hogy melyiket használjuk. A komponenseknek kell az életciklusukat kezelni, tehát elindítani és leállítani. Hátránya, hogy nem determinisztikus, valamint bonyolultabb lesz a kód.

Szereplői:
* Komponens: Szolgáltatást leíró interface
* Konkrét komponensek: Az interface-t megvalósító osztályok
* Komponenstár (repository): Tárolja a konkrét komponenseket
* Komponens konfiguráló: A komponensekhez konkrét komponenst rendel, és ezt futásidőben tudja változtatni.

===I.3. Interceptor===
Az interceptor egy olyan eseménykezelő, amit a keretrendszer eseményeire lehet kötni. Hasonlít az AOP-hez.

Szereplői:
* Konkrét keretrendszer (framework): Egy generikus architektúra
* Elfogó (interceptor): Olyan interface, amely az egyes eseményekre bekövetkező eseménykezelőnek meg kell valósítania
* Konrét elfogó: Interceptor implementációja
* Diszpécser (dispatcher): Eseményekhez van rendelve, ehhez pedig lehet konkrét elfogó. Ez fogja hívni az interceptort.
* Kontextus objektum: Az eseményt és a keretrendszert lehet rajtuk keresztül elérni az elfogóból
* Alkalmazás: A keretrendszeren futó alkalmazás

===I.4. Extension Interface===
Akkor jó, ha úgy kell kiterjeszteni egy osztályt, hogy a kliensen ne kelljen változtatni. Példakódhoz [http://stackoverflow.com/questions/1055833/need-citation-for-extension-interface-pattern-in-java lásd]

Szereplői:
* Komponens: Ezt szeretnénk kiterjeszteni
* Kiterjesztő interface: A komponens szerepeit tartalmazza
* Gyökér interface: Minden komponensnek meg kell valósítania, ettől lehet lekérni a kiterjesztő interface-kat, valamint közös szolgáltatásokat is adhat.
* Kliens: Aki hívja
* Komponensgyár: A gyökeret lehet tőle kikérni

==II. Eseménykezelési minták==
===II.1. Reactor===
[[OotTervezesiMintak#Reactor | Lásd.]]

Szereplői:
* Kezelő: OS biztosítja, ami jelzést tud adni, pl hálózati kapcsolat.
* Szinkron esemény szétválasztó: Addig blokkolódik, amíg nincs jelzés
* Eseménykezelő interface: Megadja, hogyan kell az eseményt feldolgozni
* Konkrét eseménykezelő: Az előző interface-t megvalósítja
* Reaktor interface: Eseménykezelőt lehet hozzáadni és eltávolítani

===II.2. Proactor===
A reactor aszinkron változata, híváskor a kezelőt aszinkron módon hívja meg, és amikor az visszatér, akkor kikeresi a kezelőt, amivel választ tud küldeni.

===II.3. Asynchronous Completion Token (ACT)===
Mint a proactor, csak a választ kezelőt megkapja a feldolgozó, ezért nem kell kikeresni. [http://en.wikipedia.org/wiki/Proactor_pattern Leírás.]

===II.4. Acceptor-Connector===

* Acceptor: Passzívan várakozik bejövő kapcsolatra
* Connector: Aktívan felép egy kapcsolatot

A kapcsolat felépítése után várakoznak eseményre, amit valamelyik másik minta fog kezelni. Azért jó, mert leválasztható vele az, hogy éppen klienst vagy szervert írunk.

==III. Konkurenciakezelési minták==
===III.1. Active Object===
[[OotTervezesiMintak#Akt_v_objektum | Lásd.]]

===III.2. Monitor Object===
[[OotTervezesiMintak#Monitor | Lásd.]]

===III.3. Half-Sync/Half-Async===
Lényege, hogy hardverfejlesztők aszinkron műveleteket szeretnek, szoftveresek meg szinkronokat. Ezzel a mintával megoldható, hogy mindenki úgy programozzon, ahogy szeretne.

Szereplői:
* Aszinkron réteg: Az aszinkron hívások végrehajtásáért felel
* Szinkron réteg: A szinkron hívások végrehajtásáért felel
* Üzenetkezelő réteg: A másik 2 réteg üzenetekkel kommunikál egymással, ezen keresztül
* Eseményfigyelő: Eseményre meghívja az aszinkron réteget

===III.4. Leader/Followers===
[[OotTervezesiMintak#Vezet_k_vet | Lásd.]]

==IV. Szinkronizációs tervezési minták==
===IV.1. Scoped Locking===
Felhasználja, hogy a C++-ban amikor kilép a vezérlés az objektum scope-jából, akkor lefut a destruktora. Így a lock egy Guard osztály, aminek a konstruktorában lefoglalódik a zár, a destruktorában felszabadul. Így a zárolt részt bárhogyan hagyjuk el, biztosan nem marad zárolva.

===IV.2. Strategized Locking===
A lényege, hogy a lock objektumot paraméterként megadhatóvá tesszük, így a védett objektum létrehozásakor megadhatjuk, hogy milyen módon zárolható (R/W lock, mutex, stb...). Ehhez kell egy ősosztály, amiből a különböző implementációkat származtatjuk.

===IV.3. Thread-Safe Interface===
A probléma az, hogy egy osztályon belüli metódushívásoknál többször is zárolni akar, akkor self-deadlock alakul ki. Ezért elválasztjuk a publikus metódusok hívását és az implementációjukat private metódusokba tesszük, és minden publikus metódus elején zárolunk, a többinél azonban nem. Így ha a függvények egymást hívják, nem lesz újrazárolás, viszont minden bejöbő hívás zárolt lesz.

===IV.4. Double-Checked Locking Optimization===
Ha egy kritikus szakasznak pontosan 1-szer szabad lefutnia, akkor zárolás után is meg kell győződnünk arról, hogy még nem futott-e le. Ez pl. Singletonok létrehozásánál lehet fontos, mivel a létrehozó fv-t több szál is meghívhatja egyszerre, ekkor ha csak záraink vannak, akkor egymás után több példányt is létrehoznak belőle.

Pl:<pre>
static SingletonClass *GetInstance() {
//Az első ellenőrzés.
if (instance == 0) {
//Szinkronizálás.
Guard guard(lock);
//A második ellenőrzés.
if (instance == 0)
instance = new SingletonClass();
}
return instance;
}
}
</pre>

-- [[PallosTamas|Velias]] - 2010.10.14.
-- [[SallaiTamas|sashee]] - 2010.10.16.

[[Category:InfoMsc]]

Szoftverarchitektúrák - Jegyzet

2013-10-13T18:40:36Z

Lancelot: régi jegyzet beillesztése

Ennél persze több van, érdemes átnézni a tárgyhonlapot.

Régi, hivatalos jegyzet [[Fájl:InfMsc_szoftarch_JegyzetPatternek.pdf]]

==I. Szolgáltatás-hozzáférési és konfigurációs minták==

===I.1. Wrapper Facade===
Nem OO API-k elé egy OO réteget húzunk, ami nyújt bizonyos szolgáltatásokat, ami felhasználja az alatta levő réteget. Így az alacsony szintű API helyett egy OO-sat hívunk, ez kényelmesebb és hordozhatóbb. Hátránya, hogy a funkcionalitás csökkenhet, valamint valószínűleg lassabb lesz a kód.

===I.2. Component Configurator===
Egy szolgáltatás interface-re több implementáció is létezhet, amelyek közül nem feltétlenül tudjuk kiválasztani fejlesztés közben a legjobbat. Ezzel a mintával elkészítjük az összes implementációt, és futási időben választjuk ki, hogy melyiket használjuk. A komponenseknek kell az életciklusukat kezelni, tehát elindítani és leállítani. Hátránya, hogy nem determinisztikus, valamint bonyolultabb lesz a kód.

Szereplői:
* Komponens: Szolgáltatást leíró interface
* Konkrét komponensek: Az interface-t megvalósító osztályok
* Komponenstár (repository): Tárolja a konkrét komponenseket
* Komponens konfiguráló: A komponensekhez konkrét komponenst rendel, és ezt futásidőben tudja változtatni.

===I.3. Interceptor===
Az interceptor egy olyan eseménykezelő, amit a keretrendszer eseményeire lehet kötni. Hasonlít az AOP-hez.

Szereplői:
* Konkrét keretrendszer (framework): Egy generikus architektúra
* Elfogó (interceptor): Olyan interface, amely az egyes eseményekre bekövetkező eseménykezelőnek meg kell valósítania
* Konrét elfogó: Interceptor implementációja
* Diszpécser (dispatcher): Eseményekhez van rendelve, ehhez pedig lehet konkrét elfogó. Ez fogja hívni az interceptort.
* Kontextus objektum: Az eseményt és a keretrendszert lehet rajtuk keresztül elérni az elfogóból
* Alkalmazás: A keretrendszeren futó alkalmazás

===I.4. Extension Interface===
Akkor jó, ha úgy kell kiterjeszteni egy osztályt, hogy a kliensen ne kelljen változtatni. Példakódhoz [http://stackoverflow.com/questions/1055833/need-citation-for-extension-interface-pattern-in-java lásd]

Szereplői:
* Komponens: Ezt szeretnénk kiterjeszteni
* Kiterjesztő interface: A komponens szerepeit tartalmazza
* Gyökér interface: Minden komponensnek meg kell valósítania, ettől lehet lekérni a kiterjesztő interface-kat, valamint közös szolgáltatásokat is adhat.
* Kliens: Aki hívja
* Komponensgyár: A gyökeret lehet tőle kikérni

==II. Eseménykezelési minták==
===II.1. Reactor===
[[OotTervezesiMintak#Reactor | Lásd.]]

Szereplői:
* Kezelő: OS biztosítja, ami jelzést tud adni, pl hálózati kapcsolat.
* Szinkron esemény szétválasztó: Addig blokkolódik, amíg nincs jelzés
* Eseménykezelő interface: Megadja, hogyan kell az eseményt feldolgozni
* Konkrét eseménykezelő: Az előző interface-t megvalósítja
* Reaktor interface: Eseménykezelőt lehet hozzáadni és eltávolítani

===II.2. Proactor===
A reactor aszinkron változata, híváskor a kezelőt aszinkron módon hívja meg, és amikor az visszatér, akkor kikeresi a kezelőt, amivel választ tud küldeni.

===II.3. Asynchronous Completion Token (ACT)===
Mint a proactor, csak a választ kezelőt megkapja a feldolgozó, ezért nem kell kikeresni. [http://en.wikipedia.org/wiki/Proactor_pattern Leírás.]

===II.4. Acceptor-Connector===

* Acceptor: Passzívan várakozik bejövő kapcsolatra
* Connector: Aktívan felép egy kapcsolatot

A kapcsolat felépítése után várakoznak eseményre, amit valamelyik másik minta fog kezelni. Azért jó, mert leválasztható vele az, hogy éppen klienst vagy szervert írunk.

==III. Konkurenciakezelési minták==
===III.1. Active Object===
[[OotTervezesiMintak#Akt_v_objektum | Lásd.]]

===III.2. Monitor Object===
[[OotTervezesiMintak#Monitor | Lásd.]]

===III.3. Half-Sync/Half-Async===
Lényege, hogy hardverfejlesztők aszinkron műveleteket szeretnek, szoftveresek meg szinkronokat. Ezzel a mintával megoldható, hogy mindenki úgy programozzon, ahogy szeretne.

Szereplői:
* Aszinkron réteg: Az aszinkron hívások végrehajtásáért felel
* Szinkron réteg: A szinkron hívások végrehajtásáért felel
* Üzenetkezelő réteg: A másik 2 réteg üzenetekkel kommunikál egymással, ezen keresztül
* Eseményfigyelő: Eseményre meghívja az aszinkron réteget

===III.4. Leader/Followers===
[[OotTervezesiMintak#Vezet_k_vet | Lásd.]]

==IV. Szinkronizációs tervezési minták==
===IV.1. Scoped Locking===
Felhasználja, hogy a C++-ban amikor kilép a vezérlés az objektum scope-jából, akkor lefut a destruktora. Így a lock egy Guard osztály, aminek a konstruktorában lefoglalódik a zár, a destruktorában felszabadul. Így a zárolt részt bárhogyan hagyjuk el, biztosan nem marad zárolva.

===IV.2. Strategized Locking===
A lényege, hogy a lock objektumot paraméterként megadhatóvá tesszük, így a védett objektum létrehozásakor megadhatjuk, hogy milyen módon zárolható (R/W lock, mutex, stb...). Ehhez kell egy ősosztály, amiből a különböző implementációkat származtatjuk.

===IV.3. Thread-Safe Interface===
A probléma az, hogy egy osztályon belüli metódushívásoknál többször is zárolni akar, akkor self-deadlock alakul ki. Ezért elválasztjuk a publikus metódusok hívását és az implementációjukat private metódusokba tesszük, és minden publikus metódus elején zárolunk, a többinél azonban nem. Így ha a függvények egymást hívják, nem lesz újrazárolás, viszont minden bejöbő hívás zárolt lesz.

===IV.4. Double-Checked Locking Optimization===
Ha egy kritikus szakasznak pontosan 1-szer szabad lefutnia, akkor zárolás után is meg kell győződnünk arról, hogy még nem futott-e le. Ez pl. Singletonok létrehozásánál lehet fontos, mivel a létrehozó fv-t több szál is meghívhatja egyszerre, ekkor ha csak záraink vannak, akkor egymás után több példányt is létrehoznak belőle.

Pl:<pre>
static SingletonClass *GetInstance() {
//Az első ellenőrzés.
if (instance == 0) {
//Szinkronizálás.
Guard guard(lock);
//A második ellenőrzés.
if (instance == 0)
instance = new SingletonClass();
}
return instance;
}
}
</pre>

-- [[PallosTamas|Velias]] - 2010.10.14.
-- [[SallaiTamas|sashee]] - 2010.10.16.

[[Category:InfoMsc]]

Fájl:Szoftarch jegyzet 2011 patternek.pdf

2013-10-13T18:25:28Z

Lancelot:

Kooperáció és gépi tanulás laboratórium - 3. mérés beugró kérdései

2013-10-10T07:17:38Z

Lancelot: Új oldal, tartalma: „Mérés 3 Beugró kérdések kidolgozása - Mi a STRIPS? Stanford Research Institute Problem Solver. Automata tervkészítő - Mi az RRT? Részben Rendezett Tervkész…”

Mérés 3 Beugró kérdések kidolgozása

- Mi a STRIPS?
Stanford Research Institute Problem Solver. Automata tervkészítő
- Mi az RRT?
Részben Rendezett Tervkészítés.

- Rajzolja fel a Sussman anomáliát (start- és célállapot)!
- Mi az LPG?
RRT alap Local search for Planning Graphs tervkészítő alkalmazás. PDDL-ben leírt problémák megoldására használható.

- Nevezze meg a PDDL 2.1 három szintjét!

- Milyen részekre bomlik egy PDDL leírás, és miért?
Az I. szint a problémák elsőrendű logikai leírását biztosítja (STRIPS-hez hasonló módon); a II. szint már nem csak logikai, hanem numerikus változókat és kényszereket is megenged, továbbá jósági kritériumok megfogalmazására is lehetőséget ad; a III. szint pedig már időzítéseket is tartalmaz.

- Milyen részekből áll a domain-leírás?
(define (domain sussman1)
(:requirements :strips :equality)
(:constants table)
(:predicates (on ?x ?y)))

domain-leírás ilyen értelemben tehát egy lista, melynek első eleme egy „define” string. Ezt követi egy 2-elemű lista. a domain-leírás tervkészítőkkel szemben támasztott követelményeinek felsorolása A lista többi eleme pedig az úgynevezett követelmény flag-ek halmaza konstans deklaráció - nem kötelező, csak akkor szükséges, ha létezik olyan objektum (ezt nevezik konstansnak), amely a domain összes létező problémájában előfordul. Itt vannak a lehetséges cselekvések is felsorolva.
predikátumok listája

- Milyen részekből áll a probléma-leírás? (a fejlécen kívül)
1. Világban létező véges sok objektum felsorolása
2. Világ kiinduló-állapotában igaz tények felsorolása
3. Célállapot meghatározása

- Milyen flag-et kell a domain-leírás követelmény-részébében feltüntetni típusok kapcsán?
- typing
- Milyen flag-et kell a domain-leírás követelmény-részébében feltüntetni numerikus változók kapcsán?
- fluents
- Milyen flag-et kell a domain-leírás követelmény-részébében feltüntetni folytonos idejű cselekvések kapcsán?
- durative-actions
- Milyen flag-et kell a domain-leírás követelmény-részébében feltüntetni származtatott predikátumok kapcsán?
- derived-predicates

- Milyen flag-et kell a domain-leírás követelmény-részébében feltüntetni időzített kezdeti literálok kapcsán?
- timed-initial-literals
- Mik a típusok PDDL-ben, és hol és hogyan adjuk meg a hierarchiájukat?
Valamiféle tulajdonság, amely minden objektumhoz rendel egy típus-azonosítót, vagy egyfajta kategória, osztály. (:types után sorolhatjuk fel a típusokat, és hierarchiájukat) pl.(:types Car Van Truck – MotorVehicle MiniVan – (either Car Van))

- Miből áll egy predikátum definíciója a domain-leírásban?
argumentumok (változók) felsorolása. neve
- Miből áll egy numerikus változó definíciója a domain-leírásban?
(:functions
(data_capacity ?s - satellite)
(data ?d - direction ?m - mode)
(slew_time ?a ?b - direction)

- Miből áll a cselekvés-sémák definíciója a domain-leírásban?
(:action switch_on
:parameters (?i ?s)
:precondition (and (on_board ?i ?s)
(power_avail ?s))
:effect (and (power_on ?i)
(not (calibrated ?i))
(not (power_avail ?s)))
)
elnevezés, paraméterek, elő és -utófeltételek
- Mi a hasonlóság/különbség a cselekvés-sémák és a tervbéli cselekvések között?

- Mi a hasonlóság/különbség a PDDL objektumok és konstansok között?
A hasonlóság, hogy ugyanúgy fel lehet őket használni paraméterekként. A konstans is objektum, csak a konstans a domain összes létező problémájában előfordul.
- Adjon példát numerikus változók értékadására a probléma-leírásban!
(:init
(= (fuel satellite0) 112)
(= (data Phenomenon3 image1) 22)
)
- Adjon példát jósági mérce definíciójára a probléma-leírásban! Mire jó ez általában?
(:metric minimize (fuel-used)) arra jó, hogy leszűkítsük a jó megoldások körét. Csak olyan megoldásokat mutasson a tervkészítő, amilyenekre szükségünk van.
- Miből áll pontosan egy LPG által visszaadott megoldási terv?
Események, tények száma. Mennyi időbe telt elkészíteni a tervet. A terv pontos eseményleírása. Mely időpontokban milyen akciókat kell végrehajtani.Kimeneti fájl.

- Fizikailag hogyan működnek a laborgyakorlatban vizsgált web-áruházak?

- Üzleti logika szempontjából nézve hogyan működnek a laborgyakorlatban vizsgált web-áruházak?

- Milyen JADE-es ágens(eke)t használunk a laborgyakorlat során, és milyen célból?
PlanExecutorAgent
- Mire való a CSVtable osztály?
Arra, hogy a CSV fájlokban tárolt objektumokat és a tények megfogalmazásához szükséges adatokat könnyen át tudjuk konvertálni PDDL szintaxisúvá.
- Milyen CSV fájlokkal dolgozunk a laborgyakorlat során, és melyik-mire való (mit tartalmaz)?
1.Katalógus: mi-mennyiért-hol, milyen URL-en tehetjük kosárba.
2.Áruház-szótár(nem biztos, hogy a PDDL lerásban ugyanaz a neve, mint a CSV fájlban)
3.Termék-szótár
- Mire való és hogyan működik a PlanExecutorAgent ágens parsePlanString metódusa?
Beolvas egy LPG által generált tervet, fájlt.
- Mire való és hogyan működik a PlanExecutorAgent ágens interpretAction metódusa?
Itt kell ugyanis beállítanunk, hogy a paraméterként megadott LPG-s megoldási tervből kiolvasott cselekvéseket hogyan alakítsuk át URL-lé.

- Mire való és hogyan működik a PlanExecutorAgent ágens executeInterpretation metódusa?
Arra való, hogy az áruházban kikeresett termékeink URL-jét kikeressük, ami a PDDL cselekvés fizikai interpretációja. Küld egy HTTP REQUEST-et az adott URL-re.

- Mire való és hogyan működik a PlanExecutorAgent ágens ExecutePlan viselkedése?
Az említett metódusok megfelelően ütemezett és paraméterezett hívását a PlanExecutorAgent.ExecutePlan JADE-viselkedés végzi
- Milyen főbb lépések végrehajtásával jut el egy intelligens tervkészítő ágens a valós problémától a valós megoldásig? (ábra + rövid szöveg)

�

Kooperáció és gépi tanulás laboratórium - 4. mérés beugró kérdései

2013-10-09T18:58:50Z

Lancelot: Új oldal, tartalma: „ - Milyen elemekbõl áll egy játék normál alakja? (felsorolás) Játékosok, stratégiák, haszonfüggvények, kimenetelek. - Mik a stratégiák? A játékosok l…”

- Milyen elemekbõl áll egy játék normál alakja? (felsorolás)

Játékosok, stratégiák, haszonfüggvények, kimenetelek.

- Mik a stratégiák?

A játékosok lehetőségei a másik játékosok lépéseinek függvényében.

- Mire valók a játékosok haszonfüggvényei?

Egy valós számot rendelnek a lépésekhez, amivel értékelik a lépés kifizetését.

- Mik egy játék kimenetelei?

A stratégia kombinációk eredménye.

- Mit értünk egy adott játékos domináns stratégiáján? Mindig létezik ilyen?

Ha a többi játékos döntésétől függetlenül, mindig jó eredményt hoz. Nem mindig létezik.

- Mit értünk Nash-egyensúly alatt? Mindig létezik ilyen (tiszta és kevert esetben)?

Nash egyensúly nem mindig egyértelmű.

- Mit értünk Pareto-optimumon?

Az az állapot, amelyikből egyik ágensnek sem éri meg eltérni anélkül, hogy bármely másik rosszabbul járjon.

- Mi a különbség a tiszta és kevert stratégiák között?

Tiszta stratégiánál egy stratégiáról beszélünk, míg kevert esetén a stratégiák valamilyen valószínűséggel következnek be.

- Mit nevezünk kevert stratégiának?

Amikor a játékos több stratégiát is játszhat és csak a stratégiák valószínűségét ismerjük, az a kevert stratégia.

- Mikor szimmetrikus egy 2-szereplõs játék?

Ha mindkét fél azonos stratégiákat játszik, a hasznosságfüggvényeik megegyeznek.

- Minek a rövidítése a TFT, és mire való?

Tit-for-tat rövidítése. Egy stratégia ismétlődő, 2 szereplős játékokban.

- Hogyan mûködik ismételt, 2-szereplõs játékok esetén a Tit-For-Tat (TFT) stratégia-választó program?

Első lépésben kooperatív, utána másolja az ellenfél stratégiáját. Szemet-szemért alapon játszik, meglepően eredményes.

- Mi a kapcsolat egy játék extenzív és normál alakja között?

Az extenzív alak a normálalak kiegészítve, mely mélyebb betekintést enged a stratégiák szerkezetébe. pl. dinamika temporális és logikai felépítés.

- A kiadott 2-lapos pókerjátékban pontosan mikor blöfföl egy játékos?

Ha alacsony kártyára emel.

- Írja fel a Fogolydilemma játék bimátrixát! (a könnyebbség kedvéért gondoljon a játékhoz kötõdõ történetre)

A,B
B Vall
B Tagad
A Vall
-2,-2
3,-3
A Tagad
-3,3
2,2

- Írja fel a Gyáva Nyúl játék bimátrixát! (a könnyebbség kedvéért gondoljon a játékhoz kötõdõ történetre)

A,B
B Vakmerő
B Gyáva
A Vakmerő
-10,-10
1,-1
A Gyáva
-1,1
0,0

- Írja fel a Nemek Harca játék szimmetrikus bimátrixát! (a könnyebbség kedvéért gondoljon a játékhoz kötõdõ történetre)

A,B
B Balett
B Meccs
A Balett
1,2
-1,-1
A Meccs
0,0
2,1

- Írja fel a Vezérürü játék bimátrixát! (a könnyebbség kedvéért gondoljon a játékhoz kötõdõ történetre)

A,B
B Megy
B Vár
A Megy
-10,-10
2,1
A Vár
1,2
0,0

- Írja fel az Érmepárosítás játék bimátrixát! (a könnyebbség kedvéért gondoljon a játékhoz kötõdõ történetre)

A,B
B Fej
B írás
A Fej
1,-1
-1,1
A Írás
-1,1
1,-1

- Írja fel a 2-szereplõs Héja-Galamb játék paraméteres bimátrixát! (a könnyebbség kedvéért gondoljon a játékhoz kötõdõ történetre)

A,B
B Héja
B Galamb
A Héja
(V-C)/2,(V-C)/2
V,0
A Galamb
0,V
V/2,V/2

- Melyik játéknak felel meg a Héja-Galamb játék, hogyha V>C, illetve mikor V<C?

Ha V<C: gyáva nyúl,
Ha V>C: fogolydilemma

- Írja fel a 3 szereplõs Közlegelõk Tragédiája játék mátrixát!
- Mire való a GAMBIT alkalmazás?
- Mire használhatjuk az msclab01.gametheory_lab.Game osztályt?

Konzolos megjelenítése a játék haszonfüggvényének, Nash egyensúlyának.

- Milyen ágensek szerepelnek a laborgyakorlatban, és hogyan mûködnek együtt (nagyon vázlatosan)?

Játékvezető és Gépi ill. Emberi játékosok, a játékvezetőn keresztül.

- Milyen típusú üzenetek cserélnek gazdát a GameAgent ágens és a többi platformon lévõ ágens közt?

INFORM és REQUEST

- Mire való a GameAgent ágens?

Játékvezető ágens.

- Mire való a UserAgent ágens?

Felhasználói ágens (emberi)

- Mire való a Player ágens?

Játékos ágens (gépi)

- Mire való a Player ágens myType paramétere?

Itt adható meg a Player (gépi) stratégiája pl. PlayerType.RANDOM. Ezt kell TFT-re állítani a labor felkészülés során.

- Mi a JADEX-es ADF?
- Hogy történik egy JADEX-es (ADF-ben definiált) ágens JADE-es futtatása?

Kooperáció és gépi tanulás laboratórium

2013-10-09T18:58:31Z

Lancelot: /* Beugró kérdések */

{{Tantárgy
| név = Kooperáció és<br>gépi tanulás laboratórium
| tárgykód = VIMIM223
| szak = info MSc
| kredit = 4
| félév = 2
| kereszt =
| tanszék = MIT
| labor = 10 db
| kiszh =
| nagyzh =
| hf =
| vizsga =
| levlista =
| tad = https://www.vik.bme.hu/kepzes/targyak/vimim223/
| tárgyhonlap = http://www.mit.bme.hu/oktatas/targyak/vimim223
}}

== Beugró kérdések ==
[[Harmadik mérés beugró kérdései]]

[[Negyedik mérés beugró kérdései]]

[[Category:InfoMsc]]

Kooperáció és gépi tanulás laboratórium

2013-10-09T18:58:18Z

Lancelot: /* Beugró kérdések */

{{Tantárgy
| név = Kooperáció és<br>gépi tanulás laboratórium
| tárgykód = VIMIM223
| szak = info MSc
| kredit = 4
| félév = 2
| kereszt =
| tanszék = MIT
| labor = 10 db
| kiszh =
| nagyzh =
| hf =
| vizsga =
| levlista =
| tad = https://www.vik.bme.hu/kepzes/targyak/vimim223/
| tárgyhonlap = http://www.mit.bme.hu/oktatas/targyak/vimim223
}}

== Beugró kérdések ==
[[Harmadik mérés beugró kérdései]]
[[Negyedik mérés beugró kérdései]]

[[Category:InfoMsc]]

Kooperáció és gépi tanulás laboratórium

2013-10-09T18:57:55Z

Lancelot:

{{Tantárgy
| név = Kooperáció és<br>gépi tanulás laboratórium
| tárgykód = VIMIM223
| szak = info MSc
| kredit = 4
| félév = 2
| kereszt =
| tanszék = MIT
| labor = 10 db
| kiszh =
| nagyzh =
| hf =
| vizsga =
| levlista =
| tad = https://www.vik.bme.hu/kepzes/targyak/vimim223/
| tárgyhonlap = http://www.mit.bme.hu/oktatas/targyak/vimim223
}}

== Beugró kérdések ==
[Harmadik mérés beugró kérdései]
[Negyedik mérés beugró kérdései]

[[Category:InfoMsc]]

Intelligens rendszerek szakirány

2013-06-15T13:49:19Z

Lancelot: /* Tárgyak */

{{GlobalTemplate|Infoszak|MscIntelligensRendszer}}

==Tárgyak==

* [[Gépi tanulás]]
* [[MscInformacioEsTudasIntegralas|Információ és tudás integrálás]]
* [[MscBeagyazottIntelligensRendszerek|Beágyazott Intelligens Rendszerek]]
* [[Valószínűségi következtető és döntéstámogató rendszerek]]
* [[Kooperáció és intelligencia]]

-- [[PalfalviJozsef|afro]] - 2011.12.16.
-- [[ZsirosLeventeGabor|zslevi]] - 2010.02.24.
-- [[VelinszkyLaci|lancelot]] - 2013.06.15.

[[Category:Infoszak]]

Intelligens rendszerek szakirány

2013-06-15T13:21:07Z

Lancelot: /* Tárgyak */

{{GlobalTemplate|Infoszak|MscIntelligensRendszer}}

==Tárgyak==

* [[Gépi tanulás]]
* [[MscInformacioEsTudasIntegralas|Információ és tudás integrálás]]
* [[MscBeagyazottIntelligensRendszerek|Beágyazott Intelligens Rendszerek]]
* [[MscValoszinusegiKovetkeztetoEsDontestamogatoRendszerek|Valószínűségi következtető és döntéstámogató rendszerek]]
* [[MscKooperacioEsIntelligencia|Kooperáció és intelligencia]]

-- [[PalfalviJozsef|afro]] - 2011.12.16.
-- [[ZsirosLeventeGabor|zslevi]] - 2010.02.24.
-- [[VelinszkyLaci|lancelot]] - 2013.06.15.

[[Category:Infoszak]]