Szakdolgozat
Miskolci Egyetem
Közös fejleszt®i keretrendszer fuzzy szabály interpolációs módszerekhez
Készítette: Tóth Dávid 2008. Programtervez® Informatikus
Témavezet®: Krizsán Zoltán
Miskolc, 2013
Miskolci Egyetem
Gépészmérnöki és Informatikai Kar Alkalmazott Matematikai Tanszék
Szám:
Szakdolgozat Feladat
Tóth Dávid (EN2L32) programtervez® informatikus jelölt részére. A szakdolgozat tárgyköre: Fuzzy Szabály-Interpolációs módszerek keretrendszere A szakdolgozat címe: Közös fejleszt®i keretrendszer fuzzy szabály interpolációs mód-
szerekhez
A feladat részletezése:
A MTATLAB-ból már ismert Fuzzy Rule Interpolation Toolbox (FRIT) alapján C++ nyelven egy keretrendszer kialakítása. A meglév® 6 eljáráson túl további b®víthet®ség és könny¶ használat biztosítása.
Témavezet®: Krizsán Zoltán egyetemi tanársegéd Konzulens: Dr. Karácsony Zsolt, egyetemi adjunktus A feladat kiadásának ideje:
................................. szakfelel®s 2
Eredetiségi Nyilatkozat
Alulírott . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ; Neptun-kód: . . . . . . . . . . . . . . . . . . . a Miskolci Egyetem Gépészmérnöki és Informatikai Karának végz®s . . . . . . . . . . . . . . . . . . . szakos hallgatója ezennel büntet®jogi és fegyelmi felel®sségem tudatában nyilatkozom és aláírásommal igazolom, hogy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . cím¶ szakdolgozatom/diplomatervem saját, önálló munkám; az abban hivatkozott szakirodalom felhasználása a forráskezelés szabályai szerint történt. Tudomásul veszem, hogy szakdolgozat esetén plágiumnak számít:
• szószerinti idézet közlése idéz®jel és hivatkozás megjelölése nélkül; • tartalmi idézet hivatkozás megjelölése nélkül; • más publikált gondolatainak saját gondolatként való feltüntetése. Alulírott kijelentem, hogy a plágium fogalmát megismertem, és tudomásul veszem, hogy plágium esetén szakdolgozatom visszautasításra kerül.
Miskolc, . . . . . . . . . . . .év . . . . . . . . . . . .hó . . . . . . . . . . . .nap
................................. Hallgató
3
1.
szükséges (módosítás külön lapon) A szakdolgozat feladat módosítása nem szükséges ......................
...........................
dátum
témavezet®(k)
2. A feladat kidolgozását ellen®riztem: témavezet® (dátum, aláírás):
konzulens (dátum, aláírás):
..............
.............
..............
.............
..............
.............
3. A szakdolgozat beadható: ......................
...........................
dátum
témavezet®(k)
4. A szakdolgozat . . . . . . . . . . . . . . . . . . . szövegoldalt . . . . . . . . . . . . . . . . . . . program protokollt (listát, felhasználói leírást) . . . . . . . . . . . . . . . . . . . elektronikus adathordozót (részletezve) ................... . . . . . . . . . . . . . . . . . . . egyéb mellékletet (részletezve) tartalmaz.
5.
................... ......................
...........................
dátum
témavezet®(k) bocsátható
A szakdolgozat bírálatra nem bocsátható A bíráló neve: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ......................
...........................
dátum
szakfelel®s
6. A szakdolgozat osztályzata a témavezet® javaslata:
................
a bíráló javaslata:
................
a szakdolgozat végleges eredménye: . . . . . . . . . . . . . . . . Miskolc, . . . . . . . . . . . . . . . . . . . . . . . .
................................. a Záróvizsga Bizottság Elnöke 4
Tartalomjegyzék
1. Bevezetés
6
2. Téma elméleti kifejtése
8
2.1. A Fuzzy . . . . . . . . . . . . . . . . 2.2. Keretrendszerek tervezése . . . . . . 2.3. Megvalósítás módja . . . . . . . . . . 2.3.1. Library . . . . . . . . . . . . 2.3.2. DLL (Dinamic Link Library) . 2.3.3. A kiválasztott stratégia . . . . 2.4. FRI módszerek . . . . . . . . . . . .
3. 3 A keretrendszer
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
3.1. A keretrendszer szerkezete . . . . . . . . . . . . . . 3.2. A keretrendszer osztályai . . . . . . . . . . . . . . . 3.2.1. A kivételosztály . . . . . . . . . . . . . . . . 3.2.2. Az egylépéses FRI módszerek ®sosztálya . . 3.2.3. A kétlépéses FRI módszerek ®sosztálya . . . 3.3. A keretrendszer használata . . . . . . . . . . . . . . 3.3.1. LIB használata Visual Studio 2010-ben . . . 3.3.2. LIB használata Ubuntu alatt Eclipse-ben . . 3.4. A keretrendszer kib®vítése . . . . . . . . . . . . . . 3.5. A keretrendszerben található egylépéses módszerek 3.5.1. KH . . . . . . . . . . . . . . . . . . . . . . . 3.5.2. VKK . . . . . . . . . . . . . . . . . . . . . . 3.5.3. MACI . . . . . . . . . . . . . . . . . . . . . 3.5.4. GK(CRF) . . . . . . . . . . . . . . . . . . . 3.5.5. FIVE . . . . . . . . . . . . . . . . . . . . . . 3.6. A keretrendszerben található kétlépéses módszerek . 3.6.1. FRIPOC . . . . . . . . . . . . . . . . . . . . 3.7. Módszerek összegzése . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
8 10 11 11 11 13 14 17
17 19 20 22 24 26 26 30 31 33 34 35 35 36 36 37 37 38
4. Konklúzió
39
Irodalomjegyzék
41
Adathordozó használati útmutató
45
5
1. fejezet Bevezetés
Szakdolgozatom egy olyan problémára próbál megoldást kínálni, mellyel a következtet® rendszereket használók már találkozhattak. A probléma, amit nevezhetünk akár hiányosságnak is, a következ®: nincs olyan keretrendszer, amely összefogná a fuzzy szabály interpolációs módszereket, vagy azok egy részét, és valós id®ben adná vissza az eredményt. El®ször azonban szeretném röviden bemutatni a téma elméleti hátterét. A fuzzy rendszerek a következtetést a fuzzy szabályok segítségével számolják ki. A karakterisztikája ezeknek a rendszereknek leírható a szabályokkal. A klasszikus fuzzy következtet® eljárások megkövetelik az input intervallum teljes lefedését, ami azt jelenti, hogy minden egyes lehetséges meggyeléshez (observation) létezik legalább egy megel®z® antecedens, így kapjuk meg az érvényes következtetést (conclusion). A valóságban sokkal gyakoribb a másik típusú fuzzy rendszer, a ritka fuzzy rendszer. Ennek oka lehet a hiányos ismeret, ami azt jelenti, hogy kevesebb ismeret áll rendelkezésre, mint amennyi szükséges lenne egy teljes szabály bázishoz, vagy a teljesítményt rontaná nagyban egy teljesen fed® rendszer. Számos fuzzy eljárás létezik, melyek eredményt adnak ebben az esetben is. Ezeket Fuzzy Szabály Interpolációs eljárásoknak hívják, melyek a meglév® szabályokból le tudják generálni a következtetést. Ezeket a módszereket két nagy csoportba lehet sorolni az alapján, hogy milyen stratégia szerint generálják az eredményt: direkt eljárás (más néven egylépéses eljárás), a másik pedig a kétlépéses eljárás. A kétlépéses módszerek el®ször interpolálnak egy ideiglenes szabályt, ez alapján kiszámolják a következtetés pozícióját és alakját. A gyakorlatban többször el®fordul a ritka szabálybázisú fuzzy rendszer, mint a teljes lefedettség¶, mégis eddig nem volt olyan programozói keretrendszer, mely kezelte volna ezt az esetet, és több fuzzy interpolációs módszert is tartalmazna. Sajnos ennek köszönhet®, hogy éles környezetben egyáltalán nem használták a ritka szabály bázisú fuzzy interpolációs módszereket. Több programozói könyvtár is létezik a teljes szabály bázisú rendszerekhez, de nincs egy se, ami a ritka szabály rendszer esetén is jó volna. Eddig, ha egy olyan programot akartak fejleszteni, mely ritka szabálybázist használ, akkor a programozónak, vagy programozóknak a kiválasztott módszert egy programnyelven meg kellett írni. Ha azonban valamilyen okból kifolyólag át tértek másik nyelvre, akkor minden módszert újra és újra implementálni és tesztelni kellett, ami egyáltalán nem költséghatékony, a befektetett id®r®l nem is beszélve. Azon fejleszt®knek, akik nincsenek teljesen tisztában a fuzzy rendszerekkel, nagy segítséget nyújthat a MATLAB-os Fuzzy Toolbox [9] (ez a program könnyen használható, praktikus kutatásokhoz és bemutatókhoz, valamint letölthet® GNU liszensz alatt [10]), ahol különböz® 6
módszereket próbálhatnak ki és vethetik össze a kapott eredményeket. Azonban ha a projekt fejlesztési költségébe nem volt beleszámolva a MATLAB szoftver költsége, az plusz kiadást jelent, ugyanakkor a MATLAB alap szint¶ használatához is érteni kell, ami pedig id®ben jelent kiesést. Abban az esetben, ha gyors reakcióra van szükség, valós id®ben futó alkalmazás fejlesztésr®l van szó, a módszereket abban a nyelvben kell implementálni ahol használni is fogják azokat, mert minden beágyazott réteg jelent®sen megnöveli a rendszer válaszidejét, ezzel csökkentve a program használhatóságát. A már említett MATLAB-os FRI Toolbox éles környezetbe való átültetése csak más nyelvbe való beágyazással történhet, de ennek több hibája is van. Nem támogatja csak a MATLAB saját nyelvét, nem használható más matematikai ingyenes szoftverb®l vagy natív programozói nyelvb®l (Java, C# vagy Python). A beágyazást C++ alkalmazásba meg lehet tenni, de ebben az esetben az eredmények kiértékelése nem elég gyors. Szakdolgozatom témája tehát egy olyan keretrendszer kifejlesztése, mely kezeli a ritka szabálybázisú fuzzy rendszereket, könnyen b®víthet® és elég gyors m¶ködést biztosít egy valós id®ben futó alkalmazásnak. Els® lépésként a Windows és Linux operációs rendszerek támogatása a cél, azok elterjedtsége miatt. Szakdolgozatomban a témát az alábbi részekre taglalom:
• Fuzzy bemutatása, LIB és DLL összevevtése • Keretrendszer ismertetése • FRI metódusok jellemz®i • Szerkezet és osztályok leírása • Keretrendszer használata és kib®vítése • FRI metódusok, melyek implementálásra kerültek
7
2. fejezet Téma elméleti kifejtése
2.1. A Fuzzy Az életben vannak dolgok, amikr®l egyértelm¶en megállapítható, hogy mik azok pontosan. Például egy pontyról meg tudjuk mondani, hogy hal, egy németjuhászról pedig azt, hogy kutya. Az ilyen helyzeteket könnyen szemléltethetjük a matematika nyelvén halmazokkal, Venn diagram segítségével (2.1 ábra). Az A halmaznak minden elemér®l elmondható, hogy teljes egészében az A-ban helyezkedik el. Ha logikailag szeretnénk megfogalmazni, akkor a halmazon belül lév® elemek igaz (1) értéket kapnak, az azon kívül es®k pedig hamis (0) értékkel írhatóak le. Vannak viszont olyan fogalmak, tárgyak, stb, amirk®l már nem tudjuk egyértelm¶en megmondani, hogy melyik csoportba, hova tartoznak. Vegyük például az ember fején lév® hajszálakat, vagy éppen azok hiányát. Mi az a hajszál szám, ahonnan valakit már kopasznak lehet titulálni? Nyilván való, hogy ha egy szál haja sincs az illet®nek, az az egyén kopasz, és akinek dús frizurája van, ® egyáltalán nem sorolható ebbe a csoportba. A két végpont között azonban vannak köztes állapotok is, hiszen az utcán sétálva nem csak dús hajú, vagy kopasz egyéneket látni. Emberi nyelven nem nehéz megfogalmazni az ilyen és ehhez hasonló helyzeteket, de a matematika és az informatika nyelvén, hogy ez értelmezhet®vé váljon, a fuzzy halmazokat használjuk. A fuzzy lehet®vé teszi, hogy egy halmaz elemeir®l azt is meg tudjuk mondani, mennyire van benne, nem csak 1-essel és 0-ával tudjuk jellemezni. Így tehát az imént említett A halmaz minden eleméhez hozzá tudunk rendelni egy számot 0 és 1 között. Ezek segítségével a halmaz elmélet nem korlátozódik éles határú halmazokra, hanem megadhatjuk, hogy az elemek mennyire tartozzanak bele egyes csoportokba, szokás ezért ezeket elmosódott él¶ halmazoknak is nevezni. A különbség szemléltetésének kedvéért ezt is Venn diagramon mutatom be els®nek (2.2 ábra).
8
2.1. A Fuzzy
2.1. ábra. Hagyományos Venn diagram
2.2. ábra. Elmosódott él¶ halmaz Venn diagram használatával Az általános iskolai padban ülve, matematika órán, még elegend®ek voltak az éles (crisp) halmazok, melyeknek elemeir®l egyértelm¶en meghatározható volt, hogy hova tartoznak. Kés®bb azonban ez a szemlélet már nem állja meg a helyét, hiszen vannak olyan dolgok, amelyek egyszerre több helyre is tartoznak, de nem egyforma mértékben. Az emberek számára ez könnyen érthet®, azonban mindezt a gondolatmenetet átültetni a számítógépbe már nem olyan egyszer¶. Az el®bbi példához visszatérve nem a hajszálak alapján mondható valakir®l, hogy kopasz, hanem úgy is, hogy fejtetején milyen %-ban van haj. Így tehát a 2.3 ábrán Fuzzy halmazok segítségével már egyértelm¶en tudjuk ábrázolni ezt az esetet. Amint látszik, vannak bizonyos részek ahol egyértelm¶en megmondható, melyik
2.3. ábra. Fuzzy halmazok ábrázolása 9
2.2. A Fuzzy
csoportba tartozik az illet®, de vannak átfedések is.
2.2. Keretrendszerek tervezése A most következ® rész ki fog térni a keretrendszerek fejlesztésében követend® mintákra, melyeknek f® forrása Kent Beck alkotása volt [17]. A keretrendszerek fejlesztésének, verzióváltásának egyik legnagyobb problémája az, hogy a programozók nem módosíthatják a felhasználók kódját. Az ügyfél szempontjából viszont annál jobb, minél kevésbé lát bele a programba elegend® számára az, ha zökken®mentesen tudja a rendszert használni. Keretrendszer írásánál gondolni kell a majdani verzió frissítésekre, újabb változat megjelentetésére. A veszélye ennek az inkompatibilitás, amikor a felhasználó kódja "elromlik", hibák keletkeznek anélkül, hogy ®(k) bármit is változtatott volna. Tehát egy-egy frissítés kiadásánál arra kell gyelni, hogy a keretrendszerhez úgy kerüljön új funkció, hogy a régiek továbbra is tökéletesen m¶ködjenek. Persze ezt nem könny¶ kivitelezni, f®leg úgy, hogy a mérleg másik nyelvén a költségek, a munkaóra alacsonyan tartása szerepel. Egy általános programnál például elegend® a változókat, függvényeket protected-ként létrehozni, keretrendszer esetében azonban el®nyösebb (még ha ez meg is nehezíti olykor a dolgokat) private biztonsági módosítót használni. Ha egy régi osztályt lecserélünk gyakran megéri a nevét meghagyni, így a klienseknek elegend® csupán az import-ot átírni, ami jóval kevesebb problémával jár, mintha a felhasználónak kéne a programját nagymértékben megváltoztatni emiatt. Emellett sokszor el®forduló megoldás az is, amikor egy-egy funkció neve más lesz (mert az új verzióban kicsit másabb szerepet tölt be), de az argumentumok sorrendje változatlan marad. Így egy egyszer¶ cserével megoldhatók a frissítéssel bekerül® változtatások. Valamint arról sem szabad elfelejtkezni, hogy 1-1 módosítással mennyi felhasználót nyerhetünk vagy éppen veszíthetünk. A kompatibilitás meg®rzését úgy a legkönnyebb kivitelezni, ha a kliens a lehet® legkevesebbet látja, éppen annyit amennyit feltétlenül szükséges ahhoz, hogy használni tudja a keretrendszert. Optimális esetben ezek a részek, részletek a fejlesztés közben nem változnak, vagy csak nagyon minimálisan, ám ezt megjósolni nehéz. A kompatibilitásnak 2 fajtája van, az egyik az el®refelé, a másik a visszafelé való kompatibilitás. Mind a kett®t fenntartani azonban túlzottan költséges lenne, ezért a tervezés elején fontos leszögezni melyik lesz alkalmazva. A kompatibilitás meg®rzésér®l elmondható, hogy általánosan két megoldás kínálkozik. Az egyik a könyvtárosztály, melynek el®nye, hogy frissítéskor csak arra kell gyelni, hogy az eddig jól m¶köd® metódusok továbbra is ugyan úgy használhatók legyenek, hátránya viszonyt, hogy korlátozott lehet®ség van a b®vítésére. A másik szóba jöhet® koncepció az objektumok. Az objektumoknak háromféle használata lehet: példányosítás, konguráció, vagy implementáció. A példányosítás akkor el®nyös, ha a kliensnek csak az adatokra van szüksége. A konguráció már nagyobb rugalmasságot kínál, hiszen ilyenkor a felhasználó saját változóival, vagy objektumaival példányosítja a metódust, azonban a tervez®nek gyelnie kell arra, hogy így kevesebb szabadság áll rendelkezésre. Egy-egy objektum maximum kétféleképpen legyen példányosítható, különben nagyon bonyolulttá válna a rendszer. A harmadik az implementáció, mely a fejleszt®k szempontjából a legkevesebb mozgásteret engedi meg. Az absztakció megvalósítására is két lehet®ség kínálkozik: az interface és a szuperosztály. Az interface el®nye, hogy a kliens csak annyit lát, amennyit feltétlen szüksé10
2.3. A Fuzzy
ges neki, hátránya, hogy fejlesztés közben ha egy új metódus kerül a keretrendszerbe, minden implementáció hibás lesz. További jó tulajdonsága, hogy több interface is implementálható. A szuperosztály majdhogynem ellenkez® adottságokkal rendelkezik, mint az interface. Mikor új metódus kerül bele, azzal nem rontja el a felhasználó kódját, tehát a fejlesztés ilyen szempontból könnyebb, viszont egyszerre csak egy osztályát lehet kiterjeszteni. Fejlesztés közben csak a private metódusokat és adattagokat változtathatjuk meg, hogy a kompatibilitás megmaradjon. Jól át kell gondolni, melyek kapnak protected biztonsági besorolást, mert azt kés®bb már nem módosíthatjuk.
2.3. Megvalósítás módja Ahhoz hogy a keretrendszer minél szélesebb körben elterjedhessen, szem el®tt kell tartani a következ® pontokat:
• könnyen kezelhet® és b®víthet® legyen • több operációs rendszeren, esetleg több elterjedt programnyelven is elérhet® legyen • a keretrendszer programozásába befektetett munka kell®en hatékony legyen
2.3.1. Library A programnyelvek mindegyikének megvan a saját, betölthet® könyvtára, melyben az adott nyelv szintaktikájának megfelel® függvények, változók vannak letárolva, mely az azt felhasználó kód elejére másolódik fordítási id®ben. A DLL-el szemben hatalmas el®nye az, hogy program ami használja biztos lehet benne, hogy ez az a verziója a könyvtárnak, amire szüksége van, elkerülve így a függ®ségi hibákat (dependency problems). Ezt a gyakran el®forduló hibát szokták "DLL hell"-nek nevezni, de err®l majd kés®bb. Statikus könyvtárakat használni jelent®s teljesítmény növekedéssel járhat, valamint lehet®vé teszi hogy a programmal egybe legyen fordítva, és így alkossanak egy futtatható fájlt. Statikus könyvtárak esetén csak azok a részek tölt®dnek be, amik a program során meghívásra kerülnek direkt, vagy indirekt módon, mely szintén el®ny a DLL-el szemben, ahol az egész tartalom betöltésre kerül, anélkül, hogy tudná mely funkciója lesz használva. Ugyanakkor statikus könyvtár esetében a futtatható fájl nagyobb lesz, mivel bele épül a kódba, míg DLL esetén a funkciókat tartalmazó fájl máshol helyezkedik el, és úgy hivatkozik rá a program. Hátránya valamint, hogy nem teszi lehet®vé azt, hogy más programnyelvekbe is betölthet® legyen, és a benne található függvényeket használni lehessen. Nem beszélve a típusok különböz®ségér®l. Továbbá egyszerre csak egy program használhatja a belinkelt könyvtárat, tehát a megosztást nem támogatja.
2.3.2. DLL (Dinamic Link Library) Ahogy a neve is mutatja Dinamic Link Library, magyarul talán leggyakrabban megosztott könyvtáraknak szokás hívni, azt jelenti, hogy a DLL-ben tárolt adatokat és függvényeket több alkalmazás is képes használni egy adott id®ben. Vegyük például a 11
2.3. A Fuzzy
Windows-ban a USER32.dll, vagy KERNEL32.dll, ezek azok a DLL-ek, melyek szükségesek ahhoz, hogy a Win32 alrendszer m¶ködhessen. Ha egy függvényt egyszer megírtak és DLL-be rakták, akkor azt bármelyik alkalmazás tudja használni anélkül, hogy a program forráskódjában direkt módon szerepelne. Természetesen ugyan ez a helyzet a benne tárolt adatokkal is. El®nyei:
• Alacsony memória használat: Azok a függvények és adatok, amiket összeállítottunk egy DLL-be, elérhet®ek az összes program számára, melyek használják azt. A DLL csak akkor tölt®dik be a memóriába, amikor szükség van rá. A DLL belsejében lév® kódok csak olvashatók, íráshoz nem adnak felhatalmazást, így mikor memóriába tölt®dnek, a memória read-only területére kerülnek. A rendszernek így lehet®sége van le mapp-elni a DLL tartalmát a folyamat címtartományába. Ha több programnak is szüksége van rá, akkor azok is a memóriából le mapp-elik maguknak, létrehozva így a saját példányukat a címtartományukban. • Kevesebb ki-be töltés: Képzeljük el, hogy két alkalmazás egyszerre használja ugyan azt a DLL-t, az egyik végez és kilép. A DLL még bent marad a memóriában, mert gyeli, számolja, hogy épp hány alkalmazás használja. Amikor ez a számláló eléri a nullát, csak akkor törli magát. Gondoljunk bele egy másik helyzetbe, mikor egy program egy olyan DLL-t akar használni, ami már a memóriában van és más alkalmazás használja. A rendszer nem tölti be újra a DLL-t, csupán át map-eli az új alkalmazásnak, így az is tudja használni. Ez rengeteg id®t és munkát spórol az operációs rendszernek, mivel sokkal lassabban olvasná be az adatot a HDD-r®l, mint a memóriából. • "Csak a polcról kell levenni": Egy jól megtervezett DLL bármelyik másik programnak hasznos része lehet. Gondoljunk rá úgy, mint egy komponensre, aminek a m¶ködésében és funkcionalitásában teljesen biztosak vagyunk. Csak be kell hívni egy másik projektbe és már be is tölti a kívánt funkciót/funkciókat. Képzeljünk el egy olyan DLL implementációt, ami elvégzi az összes lehetséges számítást, melyre szükség van ahhoz, hogy grakus szoftvert fejlesszünk. Ha ez egyszer kész, bármelyik másik ilyen programba betehetjük, minden probléma nélkül. • Együttm¶ködés több programnyelvvel: Egy DLL amit egy nyelven megírtunk, használhatjuk olyan alkalmazásokban is, melyeket más nyelven írunk. Fejleszt®knél ez gyakori, hogy optimalizált rutinokat írnak assembly-ben, majd ezeket összegy¶jtik egy DLL-be, és kés®bb meghívják C-ben vagy Visual Basicben. A fejleszt®k szempontjából nem túl szerencsés, hogy elég sok nyelv támogatja a DLL használatát, viszont nagyon kevés az olyan, ami alkalmas az írásra is. Képzeljünk el egy alkalmazást, ami a DLL segítségével I/O m¶veleteket hajt végre Visual Basic-ben, használva az inportb és outportb függvényeket a CRT natív könyvtárból. A DLL-ek lehet®vé teszik az ilyen együttm¶köd® kódokat. • Könny¶ utólagos javítások: Mivel könnyen el®fordulhat, hogy egy termék eladása után derülnek ki a problémák, ezt kijavítani általában nagyon fáradtságos munka. Újra build-elni egy nagy alkalmazást majd újra kiküldeni a vásárlóknak sok id®t vesz igénybe. Mindez elkerülhet®, ha a projekt úgy van megtervezve, 12
2.3. A Fuzzy
hogy könnyen kezelhet®, különálló modulokból kapcsolódik össze, melyek DLL formájában tárolódnak. Csak annyit kell tenni, hogy a hibás részt kijavítani és a vásárlók számára elérhet®vé tenni, mint egy frissítést. Ugyanakkor ez az el®ny a DLL-ek legnagyobb hátránya is lehet. Minden attól függ, mennyire gondosan van megtervezve a kód. Hátrány:
• A DLL hell: Ez a legnagyobb probléma, amit a DLL-ek okozni tudnak. Amennyire lehet, el kell kerülni az olyan helyzeteket, amikor a fordító olyan hibát dob, hogy nem talál egy bizonyos részt a DLL-ben. Vagy egy másik esetben például telepítésre kerül egy új program, ezt követ®en az eddig fent lév®k pedig hibásan futnak le, vagy el sem indulnak. Ezek egyértelm¶en a "DLL hell"-nek nevezett problémának a jelei. Leggyakrabban akkor fordul el® ilyen, ha a szoftver telepít®je nem gyeli a verziószámban láv® eltéréseket, és vagy egy újabb DLL-t ír felül egy régebbivel, vagy pont ellenkez®leg, egy régit módosít az újra, amiben viszont nagy változások történtek. A DLL-eknek visszafelé kompatibiliseknek kéne lenniük, ez csakis a tervezésen múlik, ezt azonban nehéz elérni. Mit tartalmazhat egy DLL:
A DLL-ek általában kódokat, adatokat és forrásokat tartalmaznak. A kódok a readonly részen tárolódnak így könnyen használhatja egyszerre több alkalmazás is, de az adatokkal más a helyzet. Minden egyes alkalmazás, melynek szüksége van az adatokra, megkapja a saját privát másolatát, hacsak nem valaki megosztottnak jelöli meg azokat. A kód részben tárolódnak az osztályok, illetve a függvények. Lehetnek olyan osztályok, melyekben a függvények és az adatok egy helyen tárolódnak, egy egységet alkotnak, de az önálló függvények használhatnak globális változókat is. Az el®bb felsoroltak egy, vagy több forrás fájlba van eltárolva, de ezek össze vannak csomagolva egy DLL le-á. A DLL-ek másik DLL fájlból is importálhatnak függvényeket vagy osztályokat.
2.3.3. A kiválasztott stratégia A fent leírtak alapján jól látszik, hogy a DLL egy univerzális megoldás lenne a toolbox számára, ugyanakkor a statikus librarynak is vannak el®nyei és véleményem szerint keretrendszer elterjedéséhez vezet® úton els® lépésnek tökéletesen elegend® a LIB. A közeljöv®ben kilátás van egy francia kooperációra, mely ha sikeres lesz, minden bizonnyal elkészül majd a rendszerb®l egy DLL is, ezáltal kib®vítve a felhasználhatóság körét és a célközönséget.
13
2.4. A Fuzzy
2.4. FRI módszerek A Fuzzy logikával dolgozó rendszerek a szabályokon alapszanak. A szabálybázisnak két típusa létezik:
• s¶r¶ szabálybázis • ritka szabálybázis S¶r¶ szabálybázisról akkor beszélünk, ha az input tér teljesen le van fedve, tehát minden lehetséges meggyeléshez létezik legalább egy olyan szabály, melynek antecedens része átfedésben van vele és ez alapján érvényes konklúziót lehet generálni. Amennyiben a fent leírt eset nem teljesül, a szabálybázist ritkának tekintjük. Ritka szabálybázis esetén a klasszikus következtetési módszerek nem használhatóak. Ekkor az eredményt különböz® közelít® eljárással számítják ki a rendelkezésre álló információk alapján. Ezeket Fuzzy Szabály Interpolációs módszereknek hívják. S¶r¶ szabálybázisokat kezel® rendszerek már léteznek, de olyan, amely a ritka szabálybázisú eljárásokat összefogná és egy egységes keretrendszert alkotna, mely ingyenesen elérhet® mindenki számára, még jelen pillanatban nincs. Arról nem is beszélve, hogy a módszerek viszonylag nagy százaléka rosszul, vagy hiányosan dokumentált, esetleg nehezen fellelhet®, megnehezítve így a fejleszt®k dolgát. Ezért is fontos hogy össze legyenek gy¶jtve, így akik ritka fuzzy rendszerekkel szeretnének foglalkozni, a kutatás és programozás résszel ne kelljen foglalkozniuk. Ritka szabálybázis többféleképpen keletkezhet:
• Szakért®t®l vagy más forrásból származó ismeretek, tapasztalatok nem elegend®ek a teljes input terület lefedésére • Lehetséges, hogy a szabálybázis kezdetben s¶r¶nek számított, de a kés®bbi hangolás folyamán, az antecedens halmazok formája és pozíciója változhat, melynek következtében a halmazok között úgynevezett lyukak alakulhatnak ki (2.4 ábra). • A s¶r¶ szabálybázis a sok dimenziónak és az inputhalmazoknak köszönhet®en túl nagy, meghaladja a hardver tárolási kapacitását, ezért mesterségesen megritkítják. • Amennyiben az el®bb említett helyzet nem jelent problémát, tehát a tárolás megoldható, a számítási id® még mindig elérhet olyan szintet, ami után már kénytelenek megritkítani a szabálybázist.
2.4. ábra. Példa s¶r¶ és ritka szabálybázisra
14
2.4. A Fuzzy
A ritka szabálybázisú eljárások két csoportba sorolhatók. Az els® csoportba tartozó eljárások az eredményt közvetlenül állítják el® becslés segítségével, ezeket egylépéses módszereknek nevezzük. A másik csoport tagjai el®ször egy ideiglenes szabályt alkotnak a már meglév®k alapján, melynek antecedens része legalább részben fedi a meggyelést, majd ezt követ®en az új szabály és a meggyelés közti hasonlóság alapján számítják ki a becsült konklúziót. Az egylépéses módszerek legjelent®sebb tagjai: KH [1] (Kóczy és Hirota), MACI [2] (Tikk és Baranyai), FIVE [21] (Kovács és Kóczy), IMUL [4] (Wong, Gedeon, Tikk) és VKK [5] (Vass, Kalmár, Kóczy). Legismertebb kétlépéses eljárások: GM (Baranyi, Kóczy és Gedeon) [6], FRIPOC (Joahnyák és Kovács) [8], ST (Yan, Mizumoto és Qiao) [7], FIVE (Kovács és Kóczy) [21]. A felsorolt módszerek közül nem mind, jelenleg 6 implementált a keretrendszerben, de ez a szám változni fog, ahogy el®rehaladnak a fejlesztések. Ezek a következ®k: KH [1], VKK [5], CRF [13], MACI [2], FIVE [21], FRIPOC [8]. Amint látható 5 egylépéses és 1 kétlépéses módszer található eddig a keretrendszerben. Mivel az egylépéses módszerek leprogramozása kevesebb id®t vesz igénybe és esetenként egyszer¶bbek is, mint a kétlépésesek, ezért ebb®l került több implementálásra. A fuzzy interpolációs módszerek, melyek a keretrendszerbe kerülnek, gyelembe veszik az FRI technikákra vonatkozó általános szabályokat [11]:
• Érvénytelen eredmény elkerülése. • Legyen forma®rz®. Ez azt jelenti, hogy a megadott meggyelésnek és a kiszámított közelít® eredménynek az alakja hasonló kell, hogy legyen. • A köztes kapcsolatok meg®rzése. Amennyiben a meggyelés két antecedens között helyezkedik el, akkor a becsült eredménynek a szabálybázis szerinti két konzekvens közé kell esnie. • Szabálybázissal való kompatibilitás. Megköveteli a modus ponens elvének teljesülését. Ez azt jelenti, hogy ha egy meggyelés egybeesik egy antecedens-el, akkor a konklúziónak a szabálybázis szerinti konzekvensnek kell megfelelnie. • A becsült eredménynek meg kell tartania a fuzzy tulajdonságot. Két ellentétes megközelítése van ennek a témának az irodalomban. Az egyik szerint ha van egy singleton meggyelésünk, akkor abból a módszernek egy szintén singleton következtetést kell készítenie. A másik vélemény szerint a konzekvens fuzzy tulajdonságait kell gyelembe venni a szabályok alapján. Singleton-t csak akkor kaphatunk ha az összes konzekvens amit a szabályokban gyelembe vesznek az interpolációnál, mindegyik singleton. • Közelít® képesség (stabilitás). A becsült szabálynak a lehet® legjobban közelítenie kell a kapcsolatot két dimenzió antecedens-ei és konzekvensei között. • Szakaszonkénti linearitás megtartása. Ha a gyelembe vett fuzzy halmazok szakaszonként lineárisak, akkor a közelített halmazoknak is meg kell tartaniuk ezt a tulajdonságit. • Többdimenziós antecedens univerzumok használhatósága. Ez azt jelenti, hogy az FRI módszernek hasonló karakterisztikát kell mutatnia ha kiegészítik, és több dimenziós bementi tere lesz. 15
2.4. A Fuzzy
• A fuzzy halmaz alakjára vonatkozó bármilyen jelleg¶ megszorítás nélküli alkalmazás. Ezt a pontot nem feltétlen kell gyelembe venni, mert a gyakorlatban elég s¶r¶n találkozunk szakaszonként lineáris fuzzy halmaz és Gauss-görbe alakú halmaz találkozásával.
16
3. fejezet 3 A keretrendszer
A keretrendszerrel szemben támasztott 3 f® követelmény:
• Kell®en gyors legyen ahhoz, hogy valós id®ben tudjon reagálni, így éles helyzetekben is tökéletesen m¶ködjön • Széles kör¶ használhatóság is fontos szempont. Azt szeretném elérni, hogy minél több projektben alkalmazható legyen, így segítve a keretrendszer elterjedését. Ehhez pedig az kell, hogy minél több programozási nyelvbe beágyazható legyen. A közeljöv®ben a Java, C#, és a MATLAB, illetve a Freemat matematika szoftverek támogatása a cél. • Univerzális kezel®felület kialakítása. Mivel több módszert is tartalmaz a keretrendszer, biztosítani kell a menet közbeni változtatás lehet®ségét, mindezt úgy, hogy küls®leg ne legyen különbség az eljárások közt, kényelmessé téve felhasználó számára a használatot. Ahhoz hogy a fenti kritériumoknak megfeleljen a keretrendszer, többféleképpen is elérhet®vé kell tenni: el®ször is egy programozói könyvtár formájában, mely C++-ban használható, valamint tervbe van véve egy úgynevezett wrapper osztály is a népszer¶bb programnyelvekhez (Java, Python, C#). Az FRI módszerek használatának egységesítése úgy lett megoldva, hogy bármelyik metódust ugyan azzal az interface-el lehet kezelni. Az osztály hierarchia és az objektumorientált minták biztosítják ezt. A toolbox f® célja, hogy egyszer¶sítse a programozók dolgát azzal, hogy szabványosított függvénykönyvtárat ad a kezükbe. Az el®z® fejezetben felsorolt 9 pontból, melyet Baranyai és szerz®társai határoztak meg, csak az egyes feltétel teljesíthet®, mert több olyan módszer is van, mely a maradék 8at csak részben, vagy egyáltalán nem tudja kielégíteni. Ha a program futása közben abnormális m¶ködés következik be, akkor ez egy kivételt vált ki (err®l kés®bb). Minden hibára különböz® hibakódot és kivétet generál a porgram a könnyebb, egyértelm¶bb hibakezelés végett. A keretrendszer f® koncepcióiról, valamint megvalósítási módjáról a [18]-cikkben is olvasni lehet.
3.1. A keretrendszer szerkezete A toolbox alapja C++ban íródott, mivel ez egy gyors objektum orientált nyelv és széles körben elterjedt. Sok osztály már el®redeniált, de az objektum orientáltságnak 17
köszönhet®en ezek felülírhatók, vagy származtathatóak bel®lük új osztályok. Csak a felhasználón múlik az, hogyan alakítja ezek után a kódot. A keretrendszer támogatja az eljárások mindkét típusát, az egylépéseseket és a kétlépéseseket egyaránt. A kompatibilitás érdekében ugyanúgy, mint a MATLAB-os FRI Toolbox, a FIS fájlt használja adatok bevitelére. A FIS fájl tartalmazza a felhasználó ritka szabálybázisát, mely alapján a választott módszer meghatározza az eredményt. Valós körülmények között általánosságban az mondható el, hogy a szabálybázis nem szokott változni, csak a meggyelés. Így tehát a jobb teljesítmény érdekében a meggyelés nem feltétlen egy OBS fájlból származik, hanem egy függvény paramétereként is átadódhat a programnak. Általában az összes Fuzzy interpolációs módszernek lehetnek további input adatai, melyet felhasználhatnak a fejleszt®k a kód írása során, ilyenek például az alfa szintek. A paraméterek típusa és száma a kiválasztott módszert®l függ, tehát egy paraméter lehet akár egy speciális karakter lánc is. A CFRIMethod osztály a közvetlen, vagy közvetett szül®je az összes FRI metódusnak. Ez az osztály deniálja a közös interface-t az FRI módszereknek, így biztosítva a különböz® módszerek egységes felületét. A felhasználó szemszögéb®l nézve négy egyszer¶ lépést kell végrehajtania, hogy használni tudja bármelyik FRI módszert: 1. Rendszer létrehozása. Els® lépésben a fuzzy rendszert kell el®állítani FIS fájl használatával, vagy karakter lánccal. Ez a rendszer lehet ritka szabálybázisú is. 2. FRI módszer kiválasztása az el®z® lépésben létrejött rendszerhez. Ennél adja meg a felhasználó, hogy melyik módszert szeretné használni. A háttérben a kiválasztott metódus neve alapján létrejön a megfelel® objektum. Fontos megjegyezni, hogy ezt a lépést futás közben többször is végre lehet hajtani. 3. FRI metódus inicializálása, ahol speciális paraméterek is megadhatók. A módszerek különböznek egymástól, így vannak olyanok amelyeknek további adatokra van szükségük. Ezek a paraméterek fontos szerepet játszhatnak a végeredmény kiszámításában. Az init metódus futás közben is képes adatokat fogadni a felhasználótól, melyeket a kiválasztott módszer a számítások során felhasznál. 4. A konklúzió meghatározása, amire akkor kerül sor, ha meghívódik az interpolate metódus. Ez a f® lépése az FRI módszereknek, melynek során a meggyelésb®l és az input szabálybázisból kiszámítódik a becsült eredmény. Amennyiben valós id®ben futó alkalmazásról van szó, ez a lépés többször is meghívódik.
3.1. ábra. Egylépéses módszerek struktúrája 18
Az egylépéses módszerek esetében, amit a 3.1-es kép illusztrál, az FRI metódus osztályát a CFIMethod osztályból kell származtatni. Ez az osztály deklarál egy virtuális metódust, melyet implementálni és felüldeniálni kell. Ez a metódus számolja ki a becsült eredményt a kapott meggyelés és a fuzzy rendszer felhasználásával. A meggyelések egy Membership function (tagsági függvények) nev¶ vektorban vannak eltárolva, mint paraméterek, és innen lehet hivatkozni rájuk. A keretrendszer jelenleg az alábbi egylépéses módszereket tartalmazza: KH [1] (CKH osztály) VKK [5] (CVKK osztály), MACI [2] (CMACI osztály), FIVE (CFIVE) [21], és CRF [13] (CCRF osztály). Ha új egylépéses módszert szeretnénk létrehozni, akkor annak a CFRIMethod osztályból kell származnia és az interpolate metódusát felül kell deniálni.
3.2. ábra. Kétlépéses módszerek struktúrája A másik csoport tagjait kétlépéses módszereknek hívjuk, és ahogy a 3.2-es ábrán látható az FRI metódus(ok) a CGeneralizedMethod osztályból származnak, majd pedig felül kell deniálni a következ® 3 osztályt: determineAntecedentShapes, determineConsequentPositions és a determineConsequentShapes osztályokat. Ezek a CGeneralizedMethod osztályból hívódnak meg szigorúan ragaszkodva az el®bb látott sorrendhez. Itt a meggyeléseket paraméterként kapják meg, ami a Membership Function vektorban vannak karakter láncként tárolva. A keretrendszer jelenlegi állapotában egy kétlépéses módszert tartalmaz ez pedig a FRIPOC [8] (CFRIPOC osztály). Tehát amennyiben a programozó egy új kétlépéses módszert szeretne implementálni, annak a következ®képpen kell történnie: 1. Származtatja a metódusát a CGeneralizedMethod osztályból 2. Felüldeniálja a következ® osztályokat: determineAntecedentShapes, determineConsequentPositions és determineConsequentShapes.
3.2. A keretrendszer osztályai Ebben a fejezetben a toolbox-ot felépít® osztályokról lesz szó. Nem mind kerül bemutatásra, lesznek olyanok, amik részletezésre kerülnek, másokat pedig csupán felszínesen 19
érint ez a rész. A keretrendszerben a FIS le (melyben találhatók az input "A", az output "B", valamint a szabályok) beolvasását és írását a CFISle osztály végzi. Ez tartalmaz 2 readFIS() és 2 writeFIS() függvényt, eltér® argumentum listával. Az írás és az olvasás is megtehet® két módon, le átadásával, illetve stringstream használatával. A meggyelés kezelésér®l a COBSFile osztály gondoskodik. Mivel itt írni nem, csak olvasni kell az adatot, 2db readOBS() függvény található benne, a már imént említett kétféle argumentumlistával (le, illetve stringstream). A FIS le-ból kiolvasott szabályoknak külön osztályuk van, melyben letárolásra kerül maga a szabály, mint string, valamint az input és output mérete a könnyebb kezelhet®ség érdekében. Lekérhet® továbbá a súlyozás és a szabályok kapcsolatai (1 illetve 0, mely a logikai AND-nek és OR-nak felel meg). A fuzzy halmazok pontjait a CPoint osztály kezeli. X és Y koordinátákat tárol és ezekr®l kérhet®k le információk. A pontból, vagy pontokból álló halmaz neve a tagsági függvény (MF), ennek is külön osztálya van CMembershipFunction néven. A függvények lehet®vé teszik, hogy lekérdezzük a halmaz X illetve Y koordinátáit egy vektorba, valamint a halmaz alakját és nevét is. Egy dimenzióban lev® tagsági függvények alkotnak egy-egy úgynevezett partíciót, ennek megfelel®en a következ® osztály a CPartition. Ebben rögzítésre kerülnek az MF-ek, az intervallum amin találhatók, valamint a nevei. Az eddig felsorolt osztályokból áll össze a CSystem osztály. A továbbiakban három, a keretrendszert alkotó osztály kerül részletezésre.
3.2.1. A kivételosztály A kivétel nem más, mint egy, a program futását megszakító hiba mely lehet a véletlen m¶ve (melyet try-catch felépítéssel lehet "elkapni"), de ki lehet váltani szándékosan is (throw parancs használatával). A keretrendszer egyik érdekes feature-je, hogy külön kivétel osztállyal rendelkezik. Ez a megoldás segíti mind a programozót a kód tesztelésénél, debuggolásnál, illetve a felhasználót a programja futtatása közben. Teszi mindezt úgy, hogy mikor kiváltódik a kivétel, akkor sokkal pontosabb információt szolgáltat a hibáról, mint amit tenne egy általános exception. Mint minden osztálynak, így ennek is van konstruktora, méghozzá kett® melyeket a 3.1-es kód szemléltet. Ahogy az 1. sorban látható az els® konstruktor argumentumként fogad egy egész számot, ami a hibát kiváltó sort tárolja, valamint egy le nevet. Ilyenkor a rendellenesség forrása ismeretlen. A különlegessége, hogy ez meghívja az osztály másik konstruktorát egy UNKNOWN_ERROR (a headerben) el®re deniált értékkel. Ez látható a 2. sorban. A másik konstruktor annyiban tér el az el®z®t®l, hogy a paraméterként átadott hibakód alapján állítja be a változókat. A 6. sorban a hiba kódot, a 7-ben a hibás sor számát, a 8. sorban pedig a kivételt dobó le neve kerül inicializálásra. Íme a két konstruktort tartalmazó kódrészlet: 1
CFRIException : : CFRIException ( c o n s t
2 3
int
line ,
C F R I E x c e p t i o n ( C F R I E x c e p t i o n : : UNKNOWN_ERROR,
const line ,
char
∗
f i l e ){
file ) ;
};
4 5
CFRIException : : CFRIException ( i n t
error_code ,
const
int
line ,
const
char
∗
f i l e ){
6
m_error_code
7
m_line
=
line ;
8
m_file
=
file ;
=
error_code ;
20
9
};
Code 3.1. Kivételosztály konstruktorai Az adattagok (m_error_code, m_line m_le ) a header-ben kerültek deklarálásra, valamint itt vannak deniálva a hibakódok is. A hibakód pozitív egész szám (jelenleg maximum 4 tizedes jegy¶), mely úgy épül fel, hogy az ezres és százas helyi értéken lév® szám egy b®vebb probléma kört határoz meg (pl: melyik metódus rendellenes m¶ködéséb®l származik a probléma, 1xx: FIS le hiba, 11xx FIVE hiba), a tizedes és egyes helyi értéken lév® pedig a pontosabb megfogalmazást rejti (01-el kezd®dik a szám). Így tehát egy adott hiba csoportnak maximum 99 kivétel deníciója lehet. 1
int
2 3
CFRIException : : g e t E r r o r C o d e ( ) {
return
m_error_code ;
};
4 5
const
6 7
int
return
CFRIException : : getLineNumber ( ) { m_line ;
}
8 9
const
10 11
char
return
∗
CFRIException : : g e t F i l e N a m e ( ) {
m_file ;
}
Code 3.2. A kivételosztály 3 egyszer¶ getter függvénye Magában az osztályban 3 egyszer¶ getter függvény található (3.2 kódrészlet): getErrorCode() 1-3. sor, getLineNumber() 5-7. sor, getFileName() 9-11. sor. Ezek arra szolgálnak, hogy visszaadják a hibakódot, a sor számát ahol bekövetkezett a kivétel, valamint a le nevét amin belül rendellenesség keletkezett. Továbbá az osztály tartalmaz egy olyan metódust, melynek neve GetMessage() és visszatér a le nevével, a hiba szöveges üzenetével és a sor számával. A 3.3 kódrészlet szolgál például a fentebb leírtakhoz. 1
string
CFRIException : : g e t M e s s a g e ( ) {
2
stringstream
3
s w i t c h ( m_error_code ) {
4
case
5
case
6
case
−101: −102:
message ;
m e s s a g e <<
" FIS :
File
m e s s a g e <<
" FIS :
Convert
not
m e s s a g e <<
" FIS :
File
found to
or
invalid ! " ;
Integer
is
not
break ;
possible ! " ;
break ;
−103:
forced
mode
if
you
would
like
already to
able
exist ! to
Please
write
turn
it .";
case
−104:
m e s s a g e <<
" FIS :
case
−201:
m e s s a g e <<
" Input :
11
case
" Rule :
Input
MF
index
is
too
high " ;
case
−401: −402:
m e s s a g e <<
12
m e s s a g e <<
" Rule :
Input
MF
index
is
too
low " ;
7
Can
not
open
and
y
file ";
on
the
break ;
break ;
8 9
x
dimension
not
match ! " ;
break ;
10 break ; break ;
Code 3.3. A kivételek sorszámai Érdemes meggyelni, hogy egy message változó került deniálásra, mely stringstream típusú (2. sor) és ez lesz a függvény visszatérési értéke minden esetben. Amint látható egy sima switch case elágazás oldja meg a hibakódok visszafejtését szöveges üzenetre (3. sortól). Ezután következnek a hibakódok, szépen tagolva. A 3.4 kódrészlet a kivételek sorszámának végét tartalmazza. Amennyiben olyan rendellenesség keletkezne a kód futása közben, amire nem volt felkészülve a rendszer, akkor 21
alapértelmezett értékként úgynevezett Unhandled exception-t állít be üzenetként (lekezeletlen hiba), ez látható a 4. sorban. A switch elágazás a 3.4 kódrészlet 5. sorában ér véget, ezután kerül hozzáf¶zésre a visszatérési értékhez a le neve, valamint a hibás sor száma (6. sor). Végül a függvény a 8. sorban visszatér a message-el. 1
−1201:
case
m e s s a g e <<
antecedent " ;
2
−1202:
case
m e s s a g e <<
antecedent " ;
"VKK:
The
observation
hasn ' t
any
left
"VKK:
The
observation
hasn ' t
any
right
break ;
break ;
3 4
default :
5
}
6
m e s s a g e <<
m e s s a g e <<
" Unhandled
"
" <<
in
FILE :
exception ! " ;
m _ f i l e <<
"
at
LINE :
" <<
m_line ;
7 8 9
return
message . s t r ( ) ;
}
Code 3.4. A kivételek sorszámai és a függvény visszatérése
3.2.2. Az egylépéses FRI módszerek ®sosztálya Annak érdekében hogy a módszerek egységesek legyenek, létre kellett hozni egy ®sosztályt, melyb®l származtatható mindegyik: közvetve, vagy közvetlenül. Ez az osztály a CFRIMethod. Tárol minden fontos információt ahhoz, hogy számolni tudjon az interpolációs módszer, mindezt úgy teszi, hogy a konstruktorába argumentumként kér egy CSystem típusú objektumot, valamint segédfüggvényeket is magába foglal. Az egyik ilyen az init metódus, mely az argumentumként megkapott string-et szétdarabolva paramétereket ad át a módszereknek, map-ben (m_methodParams, mely a headerben lett deniálva). A módszerek egy része referencia pont alapú számításokat végez, ennek megfelel®en, az osztályban deklarálásra került a getReferencePoint() függvény, melyet a 3.5 kódrészlet mutat be. 1
CPoint
CFRIMethod : : g e t R e f e r e n c e P o i n t ( C M e m b e r s h i p F u n c t i o n
mf ,
string
RPType ) {
2
i f ( mf . g e t P o i n t s ( ) . empty ( ) ) {
3
throw
C F R I E x c e p t i o n ( C F R I E x c e p t i o n : : FRIM_NO_POINTS,
__LINE__,
__FILE__
) ;
4
}
5 6
string
mftype
7
double
RPx ,
= mf . g e t T y p e ( ) ;
RPy ;
8 9 10
i f ( RPType == " c o r e c e n t r e " ) { i f ( mftype
11
== " s i n g l m f " ) {
RPx = mf . g e t P o i n t s ( ) [ 0 ] . g e t X ( ) ;
12
RPy = mf . g e t P o i n t s ( ) [ 0 ] . g e t Y ( ) ;
13
}
14
else
i f ( mftype
== " t r i m f " ) {
15
RPx = mf . g e t P o i n t s ( ) [ 1 ] . g e t X ( ) ;
16
RPy = mf . g e t P o i n t s ( ) [ 1 ] . g e t Y ( ) ;
Code 3.5. Az CFRIMethod osztály Referencia pont lekérésére alkalmas függvénye Amint látható, bekér egy MF halmazt, valamint a referencia típusát (1. sor), és ez alapján adja meg a referenciapont X és Y koordinátáit. Valamint azt is érdemes 22
meggyelni a függvény elején, a 2-4. sorban, hogy használja a kivételosztályt, amit az el®z® pontban részleteztem. A 6. sorban egy változóban letárolásra kerül a megadott halmaz típusa, a 7. sor pedig deklarálja a referencia pont X és Y koordinátáit. Ezután a 9. sorban egy elágazás dönt a referencia pont típusának ismeretében, hogy merre haladjon tovább az irányítás. A ref.pont számításnak 3 változatát kezeli, ezek sorban:
• corecentre • corecentreprojection • supportcentre Minden referenciapont alapú elágazáson belül van még egy IF, mely a halmaz típusa alapján ágazik el, mivel ezt gyelembe véve máshogy kell kiszámítani az X és Y koordinátákat. Ezek lehetnek:
• singlmf 10. sor (egyérték¶ halmaz)1 • trimf 14. sor (háromszög alakú halmaz) • trapmf (trapéz alakú halmaz) • polymf (poligon alakú halmaz) A függvény visszatérési értéke természetesen szintén egy saját osztály objektuma, a CPoint. Mivel a keretrendszer alapja a MATLAB-os FRIToolbox, az eljárások is az alapján lettek átírva. Ennek megfelel®en szükségszer¶ volt néhány MATLAB-os eljárást lekódolni C++-ba, hogy könnyebb legyen a módszerek leprogramozása. Az egyik ilyen a Find() függvény, melynek 4 példánya is megtalálható. A függvény bekér egy vektort, egy operátort (=, <, >, <=, >=), valamint egy számot ami a viszonyítási alap lesz és visszaadja azon számok halmazát (vektorban), melyek kielégítik a feltételt. A további hármat nem részletezném, megegyezik a m¶ködése a MATLAB-ossal. Az utolsó bemutatásra kerül® függvény a CFRIMethod osztályból, az interpolate, melyet minden metódusnak felül kell deinálnia és majd ez fogja elvégezni a számításokat. A 3.6 kódrészlet mutatja a megvalósítását. Az 1. sorban argumentumként megkapja a meggyelést, azonban ha nem deniálják felül, akkor a 2. sorban dob egy "metódus nincs implementálva" hibát, hiszen ebben az esetben a módszer nem is lehet megírva. 1
v e c t o r
CFRIMethod : : i n t e r p o l a t e ( C O b s e r v a t i o n observation )
2 3
throw
" method
{ not
implemented ! " ;
}
Code 3.6. CFRIMethod Interpolate függvénye Amit még érdemes megemlíteni, hogy a keretrendszer fejlesztése közben integrálásra került egy C++-os matematikai függvénytár, az Armadillo [25]. Ez a könyvtár speciálisan mátrixok és vektorok kezelését segíti el® és talán ez áll a legközelebb a MATLAB-os függvények egy részéhez. Az utoljára implementált FIVE módszer már kihasználja ennek az el®nyeit. 23
Amint látszik az osztálydiagramon ( 3.3 ábra ) a függvények elég nagy része használja az armadillo-t. Erre els®sorban a FIVE miatt volt szükség, de amennyiben a többi módszer is átírásra kerül majd, hasznos lehet azok számára is.
3.3. ábra. FRImethod osztálydiagramja
3.2.3. A kétlépéses FRI módszerek ®sosztálya Az egylépéses módszerek közvetlenül származnak a CFRIMethod osztályból (ezekr®l volt szó eddig), a kétlépéses módszerek viszont közvetve származnak csupán bel®le, mert beiktatásra került a CGeneralizedMethod (másnéven GM) osztály is. Erre azért volt szükség, mert a kétlépéses módszerek az interpolálás el®tt új szabályt hoznak létre, majd 3 fontos feladatot kell, hogy elvégezzenek. Ezek a számítások sorban a következ®k: az új szabály antecedens fuzzy halmazainak alakjának meghatározása, a konzekvens halmazok referencia pontjának kiszámítása, utolsó lépcs®ben pedig a konzekvens halmaz alakját határozza meg. Amennyiben ezzel a 3 feladattal végzett,a m¶ködésük már nem tér el a fentebb bemutatottól. Ezért került tehát a GM.cpp-be az alábbi 3 függvény: determineAntecedentShapes(), determineConsequentPositions és a determineConsequentShapes. A GM.cpp az el®bbi 3 virtuális függvényt (leszármaztatáskor ezeket mindenképp felül kell deniálni), valamint az interpolate metódust tartalmazza, tehát úgymond mintaként szolgál a módszerek megírásához. Az 3.7 programkód a GM.cpp teljes kódja. 1
#i n c l u d e
"GM. h "
24
2 3
∗
GM: :GM( CSystem
4
pSys )
:
CFRIMethod ( p S y s )
{
5
m_type =
6
"GM" ;
}
7 8
GM: : ~GM( v o i d )
9
{
10
}
11 12
v e c t o r GM: : i n t e r p o l a t e ( C O b s e r v a t i o n
13
observation )
{
14
determineAntecedentShapes ( observation ) ;
15
determineConsequentPositions ( observation ) ;
16
return
17
determineConsequentShapes ( o b s e r v a t i o n ) ;
}
Code 3.7. GM program kódja Amint látható az 1. sorban meghívásra kerül a GM header-je, a 3-6. sorban található a konstruktor, a 8-10. sor pedig a destruktort tartalmazza. A 12-17- sorban mind a 3 függvénynek a meggyelést kell csupán átadni. A 14. sorban lév® eljárás az antecedens oldali fuzzy halmazok alakját hivatott megállapítani, a 15. sorban a konzekvens pozícióját kiszámoló függvény van, valamint a 16. sorban az utolsó lépés, a konzekvens alakját meghatározó függvény kapott helyet, mellyel vissza is tér a GM A m¶ködés megértéséhez a 3.8-as kódrészlet a GM header-jét tartalmazza: 1
#i f n d e f
__CGM_H
2
#d e f i n e
__CGM_H
3 4
#i n c l u d e
" FRIMethod . h "
5 6
class
7
GM
public
: CFRIMethod
8
{
9
protected :
10
// /
Az
interpolált
szabály
antecedens
halmazai
alakjának
a
meghatározása
11
virtual
12
// /
13
virtual
A
void
determineAntecedentShapes ( CObservation
konzekvens
halmazok
helyzetének
( referencia
observation )
=
0;
pontjainak )
meghatározása void
d e t e r m i n e C o n s e q u e n t P o s i t i o n s ( CObservation
observation )
=
0;
14
// /
15
virtual
Az
interpolált
szabály
konzekvens
v e c t o r
CObservation
observation )
=
halmazai
alakjának
meghatározása
determineConsequentShapes (
0;
16 17
public :
18
GM( CSystem
19
~GM( v o i d ) ;
∗
pSys ) ;
20 21 22
v e c t o r GM: : i n t e r p o l a t e ( C O b s e r v a t i o n
observation ) ;
};
23 24
#e n d i f
Code 3.8. A GM header-je
25
A kommentelés olvashatóvá teszi a kódot. A 4. sorban az FRIMethod.h behívásra kerül, melyre azért van szükség, mert 6-7. sorban ebb®l származik maga a GM is. A 11. 13. és 15. sorban érdemes meggyelni, hogy a függvények "virtual" módosítót kaptak, ezzel jelezve a fejleszt®k felé, hogy ezeket feltétlenül felül kell deniálni. A 18. és 19. sorban a konstruktor, illetve a destruktor látható, lehet®vé téve így a memóriagazdálkodásból adódó problémák megel®zését.
3.3. A keretrendszer használata A keretrendszer jelenleg a statikus könyvtárnak köszönhet®en C++ alól érhet® el. Ebben a részben két fejleszt®környezetben való használat kerül bemutatásra, az egyik a csak Windows alatt elérhet® Visual Studio, míg a másik a Linux alatt is alkalmazható Eclipse. Amennyiben a keretrendszer sikeres lesz, a közeljöv®ben támogatást fognak élvezni más nyelvek is, például a java, MATLAB és a FreeMat is [12].
3.3.1. LIB használata Visual Studio 2010-ben A következ® pár pontban szeretném bemutatni hogyan lehet m¶ködésre bírni a toolbox könyvtárát Visual Studio 2010 alatt, kezdve egészen az elejér®l, a projekt létrehozásával, a végét pedig az eredmény kiíratásával zárnám. A lépéseket képekkel illusztrálom a könnyebb megértés érdekében. 1. Mindenek el®tt létre kell hozni egy C++ Win32 alkalmazás projektet a Visual Studioban. Elérési útja: File → New → Project . . . (ugyanez elérhet® a Ctrl + Shift + N billenty¶ kombinációval). A projekt megkonstruálása közben gyelni kell arra, hogy az Application Type Console application legyen, az Additional options-ben a Precompiled header bekapcsolva maradhat, ez gyorsítja majd a program futását. További header-ökre (AFC, MFC) nincs szükség. A m¶velet a 3.4 ábrán látható.
26
3.4. ábra. C++ Projekt létrehozása 2. Nagyon fontos, hogy a project conguration-t Debug-ról át kell állítani Releasere. Ezután a projekt beállítás ablakot kell el®hozni, mely úgy érhet® el, hogy jobb-gombot nyomunk a frissen létrehozott projektre és a legalsó, Properties opciót választjuk. A Code Generation fület kell megkeresni, mely a Conguration Properties → C/C++ → Code Generation úton érhet® el. Ezen belül át kell állítani a Runtime Library beállítását Multi-Threaded DLL (/MD)-r®l MultiThreaded (/MT)-re. Magyarázat a 3.5 ábrán látható.
3.5. ábra. Runtime Library beállítása 3. Ugyan abban az ablakban ahol a 2-es lépés végrehajtásra került, át kell navigálni a Linker-re, melyet a Conguration Properties → Linker → Input útvonalon lehet elérni (3.6 ábra ). Ezen is belül az Additional Dependencies-hez kell hozzáadni a library elérhet®ségét. Amennyiben a FRIT lib a projekt mellett van, 27
akkor a hozzáadandó szöveg a következ®: fritoolbox/fritoolbox.lib. Természetesen amennyiben máshol lett elhelyezve a library, akkor azt az útvonalat kell odaírni.
3.6. ábra. Library hozzáadása 4. Negyedik és egyben utolsó lépés nem más, mint egy teljesen egyszer¶ példa porogram írása mely használja a toolbox egy metódusát. El®sször a kód elején include-olni kell a library-t melyet az alábbi kód segítségével lehet megtenni: 1
#i n c l u d e
" f r i t o o l b o x \ f r i t o o l b o x . h"
Code 3.9. FRIToolbox behívása Ezzel elérhet®vé válik az összes eljárás valamint minden függvény, amit a toolbox tartalmaz. A program main részében, a metódus választás el®tt els®ként be kell olvasni egy .FIS illetve egy .OBS le-t. A FIS le-ban van a leírása az inputnak (A halmazok), az outputnak (B halmazok), valamint a szabályok is itt találhatók. Az OBS-ban a meggyelés (A*) található. Ezek beolvasására szolgáló kód alább olvasható: ∗ pSys
1
CSystem
2
CObservation
= obs
CFISFile : : readFIS (
" example . f i s "
= COBSFile : : readOBS (
) ;
" example . obs "
) ;
Code 3.10. FIS le és OBS le beolvasása Ez a kód elvégzi a beolvasást az example.s, illetve az example.obs le-okból, ugyanakkor fontos megemlíteni, hogy mind a readFIS() mind pedig a readOBS() képes stringstream kezelésére is. Ezek után, hogy sikerült letárolni a fuzzy rendszert, valamint a meggyelést, a következ® lépés az FRI metódus kiválasztása. Ehhez létre kell hozni egy FRIToolbox objektumot, aminek az els® argumentuma a módszer neve (stringként megadva, gyelni kell az idéz®jelekre), a második pedig az imént beolvasásra került pSys fuzzy rendszer. 28
1
FRIToolbox
frit
=
F R I T o o l b o x ( "FIVE" , p S y s ) ;
Code 3.11. FRI módszer kiválasztása A következ® lépés a módszer interpolate függvényének meghívása a meggyeléssel ,mint argumentummal. Ez a kialakítás lehet®vé teszi, hogy az interpolate metódust szükség esetén mindig más observation-el hívjuk meg, anélkül, hogy a fuzzy rendszert újra be kellene tölteni. 1
v e c t o r
mfs
=
f r i t . i n t e r p o l a t e ( obs ) ;
Code 3.12. Interpoláció meghívása Amint látható a visszatérési érték egy vektor lesz, ami CMembershipFunctionb®l áll és minden dimenzióban tartalmazza a kiszámított értékeket. Az eredmény megjelenítésére a legegyszer¶bb módszer az mfs objektum toString() metódusának meghívása. Az utolsó képen (3.7 ábra) látható a mintaprogram maga, valamint egy futási eredmény.
3.7. ábra. Mintaprogram futási eredménye Összefoglalva tehát a keretrendszer használatát:
• include-olni kell a toolbox header le-ját • a program main részében a FIS és az OBS le-t be kell olvasni • ki kell választani a használni kívánt FRI módszert • meghívni annak interpolate metódusát Már ez a néhány szimpla lépés is lehet®vé teszi a toolbox használatát. 29
3.3.2. LIB használata Ubuntu alatt Eclipse-ben Az el®z® blokkban egy egyszer¶ példa került bemutatásra, hogyan is lehet alkalmazni a toolbox-ot Windows alatt Visual Studio-t használva. A koncepció egyik fontos pontja, hogy ne csak egy operációs rendszer alatt legyen elérhet® a keretrendszer, ezért ez a rész a Linux alatti m¶ködésr®l ad egy rövid áttekintést. Mivel a példaprogram kódja szerepelt már fentebb, az itt felsorolásra kerül® pontokban nem lesz róla szó, hiszen mindkét OS-en ugyanúgy m¶ködik. 1. Els® lépésként az Eclipse-ben létre kell hozni egy üres C++ projektet. Ez a File → New → C/C++ úton érhet® el (3.8 ábra). A megjelen® ablakban az Executable/Empty project opciót kell választani, a többi beállítási lehet®ség nem lényeges, maradhat alapértelmezetten.
3.8. ábra. Üres C++ projekt létrehozása 2. Miután elkészült az üres projekt, a következ® lépés a header hozzáadása. A Project Explorer-ben jobb-gomb a most készített projektre, majd a Properties opciót kell választani, melynek hatására megjelenik egy ablak a beállítási lehet®ségekkel. Az ablakon belül a C/C++ Build → Settings-en belül a Cross G++ compiler → Includes opciót kell választani (3.9 ábra). Az Include path(-l)-nál az Add gombot megnyomva lehet beírni a toolbox header-jének elérési útját.
3.9. ábra. Include path beállítása 30
3. Ezek után már csak a static library (fritoolbox.a) útvonalát kell megadni. Ezt ugyanazon a panelen lehet megtenni, mint az el®z® lépést. A különbség annyi, hogy a Cross G++ Linker/Libraries opcióhoz kell navigálni (3.10 ábra). Akár csak az imént, a hozzáadás itt is hasonlóan m¶ködik. A megjelen® kis ablakba a toolbox nevét kell írni kiterjesztés (.a, .lib) nélkül, csak ezt: FRIToolbox. Ezen 3 lépés elvégzésével a fejleszt®i környezet már készen áll arra, hogy használja a keretrendszer minden metódusát és a függvényeit.
3.10. ábra. Static Library hozzáadása
3.4. A keretrendszer kib®vítése Ahogy szinte minden keretrendszer, úgy a szakdolgozatom által bemutatott is egy folyamatosan változó, fejl®d®, nem pedig statikus program. Ennek megfelel®en ebben a szakaszban szeretném leírni hogyan lehet az FRI Toolboxhoz hozzáadni új metódusokat, így elérve azt, hogy a felhasználó, ha szükség van rá implementálja a saját, vagy akár más által már leprogramozott interpolációs módszert. A következ® pár pontban tehát arról lesz szó, hogyan lehet új FRI módszert hozzáadni a lehet® legkönnyebben a toolboxhoz. Az 3.13 kód szemlélteti a kib®víési eljárás menetét. 1-2. sorban beágyazásra kerül a FRIMethod valamint az FRIException header le-ja. A 4. sorban létrehozásra kerül a programozó saját osztálya, melyet a CFRIMethod osztályból kell leszármaztatnia. Az 5. és 6. sor deklarál egy stringet, ami az új eljárás nevét fogja majd tárolni, valamint egy integer változót, ami az Alfa vágatok számát tartalmazza. Ennek a függvénynek kell kiszámolnia az interpolációt. A példa kedvéért egy háromszög alakú fuzzy halmazzal fog visszatérni a függvény. Az osztály konstruktorában (9-13. sor) inicializálásra kell hogy kerüljenek a kezdeti értékek, jelen esetben ez az eljárás neve, ami a resoultname változóban tárolódik. Amennyiben ez nem történik meg, javasolt egy init metódus (15-21. sor) írása amely betölti ezt a feladatot. Ennek void típusúnak kell lennie, valamint egy string változójú argumentumot szükséges fogadnia. Ez a metódus fogja beállítani az interpoláció paramétereit. A megírt osztálynak mindenképp magába kell foglalnia egy Interpolate metódust,ami argumentumaként CObservation típust fogad el, valamint a visszatérési értéke egy vector (23-31. sor).
31
1
#i n c l u d e
" FRIMethod . h "
2
#i n c l u d e
" FRIException . h"
3 4
class
InterpolateNew :
5
private :
string
6
int
acuts ;
public
CFRIMethod {
resoultname ;
7 8 9
InterpolateNew ( s t r i n g
10
// a d a t o k
11
// p é l d a :
12
name ) {
beállítása
r e s o u l t n a m e=name ;
13
}
14 15
void
init ( string
16
// a d a t o k
17
// p é l d a :
18
string
19
const
20
a c u t s= a t o i ( c ) ;
21
ini ){
inicializálása
str ;
∗
char
c
=
s t r . c_str ( ) ;
}
22 23
v e c t o r
24
// s z á m í t á s o k
25
/ / majd
26
CMembershipFunction
az
eredménnyel
−0.5
i n t e r p o l a t e ( CObservation
való
visszatérés :
mf=C M e m b e r s h i p F u n c t i o n ( "MF1= ' "+r e s o u l t n a m e+" ' :
27
' trimf ' ,[
28
v e c t o r
29
r e t [ 0 ] = mf ;
30
return
31 32
observation ){
elvégzése
0
0.5]![0
1
0] ") ; ret ;
ret ;
} }
Code 3.13. Új FRI metódus mintakódja A fenti kód egy minta, amely segítséget nyújt a saját osztály megírásában. Azonban ahhoz, hogy az új módszer teljesen része legyen a toolbox-nak, bele kell írni az fritoolbox.cpp-be. Ez a fájl hivatott arra, hogy meghívja az összes interpolációs módszert. A 3.14 kód az fritoolbox.cpp kódból egy részlet. Az els® sorban behívásra kerül a header le, a 3-5. sorban a konstruktor található ami bemenetül egy interpolációs módszer nevét, valamint egy fuzzy rendszert kér. 8-10. sorig a changeMethod függvény van, amivel meg lehet változtatni az eljárást. A 12-14. sorban lév® függvény segítségével lekérhet® a választott módszer neve. A kódrészletb®l a kib®vítés szempontjából fontos rész a 16. sortól kezd®dik, innen indul az interpolate függvény (plusz paraméterek és meggyelés fogadására képes). Ebben található egy összetett IF szerkezet, ami megállapítja melyik módszer nevével hívódott meg a toolbox. Amennyiben az elágazás igaz értéket kap, a kell® módszerb®l létrejön egy példány, meghívódik az init függvénye végül pedig az FRI eljárás interpolate függvénye, a meggyeléssel. Ez az metódus egyben a visszatérési értéke az FRIToolbox interpolate metódusának. Az új módszer hozzáadásának példája a 23. sortól látható, ami követi az el®bb felsorolt 3 lépést. Ha nincs ilyen módszer, amilyen nevet kapott a toolbox, akkor a 29. sorban hibát dob, mely tájékoztatja a felhasználót, hogy a keretrendszerben nem található ilyen módszer. 32
A 33-35. sorban a másik interpolate metódus taláható, melyre azért volt szükség, mert vannak olyan módszerek amik nem igényelnek további paramétereket. Ez meghívja az el®z® interpolate metódust, így könnyítve meg a felhasználó dolgát, hogy ne kelljen üres stringet megadni paraméterként. Az alábbi 3.14 kód tehát megmutatja hogyan is lehet az új módszer a keretrendszer része. 1
#i n c l u d e
" f r i t o o l b o x . h"
2 3
FRIToolbox : : FRIToolbox ( s t r i n g
4
CFRIMethod ( p S y s )
5 6
m_pSys =
{
method ,
m_smethod =
CSystem
∗ pSys )
:
method ;
pSys ;
}
7 8
void
9 10
FRIToolbox : : changeMethod ( s t r i n g
methodName ) {
m_smethod = methodName ; }
11 12
string
13 14
F R I T o o l b o x : : getMethodName ( ) {
return
m_smethod ;
}
15 16
v e c t o r
17
CObservation
18
if (
19
m_smethod . c o m p a r e ( "FIVE" )
∗fri
CFIVE
params ,
= new
== 0
){
CFIVE ( m_pSys ) ;
−> i n i t ( p a r a m s ) ; f r i −> i n t e r p o l a t e ( o b s e r v a t i o n ) ;
20
fri
21
return
22
FRIToolbox : : i n t e r p o l a t e ( s t r i n g
observation ){
}
.. . 23
\}
else
if (
m_smethod . c o m p a r e ( " U j M o d s z e r " )
24
// I t t
25
InterpolateNew
26
fri
az
új
== 0
)
{
metódus
} else {
29
throw
30 31
meg
∗ f r i = new I n t e r p o l a t e N e w ( m_pSys ) ; −> i n i t ( p a r a m s ) ; return f r i −> i n t e r p o l a t e ( o b s e r v a t i o n ) ;
27 28
hívódik
" method
not
implemented ! " ;
} }
32 33
v e c t o r
FRIToolbox : : i n t e r p o l a t e
34
( CObservation
return
35
}
observation ){
i n t e r p o l a t e ( "" , o b s e r v a t i o n ) ;
Code 3.14. Az fritoolbox.cpp forrása
3.5. A keretrendszerben található egylépéses módszerek Az egylépéses módszerek alkotják a fuzzy szabály interpolációs eljárások egyik csoportját. Ezek a módszerek a következményhalmazt mindenféle megel®z® számítás nélkül adják meg, a rendelkezésre álló (legalább egy-egy) közrefogó szabály alapján. Az 33
el®z®ekben már volt róla szó, hogy jelen pillanatban a keretrendszer 5 egylépéses módszert tartalmaz. A továbbiakban röviden bemutatásra kerülnek ezek a módszerek implementálásuk sorrendjében.
3.5.1. KH Kóczy és Hirota [1] vezette be els®ként az alfa vágat alapú KH fuzzy távolság fogalmát (3.11ábra). Ez az eljárás segít rendezni a fuzzy halmazokat. Az A halmaz akkor el®zi meg B halmazt, ha bármely alfa vágat esetén [0, 1] inf(A) < inf(B), illetve sup(A) < sup(B) teljesül, ahol az inf az alfavágatnál a halmaz alsó pontja, sup-nál pedig a fels® pontja. Csak CNF halmazokra m¶ködik a rendezési algoritmus, azonban van egy nagy hibája. Amennyiben A és B halmaznak van közös része, tehát van olyan intervallum ahol mind a kett® értelmezve van, akkor nem lehet egyértelm¶en megmondani melyik halmaz van el®rébb (3.12 ábra).
3.11. ábra. KH távolság értelmezése
3.12. ábra. Egy példa arra, amikor a KH távolság nem tud rendezni Az interpolációs módszer alapgondolata az volt, hogy a becsült eredményhalmaznak ugyanolyan arányban kell felosztania a két közrefogó konzekvens halmazok közötti távolságot, mint ahogy a meggyelés a két legközelebbi antecedens közti távolságot. Az eljárás minden alfa vágat szintjén elvégzi ezeket a számításokat. Szakaszonként lineáris halmazok esetében elegend® csak a töréspontok magasságában alfa vágatokkal számolni. Ugyan az eljárás nem ®rzi meg a szakaszonkénti linearitást, de az eltérés olyan kicsi, hogy elhanyagolható. A módszer el®nye, hogy rendkívül gyors, azonban vannak olyan esetek, melyekre nem ad érvényes eredmény halmazt.
34
3.5.2. VKK Vass, Kalmár és Kóczy [5] szintén alfa vágat alapú rendezést javasolt a fuzzy halmazokra. A távolságot azonban teljesen máshogy értelmezik, mint a fenti esetben. Az alfa vágatot nem az el®z® módon, a halmaz két széls® pontjával határozzuk meg, hanem a halmaz középpontjával és a halmaz szélességével. Két halmaz távolságát pedig a középpontok euklideszi távolságával értelmezi (3.13 ábra). Ez alapján az A halmaz akkor el®zi meg a B halmazt, ha minden alfa vágat magasságában A középpontja el®rébb helyezkedik el, mint B középpontja. A megoldás el®nye, hogy gyorsítja a távolság számítást, viszont még mindig csak részleges rendezést biztosít.
3.13. ábra. VKK távolság értelmezése Az interpolációs eljárás kiküszöböli a KH [1] egyik legnagyobb hibáját, az érvénytelen eredmény halmazt. Ezt úgy érték el, hogy a távolságot másképp deniálták, mint a KH [1] és a halmazok szélességével számol a módszer. Az el®z®höz hasonlóan ez is csak CNF halmazokkal m¶ködik. Hátránya, hogy nem tudja kezelni azt az esetet, amikor valamelyik halmaznak az alfa vágat magasságában a szélessége nulla (singleton). A szakaszonkénti linearitást ez az eljárás sem ®rzi meg, de az eltérés itt is olyan kisméret¶, hogy elhanyagolható.
3.5.3. MACI Tikk és Baranyai [2] dolgozták ki a módosított alfa vágat alapú eljárást (Modied Alpha based Cut Interpolation, innen kapta a nevét). Az eljárás lényege, hogy a Yam által publikát [23] vektorreprezentációs módszert alkalmazva a fuzzy halmazokat olyan térbe transzformálják ahol minden esetben érvényes következmény halmazt eredményeznek a számítások. A szemléletesség kedvéért a továbbiakban háromszög alakú fuzzy halmazokon lesz bemutatva a módszer. Minden halmazt két részre bont, jobb (alsó), bal (fels®) részre, és a vektorokban a halmazok karakterisztikus pontjait tárolja. A számításokat ezek után külön végzik a jobb illetve a baloldalra. Az élek vektorait síkbéli pontokkal ábrázolva elmondható az, hogy csak akkor kapunk érvényes következtetés halmazt, ha a B* pont a B1 és B2 által határolt téglalapon belül, valamint az l vonalon felül helyezkedik el (3.14. ábra). Transzformáljuk a B1 és B2 konzekvenseket egy olyan koordináta rendszerbe, amely kizárja az abnormalitás lehet®ségét. A B1 és B2 konvexitása biztosítja az új rendszerbeli nem negatív értékeket. Ezek után számítsuk ki a következtetés helyét az új koordináta rendszerben, majd végül transzformáljuk vissza a kapott eredményt az eredeti rendszerbe. Ez a megoldás biztosítja a következtetés koordinátáinak monoton növekedését. 35
3.14. ábra. Grakus szemléltetése az éleket leíró vektoroknak
3.5.4. GK(CRF) A módszert Gedeon és Kóczy [13] dolgozták ki, innen az egyik neve, valamint még Conservating of Relative Fuzzynes-nek is szokták hívni. Az eljárást trapéz alakú CNF halmazokra dolgozták ki, az eddigiekhez hasonlóan két közrefogó halmaz segítségével számolja ki az eredményt. Az el®z®ekt®l eltér®en, ez nem az alfa vágatok alapján becsüli az eredményt. A szerz®k ugyanis rájöttek arra, hogy az antecedens halmazok szárai általában hosszabbak, mint a meggyelés élei. Ezért elegend® csak a számítandó oldalon lév® antecedens azonos oldali tartójával kalkulálni (3.15.ábra). A következmény helyzetének becslésére pedig a meggyelés és a szomszédos antecedens magjának távolságát használja fel. Többdimenziós esetre is kiterjeszthet®, ilyenkor a magok euklideszi távolságát használja.
3.15. ábra. Magtávolságok és magszélességek
3.5.5. FIVE Az utoljára bemutatásra (és implementálásra) kerül® egylépéses módszer a Fuzzy Interpolation in the Vague Envirement (innen a neve). Az eljárást 1997-ben Kovács és Kóczy fejlesztette ki [21]. A módszer lényege, hogy a becsléseket az úgynevezett bizonytalan térben [20] végzi el, ahol a fuzzy halmazok alakját skálafüggvények írják le. Hátrányaként róható fel, hogy skálafüggvényt csak háromszög illetve trapéz halmazok esetén találhatunk csak, valamint nem ®rzi meg a szakaszonkénti linearitást. El®nye viszont a többdimenziós esetek kezelése és a gyorsaság, ami annak köszönhet®, hogy a bizonytalan tereket el®re elkészíti. Továbbá elengedhetetlen a bementi és az antecedens oldali bizonytalan tér összeolvasztása [24]. 36
3.6. A keretrendszerben található kétlépéses módszerek A fuzzy szabály interpolációs módszerek másik csoportja a kétlépéses eljárások. Annyiban különböznek az egylépéses társaiktól, hogy miel®tt elkezdenék kiszámolni a következményhalmazt, megel®z® számításokat végeznek. Ezeket a lépéseket a Baranyai, Kóczy és Gedeon által létrehozott GM [6] határozza meg. A koncepció lényege, hogy a következtetést két lépésben állítja el® (innen a neve). El®ször egy új szabályt interpolál magának, melyben az antecedens oldali halmazok referencia pontjai egybe esnek az azonos dimenzióban lév® meggyelés referencia potjával. Ehhez 3 pontot kell megvalósítania:
• Az új szabály antecedens oldali halmazainak alakját határozza meg • A konzekvens halmazok referencia pontját számolja ki • Végül a könzekvens halmazok alakját határozza meg Ezután a 3 számítás után jöhet a következmény halmaz megállapítása, melynek alapötlete, hogy amennyire hasonlít a meggyelés alakja az antecedensére, annyira kell hasonlítania a következmény halmaznak a konzekvensére.
3.6.1. FRIPOC A keretrendszer egyetlen kétlépéses módszere a polárvágat alapú szabály interpolációs eljárás, melyet Johanyák és Kovács dolgoztak ki [15]. A GM-et [6] követve els® lépésben a segédszabály antecedens és konzekvens nyelvi értékeinek meghatározásának érdekében polár-vágat alapú halmaz-interpolációt (FEAT-p) [14] hajt végre. Mivel ezek a számítások nem függnek egymástól, ezért amennyire az adott programnyelv engedi, párhuzamosítással akár jelent®s mértékben gyorsítható a módszer ezen része. A Shepard interpoláció [16] egy adoptált változata segítségével meghatározható az új szabály konzekvens halmazának referencia pontja. A következtetési folyamat második lépésében a szintén polár-vágat alapú SURE-p [15] eljárás segítségével határozzuk meg a következményt.
37
3.7. Módszerek összegzése Az alábbi fejezetben a keretrendszerben található módszereket hasonlítom össze fontos tulajdonságaik alapján. Az els® lényeges szempont a lépések száma. A különbségr®l fentebb már lehetett olvasni, és arról is, hogy 5 egylépéses és 1 kétlépéses eljárás került implementálásra. A következ® oszlopban az összehasonlítás a módszerek azon tulajdonsága alapján történik, hogy kezelnek-e többdimenziós inputot, tehát egyszerre több antecedens dimenzió fogadására és feldolgozására is képesek-e. Látszik, hogy az egyetlen ilyen módszer a FIVE. Az utolsó összehasonlítás alapját a módszerek azon jellegzetessége képezi, hogy minden bemenetre érvényes konklúziót, tehát helyes fuzzy halmazt adnak-e eredményül. Látszik, hogy a KH valamint a VKK nem rendelkezik ezzel a képességgel, olykor homokóra alakú következménnyel térnek vissza. módszer neve
lépések száma
több dimenziós inputot is kezel-e
mindig érvényes-e a következmény
KH
1
kiterjesztve igen
nem
VKK
1
kiterjesztve igen
nem
CRF(GK)
1
kiterjesztve igen
igen
MACI
1
kiterjesztve igen
igen
FIVE
1
igen
igen
FRIPOC
2
kiterjesztve igen
igen
3.1. táblázat. Módszerek összegzése
38
4. fejezet Konklúzió
Szakdolgozatom végére kiderült, hogy több megoldás is létezik melyek feldolgozták a s¶r¶ szabálybázis alapú módszereket, de eddig nem volt olyan, amely a ritka szabálybázisú eljárásokkal foglakozott volna, leszámítva a Johanyák által írt MATLAB FRI Toolbox-ot [8]. Ennek azonban a hátulüt®je, hogy csak MATLAB alól használható, és nem alkalmas valós környezetben való futtatásra. Az általam bemutatott keretrendszer, a MATLAB FRI Toolbox-hoz hasonlóan (legalábbis az abban felhasznált módszereket tekintve) a ritka szabálybázisú eljárásokat foglalja össze. A rendszer mindenki számára elérhet® Windows-on illetve Linux-on egyaránt. A támogatott programnyelv ugyan jelenleg csak C++ (LIB technológiának köszönhet®en), de ez a nyelv elég gyors ahhoz, hogy valós környezetben is használható legyen. Az egységes kezel®felületnek hála bármely FRI módszert, könnyen lehet használni saját kódból, hiszen elegend® belinkelni a toolbox könyvtárát, beolvasni a FIS és OBS le-t, utána a kiválasztott módszer nevével és a fuzzy rendszer megadásával meghívni az interpolate függvényt. A fejlesztést és a használatot is megkönnyíti a kivételosztály, ami módszerekre bontva tartalmazza a kivételek pontos leírását. A keretrendszer kib®vítése, abba új módszer belehelyezése nagyon könnyen elvégezhet®, pusztán pár sor hozzáadásával. A dolgozatom példát szolgáltat arra, hogyan lehet a keretrendszert életre kelteni Windows alól Visual Studio 2010-et használva, illetve Ubuntu alól Eclipse segítségével. Kitér arra is hogyan lehet a toolbox-ot b®víteni, továbbá mintát ad egy új módszer megírására is. A rendszer még fejlesztés alatt áll, jelenleg 5db egylépéses és 1db kétlépéses módszert tartalmaz, ezek a következ®k: KH , VKK , CRF (GK) , MACI, FIVE és FRIPOC. Ez a lista minden bizonnyal b®vülni fog, hiszen további módszerek implementálását bárki nagyon egyszer¶en megteheti (akár egylépéses, vagy kétlépéses módszerr®l legyen szó), akinek igénye van rá, A toolbox-ban rengeteg lehet®ség rejlik, ilyen például a több programnyelv támogatása, amit a LIB helyett DLL-el, illetve wrapper classokkal lehet elérni és a közeljöv®ben reményem szerint meg is fog valósulni, ezzel el®segítve az elterjedést. Valamint azt is mérlegelni lehet, hogy érdemes-e a FIVE-nál használt matematikai könyvtár (Armadillo) segítségével újra leprogramozni a már meglév® módszereket, ezzel elérve némi teljesítmény javulást. Továbbá elkészült egy benchmark rendszer is, amely megkönnyíti a már implementált és kés®bbiekben beültetésre kerül® FRI módszerek összehasonlítását, mind a futási idejüket tekintve, mind pedig a módszerek használhatóságát gyelembe véve. Ezek alapján konkrét javaslotokat tesz, mely módszer alkalmas a feladatok megoldására. 39
Úgy érzem, hogy a szakdolgozat megírása alatt sokat fejl®dtem. Megtanultam csapatban dolgozni, megismerkedtem a keretrendszerek tervezésének fontos szempontjaival és lépésével, valamint a C++ nyelvben is már jobban kiismerem magam.
40
Irodalomjegyzék
[1] L. T. Kóczy and K. Hirota, "Rule interpolation by -level sets in fuzzy approximate reasoning," BUSEFAL, vol. 46, no. Automne, pp. 115-123, 1991. [2] D. Tikk and P. Baranyi, "Comprehensive analysis of a new fuzzy rule interpolation method," IEEE Trans. on Fuzzy Systems, vol. 8, no. 3, pp. 281?296, 2000. [3] S. Kovács and L. T. Kóczy, "Application of an approximate fuzzy logic controller in an agv steering system, path tracking and collision avoidance strategy," Tatra Mountains Math. Publ., vol. 16, pp. 456-467, 1999, http://www.mat.savba.sk/tatra/Full/16/31kovacz.ps. [4] K. W. Wong, T. D. Gedeon, and D. Tikk, "An improved multidimensional -cut based fuzzy interpolation technique," in Proc. of the Int. Conf. on Articial Intelligence in Science and Technology (AISAT'00), V. Karri and M. Negnevitsky, Eds., Hobart, Tasmania, Australia, December, 2000, pp. 33-38. [5] G. Vass, L. Kalmár, and L. T. Kóczy, "Extension of the fuzzy rule interpolation method," in Proc. of the Int. Conf. on Fuzzy Sets Theory and its Applications (FSTA?92), Liptovsky Jan, Slovakia, 1992, pp. 1?6. [6] P. Baranyi, L. T. Kóczy, and T. D. Gedeon, "A generalized concept for fuzzy rule interpolation," IEEE Trans. on Fuzzy Systems, vol. 12, no. 6, pp. 820?837, December 2004. [7] S. Yan, M. Mizumoto, and W. Z. Qiao, "An improvement to Kóczy and Hirota's interpolative reasoning in sparse fuzzy rule bases," Int. J. of Approximate Reasoning, vol. 15, pp. 185?201, 1996. [8] Johanyák, Zs. Cs. and Kovács, Sz.: Fuzzy Rule Interpolation Based on Polar Cuts, in Computational Intelligence, Theory and Applications, Springer Berlin Heidelberg, 2006, pp. 499-511. [9] Z. C. Johanyák, D. Tikk, S. Kovács, and K. W. Wong, "Fuzzy rule interpolation Matlab toolbox - FRI toolbox," in Proc. of the IEEE World Congress on Computational Intelligence (WCCI?06), 15th Int. Conf. on Fuzzy Systems (FUZZ-IEEE?06). Vancouver, BC, Canada: Omnipress, July 16?21, 2006, pp. 1427?1433. [10] ] Z. Johanyák. Fuzzy rule interpolation matlab toolbox website. [Online]. Available: http://fri.gamf.hu
41
[11] D. Tikk, Z. C. Johanyák, S. Kovács, and K. W. Wong, "Fuzzy rule interpolation and extrapolation techniques: Criteria and evaluation guidelines," Journal of Advanced Computational Intelligence and Intelligent Informatics, vol. 15, pp. 254?263, 2011. [12] Freemat website. [Online]. Available: http://freemat.sourceforge.net [13] Kóczy, L.T., Hirota, K. and Gedeon, T. D.: Fuzzy rule interpolation by the conservation of relative fuzziness, in Journal of Advanced Computational Intelligence, Vol. 4/1, 2000, pp. 95-101. [14] Johanyák, Zs. Cs. and Kovács, Sz.: Fuzzy set approximation using polar coordinates and linguistic term shifting, 4rd Slovakian-Hungarian Joint Symposium on Applied Machine Intelligence (SAMI 2006), Herl'any, Slovakia, 2006, pp. 219227. [15] Johanyák, Zs. Cs. and Kovács, Sz.: Fuzzy Rule Interpolation Based on Polar Cuts, in Computational Intelligence, Theory and Applications, Springer Berlin Heidelberg, 2006, pp. 499-511. [16] Shepard, D.: A two dimensional interpolation function for irregularly spaced data, in Proceedings of the 23rd ACM International Conference, New York, USA, 1968, pp. 517-524. [17] Kent Beck Implementation Patterns, Addison-Wesley, 2008 [18] Zoltán Krizsán, Szilveszter Kovács: Fuzzy Rule Interpolation Developer Toolbox Library. SACI 2012: 119-123 [19] Krizsán Zoltán:KÖZÖS FEJLESZTI KERETRENDSZER FUZZY SZABÁLY INTERPOLÁCIÓS MÓDSZEREKHEZ, Miskolci Egyetem (2012) [20] Klawonn, F.: Fuzzy Sets and Vague Environments, in Fuzzy Sets and Systems, Vol.66, 1994, pp. 207-221. [21] Kovács, Sz. and Kóczy, L.T.: The use of the concept of vague environment in approximate fuzzy reasoning, Fuzzy Set Theory and Applications, Tatra Mountains Mathematical Publications, Mathematical Institute Slovak Academy of Sciences, vol.12., pp.169-181, Bratislava, Slovakia, (1997). [22] Johanyák Zs. Cs.: Fuzzy szabály-interpolációs módszerek és mintaadatok alapján történ? automatikus rendszergenerálás, PhD disszertáció, Hatvany József Informatikai Tudományok Doktori Iskola, Miskolci Egyetem, Miskolc, 2007. [23] Yam, Y. and Kóczy, L. T.: Representing membership functions as points in high dimensional spaces for fuzzy interpolation and extrapolation, in IEEE Transactionsnon Fuzzy Systems, Vol. 8., Issue 6, 2000, pp. 761-772 [24] Kovács, Sz.: Extending the Fuzzy Rule Interpolation "FIVE" by Fuzzy Observation, Theory and Applications, Springer Berlin Heidelberg, 2006, pp. 485-497. [25] Armadillo C++ linear algebra library http://arma.sourceforge.net/
42
Ábrák jegyzéke
2.1. 2.2. 2.3. 2.4.
Hagyományos Venn diagram . . . . . Elmosódott él¶ halmaz Venn diagram Fuzzy halmazok ábrázolása . . . . . . Példa s¶r¶ és ritka szabálybázisra . .
. . . . . . . . használatával . . . . . . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
9 9 9 14
3.1. Egylépéses módszerek struktúrája . . . . . . . . . . . . . 3.2. Kétlépéses módszerek struktúrája . . . . . . . . . . . . . 3.3. FRImethod osztálydiagramja . . . . . . . . . . . . . . . 3.4. C++ Projekt létrehozása . . . . . . . . . . . . . . . . . . 3.5. Runtime Library beállítása . . . . . . . . . . . . . . . . . 3.6. Library hozzáadása . . . . . . . . . . . . . . . . . . . . . 3.7. Mintaprogram futási eredménye . . . . . . . . . . . . . . 3.8. Üres C++ projekt létrehozása . . . . . . . . . . . . . . . 3.9. Include path beállítása . . . . . . . . . . . . . . . . . . . 3.10. Static Library hozzáadása . . . . . . . . . . . . . . . . . 3.11. KH távolság értelmezése . . . . . . . . . . . . . . . . . . 3.12. Egy példa arra, amikor a KH távolság nem tud rendezni 3.13. VKK távolság értelmezése . . . . . . . . . . . . . . . . . 3.14. Grakus szemléltetése az éleket leíró vektoroknak . . . . 3.15. Magtávolságok és magszélességek . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
18 19 24 27 27 28 29 30 30 31 34 34 35 36 36
43
Táblázatok jegyzéke
3.1. Módszerek összegzése . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
44
Adathordozó használati útmutató
A DVD melléklet alapvet®en 2 f® könyvtárra osztható. A gyökérben külön választottam a Visual Studio-ba betölthet® project-et valamint a már lefordított könyvtárakat, az fritoolbox.lib, illetve fritoolbox.a-t. (el®bbi windowsos, utóbbi, linuxos használatra). Az FRIT project mappában a project fájlt megnyitva (fritoolbox.sln) Visual Studioban ki lehet próbálni hogyan is lehet új metódsust hozzáadni a keretrendszerhez, ahogy a szakdolgozat el®bbi pontjaiban látható volt. A könyvtárak pedig Könyvtárak mappában található. Szintén meg lehet nézni m¶ködés közben, akár Linux alatt is, a fentebb ismertetett módon. A toolbox tartalma:
Base.cpp Convert.cpp CRF.cpp FEAT_P.cpp FISFile.cpp FIVE.cpp FRI.cpp FRIEXception.cpp FRIMethod.cpp FRIPOC.cpp fritoolbox.cpp GM.cpp KH.cpp MACI.cpp MembershipFunction.cpp Observation.cpp OBSFile.cpp Partition.cpp Point.cpp Rule.cpp Shapes.cpp StringUtils.cpp System.cpp VKK.cpp Mivel maga a keretrendszer megírása csapatmunka volt, ezért vannak olyan osztályok, le-ok melyen többen is dolgoztunk. A fájlok melyeket önállóan írtam, vagy közrem¶ködésem köthet® hozzájuk: VKK.cpp VKK.h, MACI.cpp, MACI.h, FIVE.cpp, FIVE.h, CFRIMethod.cpp CFRIMethod.h, fri.cpp, fri.h, FRIException.cpp, FRIException.h. A DVD nem tartalmazza a keretrendszerhez tartozó benchmark rendszert. 45