VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY

Transkript

1 VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA ELEKTROTECHNIKY A KOMUNIKAČNÍCH TECHNOLOGIÍ ÚSTAV MATEMATIKY FACULTY OF ELECTRICAL ENGINEERING AND COMMUNICATION DEPARTMENT OF MATHEMATICS TVORBA OPERAČNÍHO SYSTÉMU ZALOŽENÉHO NA EVOLUČNÍCH A GENETICKÝCH ALGORITMECH DEVELOPMENT OF OPERATING SYSTEM BASED ON EVOLUTIONARY AND GENETIC ALGORITHMS DIZERTAČNÍ PRÁCE DOCTORAL THESIS AUTOR PRÁCE AUTHOR VEDOUCÍ PRÁCE SUPERVISOR Ing. PETR SKORKOVSKÝ prof. RNDr. JAN CHVALINA, DrSc. BRNO 2013

2 Abstrakt Hlavním cílem této práce je představt nové myšlenky, jak obvyklé postupy pro návrh operačního systému a přdruženého software mohou být vylepšeny aby se staly součástí automatzovaného vývoje software. Obecně se předpokládá, že algortmy nalezené pomocí genetckého programování nemohou být použty pro přesné výpočty, ale jen pro přblžná řešení. Je představeno několk příkladů jak lze př evoluc software přesto dosáhnout přměřené přesnost. Pro dosažení tohoto cíle jsou vlastnost stromově orentovaných struktur spolu s postupy používaným u buněčných automatů spojeny do nového slbného přístupu, který slučuje výhody obou metod. Byla vyvnuta aplkace založená na těchto nových postupech a předpokládá se její budoucí využtí v procesu automatzovaného vývoje software. Klíčová slova genetcké programování, buněčný automat, automatzovaný vývoj software Abstract The man goal of the work s to ntroduce new deas how tradtonal approaches for desgnng an operaton system and assocated software can be mproved to be a part of automatc software evoluton. It s generally supposed that algorthms found by the genetc programmng processes cannot be used for exact calculatons but only for approxmate solutons. Several examples of software evoluton are ntroduced, to show that qute precse solutons can be acheved. To reach ths goal, characterstcs of treelke structures wth approaches based on cellular automata features are combned n a new promsng technque of algorthm representaton, jonng benefts of both concepts. An applcaton has been developed based on these new genetc programmng concepts and t s supposed t can be a part of a future automatc software evoluton process. Keywords genetc programmng, cellular automaton, automatc software development

3 Bblografcká ctace SKORKOVSKÝ, P. Tvorba operačního systému založeného na evolučních a genetckých algortmech. Brno: Vysoké učení techncké v Brně, Fakulta elektrotechnky a komunkačních technologí, Ústav matematky, s., 6 s. příloh. Dzertační práce. Vedoucí práce: prof. RNDr. Jan Chvalna, DrSc. Prohlášení Prohlašuj, že svou dzertační prác na téma Tvorba operačního systému založeného na evolučních a genetckých algortmech jsem vypracoval samostatně pod vedením vedoucího dzertační práce prof. RNDr. Jana Chvalny, DrSc. a s použtím odborné lteratury a dalších nformačních zdrojů, které jsou všechny ctovány v prác a uvedeny v seznamu lteratury na konc práce. Jako autor uvedené dzertační práce dále prohlašuj, že v souvslost s vytvořením této dzertační práce jsem neporušl autorská práva třetích osob, zejména jsem nezasáhl nedovoleným způsobem do czích autorských práv osobnostních a/nebo majetkových a jsem s plně vědom následků porušení ustanovení 11 a následujících zákona č. 121/2000 Sb., o právu autorském, o právech souvsejících s právem autorským a o změně některých zákonů (autorský zákon), ve znění pozdějších předpsů, včetně možných trestněprávních důsledků vyplývajících z ustanovení část druhé, hlavy VI. díl 4 Trestního zákoníku č. 40/2009 Sb. V Brně dne: Ing. Petr Skorkovský Poděkování Na tomto místě bych rád poděkoval mému školtel panu prof. RNDr. Janu Chvalnov, DrSc. za veškerou pomoc, podporu a ochotu, která m byla věnována po celou dobu mého doktorského studa a během přípravy této dzertační práce.

4 Obsah 1. Úvod 4 2. Cíle dzertace 5 3. Rozsah a význam řešeného problému 6 4. Operační systém pro automatzovaný vývoj aplkací Vymezení pojmů Funkce současného operačního systému Dnešní praxe realzace softwarových produktů Vývoj operačního systému nové generace Vlastnost operačního systému nové generace Archtektura operačního systému pro automatzovaný vývoj Rozdělení podle typu ntegrace v nadřazeném systému Rozdělení podle stupně nahrazení původní ntegrace Předpokládané část operačního systému nové generace Rozsah a hloubka popsu, směr zaměření práce Rozhraní pro propojení s vnějším prostředím Zdrojové specfkace Zdrojová specfkace popsující aplkac Zdrojová specfkace popsující komponentu Zdrojová elementární specfkace Cílové mplementace, nterpret a kontrola shody Reprezentace mplementace bnárním vektorem Celulární procesor logckých funkcí Matematcký pops celulárního procesoru logckých funkcí Návrh mplementace bez Párovacího systému Kontrola shody mplementace se specfkací Teoretcké základy genetckého programování Hstorcké souvslost evolučních výpočetních technk Základní rozdělení optmalzačních metod Evoluční výpočetní technky Genetcké algortmy - základní nformace Genetcké algortmy - shrnutí Genetcké programování Aplkace GenAlg Aplkace pro realzac párovacího systému Vzhled a ovládání aplkace Pops datových formátů Příprava nové specfkace Zkušenost s provozem aplkace a doporučení pro její provoz Archtektura aplkace, pops programových bloků Algortmus ověření shody mplementace se specfkací Algortmus selekce jednců podle jejch kvalty

5 10.9 Algortmus generování párů jednců a počty potomků Algortmus křížení párů jednců Algortmus aplkování mutačních operátorů na nové jednce Příklady specfkací a nalezených mplementací Dekodér pro převod 3-btové nformace na 8-btovou Dekodér číselné nformace pro 7 segmentů Indukce číselné řady násobení 3m Identfkace typů ASCII znaků ze 7m bnárních vstupů Úplný seznam funkcí F n Závěr Lteratura 104 Příloha A: CD-ROM 106 Příloha B: CURRICULUM VITAE 109 Seznam obrázků Obr Znázornění hledané aplkace složené z více komponent K, obsahující několk vstupů I a několk výstupů O Obr Znázornění komponent K a jejch propojení pro přenos dat mez sebou, které jako celek tvoří aplkac Obr Znázornění jedné komponenty K a jejch vstupů I a výstupu O, jejíž chování je utvořeno spoluprací skupny vntřních mplementací (např. 1-10) Obr Znázornění 3 typů specfkací, které na různých úrovních popsují složení a chování aplkace (vlevo), složení komponenty (uprostřed) a chování vntřní mplementace, nebo skupny vntřních mplementací (vpravo) Obr Znázornění herarche jednotlvých zdrojových specfkací podle toho jak popsují cílovou aplkac na různých úrovních: Nahoře se nachází specfkace celé aplkace, uprostřed specfkace jednotlvých komponent a dole specfkace jednotlvých mplementací Obr. 6.1 Užvatel ovládá aplkac skrze vstupy a výstupy zprostředkované přes Operační systém Obr Znázornění struktury nalezené mplementace Obr Implementace 3-btového bnárního čítače nalezená ručně Obr Kroky 0 15 nterpretu mplementace bnárního čítače Obr Implementace 3-btového čítače a 8-btového shft regstru Obr Kroky 0 15 nterpretu mplementace čítače + shft regstru Obr Implementace 3-btového čítače a 8-btového shft regstru se zastavovací funkcí Obr Kroky 0 15 nterpretu mplementace čítače + shft regstru se zastavovací funkcí Obr Ohodnocení dle účelové funkce Obr Dva příklady syntaktckých stromů [13] (strana 124, 125) Obr Vzhled aplkace po spuštění a menu pro operace s generacem Obr Vytvoření nové generace po výběru New z menu Generaton Obr Nová generace byla vytvořena s vyobrazeným parametry Obr Ukázka nabídky z menu Evoluton před nahráním specfkace Obr Ukázka nabídky z menu Evoluton po nahrání specfkace Obr Ukázka okna evoluce potom co byly nastaveny všechny parametry Obr Ukázka okna evoluce která byla spuštěna a momentálně běží

6 Obr Příklad popsu struktury bnárního souboru obsahující všechny možné prvky které program CSV2BIN umí rozlšt a použít v example.txt Obr Výsledný obsah bnárního souboru example.bn vygenerovaného s pomocí programu CSV2BIN použtím example.txt Obr Příklad popsu struktury bnárního souboru popsující jednotlvé defnce párů vstup/výstup ve specfkac zobrazení čísel LED Obr Výsledný obsah bnárního souboru LEDnumbers.fdf vygenerovaného s pomocí programu CSV2BIN použtím textového popsu LEDnumbers.txt Obr Schematcké znázornění celého procesu hledání mplementací dle zadané specfkace Obr Schematcké znázornění procesu výpočtu míry shody - ftness Obr Funkce použtá pro selekc, odvozená ze vzorce p(x) =400-0,73*(400*(1-(EXP(- x/200)))+150*sin(2*pi*(1000-x+50)/300)) normalzována na 1000 jednců a p max = Obr Dekodér pro převod 3-btové nformace na 8-btovou používaný v dgtální technce Obr Specfkace dekodéru pro převod 3-btové nformace na 8-btovou (pops zjednodušen oprot obsahu *.fdf souboru) Obr Obsah exportované mplementace, která se shoduje se specfkací Obr Prověření shody s případem č.1 ve specfkac Obr Prověření shody s případem č. 5 ve specfkac Obr Prověření shody s případem č. 7 ve specfkac Obr Všechny kombnace segmentů dekadckého LED dekóderu Obr Nalezený algortmus shodující se na 100% s předloženou defncí - 64 buněk celulárního procesoru logckých funkcí, pops všech pozc v záhlaví [23] Obr Nalezený algortmus shodující se na 100% s předloženou defncí - přehled dynamckého chování nalezeného algortmu pro případ číslo 5 [23] Obr Tento algortmus není pro párovací systém znám a musí být nalezen, nebo spíše namodelován vntřním chováním celulárního procesoru logckých funkcí Obr Příklad 12t krokové terace, kdy na vstup je přvedeno číslo 57 a postupem teračních kroků došly celulární procesory logckých funkcí př použtí bnárních vektorů A B na výstupech k hodnotě Obr Výsledný bnární vektor A nalezený během prvního průběhu evoluce př hledání mplementace pro výstupy y0 y4 specfkace hledaného algortmu Obr Výsledný bnární vektor B nalezený během druhého průběhu evoluce př hledání mplementace pro výstupy y5 y7 specfkace hledaného algortmu Obr První část výsledné nalezené mplementace: buňky Obr Druhá část výsledné nalezené mplementace: buňky Obr Verfkace nalezené mplementace u ASCII 17, kategore řídící kód Obr Verfkace nalezené mplementace u ASCII 52, kategore číslo Obr Verfkace nalezené mplementace u ASCII 115 kategore malé písmeno Seznam tabulek Tab m-btová tabulka pro převod vstupních hodnot na výstupní hodnotu y n Tab Příklady 8m-btových F n funkcí a logckých operací které reprezentují Tab Přehled formátu jak jsou ukládány buňky vektoru v pamět programové realzace párovacího systému GenAlg (vz. kaptola Párovací systém) Tab Přehled úloh u kterých je vhodné pro řešení použít genetcké programování Tab Formát bnárního souboru pro pops hledaných algortmů *.fdf Tab Formát bnárního souboru Generací nalezených mplementací *.gen Tab Výchozí počet párů k algortmu určený z celkového počtu potomků n Tab Přehled všech kombnací funkce číselného dekodéru Tab Tabulka všech vstupních a výstupních hodnot včetně chybějících výstupů, které jsou zde označeny jako? Tab Původní rozdělení znaků základní ASCII tabulky pro dentfkac Tab Rozdělení znaků ASCII tabulky pro dentfkac po zjednodušení Tab Úplný seznam všech logckých funkcí F n

7 1. Úvod Každodenní řešení problémů v mnoha různých odvětvích ldské čnnost se výrazně usnadnlo a zefektvnlo díky masvnímu využívání prostředků výpočetní technky. Zejména v posledních letech dosáhly nformační technologe takového rozmachu, že stále více narůstá jejch důležtost a prohlubuje se jejch význam, jak postupně nahrazují starší pracovní postupy. Dostávají se do popředí zájmu a výrazně ovlvňují veškeré pracovní mmopracovní aktvty každého z nás. Tento trend však přnáší na jedné straně úsporu rutnních pracovních postupů, které by bylo nutné jnak provádět ručně, na druhé straně ale znamenají výrazný nárůst práce pro programátory. Stuace je v současné době taková, že přes dostupnost moderních vývojářských nástrojů a přes významné zefektvnění vývoje programového vybavení, tvorba algortmů a další příbuzné čnnost s tím spojené zatím nebyly plně zautomatzovány a tak veškeré úslí spočívá na programátorech a vývojářích samotných. Navíc zdaleka neznamená, že jž jednou hotový softwarový produkt bude sloužt ve všech ohledech a k nejvyšší spokojenost užvatele v budoucnu. Techncké vybavení postupem času stárne, nároky užvatelů na výkonnost se zvyšují a se změnou hardware vznkají nové verze operačních systémů, pro které je často nutné vytvářet nové verze jž exstujících programů. Další údržba jž hotových produktů, jejch vývoj a rozšřování tak patří k běžnému žvotnímu cyklu, který je patrný u většny softwarového vybavení. Tyto skutečnost znamenají nepřetržtou a nkdy nekončící prác pro programátory. Je vhodné se zamyslet nad tím, zda není možné programátorům jejch prác více usnadnt. Nedá se zřejmě přímo říc, že by jejch účast na celém procesu vývoje softwaru v budoucnu nebyla vůbec nutná, ale alespoň by se výrazně omezla jen na nejnutnější úkony spojené s admnstratvou a byly by tak alespoň ušetřen časově pracovně nejnáročnějších etap. Jako vhodný směr pro automatzac řešení různých tříd problémů, který by mohl časem splňovat potřebná krtéra, se zdají být slbné současné stude a výzkumy na pol genetckého programování. Ač zatím jejch plné užtí znamená nutnost překonávat různá jejch omezení a není zatím možné je využívat v plné míře pro řešení všech známých typů problémů, byly jž přesto jsté úspěchy zaznamenány a to nejen pouze v teoretcké rovně, ale v techncké prax. Pro frmy, kterým se tento úspěch podařl, zpravdla znamenal výrazný přísun a obrovské ekonomcké úspory [11]. Techncké řešení jstého obtížného problému, které je posléze nalezeno pomocí evolučních technk (mez které patří genetcké programování), bývá často takové povahy, že člověk by jnou cestou k němu nejspíš an nedospěl. Nejvíce se tedy vyplatí užívat tyto postupy na řešení vysoce náročných problémů, pro které an neexstují jné známé klascké postupy a výpočty. Přtom bývají s pomocí genetckého programování nalezeny takové algortmy (nebo matematcké rovnce), které svou komplexností přesahují techncký rozhled běžného nženýra (nebo matematka). Mnohdy není snadné zpětně zjstt a spolehlvě určt jak a proč nalezené řešení funguje. Jedním z cílů může být tedy další automatzace převodu komplexního řešení problému na srozumtelnější a přehlednější pops, pokud je to samozřejmě v daném případě vůbec možné

8 2. Cíle dzertace V rámc dzertační práce vyvíjená aplkace je založena na aplkování jž známých poznatků genetckého programování, kde použtým jádrem procesu je určtý mechansmus odvozený od vlastností podobných vlastnostem buněčného automatu. Nejedná se přímo o buněčný automat, ale spíše o procesor logckých funkcí, který má některé vlastnost odvozeny od chování buněčného automatu. Rozsahu dzertační práce odpovídá zpracování těchto bodů: Rešerše současného stavu zkoumané oblast genetckého programování, jž dosažené výsledky v oboru, ze kterých vlastní práce vychází. Navrhnout vlastnost nového operačního systému (nové generace), který by využíval pro svůj vývoj a vývoj pro něj určených aplkací technky genetckého programování. Navrhnout archtekturu operačního systému nové generace. Analýza požadavků na nový (programovací) jazyk a jeho vlastností (nejspíš neprocedurálního typu), kterým lze vhodným způsobem kódovat algortmy, aby bylo možné zautomatzovat jejch vývoj. Matematcký pops nalezeného jazyka pro kódování algortmů. Vývoj aplkace, která je schopna po zadání vhodně kódovaných defnc popsujících chování hledaného algortmu (jeho vstupy, výstupy, dynamcké chování, přechodové stavy, atd.), automatcky nalézt tento algortmus a jeho reprezentac vyjádřenou novým jazykem. Nalezený algortmus je poté možno kdykolv a opakovaně spouštět a používat ho na řešení problémů pro které byl určen. Nalézt způsob jak pops získaného algortmu převést do jného, ldem srozumtelnějšího formátu (např. na pops logckým rovncem číslcové technky), místo pouhé řady bnárních čísel, které mnoho neřeknou o fungování algortmu a jsou nepřehledné. Detalní pops vyvíjené aplkace, programové bloky, podprogramy, moduly, syntaxe a formát vstupních a výstupních souborů, pops datových typů, atd. Praktcké příklady a ukázka hledaných a nalezených algortmů s použtím vyvnuté aplkace. Návrhy pro navazující výzkum

9 3. Rozsah a význam řešeného problému Zde je nutné představt rozsah a dopad popsovaného výzkumu v šrším kontextu a nastíníme, kam až by mohly poznatky získané v rámc dzertační práce vést př pozdějším uplatnění v prax. Význam dosažených výsledků lze tak především ocent př dalším rozšřování a prohloubení jž započatého výzkumu, který momentálně směřuje pouze do jstého dílčího bodu v rámc dzertační práce a skutečný cíl leží tak mnohem dál, avšak v tuto chvíl je ještě přílš vzdálen, aby se dal do dzertační práce zahrnout celý. V současné době jsme svědky prudkého rozmachu výpočetní technky. I trh se softwarovým vybavením je rozvnutý do té míry, že pokrývá potřeby většny zákazníků a lze pořídt téměř jakoukolv aplkac zabývající se téměř lbovolným zaměřením užvatelů. Jedny z krtérí, která určují úspěšnost softwarového produktu jsou: množství funkcí které poskytují, ergonomčnost ovládání a popřípadě jeho výkonnost (rychlost a množství zpracování dat, apod.). Všechny softwarové produkty mají ale jednu společnou vlastnost a tou je vývoj v rež softwarové frmy zaměstnávající mnohdy značné množství programátorů, kteří tráví spousty hodn návrhem a vývojem algortmů dle specfkace, která je sestavena tak, aby co nejlépe naplnla potřeby zákazníka č cílové skupny užvatelů. Většnu těchto aplkací je nutno nadále ručně vyvíjet spolu s tím jak narůstají časem potřeby zákazníků, jak se mění hardware počítače č př přechodu na nový operační systém. Je tedy vhodné zabývat se tím, zda je možné vyvíjet software jným způsobem, jestl lze př vhodně navržené a propracované specfkac a s použtím odlšných přístupů, než na které jsme zvyklí, dosáhnout stavu, kdy se z velké část software vyvíjí sám. Většna aplkací se v současné době vyvíjí ručně s pomocí procedurálního programovacího jazyka a pochoptelně nelze počítat s tím, že by se daly pro automatzovaný vývoj software použít stejné programovací jazyky, jaké jsou dnes hojně používány př ručním vývoj, neboť pro účely automatzovaného vývoje nejsou tyto přílš vhodné. Od základů musíme změnt představu o tom co to vlastně software je, jak funguje, respektve jakých různých podob může nabývat. Rovněž důležtým parametrem je způsob, jak je software prováděn (nterpretován) systémem, pro který byl napsán, a jak svým následným chováním (často dynamckým) ovlvňuje své okolí (hardware), jak zpracovává různé hodnoty na vstupech a jak dle předem přpraveného předpsu (dle specfkace) daný algortmus generuje očekávané hodnoty na výstupech. V případě, že by se podařlo vybudovat metodolog pro automatzovaný vývoj algortmů (nebo automatzovaný vývoj software, což může být totéž), mělo by být teoretcky možné vytvořt operační systém, který dynamcky mění svou podobu podle aktuálních potřeb svého užvatele, neustále se zdokonaluje, vyvíjí a rozšřuje se sám o funkce, které jsou potřeba. Kdykolv by to bylo nutné, stačlo by, aby se jen změnly parametry specfkace a už by se mohl vývoj ubírat jným, aktuálně potřebným směrem a možná přímo za chodu. Každý užvatel by pak dsponoval operačním systémem, který by v maxmální možné míře naplňoval jeho požadavky a potřeby a sám by se podle toho aktualzoval, kdyby se požadavky časem změnly. Dosáhnout těchto vzdálených cílů v rámc dzertační práce pochoptelně není v krátkém čase možné a proto je potřeba stanovt takový cíl, který je možné sthnout a uspokojvě vyřešt. Přesto by ale mohl tento blžší cíl znamenat dobrý základ pro návazný výzkum a přblížení se v započatém směru ke vzdálenému cíl

10 4. Operační systém pro automatzovaný vývoj aplkací 4.1 Vymezení pojmů Operačním systémem v rámc této dzertační práce je myšlen počítačový systém založený na softwarovém vybavení, sloužícím ke snadné správě, údržbě, ovládání, spouštění a přístupu k dalšímu softwarovému vybavení. Veškeré softwarové vybavení slouží pro ovládání perferních zařízení, zajštění nterních systémových služeb operačního systému, nebo pro: vytváření, správu, údržbu, užívání, a dstrbuc různého typu dat, nformací a jného programového vybavení v lokálních, externích, nebo vzdálených datových úložštích a médích. Podle způsobu ntegrace do počítačového systému je softwarové vybavení tohoto typu: Je součástí operačního systému samotného a je spouštěno lokálně, bylo pozděj přdáno podle ndvduálních potřeb užvatele a je spouštěno lokálně, lze jej spouštět jako hosttel pro jného užvatele přstupujícího ze vzdáleného místa a dstrbuovat výstupy do vzdáleného místa, lze jej spouštět na vzdáleném místě na jném hosttelském systému a přejímat jeho výstupy do lokálního místa, ve chvíl použtí lze softwarové vybavení stáhnout ze vzdáleného místa ale dále ho spustt lokálně ve chvíl použtí lze softwarové vybavení poskytnout jnému užvatel pro stažení do vzdáleného místa, aby se spustlo na jném, vzdáleném systému. Ve chvíl, kdy se nějaké softwarové vybavení zavádí a spouští operačním systémem, obvykle se nazývá procesem. Je běžné, že v jeden okamžk běží v operačním systému více procesů najednou. Pro bezproblémový chod je nutné správně procesy - 7 -

11 přepínat a na vyžádání jm přdělovat různé, v tu chvíl dostupné, systémové zdroje, které jsou poskytovány systémovým službam. Dříve přdělené systémové zdroje jsou ve chvíl, kdy nejsou předchozím procesem dále využívány, opět uvolněny pro budoucí užtí jným procesem. 4.2 Funkce současného operačního systému Operační systém lze rozdělt na část zajšťující: správu systémových zdrojů na systémové úrovn, správu systémových služeb, správu vstupních a výstupních užvatelských rozhraní na užvatelské úrovn, správu grafckých prvků pro vzuální komunkac s užvatelem Systémové zdroje, se kterým operační systém pracuje a které spravuje na systémové úrovn, bývají: správa dočasné systémové pamět typu RAM, správa trvalé pamět realzované pevným dskem nebo pamětí typu flash pro data zapsaná v lokálním souborovém systému, správa a přístup k datům uloženým na externích, nebo vzdálených datových úložštích a médích sběrnce pro sérový přenos dat po kabelu sběrnce pro paralelní přenos dat po kabelu sběrnce pro sérový přenos dat bezdrátově přes nfra port sběrnce pro sérový přenos dat bezdrátově přes bluetooth USB sběrnce a perferní zařízení k nm přpojené nterní systémové sběrnce na základní desce počítače pro komunkac s přpojeným kartam zjštění aktuální polohy pomocí systému GPS zjštění aktuální polohy pomocí detektoru zrychlení, naklonění, pádu zjštění reálného času síťová karta přpojená do okolí pomocí kabelu: Zajšťuje přpojení do lokální počítačové sítě LAN, do vnější počítačové sítě WAN, do Internetu. síťová karta přpojená do okolí bezdrátově Wf: Zajšťuje přpojení do lokální počítačové sítě LAN, do vnější počítačové sítě WAN, do Internetu

12 Systémové služby, se kterým operační systém pracuje na systémové úrovn a které spravuje, bývají: zavádění, spouštění, provoz a pozdější bezpečné ukončení celého operačního systému zavádění a spouštění nových procesů, přdělování pamět a dalších systémových zdrojů, které s procesy vyžádají pro svůj chod bezpečné ukončování běžících procesů, uvolňování pamět a dalších systémových zdrojů, které s procesy předtím vyžádal pro svůj chod vytváření, správa a časování událostí pokud jejch vznk nějaký proces vyžádal nebo naplánoval sledování a dstrbuce nformace o vznklých událostech procesům, které událost očekávají pozastavení procesu, který čeká na událost, nebo pokračování běhu procesu pokud očekávaná událost přšla přepínání procesů a jejch časování pro souběžný běh procesů dle nastavených prort a správa těchto prort správa přístupu ke zdrojům aby nedocházelo ke kolzím, pokud dva procesy vyžadují stejný zdroj ve stejném čase - řízení dle prort nebo kvót zolace procesů mez sebou aby nemohl úmyslně nebo neúmyslně narušt vzájemnou ntegrtu správa víceužvatelského a vzdáleného přístupu, správa hesel, bometrckých údajů a užvatelských oprávnění sledování výkonnostních parametrů, tvorba statstky dagnostka správné funkčnost, samo-opravné mechanzmy, sledování ntegrty systému, zajštění bezpečnost, ochrana prot ztrátě kontroly nad systémem kvůl poruše, nebo kvůl neautorzovanému přístupu Vstupní užvatelská rozhraní na užvatelské úrovn, která operační systém spravuje, bývají: vstup z klávesnce: ovládání klávesncí pro pohyb kurzoru nebo skrze psaný text pomocí vkládání textu na místo kde se nachází kurzor, ovládání klávesncí bez psaní textu vstup z polohovacího zařízení skrze ukazatel (špku), ruku, nebo užvatelův prst: počítačová myš, dotyková plocha, pákový ovladač vstup skrze posuv nebo rotací ovládacího prvku: kolečko na myš vstup skrze zvukové záznamové zařízení: hlasové ovládání, převod nformace ze zvuku vstup skrze obrazové záznamové zařízení: kamera, skener, převod nformace z obrazu - 9 -

13 jné vstupy: autorzace užvatele pomocí otsku prstů, autorzace užvatele pomocí čpové karty, autorzace užvatele pomocí obrysů dlaně Výstupní užvatelská rozhraní na užvatelské úrovn, která operační systém spravuje, bývají: výstup na obrazovku nebo na více obrazovek pomocí změny barvy pxelů v matc zobrazovacího panelu tskový výstup zvukový výstup světelná sgnalzace pomocí LED, nebo pomocí dsplejových segmentů na doplňkových panelech zobrazující jný druh nformace než hlavní obrazový panel složený z pxelů: čísla nebo text složený ze segmentů - rozsvěcování nebo zhasínání jednotlvých segmentů, které tvoří nformac Grafcké prvky pro vzuální komunkac s užvatelem, případně pro ovládání systému užvatelem, které operační systém spravuje, bývají: pracovní plocha nabídky pro spouštění zabudovaného, nebo užvatelem přdaného programového vybavení grafcká okna, kony, okna pro operace se soubory a adresář, systémová hlášení, nabídky pro volbu výběrem, textová pole, tlačítka, posuvníky, zaškrtávací políčka, výběry z menu, změna barev, fontů a velkostí písma zobrazování nápovědy pro užvatele ovládací lšty, panely nástrojů zobrazení textového kurzoru, nebo špky polohovacího zařízení systémová lšta pro zobrazení důležtých provozních údajů, varování užvatele, upozornění na vznklé událost, žádost o provedení akcí ze strany užvatele jné grafcké ovládací prvky

14 4.3 Dnešní praxe realzace softwarových produktů Operační systémy, tak jak je známe dnes, bývají realzovány s pomocí vývojových nástrojů pro vývoj softwarového vybavení. Stejně tak další softwarové vybavení, které je pro tyto operační systémy určeno a je v nch pozděj spouštěno, bývá rovněž vyvíjeno s pomocí stejných vývojových nástrojů. Práce s vývojovým nástroj je prováděna programátory, kteří musí mít dokonalou znalost o programu, který právě vyvíjejí, aby nenastala stuace, že se program pozděj chová jnak než užvatel, nebo objednavatel programu očekává. Nejprve budoucí užvatel, nebo objednavatel programu stanoví potřebné chování, nadefnují se typy a formáty dat, se kterým má vyvíjený program pracovat a dále se stanoví další požadavky a krtéra jako je vzhled, statcké a dynamcké chování algortmů, atd. Programátor potom s pomocí programovacího jazyka napíše a odladí zdrojové kódy podle předchozích požadavků na software. Tyto zdrojové kódy slouží pozděj pro komplac a sestavení požadovaného softwarového vybavení. Vytvořené softwarové vybavení má po jeho spuštění v operačním systému zajstt svůj očekávaný vzhled a chování pokud programátor neudělal během vývoje nějakou chybu. Chyby v programech jsou často nevyhnutelné, a přestože by většna z nch měla být nalezena a odstraněna jž ve fáz vývoje, často tomu tak není. Pozděj nalezené chyby se odstraňují obvykle dodatečně s pomocí celých nových verzí programů, aktualzacem jen chybných částí programů, nebo drobným opravam (takzvaným záplatam). Jak už bylo uvedeno výše, stejný postup platí pro jakékolv programové vybavení, tedy pro vývoj operačního systému samotného - tento je jen specálním typem programového vybavení. Pro zjednodušení můžeme uvažovat o tomto sledu kroků, které jsou nutné pro vytvoření nového programového vybavení (a nového operačního systému), tak jak je to prováděno v současnost: 1. Stanovení cíle, účelu a oblast využtí nového programového vybavení 2. Určení systému, na kterém programové vybavení má běžet dle hardwarové specfkace počítačového systému a dle dostupných prostředků cílového operačního systému včetně kompatblty s hosttelským prostředím 3. Pokud využtí programového vybavení přesahuje hosttelský systém a očekává se spolupráce na úrovn počítačových sítí, nebo externích zařízení, je nutné specfkovat pravdla, podle kterých k nterakcím s blízkým a vzdáleným okolím dochází. 4. Je třeba vyjasnt, jakou rol hraje užvatel. Jestl programové vybavení vyžaduje nterakc s užvatelem (a jakou), jestl nteraguje se skupnou užvatelů ve stejnou dobu, zdal dochází k výměně dat s jným programovým vybavením, nebo jestl může pracovat zcela autonomně a nezávsle na svém okolí. 5. Zadavatel, nebo budoucí užvatel musí předložt úplnou specfkac o požadavcích, co má softwarové vybavení umět. Během samotného vývoje se tato specfkace obvykle ještě více upřesňuje, rozšřuje, nebo opravuje, pokud programátor zjstl nějaké nedostatky v popsu

15 6. Ze specfkace vyplývají typy a formáty dat nutné pro řešení problému, dále se musí popsat algortmy pracující s těmto daty. Nedílnou součástí je také omezení a rozsahy dat, stanovení okrajových podmínek, kdy ještě programové vybavení spolehlvě a přesně funguje (bez ztráty přesnost, nebo celkové funkčnost). 7. V této chvíl jž může programátor začít vytvářet zdrojové kódy podle předložené specfkace. Během samotného vývoje programátor jž hotové část testuje a odlaďuje, pokud jejch funkčnost lze ověřt nezávsle na jných částech programového vybavení, které nejsou ještě hotové. 8. Nedílnou součástí vývoje je nezávslé testování, které by měl provádět někdo jný než vyvíjející programátor. V nejlepším případě by nezávslé testování mělo probíhat souběžně během vývoje, aby se zabránlo přílš pozdnímu nalezení závažných chyb, které by mohly ovlvnt funkčnost fnálního produktu. Nedoporučuje se nechat testování až nakonec, může být už potom pozdě a dopad na případné opravy a prác programátora by byl v některých případech neúnosný. Kromě souběžného vývoje a testování by se verfkace měla provádět už ve fáz vytváření specfkace. Některé chyby mohou totž vznknout kvůl špatně napsané specfkac a bohužel takové chyby odhalí zřejmě až užvatel, který se pozděj dví, proč nějaká funkce dělá něco jného, než očekával, přestože podle specfkace je vše v pořádku. 9. Po dokončení vývoje zdrojových kódů následuje komplace a sestavení fnálního softwarového produktu. Hotový produkt je před dodáním testován v konfgurac, kterou bude pozděj používat užvatel. Zamezí se tak chybám, které nemohly být v předchozích fázích nalezeny, protože nebyl produkt sestaven do fnální podoby. Tyto chyby by mohly totž souvset až s hotovým produktem nebo s jeho fnální konfgurací. 10. Žvotní cyklus programového vybavení dále pokračuje během dodání produktu užvatel a během jeho používání. Užvatel komunkuje s dodavatel softwarového produktu a nformuje je o případných nalezených chybách, nebo vytváří další požadavky na doplnění funkcí, které by v jž hotovém produktu potřeboval v budoucnu. 11. Ze sesbíraných nformací od užvatele lze opět sestavt novou specfkac a nastartovat vývoj nové verze softwarového vybavení, nebo pouze provést drobnou aktualzac č opravu takzvanou záplatou (podle rozsahu a náročnost změny). Dalším důvodem pro vytvoření nové verze bývá změna hosttelského prostředí nebo hardwarové specfkace, kdy už stávající softwarové vybavení nelze uspokojvě provozovat v novém prostředí (například nefunguje, nelze vůbec spustt, nebo je zastaralé)

16 4.4 Vývoj operačního systému nové generace Dnešní operační systémy prošly předchozím dlouholetým vývojem a obsahují jž mnoho funkcí, které mohou využívat jak profesonální užvatelé, tak šroká lacká veřejnost. Díky jejch zjednodušenému ovládání a velkému množství užtečných funkcí se stávají operační systémy dostupné (občas dokonce atraktvní) ldem, kteří by se jnak o výpočetní technku zřejmě nezajímal. Z užvatelského hledska toho nelze mnoho operačním systémům vytknout, jejch stablta, bezpečnost a použtelnost se jž dostala na vysokou úroveň. Problematcká však zůstává jejch údržba, aktualzace a následný další vývoj nových verzí. To samé se týká ostatního programového vybavení, které je určeno pro provoz v těchto operačních systémech. Celý cyklus zaměstnává stále více ldí a bohužel je třeba konstatovat, že některé softwarové produkty se vyvíjejí pořád dokola jen proto, že se během několka let několkrát změnl operační systém, nebo v případě nového operačního systému se změnl hardware. Celý tento proces sce umožňuje zaměstnat velké množství ldí, ale občas se pouze nějaký softwarový produkt pouze zrecykluje s drobným úpravam, aby se mohl znovu prodat pro nový operační systém, a generuje tak další zsk svým dodavatelům. Užvatelé by jstě více uvítal, kdyby nebylo nutné stále dokola kupovat nové verze téhož software. Také není příjemné software neustále aktualzovat a záplatovat, protože se nový software vydává často předčasně, kdy obsahuje mnoho chyb. Oprava probíhá sce zdarma, ale je to často provázeno dalším problémy, které užvatele obtěžují. Proces vývoje nového operačního systému, nebo jakéhokolv dalšího programového vybavení by se velm zkrátl, pokud by se vytvořla pouze vhodná specfkace s popsem očekávaného chování, popsal by se formát používaných dat a statcké dynamcké chování programu by bylo také popsáno příslušným algortmy. Tyto nformace by samozřejmě musely být vhodným způsobem kódovány, aby bylo možno s nm pracovat automatzovaně bez účast člověka. Tohoto cíle by mělo být dosaženo s pomocí znalostního nženýrství, které například v oblast umělé ntelgence u expertních systémů doznalo jstého pokroku. Takto vytvořená specfkace by mohla být použta k automatzovanému vývoj programového vybavení s menší ldskou účastí, než jak je tomu doposud. Další velkou výhodou tohoto přístupu by bylo to, že testování takto vyvíjeného programového vybavení by se provádělo rovněž automatzovaně a za běhu. Velká důležtost by potom spočívala na dobře vytvořené specfkac, která by musela být jž sama bez chyb a musela by být dobře použtelná pro následný automatzovaný vývoj. Pokud by se pozděj zjstlo, že je nutné specfkac rozšířt o pops dalších funkcí, nebo opravt pozděj v ní nalezené chyby, nemělo by být už obtížné programové vybavení vygenerovat znovu s opravenou specfkací včetně opětovného automatzovaného testování za běhu př automatzovaném vývoj. Naopak změny ve specfkacích dnešních vyvíjených softwarových produktů většnou znamenají obrovské problémy, neboť je někdy nutné část jž hotové práce zahodt. Bohužel tyto změny mívají velký dopad na testování, a pokud se některé hotové část vyvíjeného produktu zahazují, byly testovány zbytečně. Často malá změna v softwarovém produktu generuje velkou prác pro testovací týmy, neboť tyto musí obvykle otestovat větší část programu a jeho užvatelských funkcí, než jaký byl původní dopad do zdrojového kódu

17 4.5 Vlastnost operačního systému nové generace Nová generace operačního systému by mohla mít tyto vlastnost, které prozatím postrádáme u současných operačních systémů: Automatzovaný vývoj operačního systému by mohl probíhat podle vhodně kódované specfkace. Správné chování systému by mohlo být ověřováno automatzovaným testováním, které porovnává aktuální chování systému se specfkací. Př změně specfkace v jakékolv fáz, ať už na počátku, př hotovém produktu, nebo na přání užvatele kdykolv pozděj, by mělo být možné v softwarovém produktu touto změnou zasažené část znovu vyvnout (vygenerovat) a automatzovaně otestovat aby opět odpovídaly chování které je popsané ve změněné specfkac. Operační systém by v sobě mohl obsahovat celý mechanzmus automatzovaného vývoje programového vybavení. Bylo by tedy možné, aby sám užvatel, pokud by to uměl, s navrhnul svou vlastní novou specfkac, která by popsovala nějaký nový program, který by rád používal a tento by byl následně sám a automatzovaně bez další účast užvatele vytvořen. Tak jako programátoř používají různé knhovny funkcí napsané ve zdrojovém jazyce, ve kterém sam programují, mohlo by být možné v operačním systému spravovat knhovny specfkací, které by bylo možné sdílet mez užvatel. Tyto volně šířené specfkace by s každý užvatel mohl upravt, aby výsledný automatzovaně vyvnutý program měl právě ty funkce, které sám nejvíce potřebuje a naopak by mohl vypustt funkce pro něj nepotřebné. Obdobně by bylo možné upravovat funkce samotného operačního systému podle potřeby užvatele, jen pouhou změnou ve specfkac. Pochoptelně by bylo nutné dodržet určtá předem daná pravdla, aby mez jednotlvým systémy zůstala základní míra kompatblty a nedocházelo k tomu, že každý užvatel by měl sce systém, který by byl jemu uštý na míru a choval se, tak jak on sám potřebuje, ale nebylo by možné sdílet a přenášet data mez ním a ostatním užvatel

18 5. Archtektura operačního systému pro automatzovaný vývoj Spíše než vymýšlet vše znovu od začátku, je rozumné vycházet z archtektury a uspořádání dnešních operačních systémů, neboť jejch vzhled, vlastnost, chování a užvatelské standardy prošly mnohaletým vývojem a ustálly se jž na jstém bodě, který mnoha užvatelům vyhovuje. Nemá smysl tedy začínat od začátku, vymýšlet vše znovu a opakovat vývoj který máme jž za sebou. 5.1 Rozdělení podle typu ntegrace v nadřazeném systému Podle míry ntegrace do exstujícího počítačového systému, se lze na počátku vývoje zamyslet nad těmto způsoby provedení: Lze začít tak, že se vybere jž exstující operační systém a v něm by se vytvořlo prostředí, které se bude spouštět jen jako jeho nadstavba. Uvntř této nadstavby lze pak vymodelovat nosné médum, které už může mít svá vlastní pravdla a své vlastní uspořádání, nezávslé na vnějších podmínkách panujících v nadřazeném operačním systému. Vznkla by tak jakás skořápka, uvntř které by mohl běžet operační systém nové generace. Tento přístup se zdá být pro začátek nejjednodušší a méně zasahuje do zvyklostí užvatele, který by jnak přšel o současný operační systém na který je zvyklý. V případě vytvoření pouhé skořápky běžící pod běžným operačním systémem, by stačlo vytvořt podobnou skořápku pro několk různých konkurenčních operačních systémů, uvntř kterých by potom nosné médum mělo stejné vlastnost. Tento přístup by mohl být jednodušší, než vytvářet operační systém, který by se dal provozovat současně na různých hardwarových archtekturách. Druhou možností je úplné nahrazení současného operačního systému novým, pokročlejším operačním systémem. Výhodou by bylo získání všech systémových prostředků pro své účely a tím vyšší výkon. Nový operační systém by byl hlavním systémem a žádný nadřazený systém by mu nebránl ve výkonu přdělováním jen omezených systémových prostředků. Nevýhodou by byla vyšší obtížnost vývoje takového systému, protože by musel zajstt sám všechny systémové služby, o které by se v případě použtí nadřazeného systému nemusel už starat byly by mu na vyžádání poskytovány. Další nevýhodou by bylo omezení jen na určtou hardwarovou archtekturu a konfgurac, protože nelze bez předchozích úprav tentýž operační systém provozovat na různých počítačových archtekturách, které mají jnou hardwarovou specfkac (jný procesor, jnak uspořádanou paměť, jná rozhraní, atd.). Určtým kompromsem prot úplnému nahrazení starého operačního systému novým, by mohlo být řešení, př kterém by se nový operační systém

19 zaváděl jen př startu počítače podle potřeby z vyměntelného datového méda a tím by nenarušl původní operační systém dostupný opět po restartování počítače z hlavního datového úložště. 5.2 Rozdělení podle stupně nahrazení původní ntegrace Na současný stav poznání v oblast operačních systémů je možné z hledska stupně nahrazení současného modelu ntegrace navazovat těmto způsoby: Nejméně náročná by byla ta varanta, vhodná jako nejsnáze dosažtelný přechodný cíl, že bychom se pro začátek zaměřl jen na automatzovaný vývoj užvatelských aplkací, kdy samotný operační systém nosné médum pro naše aplkace, by byl vyvnut klasckým metodam a nebylo by tak možné jeho vlastnost snadno měnt. Chování by bylo pevně dané a během provozu neměnné, jako je tomu u současných operačních systémů. Toto řešení je v rozporu s cílem uvedeným v ttulu této práce, neboť se do budoucna předpokládá nahrazení celého klasckého operačního systému systémem vyvnutým novým vývojovým metodam. Je zřejmé, že pro začátek je omezení jen na samotné užvatelské aplkace cílem snáze dosažtelným. Pokročlejší varantou je postup, kdy se vytvoří pevné vývojové prostředí. Toto pevné prostředí by bylo schopné využívat předdefnované specfkace defnující formáty dat a algortmy které s těmto daty pracují. Z těchto specfkací lze pomocí přpraveného vývojového prostředí dále automatzovaně vyvíjet lbovolné softwarové komponenty. Tyto softwarové komponenty by po jejch sestavení a propojení tvořl samotný operační systém nové generace. Tento nový operační systém by se zapouzdřl sám do sebe a uvntř něj by bylo opět možné spouštět, vytvářet, vyvíjet, propojovat a provozovat další automatzovaně vyvíjené operačnímu systému podřazené užvatelské aplkace. Vznkla by tak herarche automatzovaně vyvnutého operačního systému, uvntř kterého by bylo možné vyvíjet další podřazené automatzovaně vyvíjené užvatelské aplkace. 5.3 Předpokládané část operačního systému nové generace Předpokládané část nového operačního systému by mohly být tyto: Nalezená cílová aplkace: Tato aplkace je cílem, který by byl nadefnován užvatelem a který by měl operační systém za úkol nalézt. Samotným cílem může být aplkace, která odpovídá nové verz operačního systému. Nalezená cílová aplkace je složena z komponent a její komponenty jsou složeny z množny mplementací (komponenty a mplementace vz. pops níže). V Plánovač cílů (vz. pops níže) může být zadáno, že užvatel chce nalézt automatzovaně, a s pomocí všech dostupných funkcí, aplkac jedné z těchto typů: - Zcela nová aplkace: Všechny její vlastnost musí být užvatelem nadefnovány před samotným spuštěním hledání. Veškeré

20 vlastnost jsou užvatelem stanoveny s pomocí zdrojových specfkací popsujících vlastní aplkac, její komponenty a mplementace použté uvntř komponent. - Nová verze jž exstující aplkace: Užvatel upraví podle své vůle pouze některé jž hotové zdrojové specfkace jž exstující aplkace a spustí hledání nové verze. Docílí se stavu, kdy pouze některá část aplkace, komponenty, nebo specfkace změní své chování, které bude pak po skončení hledání blíže očekávanému chování. - Nový operační systém, nebo nová verze exstujícího systému: Analogcky to samé co platí pro aplkace, platí pro samotný operační systém, který je sám aplkací. Obr Znázornění hledané aplkace složené z více komponent K, obsahující několk vstupů I a několk výstupů O Obr Znázornění komponent K a jejch propojení pro přenos dat mez sebou, které jako celek tvoří aplkac

21 Obr Znázornění jedné komponenty K a jejch vstupů I a výstupu O, jejíž chování je utvořeno spoluprací skupny vntřních mplementací (např. 1-10). Edtor zdrojových specfkací: Slouží k nadefnování specfkací užvatelem podle přesně daných pravdel, tak aby bylo možné k těmto zdrojovým specfkacím automatzovaně nalézat jejch mplementace, se kterým by se daly párovat, propojovat je ve složtější komponenty a následně tyto komponenty spojovat do aplkací. Exstovalo by několk typů zdrojových specfkací: - Zdrojová specfkace popsující aplkac: Slouží k popsu, jaké komponenty jstá aplkace obsahuje a jakým způsobem jsou uvntř ní spolu komponenty propojeny (jak s předávají komponenty mez sebou data, jaké mají vstupy a jaké výstupy) - Zdrojová specfkace popsující komponentu: Slouží k popsu, jaké mplementace jsou obsaženy v nějaké komponentě a jakým způsobem jsou uvntř ní spolu mplementace propojeny (jak s předávají mplementace mez sebou data, jaké mají vstupy a jaké výstupy). - Zdrojová elementární specfkace: K této zdrojové specfkac nejnžší úrovně se nalézají (párují) vntřní mplementace s pomocí Párovacího systému (popsáno níže)

22 Obr Znázornění 3 typů specfkací, které na různých úrovních popsují složení a chování aplkace (vlevo), složení komponenty (uprostřed) a chování vntřní mplementace, nebo skupny vntřních mplementací (vpravo). Strukturovaná databáze zdrojových specfkací: Vhodně kódovaný regstr specfkací popsující základní datové typy a algortmy které s nm umí pracovat. Součástí by byly specfkace popsující komponenty umožňující ostatním specfkacím po nalezení a spárování s jejch mplementacem se propojovat do větších celků složtějších komponentů. Skupna komponentů by potom po propojení a spuštění tvořla celou aplkac (nebo operační systém). V případě že by tvořla jnou aplkac než operační systém, byla by tato určena pro spuštění v operačním systému. Rekurze tvorby operačních systémů kdy jeden operační systém přspěje k vytvoření svého nástupce je možná, tak jako je to možné například provést komplátorem nějakého obvyklého programovacího jazyka. Jako příklad lze uvést komplátor, který by byl sám napsán v nějakém programovacím jazyce a po sestavení tohoto komplátoru, by s tímto novým komplátorem šlo vytvořt novou verz komplátoru téhož programovacího jazyka a nahradt ten předchozí komplátor. Strukturovaná databáze nalezených mplementací: Ke každé elementární specfkac by náležela, buď jedna upřednostněná mplementace, nebo skupna více č méně rovnocenných varant mplementací. Nacházení a párování cílových mplementací s jejch zdrojovým specfkacem se předpokládá být automatzované toto je hlavním bodem celé úvahy a tomuto bodu je zde věnováno nejvíce prostoru. Skupna příbuzných mplementací, jejchž spolupráce je podrobně popsána ve specfkac komponenty tvoří potom chování komponenty. Spolupráce skupny mplementací vztahující se ke stejnému chování popsaného ve specfkac, je řízeno pomocí většnové volby. V některých případech se chování nalezených mplementací může lšt, především pokud se na vstupech objeví data, nebo kombnace dat, které nejsou ve specfkac defnovány. Zde se uplatní zákony pravděpodobnost a skupna paralelně zapojených mplementací vypočítá pro zadaný vstup nějaký výsledek a tento výsledek je porovnán a který výsledek vyšel stejně u více mplementací, ten bude zvolen pro výstup. Smuluje se zde prncp dedukce, kdy ze známého

23 chování pro známé případy se odvozuje chování pro případy, které nejsou popsané. Tento prncp se dá přrovnat k chování umělé neuronové sítě, která je natrénovaná na určtou množnu dat. Pokud se vyskytnou data, která nejsou obsažena v trénovací množně, hledaný výsledek je dopočítán s vědomím, že může být, ale nemusí být správný. Čím více paralelních mplementací se podílí na výpočtu a volbě výsledku v jednom okamžku, tím větší je pravděpodobnost správného výsledku. Obr Znázornění herarche jednotlvých zdrojových specfkací podle toho jak popsují cílovou aplkac na různých úrovních: Nahoře se nachází specfkace celé aplkace, uprostřed specfkace jednotlvých komponent a dole specfkace jednotlvých mplementací. Admnstrátor komponent: Slouží pro určení a naplánování s pomocí databáze zdrojových specfkací, které zdrojové specfkace jsou nutné pro vytvoření určté komponenty vyvíjeného software. Nalezené, k nm spárované mplementace dle jejch specfkací pak admnstrátor komponent pospojuje do větších celků, které potom tvoří celou komponentu. Následně jednotlvé komponenty automatcky vyvíjeného software admnstrátor komponent propojí tak, aby spojené komponenty tvořl kompletní softwarové vybavení a plnl tak svou očekávanou funkc. Interpret mplementací: Tato část systému je zodpovědná za provádění (nterpretac, exekuc) jednotlvých mplementací z databáze podle obsahu jednotlvých komponent. To by spočívalo v převzetí hodnot vstupů do mplementace a provedení algortmu (dříve nalezeného automatzovaně ze specfkace) zakódovaného uvntř mplementace, který má určtý počet kroků a ty by se teratvně opakovaly. Následoval by přenos nově vypočítané nformace na výstupy z mplementace. Tyto odevzdané výstupní hodnoty by byly opět využty jako vstupy do nové navazující zřetězené mplementace. Celý řetězec nterpretovaných mplementací (jehož struktura by byla daná nějakou specfkací) by tvořl chování celé komponenty. Mez sebou propojené komponenty tvoří celou aplkac tím

24 způsobem, že jsou na té nejnžší úrovn realzované nterpretem teratvně nterpretujícím podřazené mplementace. Párovací systém, generátor varant mplementací: Jedná se o genetckým programováním řízený systém hledání a párování mplementací se zdrojovým specfkacem. Př tomto procesu se obvykle nalézá více varant mplementací téže specfkace. K jedné zdrojové specfkac je pak obvykle možné nalézt více varant mplementací a spravovat je jako množnu různých varant mplementací. Důvodem může být to, že ve chvíl kdy se určté varanty mplementací naleznou, nemusí být ještě zřejmé, která z nch bude pro pozdější použtí nejvhodnější. Výběr lze odložt na pozdější dobu až do chvíle, kdy například jedna varanta bude poskytovat během provozu přesnější a správnější výsledky než jná varanta. V jném případě to může být zase odlšná varanta než prvně, tedy je vhodné jch spravovat více najednou. Pro určení správného výsledku lze v danou chvíl použít většnový volební systém, kdy máme lchý počet varant a část z nch hlasuje například pro hodnotu 1 a část z nch pro hodnotu 0. Vybere se potom jako nejpravděpodobnější ta hodnota pro výstup, pro nž se rozhodlo více varant jedné mplementace. Nabízí se pokročlejší řešení: Podobně jako exstují hardwarově řešené akcelerátory počítačové 3D grafky obsahující mnoho jader běžících paralelně na jednom čpu, šlo by jstě vytvořt specalzované, podpůrné hardwarově řešené karty zasunuté do základní desky počítače, které by celý proces genetckým programováním řízeného hledání a párování specfkací s mplementacem urychlly díky paralelním výpočtům. Tyto paralelní výpočty zkracující významně dobu hledání by mohly být umožněny díky specalzovaným mnohojaderným procesorovým čpům na kartě. Plánovač cílů: Užvatel, který by byl momentálně spokojen s konkrétním daným stavem, nebo verzí operačního systému a nepotřeboval by vyvíjet žádné nové softwarové vybavení (jak operační systém samotný, nebo aplkace v něm běžící), ten by zřejmě neměl an žádné cíle a nepotřeboval by tudíž an Plánovač cílů. Předpokládá se naopak, že v případě že by užvatel potřeboval, aby se něco v systému vyvnulo do jného stavu, než ve kterém se právě systém nachází, nebo aby systém dospěl k nějaké nové aplkac, stačlo by nadefnovat nový cíl. Mohlo by exstovat souběžně několk naplánovaných cílů s různým prortam a systém by se snažl s pomocí nadefnovaných zdrojových specfkací přdružených k těmto cílům (které by dostatečně přesně popsovaly detaly cílů), spárovat postupem času s pomocí Párovacího systému tyto specfkace s v té chvíl neexstujícím (a pozděj nalezeným) mplementacem. Ve chvíl, kdy by byly postupně všechny cílové mplementace nalezeny, následuje sestavení komponent s pomocí nástroje zvaného Admnstrátor komponent, který propojí všechny souvsející mplementace do větších celků a v dalším kroku se tyto komponenty propojí dohromady a vytvoří cílovou aplkac. Může to být cílová nová verze samotného operačního systému. Během celého procesu jsou v každé jednotlvé fáz sestavování všechny dílčí kroky automatzovaně kontrolovány tak, že na úrovn mplementací, na úrovn sestavených komponent a na úrovn sestavených aplkací se musí splňovat všechna pravdla, která se k nm vztahují, popsaná ve zdrojových

25 specfkacích. Pokud nebyla nalezena žádná neshoda se žádnou přdruženou zdrojovou specfkací, předpokládá se, že cíl byl splněn a výsledek se předloží užvatel s upozorněním, že došlo ke splnění zadaného cíle. V opačném případě hledání probíhá dál, dokud nebudou splněna všechna pravdla. Předpokládá se, že počítačový systém obsahující a provozující zde popsovaný operační systém nové generace, by běžel nepřetržtě, neboť po naplánování cílů by bylo spuštěno hledání, které však pravděpodobně bude časově velm náročné. Postupně se musí nalézt všechny mplementace pro všechny zdrojové specfkace a to je úkol velm časově náročný, když víme, že se využívá hledání řízené genetckým programováním. Dává tedy smysl, aby hledání probíhalo na pozadí, kdy užvatel meztím používá různé aplkace pro své vlastní účely. Jakmle by užvatel prác ukončl, nechal by systém běžet, aby dále pokračoval v hledání, dokud nebudou všechny mplementace nutné pro sestavení cílové aplkace nalezeny. Systém by se pak podle potřeby sám vypnul. Realstcky vzato je spíše ale pravděpodobné, že by se systém nevypínal nkdy a vlastně by se neustále dynamcky vyvíjel, podle právě stanovených cílů. Kontrola shody: Na všech úrovních se neustále automatcky kontroluje shoda nalezených mplementací, složených komponent a chování sestavené aplkace s popsaným chováním ve všech zdrojových specfkacích všech úrovní, které jsou momentálně přdružené k danému cíl. Shoda všech zdrojových specfkací s celkovým chováním je krtérem pro dosažení cíle a ukončení hledání. Rozhraní pro propojení s vnějším prostředím: Tato část operačního systému obsahuje pevně naprogramovanou složku, u které se přílš nepředpokládá změna běžným užvatelem a není an součástí cílů které plánuje užvatel. Využívá se pouze nformace o napojení na konkrétní poskytované část rozhraní. Prostřednctvím tohoto rozhraní by bylo možné propojt vntřní, automatzovaně vyvíjené aplkace, se skutečným systémovým zdroj počítače. Podle míry a stupně ntegrace do systému to mohou být jak vazby na systémové služby nadřazeného, klasckého operačního systému, který vntřnímu systému zprostředkovává např. čtení znaků z klávesnce, změnu pxelů na obrazovce, posílání dat přes síťové rozhraní, tak využívání služeb operačního systému pro vytváření a ovládání oken, tlačítek, apod. Pokud není použt žádný nadřazený operační systém a jsou dostupné veškeré systémové zdroje počítače v nejvyšší možné míře hned po spuštění počítače a načtení systému do pamět, tak toto rozhraní může zprostředkovávat komunkac přímo s hardwarovým funkcem počítače a jeho systémovým službam. Logcky právě toto rozhraní musí být pevně nadefnováno, jnak by nebylo možné vytvářet automatzovaně vyvíjené aplkace, které by uměly obsluhovat klávesnc, snímat pozce myš, zapsovat na obrazovku, číst z pevného dsku, zapsovat na dsk, apod

26 5.4 Rozsah a hloubka popsu, směr zaměření práce Vzhledem k rozsáhlost témata bylo zvoleno se zaměřt v této prác jen na ty část operačního systému nové generace, které by mohly být pro jeho realzac důležtější než jné část (méně zajímavé část by byly řešeny obecně známým a běžným postupy) a u nchž se předpokládá, že jejch hlubší analýza bude přínosem. Nalezneme zde především pops vztahující se k: Zdrojovým specfkacím, Nalezeným mplementacím, Interpretu mplementací, Párovacímu systému, Kontrole shody nalezené mplementace se specfkací, Rozhraní pro propojení s vnějším prostředím Tyto zasluhují hlubší pozornost a další pops ve zbytku práce je věnován už jen těmto částem. 6. Rozhraní pro propojení s vnějším prostředím Operační systém komunkuje s užvatelem prostřednctvím svých rozhraní (nterface), která jsou napojena na perferní zařízení. Přístup k těmto perferním zařízením je rovněž zprostředkován pomocí týž rozhraní užvatelské aplkac. Z pohledu aplkace je spojení s vnějším světem přímé, ve skutečnost je ale zprostředkované operačním systémem. Užvatel může rovněž nabýt dojmu, že komunkuje přímo s aplkací, mez ním a aplkací se však nachází rozhraní, které je opět řízeno operačním systémem. Kromě perferních zařízení pro komunkac s užvatelem, aplkace navíc komunkuje prostřednctvím svých rozhraní přímo s operačním systémem pro využívání dalších nterních služeb, které mohou být však skryty před užvatelem nemusí o nch mít tušení. Jako příklad nterních služeb můžeme uvést čtení systémového času, synchronzace pomocí časovačů, čtení nebo záps do souborů na nterním pevném dsku, apod. Na úrovn návrhu aplkace, propojení s externím a nterním rozhraním může být defnováno jako součást specfkace aplkace nebo její komponenty. Jaký je formát použtých dat, nebo jak probíhá komunkace s vnějším světem, to je rovněž předmětem návrhu aplkace. Pro komponenty aplkace není podstatné, jestl s právě vyměňují data dvě nterní komponenty mez sebou, dvě aplkace mez sebou, aplkace s operačním systémem, nebo jestl data přcházejí nebo odcházejí z/do vnějšího prostředí ve kterém se nachází užvatel. Obrázek Obr. 6.1 popsuje prncpy na jakých je založeno propojení aplkace s operačním systémem a s vnějším světem z kterého je řízena užvatelem. Obrázek je rozdělen na několk částí. Levá a spodní část představuje užvatele ve vnějším světě, horní a pravá část představuje operační systém. Uprostřed se nachází aplkace složená z komponent, která vlastní několk vstupů a několk výstupů, které jsou sam napojeny na různá rozhraní. Některé

27 vstupy a výstupy jsou určeny pro vntřní komunkac s operačním systémem a jné vstupy a výstupy slouží pro komunkac s vnějším světem. Ve skutečnost aplkace komunkuje pouze s operačním systémem. Část vstupů a výstupů je však svou povahou určena k propojení s vnějším světem a toto propojení je tedy operačním systémem zprostředkováno. O jaké vstupy a výstupy se právě jedná je vždy uvedeno v konkrétní specfkac dané aplkace, nebo její komponenty. Přestože sám operační systém je v této prác uvažován jako aplkace schopna evolučního vývoje a do všech detalů popsána svým specfkacem, musí exstovat jstá neměnná vntřní konstrukce, která je pevně daná. Lze uvažovat o tom, že tato konstrukce by mohla být realzována podobně, jako svého času sloužl BIOS (Basc Input Output System) na základní desce počítače. Jednalo se v té době o software, který zprostředkovával propojení hardware počítače se softwarem a poskytoval sadu základních služeb, která musela být pro všechny počítače stejná, aby veškerý software správně fungoval na všech systémech. Hardwarová konfgurace těchto systémů mohla být jná, ale když měly nad sebou standardní sadu služeb, nebyl to pro software žádný problém, aby se přes různé odlšnost s počítačovým komponentam bezchybně spojl. Základní softwarová konstrukce pro propojení operačního systému s počítačovým komponentam, rozhraním a perférem by byla naprogramována konvenčním metodam a do procesu evoluce by nebyla zahrnuta. Jsté základní prncpy a mechanzmy musí být vždy nastaveny jako neměnné. Na těchto základech lze potom dále budovat složtější struktury, které jž neměnné být nemusí a ty svou složtostí mohou dále překonávat původní pevně dané podloží. Obr. 6.1 Užvatel ovládá aplkac skrze vstupy a výstupy zprostředkované přes Operační systém

28 7. Zdrojové specfkace Název zdrojová specfkace byl zvolen pro svou podobnost se slovním spojením zdrojový kód. Tato podobnost má však hlubší význam. U zdrojového kódu jde o přeps algortmu člověkem do pro počítač srozumtelné formy, obvykle s použtím nějakého programovacího jazyka (obvykle procedurálního typu). Ze zdrojového kódu se vygeneruje aplkace, která je pak používána užvatelem a dle potřeby spouštěna v operačním systému. Tento proces je většnou jednosměrný, ze zdrojového kódu se generuje aplkace, ale z jž vygenerované aplkace obvykle nelze získat zpět zdrojový kód. V operačním systému nové generace se pro pops algortmů předpokládá užtí zdrojových specfkací místo zdrojového kódu. Hlavní rozdíl spočívá v tom, že specfkace má charakter popsný podle předložených případů, kde se vlastnost algortmu obecněj popsují očekávaným chováním. Tedy jnak, než jak jsou defnovány ve zdrojovém kódu konkrétním programovým kroky. Zdrojový kód tedy obsahuje jž realzovaný algortmus ve formě programových kroků. Je přesně dána posloupnost těchto kroků, aby bylo dosaženo správného chování popsovaného algortmu. Tyto kroky musí být popsány velce podrobně programátorem. Tento proces lze velm obtížně zautomatzovat a účast člověka je zatím nutná. Naopak u zdrojové specfkace se pro pops algortmu nepředpokládá defnce pomocí programových kroků a pops je více strukturální než procedurální. Správná posloupnost programových kroků je v tomto případě nazývána mplementací, která se vztahuje ke své zdrojové specfkac a je hledána automatzovaným procesem genetckého programování. K jedné zdrojové specfkac lze během evolučního procesu genetckého programování nalézt více varant svým chováním podobných mplementací, podobně jako jeden algortmus lze realzovat různým varantam zdrojového kódu. Která varanta je nejvhodnější, která nejlépe dokáže řešt daný problém, nemusí být předem známo, a proto je lepší uchovávat souběžně více varant, které se vztahují k jedné zdrojové specfkac. Hlavní výhoda popsu algortmů pomocí zdrojových specfkací je ta, že problém nemusí být popsán vyčerpávajícím způsobem. Vytvoří se dostatečně velká sada případů popsující daný problém a některé aspekty, které nejsou přímo uvedeny, mohou samy z jž zadaných nformací vyplynout. Pro všechny případy, které jsou uvedeny ve specfkac, je výsledné chování algortmu zřejmé to je také cílem mplementace, aby se chovala podle zadaných případů. Když se však pozděj na vstupy nalezené mplementace předloží kombnace dat, která se ve specfkac nenachází, mplementace navrhne řešení vycházející z naučeného chování u známých případů smuluje tak extrapolac výsledku u neznámého zadání. Pro účely extrapolace daného problému se proto hodí mít k dspozc co nejšrší základnu varant mplementací, kdy všechny mplementace mohou hlasovat a výsledkem bude zvolen ten výstup, který je nejčetnější. Díky zákonům pravděpodobnost, př dostatečném množství případů uvedených ve specfkac popsující nějaký problém a př dostatečně velkém počtu varant mplementací, se budeme blížt ke správným řešením pro případy extrapolace řešení u neznámého zadání. Toto není možné u procedurálního popsu algortmů. Algortmus

29 se bude chovat pouze jedním způsobem a to vždy stejně, lhostejno kolk máme varant zdrojového kódu. U každého z typů zdrojových specfkací představíme jejch vlastnost, a čím se lší od ostatních typů zdrojových specfkací. V jednotlvých specfkacích se uvádí nformace o různých datových spojích mez komponentam, nebo mez aplkací a svým okolím. Datové spoje jsou realzovány kanály dat, které mohou mít lbovolnou btovou šířku a tak reprezentují různé typy dat. Nejjednodušším typem spoje je spoj logcký, který nabývá pouze hodnoty 0 nebo 1. Pro realzac spojů například z výstupu jedné komponenty do druhé, je důležté, aby byla stejná šířka dat na straně výstupů a vstupů nformace by se neměla ztrácet, ale an vznkat mmo komponenty. 7.1 Zdrojová specfkace popsující aplkac Základní parametry aplkace jsou popsány na úrovn zdrojové specfkace pro aplkac a mez ně patří například (vše je uvedeno jen jako možné, ale ne jedné řešení): Seznam všech vstupů a výstupů s okolním prostředím. Příklad položek seznamu kde O znamená output, I znamená nput, X znamená externí: IXkeyboard, IXcom1, IXlpt1, IXmcrofon, OXscreen, OXprnter, OXspeaker Seznam všech vstupů a výstupů pro komunkac s operačním systémem. Příklad položek seznamu kde O znamená output, I znamení nput, S znamená operační systém: OSopen_fle, OSwrte_to_fle, OSset_tme, ISread_tme, IStmer1, ISreset_applcaton Seznam všech komponent, ze kterých se aplkace skládá. Příklad položek seznamu: Ksect_csla, Kzaokrouhlen, Kzjst_delku_seznamu Seznam všech spojů mez komponentam ve formě orentovaného grafu, kdy z jednoho uzlu grafu nebo do jednoho uzlu grafu může vycházet/vstupovat několk spojů m:n, kde m je počet vstupů do uzlu a n je počet výstupů z uzlu. Každý spoj má jako parametr svou datovou šířku v počtu btů, která musí souhlast jak na straně odesílatele nformace, tak na straně příjemce nformace. Příklad jedné položky seznamu: Kkomp1Ocslo1/Kkomp2Icslo1, kde Kkomp1 je jedna komponenta jejíž výstup Ocslo1 je směrován do komponenty Kkomp2, do jejího vstupu Icslo

30 7.2 Zdrojová specfkace popsující komponentu Základní parametry komponenty jsou popsány na úrovn zdrojové specfkace pro komponentu a mez ně patří například (vše je uvedeno jen jako možné, ale ne jedné řešení): Seznam všech vstupů do komponenty. Příklad položek seznamu kde číslo za : značí šířku datového spoje: Icslo1:8, Icslo2:8, Ikladne:1, Iword:16 Seznam všech výstupů z komponenty. Příklad položek seznamu kde číslo za : značí šířku datového spoje: Odelka:8, Oznak:8, Opotvrzen:1, Osouradncex:16 Seznam všech nterních spojů, které jsou použté pro propojení dat ze dvou specfkací jen uvntř komponenty. Příklad položek seznamu pro vntřní vstupy kde číslo za : značí šířku datového spoje: Xntern_spoj1:4, Xprenos_dat:8 Příklad položek seznamu pro vntřní výstupy kde číslo za : značí šířku datového spoje: Yntern3:8, Yzaokrouhleno:12 Seznam všech zdrojových elementárních specfkací popsující komponentu. Příklad položek seznamu, kde položky uvntř závorek určují které vstupy a které výstupy se u specfkace použjí. Doporučuje se v seznamu mez závorkam na začátek uvést vstupy a na konec výstupy: Esoucet(Icslo1, Icslo2, Ocslo3, Ykladny_vysledek), Epreved_znak(Iznak1, Xznak2, Oznak, Ypotvrzeno) 7.3 Zdrojová elementární specfkace Zdrojová elementární specfkace se nachází na nejnžší úrovn popsu celé aplkace. Tato slouží párovacímu systému k hledání mplementací a varant mplementací, které se mají blížt svým chování k chování popsanému v elementární zdrojové specfkac. Tato specfkace je popsána svým vstupy, svým výstupy, btovou šířkou použtých vstupních nebo výstupních dat a především se zde nachází tabulka popsující chování hledané mplementace. Jsou dvě možnost, jak může být chování hledané mplementace popsáno: Pops vyčerpávajícím způsobem: Jsou popsány všechny možné kombnace hodnot všech vstupů a výstupů. Nemůže se stát, že by se nalezená mplementace pozděj odchylovala svým chováním od předepsaných stavů ve všech jednotlvých případech, které mohou nastat. Nevýhodou je to, že se musí vytvořt rozsáhlá množna případů, aby všechny možné stavy byly podchyceny. Poté stačí nalézt pouze jednu varantu mplementace, která splní všechny uvedené případy vstupních a výstupních dat. Pops neúplnou množnou stavů: U složtého chování, u kterého neznáme způsob, jak algortmus generující data funguje, ale máme dostatečné

31 množství dat pro jeho pops, můžeme zadat alespoň tato data, která jsou v tu chvíl dostupná. Chování bude namodelováno bez znalost jeho podstaty. V tomto případě je lepší nalézt pomocí párovacího systému větší množství varant mplementací, než pouze jednu varantu, aby bylo možné volt domnělé výsledky většnovou volbou. Díky zákonům pravděpodobnost je velká šance, že př použtí více varant mplementací pro volbu aktuálních výstupů, bude zvolený výsledek správný. To jestl je pops úplný, nebo neúplný, to by mělo být uvedeno jž v nastavení specfkace, aby se párovací systém mohl rozhodovat, jestl hledat více varant, nebo zda to není pro daný případ potřeba. Podle počtu vstupů, výstupů a jejch datových šířek, párovací systém se sám pokusí rozdělt vstupní a výstupní data na menší datové šířky a tím vytvářet paralelní mplementace, které se na venek mohou tvářt jako jedna mplementace, ale uvntř může dojít k rozštěpení na menší část použté pro hledání genetckým programováním odděleně. Důvodem může být přílšná náročnost pro hledání mplementace a hrozí, že hledání by bylo neúspěšné, pokud by byly použty pro hledání mplementace více vstupů a výstupů o dlouhých btových šířkách najednou. Párovací systém může vytvořt několk varant vntřního štěpení nformací a pokust se sám o hledání mplementací s různým nastavením. Během hledání by se mělo dojít na to, které varanty vedou rychlej k hledanému výsledku a které naopak trvají neúměrně dlouho a tyto by byly ukončeny. Výhodou tohoto způsobu popsu známého neznámého chování algortmů je to, že systém může sám během provozu ověřovat, které případy kdy nastávají a provádět u nch statstku, která se může hodt pro další analýzy. Součástí této statstky může být to, že u některých předem neznámých stavů, které nebyly ve specfkac nadefnovány, ale vyskytují se během provozu, je vždy snaha nalézt správné řešení pro tyto případy. Pokud evdentně dochází př výběru k chybnému chování, užvatel může pozděj provést korekc přdáním konkrétních dodatečných dat do specfkace, podle kterých lze nalézt nové varanty mplementací, které by už pozděj měly vykazovat správné chování. Výhodou je také to, že kdykolv pozděj kdyby bylo potřeba dříve nadefnované chování změnt, stačí pouze změnt exstující data, aktualzovat je a provést opětovné hledání mplementací jen na tyto změněné část. Celá aplkace je díky tomu dynamckým systémem, který je schopen kdykolv poupravt své chování podle aktuálních potřeb a požadavků užvatele

32 8. Cílové mplementace, nterpret a kontrola shody 8.1 Reprezentace mplementace bnárním vektorem Pro potřeby automatckého vývoje algortmů - mplementací s použtím genetckého programování, je vhodné navrhnout obecný záps algortmů - mplementací genetckým jazykem a softwarové prostředí, které je schopno tímto genetckým jazykem zapsané algortmy provádět - nterpret. Cílem návrhu je algortmus zapsaný genetckým jazykem, který by měl mít tyto vlastnost [15]: Jednoduchost zápsu (př nesplnění požadavku se prudce zvyšuje výpočetní zátěž), robustnost (př nesplnění požadavku hrozí zablokování celého algortmu př jedné chybě v algortmu), optmální varablta zápsu (nízká varablta, nebo přílš vysoká varablta vede k problémům př dosažení cíle nedostatek nebo velký nárůst kombnací), upřednostnění paralelního zpracování před sekvenčním nebo procedurálním (Několk paralelních současně běžících větví algortmu může dojít k výsledku různým cestam a přtom nehrozí zablokování celého algortmu chybou jedné větve vz robustnost.), realzovaný algortmus by měl být determnstcký, aby bylo možné vždy dojít ke stejnému výsledku př stejných vstupních datech, zapsaný algortmus by měl být pokud možno do jsté míry čtelný pro člověka, aby byl schopen zpětně pochopt a analyzovat vntřní chování algortmu nebo jej následně ručně opravovat č dooptmalzovat (nepřehledné a složté zápsy algortmu neumožňují další ruční zdokonalování, úpravy nebo jen pouhou analýzu vntřního chování), celý systém (zapsaná mplementace + její nterpret) by měl být schopen realzovat lbovolný mysltelný (determnstcký) algortmus včetně vrtuální emulace sama sebe, např. měl by být schopen emulovat lbovolný známý počítačový mkroprocesor a program na něm běžící v jazyce tohoto mkroprocesoru (v mezích techncké realzovatelnost dle časové a kapactní náročnost teoretcká provedtelnost). Ke splnění výše uvedených předpokladů se velm blíží návrh, který je popsán v následující kaptole. Protože je tento návrh založen na perodckém zpracování nformací, které jsou atomzovány na jednotlvé bty (jsou reprezentovány řadou buněk) a následně jsou dále zpracovávány pomocí logckých funkcí, je tento systém nazýván Celulární procesor logckých funkcí

33 8.2 Celulární procesor logckých funkcí Celulární procesor logckých funkcí je používán pro výpočet vhodnost jednců během evolučního procesu (po nalezení hledané mplementace slouží také k provádění zakódovaného algortmu) a jeho základní stavební jednotkou je jedna buňka B n,k, která v součnnost s ostatním buňkam tvoří jednorozměrný buněčný automat s absolutním adresovým prostorem v rozsahu < 0, n max > [16]. Ve skutečnost se nejedná přímo o klascký buněčný automat, protože není splněna podmínka homogenty ve všech ohledech, a protože jednotlvé buňky mohou obsahovat jnou přenosovou funkc a mohou mít různé spoje na okolní buňky. Ostatní vlastnost jž dostatečně odpovídají vlastnostem buněčného automatu. Během procesu evoluce u genetckého programování, každý člen populace (každý člen Generace) je současně kanddátem na řešení algortmu a jedná se o bnární vektor složený z buněk, kde každá z nch obsahuje bnární nformac o svém aktuálním výstupu a jako celek určují chování hledaného algortmu (mplementace) tak, že se generují výstupy z předložených vstupů během opakování určtého počtu cyklů. V jž realzovaném programu, který provádí párování specfkací s mplementacem je každá z buněk B n,k kódována 32 bty a představuje bnární nformac (její výstup) [20]: 1 bt: aktuální platná hodnota vypočítaná pro aktuální krok k vyjádřená jako y n, k { ( 0) 2,( 1) 2 }, (8.2.1) 1 bt: předchozí platná hodnota výstupu buňky z předchozího kroku k-1 jako y n, k 1 { ( 0) 2,( 1) 2 }, (8.2.2) 11 btů: relatvní adresa ukazující na první okolní buňku a n = < -(n max +1)/2, +(n max +1)/2-1>, (8.2.3) 11 btů: relatvní adresa ukazující na druhou okolní buňku b n = < -(n max +1)/2, +(n max +1)/2-1>, (8.2.4) 8 btů: logcká funkce F n kódovaná 8m-btovou tabulkou (jeden bajt) F n = [f n,0, f n,1, f n,2, f n,3, f n,4, f n,5, f n,6, f n,7 ] = < (0) 10, (255) 10 >. (8.2.5) Během každého teračního kroku k všechny nové hodnoty výstupů každé buňky B n,k jsou vypočítávány z předchozí hodnoty výstupu první okolní buňky B n+an,k-1 (adresu buňky A vypočítáme z n + a n ), z předchozí hodnoty výstupu druhé okolní buňky B n+bn,k-1 (adresu buňky B vypočítáme z n + b n ) a z předchozí hodnoty výstupu buňky B n,k-1 samotné. Všechny tyto tř bnární hodnoty tvoří adresu v tabulce (0 7) která určuje novou výstupní hodnotu (f n,0 f n,7 ) buňky B n,k z 8m-btové tabulky F n [19]

34 Tab m-btová tabulka pro převod vstupních hodnot na výstupní hodnotu y n ndex Inputs Output y n,k-1 y n+bn,k-1 y n+an,k-1 y n,k f n, f n, f n, f n, f n, f n, f n, f n,7 Funkce F n popsuje pomocí svých osm btů logckou operac, která se provádí se vstupy y n+an,k-1, y n+bn,k-1 a y n,k-1. Příklady několka takových funkcí a logckých operací, které se k nm vztahují, jsou uvedeny v tabulce Tab V této tabulce y a,k-1 = y n+an,k-1 a y b,k-1 = y n+bn,k-1. Vyčerpávající seznam všech F n funkcí s číselnou hodnotou a jejch přdružených logckých operací je uveden v příloze A. Tab Příklady 8m-btových F n funkcí a logckých operací které reprezentují. S Q R (0) 10 y n,k = 0 (255) 10 y n,k = 1 (85) 10 nebo (51) 10 y n,k = NOT(y a,k-1 ) y n,k = NOT(y b,k-1 ) (178) 10 S = y a,k-1, R = y b,k-1 y n,k = Q AND (136) 10 y n,k = AND(y a,k-1, y b,k-1 ) (238) 10 y n,k = OR(y a,k-1, y b,k-1 ) (119) 10 y n,k = NAND(y a,k-1, y b,k-1 ) (184) 10 data = y a,k-1, wrte = y b,k-1, y n,k = out

35 Obr Znázornění struktury nalezené mplementace Jakmle je nalezena hledaná mplementace, která odpovídá zadané specfkac, nastavení všech buněk v mplementac lze znázornt určtou strukturou. Struktura mplementace je tvořena díky nastavení relatvních adres a n a b n každé buňky a jejch funkcí F n. Příklad jak by mohla vypadat struktura mplementace je znázorněn na obrázku Obr Tab Přehled formátu jak jsou ukládány buňky vektoru v pamět programové realzace párovacího systému GenAlg (vz. kaptola Párovací systém) B: Adresa - Tabulka výstupů Předchozí B: Adresa vyšší část nžší část nžší část y B2 B1 B0 F3 F2 F1 F0 y_ B10 B9 B8 B7 B6 B5 B4 B3 A: Adresa - Tabulka výstupů Aktuální A: Adresa vyšší část nžší část vyšší část y A2 A1 A0 F7 F6 F5 F4 y A10 A9 A8 A7 A6 A5 A4 A3 Formát dat představený tabulkou Tab se u momentálně realzovaného párovacího programu opakuje pro všechny buňky vektoru na adresách buněk 0 až n max [20]

36 8.3 Matematcký pops celulárního procesoru logckých funkcí Stavová matce Y k celulárního procesoru logckých funkcí obsahující aktuální bnární hodnoty všech buněk v kroku k [15]: Y y y y y y 0, (8.3.1) k [ ] =, {( ) ( ) } 0, k 1, k 2, k L n max, k n, k Matce F obsahující logcké funkce všech buněk vyjádřené pravdvostním tabulkam v matc F: f 0,0 f1,0 f 2,0 f n max,0 f 0,1 f 1,1 f 2,1 f n max,1 f 0,2 f1,2 f 2,2 f n max,2 [ ] f 0,3 f1,3 f 2,3 f n max,3 F = F 0 F1 F2 L Fn max = L, f n, { ( 0) 2,( 1) 2 } f 0,4 f1,4 f 2,4 f n max,4 f 0,5 f1,5 f 2,5 f n max,5 f 0,6 f1,6 f 2,6 f n max,6 f 0,7 f1,7 f 2,7 f n max,7 (8.3.2) Čtvercová matce V obsahující vazby na okolní buňky zakódované v koefcentech uvntř matce, sloužící pro sběr výstupů z okolních buněk: 2 2 v1,0 v2,0 L vn max,0 2 v0,1 2 v2,1 L vn max,1 2 V = v 0,2 v1,2 2 L vn max,2, pro v n,j platí: M M M O M 2 v0, n max v1, n max v2, n max L 2 (8.3.3) Buňka na pozc n přjímá výstup z jné buňky na pozc n a => buňka na pozc n přjímá výstup z jné buňky na pozc n b => 0 v n, = 2 n a 1 v n, = 2 n b,, (8.3.4) (8.3.5) buňka nemá žádnou další vazbu (maxmum jsou 2 vazby, mnmum je 0 vazeb) => v n, j = 0. (8.3.6) Matce P k obsahující vypočtené ndexy pro výběr nové aktuální bnární hodnoty všech buněk z matce logckých funkcí F pravdvostních tabulek: P k [ ] =, { ( 0),( 1),( 2),( 3),( 4),( 5),( 6),( ) } 0, k 1, k 2, k L n max, k n, k (8.3.7)

37 Transformační matce T n,k () obsahující výpočet koefcentů pro převod ndexů n,k z desítkové soustavy (0,1,2,,7) na konkrétní vybranou hodnotu z pravdvostní tabulky: ( )( )( )( )( )( )( ) ( ) ( ) ( )( )( )( )( )( ) ( ) ( ) ( )( )( )( )( )( ) ( ) ( ) ( )( )( )( )( )( ) ( ) ( ) ( )( )( )( )( )( ) ( ) ( ) ( )( )( )( )( )( ) ( ) ( ) ( )( )( )( )( )( ) ( ) ( ) ( )( )( )( )( )( ) ( ) ( ) = , 1! 7! ! 7! ! 7! ! 7! ! 7! ! 7! ! 7! ! 7! ) ( k n T, nebo = ,,,,,,,,,, ) ( k n k n k n k n k n k n k n k n k n k n T (8.3.8) Všechny výsledné matce T n,k lze sdružt transponovaně do celkové matce [ ] T k n T k T k T k k T T T T T max, 2, 1,, 0 L = (8.3.9) k pozdějšímu použtí pro skalární součn matc. Průběh výpočtu přechodu z předchozího stavu celulárního logckého procesoru Y k do nového stavu Y k+1 : Pro výpočet všech ndexů (které obsahuje matce P k ) výběru nového výstupu Y k+1 z pravdvostních tabulek P k v kroku k se provede matcová operace násobení dvou matc: Y V P k k =, (8.3.10) pro každý ze vznklých ndexů n,k matce P k se vypočítá transformační matce T n,k ( n,k ) a sdruží se jako transponované prvky T n,k T v matc T k, - vz (8.3.8) a (8.3.9). Dle vypočítaných ndexů n,k matce převedených na transformační matce v matc T k s pomocí skalárního součnu matc T n,k s pravdvostním tabulkam logckých funkcí F n vyjádřených v matc F se provede výběr nových hodnot y n,k+1 : n T k n k n k F T y Y = + +, 1, 1 : (8.3.11)

38 8.4 Návrh mplementace bez Párovacího systému Stejně tak jako se hledají mplementace splňující pops nějakého chování ve specfkac pomocí Párovacího systému metodam genetckého programování, je u některých specfkací možné mplementac navrhnout ručně. Není to původním záměrem, aby se takto navrhovala mplementace bez použtí Párovacího systému, ale spíše jsou zde tyto příklady uvedeny pro snadnější pochopení jak mplementace fungují a aby bylo zřejmé, že je lze občas navrhnout ručně. a) Prvním jednoduchým příkladem je návrh 3-btového bnárního čítače. V tomto příkladu se použjí 3 buňky celulárního procesoru logckých funkcí, které jsou propojeny jedna za druhou. Implementace nemá žádné vstupy, má pouze 3 výstupy, kterým jsou bty čítače y 0, y 1 a y 2. Buňky s čísly 0, 1 a 2 jsou zde použty pro mplementac; ostatní buňky nejsou použty. Na obrázku Obr je zobrazeno nastavení mplementace realzované těmto třem buňkam [ B 0 [a 0, b 0, F 0 ], B 1 [a 1, b 1, F 1 ], B 2 [a 2, b 2, F 2 ] ] = [ B 0 [0, 0, 15], B 1 [-1, -1, 120], B 2 [-1, -2, 120] ]: Logcká funkce F 0 = 15 odpovídá y 0,k = NOT(y 0+0,k-1 ), Logcká funkce F 1 = 120 odpovídá y 1,k = XOR(AND(y 1-1,k-1, y 1-1,k-1 ), y 1,k-1 ), Logcká funkce F 2 = 120 odpovídá y 2,k = XOR(AND(y 2-1,k-1, y 2-2,k-1 ), y 2,k-1 ). Obr Implementace 3-btového bnárního čítače nalezená ručně. Následující obrázek Obr znázorňuje několk vypočítaných kroků př provádění ručně navržené mplementace 3-btového čítače nterpretem

39 Obr Kroky 0 15 nterpretu mplementace bnárního čítače. b) Druhým příkladem je návrh 8-btového posuvného regstru. Vstupem do posuvného regstru je třetí bt bnárního čítače z předchozího příkladu. V tomto příkladu se použje 11 buněk celulárního procesoru logckých funkcí, které jsou propojeny jedna za druhou. Buňka č.3 není použta, pouze optcky odděluje čítač a posuvný regstr. Implementace nemá žádné vstupy, má pouze výstupy z čítače a z posuvného regstru kterým jsou bty čítače y 0, y 1 a y 2 a bty posuvného regstru y 4, y 5, y 6, y 7, y 8, y 9, y 10 a y 11. Na obrázku Obr je zobrazeno nastavení mplementace realzované těmto buňkam [ B 0 [a 0, b 0, F 0 ], B 1 [a 1, b 1, F 1 ], B 2 [a 2, b 2, F 2 ], B 4 [a 4, b 4, F 4 ], B 5 [a 5, b 5, F 5 ], B 6 [a 6, b 6, F 6 ], B 7 [a 7, b 7, F 7 ], B 11 [a 11, b 11, F 11 ]] = [ B 0 [0, 0, 15], B 1 [-1, -1, 120], B 2 [-1, -2, 120], B 4 [-2, -2, 232], B 5 [-1, -1, 232], B 6 [-1, -1, 232], B 7 [-1, -1, 232], B 11 [-1, -1, 232]]: Logcká funkce F 0 = 15 odpovídá y 0,k = NOT(y 0+0,k-1 ), Logcká funkce F 1 = 120 odpovídá y 1,k = XOR(AND(y 1-1,k-1, y 1-1,k-1 ), y 1,k-1 ), Logcká funkce F 2 = 120 odpovídá y 2,k = XOR(AND(y 2-1,k-1, y 2-2,k-1 ), y 2,k-1 ). Logcká funkce F 4 F 11 = 232 : y 4,k y 11,k = přepínač řízený y n,k-1 : IF(y n,k-1 = 0) : y n = AND(y n+an,k-1, y n+bn,k-1 ); ELSE y n = OR(y n+an,k-1, y n+bn,k-1 )

40 Obr Implementace 3-btového čítače a 8-btového shft regstru. Následující obrázek Obr znázorňuje několk vypočítaných kroků př provádění ručně navržené mplementace 3-btového čítače a 8-btového shft regstru nterpretem. Obr Kroky 0 15 nterpretu mplementace čítače + shft regstru. c) Třetím a posledním příkladem je návrh 8-btového posuvného regstru, který má zabudovanou zastavovací funkc. V případě, že nejvyšší bt tohoto posuvného regstru bude nastaven na 1, dojde k zastavení posuvu a regstr už potom ukazuje stále stejné hodnoty jako v mnulém cyklu. Vstupem do posuvného regstru je 3. bt bnárního čítače z předchozích příkladů. V tomto příkladu se použje také 11 buněk celulárního procesoru logckých funkcí, které jsou propojeny jedna za druhou. Buňka č. 3 není použta, pouze optcky odděluje čítač a posuvný regstr. Implementace nemá žádné vstupy, má pouze výstupy z čítače a z posuvného regstru kterým jsou bty čítače y 0, y 1 a y 2 a bty posuvného regstru y 4, y 5, y 6, y 7, y 8, y 9, y 10 a y

41 Na obrázku Obr je zobrazeno nastavení mplementace realzované těmto buňkam [ B 0 [a 0, b 0, F 0 ], B 1 [a 1, b 1, F 1 ], B 2 [a 2, b 2, F 2 ], B 4 [a 4, b 4, F 4 ], B 5 [a 5, b 5, F 5 ], B 6 [a 6, b 6, F 6 ], B 7 [a 7, b 7, F 7 ], B 11 [a 11, b 11, F 11 ]] = [ B 0 [0, 0, 15], B 1 [-1, -1, 120], B 2 [-1, -2, 120], B 4 [-2, 7, 226], B 5 [-1, 6, 226], B 6 [-1, 5, 226], B 7 [-1, 4, 226], B 11 [-1, 0, 226]]: Logcká funkce F 0 = 15 odpovídá y 0,k = NOT(y 0+0,k-1 ), Logcká funkce F 1 = 120 odpovídá y 1,k = XOR(AND(y 1-1,k-1, y 1-1,k-1 ), y 1,k-1 ), Logcká funkce F 2 = 120 odpovídá y 2,k = XOR(AND(y 2-1,k-1, y 2-2,k-1 ), y 2,k-1 ). Logcká funkce F 4 F 11 = 226 : y 4,k y 11,k = Q výstup z D flp-flopu kde WRITE = NOT(y n+bn,k-1 ); DATA = y n+an,k-1. Obr Implementace 3-btového čítače a 8-btového shft regstru se zastavovací funkcí. Následující obrázek Obr znázorňuje několk vypočítaných kroků př provádění ručně navržené mplementace 3-btového čítače a 8-btového shft regstru se zastavovací funkcí

42 Obr Kroky 0 15 nterpretu mplementace čítače + shft regstru se zastavovací funkcí. 8.5 Kontrola shody mplementace se specfkací Kontrolou shody se v kontextu mplementace myslí mechansmus porovnávání př hledání nejvyšší možné shody u nalezených mplementací porovnáním všech jejch výstupů př všech ve zdrojových elementárních specfkacích popsaných případech jednotlvých vstupů s výstupy a vstupy uvedeným v tabulkách elementárních zdrojových mplementací. Tuto shodu lze vyjádřt číselně, jako počet jednotlvých btů kdy se výstupy shodují s předlohou. Každá shoda je oceněna přčtením čísla 1 a každá neshoda přčtením čísla 0. Výsledkem je celkový počet shod, který by se během evolučních cyklů měl postupem času dopracovat až na nejvyšší možnou hodnotu. Podle toho jak rychle se během procesu genetckého programování shoda blíží cílové maxmální hodnotě, pokusí se párovací systém odhadnout, jaká stratege má být právě uplatněna pro další hledání. Podle potřeby by párovací systém měl měnt parametry hledání, jako například btovou šířku výstupní nformace - která se postupně může zvyšovat, když je hledání úspěšné, nebo snžovat pokud trvá moc dlouho. Dále lze měnt pravděpodobnost mutací hodnot popsující mplementace bnárním vektorem a pravděpodobnostní charakterstku pro selekc jednců uvntř generace. Podle rychlost hledání shody lze také měnt varanty vntřního dělení mplementací a automatcké štěpení vstupních a výstupních dat na kratší btové šířky pro vícenásobné vyhledávání menších částí jedné mplementace, které jsou pozděj opět po nalezení propojeny

43 9. Teoretcké základy genetckého programování 9.1 Hstorcké souvslost evolučních výpočetních technk V následujících odstavcích jsou shrnuty hstorcké událost, které významným způsobem přspěly k rozvoj evolučních výpočetních technk a genetckého programování z nch vycházející: 1859 Charles Darwn poprvé publkoval knhu O vznku druhů přrozeným výběrem čl zachováním vhodných odrůd v boj o žvot A.M. Turng se v esej Intelgentní stroje poprvé zmínl že... budoucí výzkum umělé ntelgence bude velm pravděpodobně spojen s prohledáváním... dále uvedl...genetcké a evoluční hledání bude zaměřeno na nalezení kombnace genů, kde krtérem bude kvalta této kombnace N.A.Barrcell (Prnceton):První reálné expermenty s evolučním prncpy na počítačích, první smulovaná evoluce Rechenberg, Schwefel a Benart vyvynul na Berlínské unverztě optmalzační metodu pro návrh převodovek, pozděj zobecněním a preczací Evoluční Stratege se zabýval H.-P. Schwefel v celé řadě prací (např. Evoluton and Optmum Seekng ) Lawrence Fogel: Evoluční Programování. Cílem bylo evolučním postupem odvodt chování konečného automatu ve smyslu schopnost určt změny prostředí, v němž se automat nachází. Prostředí bylo popsáno jako posloupnost symbolů z konečné abecedy a evoluční algortmus měl na výstupu automatu předpovědět další očekávaný symbol této posloupnost (Evolvng Artfcal Intellgence), 1994 (IEEE Transactons on Neural Networks, specal ssue on Evolutonary Computaton) zobecněno synem Davdem Fogelem na numercké optmalzační problémy John Holland (Adaptaton n Natural and Artfcal Systems): Amercký teoretcký bolog vydává knhu která položla základ genetckým

44 algortmům, kde se snaží algortmcky odpovědět na otázku...proč se navzájem lší jednc patřící k témuž bologckému druhu? Davd Goldberg (Genetc Algorthms n Search, Optmalzaton and Machne Learnng): Genetcké algortmy systematcky studovány z pohledu technckého, snažící se chápat genetcké algortmy jako technku obecně aplkovatelnou na šrokou třídu úloh. 1992, 1994 John Koza (Genetc Programmng, Genetc Programmng 2): Zakladatel genetckého programování Zbgnew Mchalewcz (Genetc Algorthms + Data Structures = Evoluton Programs ): Jedním z původců výrazných modfkací klasckých genetckých algortmů tak jak je představl J. Holland a rozpracoval D. Goldberg. 9.2 Základní rozdělení optmalzačních metod U genetckého programování a genetckých algortmů se jedná o řešení optmalzačních úloh, kde se provádí prohledávání stavového prostoru, které vede k takovému nastavení parametrů určté funkce, nebo algortmu, že se jejch výsledek, nebo chování blíží co nejvíce k žádanému optmu, nebo přímo optma dosáhne. V našem případě dosažení optma odpovídá nalezení mplementace shodující se se svou zdrojovou specfkací ve všech jejích bodech. 9.3 Evoluční výpočetní technky Nadřazená třída, do které genetcké programování přísluší, se nazývá Evoluční výpočetní technky (EVT), které se dále dělí na [14] (strana 39): Evoluční stratege - optmalzační úlohy s mutacem a křížením, Evoluční programování - konečné automaty, žádné křížení, 1 potomek, Genetcké algortmy - kódování chromozomy, posloupnost symbolů, Genetcké programování - automatzované generování programů. Obvyklé metody prohledávání stavového prostoru jsou založeny na těchto strategích [11] (strana 118): Dostatečně malý stavový prostor - lze jej prohledat úplně a beze zbytku a obvykle po uplynutí určté doby a př vynaložení přměřeného úslí bezpečně nalezneme žádané optmum hrubou slou

45 Rozsáhlé stavové prostory - řešení nelze najít hrubou slou v rozumném čase a s přměřeně vynaloženým úslím. Je nutno prohledávat heurstckým č znalostně řízeným metodam umělé ntelgence. Nasazení evolučních výpočetních technk se využívá, když velkost stavového prostoru hledaného řešení se nachází mez těmto dvěma extrémy a jsou to zpravdla stochastcké algortmy, jejchž prohledávací schopnost je posílena modelováním genetcké dědčnost a Darwnovským zápasem o přežtí [11] (strana 118). Př užtí evolučních výpočetních technk je tedy zřejmá nsprace přírodním výběrem, kde jednotlvé druhy během procesu přrozené evoluce bojují o své přežtí a o účast v dalším soutěžení s ostatním konkurenčním druhy. Podobnost s přírodní evolucí je tedy zřejmá v tom, že v tomto případě jednotlvá nalezená řešení daného problému také podstupují selekc dle určtých, předem stanovených krtérí. Př porovnání s jným nalezeným řešení, která splňují tato krtéra více než jná, nebo která dosáhnou větší shody s hledaným optmem se ta nevhodná vyřazují z dalšího procesu výběru a tak lze po uplynutí jstého počtu evolučních cyklů dospět k hledanému optmu, nebo se mu alespoň s dostatečnou požadovanou přesností přblížt. Obecný postup hledání optma u EVT [11] (strana 118): Tradční optmalzační metody vycházejí ze vhodného (nebo náhodně zvoleného) počátečního odhadu řešení, které teratvně vylepšují. EVT nepracují s jedním kanddátem řešení daného problému, nýbrž s jejch množnam, populacem jednců kanddátů na optmální řešení. Evoluce probíhá v dskrétních krocích a vznká posloupnost populací, zpravdla nazývaná generacem. Každý člen populace (každý jednec) je reprezentován stejnou datovou strukturou, ale s různým nastavením parametrů a jeho schopnost přblížt se optmu je ohodnocena krterální funkcí - vypočítá se jeho kvalta ( ftness ). Provede se statstcké vyhodnocení kvalty všech jednců, na jehož základě dojde k selekc, obvykle pomocí pravděpodobnostního mechansmu, přčemž u jednců s vyšší kvaltou je vyšší pravděpodobnost že postoupí do dalšího kola evoluce. Výsledek statstckého vyhodnocení kvalty bývá rovněž použt k rozhodování, zda je nutné dále v evoluc pokračovat, jestl výsledná kvalta jednců je dostačující a zda hledané optmum bylo dosaženo. Na jednce, kteří prošl procesem selekce (ostatní byl odstraněn z populace), jsou uplatňovány operátory změny parametrů. Tyto se poté realzují s určtou pravděpodobností a v různém rozsahu. Slučováním dvou, nebo více různých jednců jsou generován jednc noví, kdy krtérem pro jejch kombnování bývá jejch kvalta nebo určté žádané vlastnost. Tto nový jednc obvykle doplní dříve vznklou mezeru v populac. Nejrozšířenější jsou tyto vývojové stratege u EVT [11] (strana 120): Generační: Úplná náhrada jedné populace populací následující (analoge žvotního cyklu jednoletých rostln)

46 Postupné: Změny podstupuje jen malá část populace a rodče koexstují se svým potomky (déle žjící organsmy nebo víceleté rostlny). 9.4 Genetcké algortmy - základní nformace Základní termnologe (původem z bologe) [13] (strana 20 21): Indvduum fenotyp, Reprezentace ndvdua - genotyp (skupna chromozomů), Zjedodušení pro GA: Pouze jeden chromozom (= celý genotyp), Chromozom se dělí na jednotlvé lneárně uspořádané geny, Genetcké algortmy mají chromozom kódován jako posloupnost symbolů, Různé stavy jednoho genu alely: jsou to bnární stavy, decmální stavy, nebo hexadecmální stavy, Různé vlastnost nebo parametry (např. barva, typ zakřvení, délka, apod.), Nejjednodušší a nejstarší typ kódování chromozomu u GA je bnární kódování = sekvence btů. V jednoduchém příkladě na Obr , účelová funkce je reprezentována počtem btů 1 (žádané optmum je jednec s co nejvyšším počtem btů 1) [13] (strana 21). Vhodnost (ftness) [14] (strana 174): Obr Ohodnocení dle účelové funkce Obvykle je to přetransformovaná hodnota účelové funkce. Používá se pro výběr rodčů. Obvykle je to funkce v níž se hledá maxmum: pro nd1, nd 2 R, f ( nd1) f ( nd2) F( nd1) F( nd2), (9.4.1) kde nd je jednec z populace (ndvduum), f účelová funkce, F funkce počítající vhodnost. Transformace vhodnost do normalzovaného tvaru: F( nd ) F f max mn ) mn mn max max = f ( nd +, (9.4.2) mn F f max f F f mn f f kde f max je maxmální hodnota účelové funkce, f mn je mnmální hodnota účelové funkce, F max je maxmální hodnota vhodnost, F mn je mnmální hodnota vhodnost, f(nd) je hodnota účelové funkce aktvního jednce, F(nd) je vhodnost aktvního jednce. max F

47 Vhodnost je v ntervalu [0,1], musíme tedy dosadt za F max hodnotu 1 a za F mn malé kladné číslo blízké nule (kvůl dělení). Po dosazení hodnot do vztahu získáme: 1 F( nd ) = [( 1 ε ) f ( nd ) + fmnε fmax ], (9.4.3) f f mn max kde f max je maxmální hodnota účelové funkce, f mn je mnmální hodnota účelové funkce, f(nd) je hodnota účelové funkce aktvního jednce, F(nd) je vhodnost aktvního jednce, ɛ je malé kladné číslo. Rovnce přerozděluje hodnoty účelových funkcí lneárně do ntervalu [0,1], tedy největší hodnotě účelové funcke (maxmu) se přřadí hodnota 1 a nejmenší hodnotě (mnmu) 0, respektvě malé kladné číslo. Další procesy na kterých je genetcký algortmus založen [13] (strana 21 25): Přrozený výběr: Nejrozšířenější mplementací přrozeného výběru je takzvané Ruletové kolo. Jedncům s vyšším ohodnocením je na ruletovém kole přřazena větší výseč a exstuje tedy vyšší pravděpodobnost, že př pomyslném roztočení rulety se kulčka zastaví na výseč s kvaltnějším ndvduem. Potom pravděpodobnost, s jakou bude - tý jednec vybrán, odpovídá velkost jeho kruhové výseče. Křížení: Bod křížení musí být určen náhodným přrozeným číslem z množny {1,.., d-1}, kde d je délka chromozomu. Mutace: Operátor mutace s relatvně malou pravděpodobností mění hodnotu jednotlvých genů. Nová populace: Př použtí Generační stratege pro vytváření nové populace stará populace P(0) ztratí jakýkolv význam, vymře a je nahrazena populací novou P(1). 9.5 Genetcké algortmy - shrnutí Genetcký algortmus je založen na těchto prncpech: Algortmus pracuje s populací ndvduí, jež je obvykle ncalzována zcela náhodně. Každé ndvduum reprezentuje skrze vhodně zvolené kódování jedno potencální řešení daného problému. Každému ndvduu je přřazeno ohodnocení (ftness). Indvdua jsou vybírána k další reprodukc náhodně tak, že pravděpodobnost výběru každého ndvdua je úměrná jeho ohodnocení. Aplkací různých sexuálních (křížení) a asexuálních (mutace) genetckých operátorů jsou produkována nová ndvdua, tedy nová potencální řešení daného problému

48 9.6 Genetcké programování Základní pops [13] (strana 123): Genetcké programování lze považovat za rozšíření genetckých algortmů. Chromozomy zde nejsou řetězce pevné délky, ale hearchcky strukturované počítačové programy. Tyto programy po spuštění mohou představovat potencální řešení problému. Výsledkem evolučního procesu je tedy program, který řeší (nebo přblžně řeší) konkrétní problém. Výsledný algortmus (program) je zapsán specálním, pro účely genetckého programování navrženým jazykem, který je koncpován tak aby bylo možno s jeho stavebním bloky (programovým kroky) jednoduše manpulovat a provádět automatcké operace řízené evolučním procesem. Typy problémů, které je vhodné řešt s pomocí genetckých algortmů jsou přehledně shrnuty v tabulce Tab [12] (strana 129). Tab Přehled úloh u kterých je vhodné pro řešení použít genetcké programování Úloha Hledaný algortmus Vstup Výstup 1. ndukce analytcký předps Index element posloupnost posloupnost 2. symbolcká matematcký výraz nezávslé závslé proměnné regrese množny dat proměnné 3. optmální řízení řídcí stratege stavové proměnné akční velčny 4. dentfkace a matematcký nezávslé závslé proměnné predkce model systému proměnné 5. klasfkace rozhodovací strom hodnoty atrbutů přřazení do třídy 6. učení se cílenému ndvduálnímu chování program popsující chování vstupy ze senzorů akce organsmu 7. odvození kolektvního chování program popsující chování jednce nformace o vztahu jednce ke zbytku kolektvu akce jednce v kolektvu Požadavky na použtý jazyk pro genetcké programování [13] (strana 124): Herarchcká struktura (syntaktcké stromy). Syntaktcká odolnost vůč mutacím a křížení. Strom se skládá z netermnálů (funkcí) a termnálů (proměnných a konstant). Počet hran vycházejících z každého uzlu, který odpovídá nějaké funkc f z množny F, je určen artou této funkce (počtem argumentů)

49 Množna funkcí F a množna termnálů T musí být defnovány tak, že budou splňovat požadavky uzavřenost a postačtelnost. Uzavřenost: Funkce nesmí způsobt chybu programu, když se objeví nedovolená operace (např. dělení nulou), mezní stavy musí být dostatečně ošetřeny. Postačtelnost: Dobré porozumění problému je nutné k použtí takové množny funkcí a termnálů, které ve své kombnac a struktuře mohou popsat hledané cílové řešení (nelehký požadavek), jnak není možné nalézt cílové řešení. Některá řešení vyžadují přítomnost cyklů, zde je nutno je použít. Někdy je vhodné obohatt množnu termnálů o náhodnou konstantu, která se vypočítá v okamžku kdy je použta. Jazyk by měl být co nejjednodušší, mít co nejméně prvků množn F a T (rychlost). Obr Dva příklady syntaktckých stromů [13] (strana 124, 125) Generování počáteční populace [13] (strana 127, 128): Náhodná selekce funkcí a termnálů z množn F a T, které jsou propojovány do náhodných syntaktckých stromů. Začíná operátor, následují jeho operandy. Dvě metody omezení velkost syntaktckého stromu: úplná a růstová Úplná metoda: Všechny větve mají mít maxmální předepsanou délku (hloubku). Termnály se generují až po dosažení této délky. Růstová metoda: Vybírají se náhodně termnály nebo funkce, ale jakmle je vybrán termnál, větev se považuje jž za ukončenou. V prax se doporučuje kombnovat obě metody půl na půl. Polovnu populace generovat úplnou metodou a polovnu populace růstovou metodou. => Rozmantost Je třeba stanovt způsob hodnocení kvalty jednců. Blíží se program hledanému řešení a pokud ano, tak o kolk lépe nebo o kolk hůře než jné varanty v populac? Během průběhu genetckého programování se užívají tyto genetcké operátory [13] (strana 131):

50 Mutace uzlová: Nahrazuje netermnální uzel netermnálem se stejným počtem argumentů, nebo termnální uzel jným termnálem. Mutace vyzvedávající: Nahradí celý syntaktcký strom některým z jeho podstromů. Mutace smršťující: Nahrazuje náhodně zvolený podstrom jedným termnálem. Permutace: Prohazování operandů, změna pořadí. Edtace: Zjednodušování stromů, využtí známých pravdel, které redukují nadbytečné struktury. Zapouzdření: Modularta, tvorba podprogramů. Užtečné část stromu jsou zapouzdřeny a je na ně odkazováno na jných místech stromu. Současně jsou tyto část chráněny před změnam. Decmace: Způsob jak zmenšt přílš rozsáhlé populace, které zpomalují evoluční cyklus. Zvýšený tlak na vyřazování jednců, spouštěný určtou podmínkou (podle velkost populace, apod.)

51 10. Aplkace GenAlg 10.1 Aplkace pro realzac párovacího systému Párovací systém je ve své podstatě založen na vyhledávání mplementací pomocí genetckého programování porovnáváním této mplementace se svou zdrojovou specfkací tak dlouho, dokud se neshodují. V rámc této práce byl vyvnut program GenAlg jehož úkolem je provádět stejnou operac jakou by měl v operačním systému nové generace vykonávat párovací systém. Genetcké programování je založeno na mnohonásobném opakování cyklů programového kódu, takže jeho výsledná výkonnost a mnohdy použtelnost závsí na tom, jak úsporně je kód naprogramován. Čím méně programových nstrukcí bude v hlavním cyklu prováděno, tím lépe. Př běhu aplkace se ve velké míře operuje hlavně s elementárním jednotkam nformace jednotlvým bty a spolu s požadavkem na nejvyšší možnou dosažtelnou rychlost a úspornost prováděného programu tedy platí, že nejvhodnějším programovacím jazykem je v tomto případě právě assemblerový kód, který se v prax používá hlavně na časově a výkonově krtcké procesy (což je tento případ). Pro tyto účely byl zvolen vývojový nástroj MASM32 SDK V10 pro CPU x86 v grafckém prostředí Wn32API, což zaručuje dobrou kompatbltu s rodnou 32btových operačních systémů Mcrosoft Wndows [18]. Současná verze programu GenAlg je však odladěna pro chod v operačním systému Wndows 7 (pravděpodobně pro Wndows Vsta). Je známo, že ve starším operačním systému Wndows XP neběží program spolehlvě. Nekompatblta s Wndows XP byla zjštěna až pozděj a není v současné době smysluplné provést odladění pro Wndows XP. Důvodem je, že samotný běh programu GenAlg a párování mplementací se specfkacem je časově a výkonově náročné. Většna výkonově dostatečných počítačů jž novější Wndows 7 obsahuje a na starších počítačích by program stejně kvůl pomalému hledání nemělo smysl spouštět. Pro spouštění programu GenAlg by měl být použt počítač, který má procesor výkonově odpovídající alespoň procesoru Intel Core 5. Doporučuje se však výkonnější procesor, jako například nejnovější procesor Intel Core 7 s archtekturou Ivy Brdge (leden 2013). Tento procesor byl rovněž použt pro vývoj programu a pro následné získávání zkušeností př prác na příkladech evolučním procesem nalezených mplementací

52 10.2 Vzhled a ovládání aplkace V této kaptole se seznámíme se základním popsem aplkace GenAlg s ohledem na její vzhled a způsob jakým se aplkace používá. Aplkace se spouští spusttelným souborem GenAlg.exe a pro její běh se doporučuje použít operační systém Wndows 7, neboť zde byla aplkace odlaďována a nelze zaručt, že bude bez problémů fungovat jnde. Po spuštění aplkace jsou v hlavním menu dostupné tyto položky: Generaton o New o Open o Save as... o Save o Randomze o Close Evoluton Help Qut o Load Defnton o Show evoluton : obsahuje operace které se provádějí s generacem všech 8m paralelních evolucí : vytvoř novou sadu 8m generací : otevř soubor *.gen s uloženým generacem : ulož generace do souboru *.gen dle výběru : ulož generace do aktuálního souboru *.gen : naplň generace náhodným obsahem : zavř generace a vymaž je z pamět : obsahuje operace prováděné s evolucem : načt defnc/specfkac hledané funkce *.fdf : otevře, nebo zobrazí okno s aktuální evolucí : otevře okno se stručným popsem programu : ukončení aplkace, zavřou se všechna okna Obr Vzhled aplkace po spuštění a menu pro operace s generacem Na obrázcích Obr jsou zachyceny stuace během ovládání aplkace. Po spuštění můžeme vytvořt novou sadu 8m generací položkou New z nabídky Generaton, nebo otevřít generace jž exstující v souborech typu *.gen

53 pomocí položky Open. Po nastavení parametrů generací výběrem počtu mplementací (vektorů) a počtu buněk v každé mplementac (přměřených výsledků dosahováno s nastavením 2000 vektorů a 64 buněk) se doporučuje použít funkc Randomze, která naplní všechny buňky všech mplementací u všech 8m generací náhodným obsahem, ze kterého se během evoluce bude vycházet. Obr Vytvoření nové generace po výběru New z menu Generaton Obr Nová generace byla vytvořena s vyobrazeným parametry Po přípravě generací nahrajeme do aplkace *.fdf soubor, který musíme mít předem přpravený a který obsahuje defnc (specfkac) funkce (mplementace), použté k hledání algortmu evolučním procesem. Pozděj nalezená mplementace musí tuto defnc splňovat. Po otevření defnce se vypočítá nejvyšší možná shoda kterou lze během evolučního procesu dosáhnout (Maxmum ftness) a naplní se údaje o počtu vstupních a výstupních bajtů a počtu všech případů v defnc (Number of cases)

54 Obr Ukázka nabídky z menu Evoluton před nahráním specfkace Obr Ukázka nabídky z menu Evoluton po nahrání specfkace Nyní je jž možné otevřít okno evolučního procesu a po jeho otevření se zobrazí přehled všech 8m generací a u každé z nch je uveden seznam všech jejch aktuálních mplementací. U téhož okna jsou dostupné další ovládací prvky s kterým je možné spouštět (RUN), pozastavt (PAUSE), nebo zcela zastavt (STOP) evoluční děj. Pokud je evoluce zastavena, vhodnou manpulací s posuvným ovládacím prvky vpravo dole lze měnt parametry pro následně spouštěnou evoluc: p-sel. p-add. p-xor. : Lze nastavt pravděpodobnost přežtí jednců během evolučních cyklů. Touto hodnotou je násobena selekční charakterstka. : Nastavuje pravděpodobnost výskytu adtvní mutace v každé buňce během reprodukce. Jde o náhodné přčtení jednoho btu. : Nastavuje pravděpodobnost výskytu xorové mutace v každé buňce během reprodukce. Jde o náhodný xor jedním btem

55 Obr Ukázka okna evoluce potom co byly nastaveny všechny parametry Tlačítkem Cells+1 vpravo nahoře lze zvýšt počet buněk ve všech mplementacích, ale jen pokud je evoluční proces momentálně zastaven tlačítkem STOP. Po použtí tlačítka Cells+1 bude na náhodnou pozc uvntř všech mplementací vložena buňka s náhodným obsahem. Doporučuje se toto tlačítko používat s rozvahou, protože v současné verz aplkace je tento proces nevratný a tuto přdanou buňku jž nelze pozděj odstrant, an není možné jným způsobem počet buněk snžovat. Rovněž se nedoporučuje přdávat v jednom okamžku více než jednu buňku, protože př každém použtí dochází k velkým změnám v aktuálním rozložení buněk všech mplementací a v obsahu původně v seznamu blízkých a velm podobných mplementací. Po dalším spuštění evolučního procesu je vhodné nechat evoluc chvíl běžet, než přkročíme k přdání další buňky, aby se meztím sthlo rozložení vůč sobě podobných mplementací opět ustált. Do jsté míry vůč sobě podobné mplementace jsou důležté proto, aby byla možná jejch reprodukce, jnak dochází k degradac a vznkají produkty s horší kvaltou než byly jejch rodče. Tato stuace může přechodně po přdání buňky nastat, ale obvykle se generace brzy opět z tohoto šoku vzpamatuje. Přdání buňky lze také provést v případě pokud máme poct, že evoluce delší dobu stagnuje a že se dále nevyvíjí. Docílíme tak postrčení k lepším výsledkům za cenu přechodného zhoršení, které ale většnou brzy vymzí. Další parametry které výrazně ovlvňují průběh běžící evoluce jsou počty kroků předpokládaného přechodného děje (Unstable steps) a ustáleného stavu (Stable steps). Tyto kroky se vztahují k ohodnocování kvalty jednotlvých mplementací, kdy se testuje každá z defnc uvedených v souboru *.fdf a vypočítává se počet shod aktuálních výstupů s očekávaným výstupy. Během přechodného děje se nepočítají shody (až na poslední krok této fáze), ale až během kroků ustáleného stavu. Nejnžší počet kroků který lze nastavt u přechodného děje je číslo 2, kdy se potom ohodnocují vlastně všechny kroky, kromě prvního (a druhého po něm) kroku, u

56 kterého jsou výstupy všech buněk nastaveny na nulu a který je výchozím krokem po resetu všech buněk. Další parametr který lze nastavt, je maska bnárních výstupů (Output mask), která uvádí nformac o tom, jaké bnární výstupy se mají zahrnout pro aktuální výpočet shody. Pro aktvac změny lbovolného parametru je nutné použít tlačítko Refresh ftness, které slouží pro výpočet nového čísla nejvyšší možné shody (Maxmum ftness) a které automatcky upraví podle nového nastavení parametry v dříve nahrané defnc *.fdf, ale pouze v defnc nahrané v pamět (se souborem na dsku se nemanpuluje). Po změně parametrů lze opět spustt evoluční proces tlačítkem RUN (nebo PAUSE pokud byl proces jen pozastaven), který už používá nové nastavení. Zde následují doporučené hodnoty pro nastavení masky bnárních výstupů: : používá se pouze první bnární výstup y 0 (poslední buňka v mplementac) : bnární výstupy y 0 a y 1 (poslední 2 buňky v mplementac) : bnární výstupy y 0, y 1 a y 2 (poslední 3 buňky v mplementac) : bnární výstupy y 0, y 1, y 2 a y 3 (poslední 4 buňky v mplementac) : bnární výstupy y 0, y 1, y 2, y 3 a y 4 (posledních 5 buňek v mplementac) 63, 127, 255, 511, 1023, 2047, 4095, : Obdobným způsobem lze přdávat další výstupy, musí být ale splněna podmínka že s nm původní defnce počítala - nelze přdat více výstupů než původně v defnc exstovalo. Výstupy musí jít také po sobě, aplkace nepočítá s vynecháním výstupu uvntř mez několka jným. Pokud je evoluce zastavena, nebo pozastavena, je možné dvojtým klknutím vybírat lbovolné mplementace z lbovolné z 8m generací což se projeví změnou čísel u Selected Vector a Ev.. Následně tlačítkem Export vygenerujeme soubor out.txt, který by měl být k nalezení ve stejném adresář, odkud jsme naposledy prováděl nahrání souborů *.gen nebo souboru *.fdf. Pozor, pokud se nacházíte na nějakém datovém méd, které není určeno pro záps (např. CD-ROM), soubor out.txt vygenerovat nelze. Soubor *.fdf se musí pak zkopírovat například na pevný dsk a odtud musí být znovu otevřen aby bylo možné do stejného adresáře generovat soubory out.txt. Soubor out.txt obsahuje veškeré nformace o vybrané mplementac a je možné jej otevřít v lbovolném textovém edtoru. Na začátku souboru je vypsán obsah všech buněk celé mplementace, potom následují všechny defnce a jejch souvsející prováděné kroky včetně přechodných a těch ustálených z kterých se vypočítává vhodnost (ftness). Lze zkoumat výstupy všech buněk ve všech krocích a po pravé straně nalezneme vyhodnocení shody pomocí znaku. - shoda a znaku X - neshoda. Pozor, statstka shod a neshod je vyobrazena zrcadlově vůč výstupním buňkám v mplementac, takže první výstupní buňka y 0 (v mplementac ta poslední uplně napravo) je vyhodnocena hned sousedním znakem. U výstupů postupujeme zprava doleva a u jejch statstky zleva doprava. Na úplném konc souboru je zapsán

57 aktuální součet všech shod a hned vedle něj za znakem / je uveden nejvyšší možný dosažtelný součet všech shod. Pokud se obě čísla shodují, cílová mplementace byla nalezena a evoluční proces je možné ukončt. Obr Ukázka okna evoluce která byla spuštěna a momentálně běží Výpsy všech mplementací u jednotlvých generací obsahují nformac o jejch pořadovém čísle, dále za :: následuje číselný kód 10 (rodč1), 9 (rodč2 nebo nepoužt pro reprodukc), 5 (potomek1), 6 (potomek2) nebo 0 (vyřazen z evoluce) upřesňující jejch poslední status který získal př selekc, nebo př reprodukc. Nakonec za : je uvedeno jejch vypočítané číslo shody, které lze brát v potaz jen u jednců s kódem 10 nebo 9 protože u ostatních toto číslo už neplatí a musí se vypočítat nové (Výpočet probíhá na začátku cyklu, po reprodukc kde se právě nacházíme, se už znovu nepočítá). Na závěr popsu je dobré se zmínt o nformac u Current best ftness a Cycles passed. První nformace uvádí aktuálně nejvyšší dosaženou shodu, ale pozor, toto číslo je vzato pouze z první generace, v jné z ostatních 7m generací může být v tu chvíl nalezena ještě vyšší shoda. Cycles passed uvádí kolk evolučních cyklů uběhlo od posledního stštěného tlačítka RUN a smaže se na nulu kdykolv se zmáčkne tlačítko STOP a potom nový RUN. Pozor toto číslo se vztahuje opět pouze k první evoluc, neboť všechny paralelně běžící evoluce běží asynchronně a některé z nch mohou být rychlejší, jné pomalejší podle aktuální náročnost a vytíženost procesu. Př používání tlačítek pro zastavení, nebo pozastavení běhu evoluce je nutné chvíl počkat než se zastaví všech 8 paralelně běžcích evolucí, které běž zcela nezávsle a můžeme je tedy zasthnout v lbovolné z jejch fází. Dokud se všechny evoluční procesy nezastaví, nelze provádět žádnou další akc, což je poznat podle toho, že jsou tlačítka nedostupná pro jakoukolv manpulac

58 Po dosažení počtu cyklů rovno 207, nebo 353 a jejch dalších násobků (čísla jsou v aplkac nastavena napevno a jejch velkost není blíže zdůvodněna, byla jen zvolena tak aby uběhl rozumný počet cyklů) se automatcky proces evoluce pozastaví na krátkou chvíl a provede promíchání jednců mez paralelním generacem a nakonec vypíše sám aktuální nformace o všech mplementacích. Je zde potom k vdění jak byly generace mez sebou promíchány (podle uvedených aktuálních nformací o mplementacích). Dále se obnoví proces evoluce, která pokračuje dál podobně jako před chvílí, ale jž s promíchaným jednc napříč generacem. Vzhledem k tomu, že př složtějších problémech evoluční proces může v současné verz aplkace běžet velce dlouho (řádově dny), nemá zatím smysl aby aplkace kontrolovala sama dosažení nejvyšší shody mplementace se specfkací. Proto zastavení je v současné verz řešeno pouze tak, že evoluc zastaví sám užvatel. Užvatel má mnoho příležtostí občas nahlédnout na aktuální stav, případně aplkac pozastavt a ověřt s jaké shody jž bylo dosaženo u jednotlvých vybraných mplementací, včetně kontroly shody souborem out.txt. Poté může užvatel lbovolně měnt parametry, kdyby evoluce vykazovala známky stagnace, nebo jnak zasahovat do evolučního procesu. Pro jednoduché problémy nejsou zásahy užvatele přílš potřeba, pro řešení složtějších problémů je však lepší užvatelův aktvní přístup. Ten může v průběhu podle potřeby měnt parametry evoluce, nebo například přdávat buňky kdyby se zdálo že jch bylo na začátku zvoleno málo. V opačném případě by aplkace musela sama sledovat statstku procesu a autonomně s měnt sama sobě parametry podle toho jestl evoluce pokračuje vhodným tempem, nebo stagnuje. Toto by mohlo být však předmětem nějaké pokročlejší verze této aplkace, neboť toto není zcela jednoduchý problém a jeho řešení zde nebylo zahrnuto

59 10.3 Pops datových formátů Tato kaptola se zaměřuje na pops datových formátů se kterým pracuje program GenAlg. Během provozu programu se používají pouze tyto dva datové formáty (typy souborů): Soubor zdrojové elementární specfkace *.fdf (Functon Defnton Fle): Soubor slouží pro hledání cílové mplementace. Soubor je bnárního typu a obsahuje pops hledané funkce formou sady požadovaných vstupů (bnární masky + hodnoty na vstupech) a k nm očekávaných výstupů (bnární masky + hodnoty na výstupech). Je popsáno dynamcké chování během výpočtu vhodnost nalezené mplementace: Kdy se má obsah buněk resetovat (zpravdla před nesledovaným kroky přechodného děje), kolk teračních kroků se má provést, kde nejsou sledovány výstupy (není vypočítávána vhodnost) a kolk se jch má provést kde se výstupy už sledují (provádí se součet všech shod specfkace s mplementací). Soubor generací *.gen (Generaton fle): V kterékolv fáz hledání cílové mplementace lze po zastavení evolučního procesu uložt formou generací všechny v tu chvíl nalezené mplementace do jednoho souboru. Tento soubor lze pozděj opět kdykolv nahrát zpět do programu a pracovat s jeho nalezeným mplementacem. Soubor je bnárního typu a kromě hlavček, které popsují všechny parametry každé z generací, soubor obsahuje obsah všech 8m paralelních generací z 8m souběžně běžících evolučních procesů. Každá z nalezených mplementací uvntř generací je bnárním vektorem, kdy každý má sám svou vlastní hlavčku a tělo a jsou v souboru umístěny jeden za druhým

60 pozce bajtů v souboru Tab Formát bnárního souboru pro pops hledaných algortmů *.fdf část souboru hlavčka *.fdf souboru počet bajtů položka struktury standardní hodnota 4 velkost hlavčky ukazatel na data v pamět (nedůležté) sgnatura souboru pro kontrolu ntegrty "jgoewue u32hjgfpbvch" 36, 37 2 počet všech defnc= sledované kroky + nesledované kroky , 39 2 počet vstupních bajtů počet výstupních bajtů (v současné době se 40, 41 2 doporučují maxmálně dva) první defnce páru vstup/výstup pro nesledované kroky s resetem všech buněk na začátku 1 externí dll soubor pro rozšíření programu def_ft_calc.dll,0, (není používán, musí být defaultní jméno) 0,0,0,0,0,0,0,0,0,0,0,0,0 vypočítaný počet shod (dobrovolné, není nutno nastavovat) 0.. 2^32-1 sledované (stablní) kroky * (+1: reset všech buněk, +0: žádný reset na začátku) počet kroků zde vždy 1 => 1 * = 3 vždy maska prvních 8m vstupů bnárních vstupů x0.. x (79) (1) (voltelná maska dalších 8m vstupů) ( ) (80) (1) (voltelně dalších 8 bnárních vstupů x8.. x15) ( ) 79, 80 2 počet nesledovaných (nestablních) kroků, musí být větší než nula , 82 2 rezervováno, vždy maska prvních 8m výstupů bnárních výstupů y0.. y (85) (1) (voltelná maska dalších 8m výstupů) ( ) (86) (1) (voltelně dalších 8 bnárních výstupů y8.. y15) ( ) sledované (stablní) kroky * (není reset všech buněk) 85 1 počet kroků musí být větší než nula sudá čísla > 0 maska prvních 8m vstupů 86 1 (stejná jako předchozí pro nesledované kroky) bnárních vstupů x0.. x (stejné jako předchozí pro nesledované kroky) první defnce páru vstup/výstup pro sledované kroky bez resetu (88) (1) (voltelná maska dalších 8m vstupů) ( ) (89) (1) (voltelně dalších 8 bnárních vstupů x8.. x15) ( ) 88, 89 2 počet nesledovaných (nestablních) kroků, zde rovno jedné 1 90, 91 2 rezervováno, vždy maska prvních 8m výstupů bnárních výstupů y0.. y (94) (1) (voltelná maska dalších 8m výstupů) ( ) (95) (1) (voltelně dalších 8 bnárních výstupů y8.. y15) ( ) Sekvence dalších defnc složené z 94.. párů nesledovaných a sledovaných kroků. n Nmax Každý pár má v první defnc reset (sgnalzuje číslo 3). další defnce

61 pozce bajtů v souboru Tab Formát bnárního souboru Generací nalezených mplementací *.gen část souboru hlavčka *.gen souboru počet bajtů položka struktury standardní hodnota 4 velkost hlavčky ukazatel na data v pamět (nedůležté, lze 0)? sgnatura souboru pro kontrolu ntegrty "jfweouwe dshfoowgdw" počet všech mplementací v jedné generac 1.. 2^ počet všech buněk v jedné mplementac 1.. 2^32-1 velkost hlavčky mplementace (bnárního vektoru) hlavčka první mplementace 4 ukazatel na data v pamět (nedůležté, lze 0)? rezervováno 27* bajt počet bajtů kolk zabírá jedna buňka počet všech buněk v této mplementac 1.. 2^ poslední status který mplementace nabyla 10 rodč1 9 rodč2 nebo nepoužt 5 potomek1 6 potomek2 0 neprošel selekcí a nepoužt 85 1 btová maska omezující ukazatele buněk A a B ftness 4 poslední spočítaná shoda (ftness, vhodnost) 1.. 2^ první buňka první mplementace (94) další buňky první mplementace 1 rel. Adresa B: funkce Fn: mnulá hodnota y B2, B1, B0; F3, F2, F1, F0; y_ rel. Adresa B vyšší část: B10, B9, B8, B7, B6, B5, B4, B rel. Adresa A: funkce Fn: aktuální hodnota y A2, A1, A0; F7, F6, F5, F4; y rel. Adresa A vyšší část: A10, A9, A8, A7, A6, A5, A4, A (1) ( ) (95) (1) ( ) (96) (1) ( ) (97) (1) ( ) ( n * 4) (n=počet buněk) ( n * ) (n=počet buněk) hlavčka další mplementace + ftness buňky další mplementace 46 n * 4 Následuje 7 dalších generací se stejnou strukturou jakou měla první generace až sem, včetně všech hlavček. Všech 8 generací zabírá 8 *(43 + m *( n*4)) bajtů, kde m= počet mplementací a n= počet buněk

62 10.4 Příprava nové specfkace V této kaptole se zaměříme na to, jakým způsobem lze přpravovat *.fdf soubory obsahující elementární specfkace nutné pro hledání mplementací. Pro co nejvyšší efektvtu celého evolučního procesu byl pro záps všech případů párů vstup/výstup, popsující hledané chování mplementace, zvolen bnární formát. Aplkace GenAlg s tento soubor načte do pamět pro své účely hledání mplementace a hned jej v této pamět používá ve stejném formátu jako byl už uložen v souboru. Dále popsaný způsob přípravy bnárního souboru samozřejmě nemusí být použt, je to pouze jedna z možností, neboť jsou jné známé způsoby jak lze vytvářet bnární soubory. Většnou se setkáváme se zápsem dat v textovém formátu k čemuž lze obvykle použít například v operačním systému Wndows známý program zápsník (notepad). Pro vytváření bnárních souborů (jako je v tomto případě soubor *.fdf), textový edtor bohužel tak snadno použít nelze. Méně zkušení užvatelé většnou nejsou schopn vytvářet bnární soubory s lbovolným obsahem (oprot textovým souborům), právě kvůl nedostupnost vhodných nástrojů. Pro účely snadné manpulace s obsahem bnárních souborů byla vytvořena jednoduchá konzolová aplkace spusttelná v operačním systému Wndows nazvaná CSV2BIN. Její prncp spočívá v tom, že s vytvoříme textový pops očekávané struktury a obsahu jaký má být s pomocí této aplkace uložen do bnárního souboru a ten pak bude aplkací vygenerován. Výhodou je hlavně to, že pro tento pops lze opět využít lbovolný textový edtor (například zápsník notepad ). Po vytvoření textového souboru s popsem obsahu bnárního souboru, tento soubor použjeme jako vstup pro program CSV2BIN zadáním následujícího řetězce na příkazové řádce operačního systému: csv2bn.exe pops.txt soubor.bn Zde pops.txt obsahuje náš textový soubor s popsem obsahu a soubor.bn bude následně vytvořen jako bnární soubor přesně s tím obsahem, jaký byl předtím popsán v textovém edtoru. Názvy souborů lze samozřejmě změnt na ty, které jsou pro nás v tu chvíl aktuální a pro bnární soubor popsující specfkac cílové mplementace bude použta koncovka *.fdf místo *.bn. Takže například nástroj pro převod spustíme takto: csv2bn.exe zdroj_specfkace_algortmu.txt specfkace.fdf Na obrázku Obr na následující straně je vyobrazeno, s pomocí jednoduchého příkladu, jaký záps pro aplkac csv2bn.exe se používá pro pops struktury obsahu bnárního souboru s použtím textového edtoru. Další obrázek Obr znázorňuje výsledný vygenerovaný bnární soubor

63 Obr Příklad popsu struktury bnárního souboru obsahující všechny možné prvky které program CSV2BIN umí rozlšt a použít v example.txt Obr Výsledný obsah bnárního souboru example.bn vygenerovaného s pomocí programu CSV2BIN použtím example.txt Jako praktcký příklad převodu specfkace popsané v textovém edtoru je na obrázku Obr uvedena specfkace algortmu pro zobrazení číselné nformace s pomocí 7m segmentů LED a na obrázku Obr je výsledný vygenerovaný *.fdf bnární soubor

64 Obr Příklad popsu struktury bnárního souboru popsující jednotlvé defnce párů vstup/výstup ve specfkac zobrazení čísel LED Obr Výsledný obsah bnárního souboru LEDnumbers.fdf vygenerovaného s pomocí programu CSV2BIN použtím textového popsu LEDnumbers.txt

65 10.5 Zkušenost s provozem aplkace a doporučení pro její provoz Během vývoje aplkace GenAlg, př jejím testování a během praktckého využtí pro přípravu vzorových příkladů bylo nashromážděno určté množství zkušeností, které jsou soustředěny v této kaptole. V současné době aplkace není schopna samostatně analyzovat průběh evolučního procesu a na základě těchto statstcky získaných údajů neumí dále sama měnt svou strateg jakým způsobem evoluce má probíhat. Tato nedokonalost vede k tomu, že u složtějších problémů, evoluční proces po nějaké době uvízne v bodě, odkud se jen obtížně sám dostává. Pokud se mu to přesto podaří, tak až po neúměrně delším čase, než př vhodné a cílené změně parametrů podle aktuálního vývoje. Ze začátku, během postupného vývoje, měla aplkace jen velm omezené možnost a an nebylo možné měnt žádné parametry, které by mohly nějakým způsobem evoluční děj ovlvnt - vše bylo nastaveno pevně. Aplkace uměla řešt jen ty nejjednoduší typy problémů a evoluční děj probíhal velm dlouho. Z toho vyplývá nejprmtvnější typ stratege která byla použta jako první, Stratege A: Nastaví se základní parametry které budou neměnné, jako jsou velkost generace a počet buněk pro každý vektor v generac Nahraje se specfkace hledané funkce *.fdf, kde jsou přednastavené parametry: parametr pro délku přechodného děje - u nějž se nesledují výstupy a parametr délky ustáleného stavu - u kterého se počíta míra shody ftness. Počet vstupů a výstupů zůstává nezměněn a maska vystupů je pevně dána. Pravděpodobnost selekce a mutací jsou pevně dané a nemění se. Spustí se evoluční proces a nechá se bežet tak dlouho, dokud vypočítaná shoda u většny jednců nedosáhne nejvyšší možné hodnoty poté užvatel celý proces zastaví. Do té doby než je proces zastaven, tak užvatel njak do běhu nezasahuje, jen občas zkontroluje jestl míra shody jž odpovídá jeho požadavkům. Strateg A lze použít spíše na řešení jednodušších problémů s menším počtem defnovaných stavů pro vstupy a výstupy ve specfkac, s menším počtem používaných vstupů, výstupů a jen s kratším bnárním vektory. I přes jednoduchost stratege se lze dopracovat k hledanému řešení s přhlédnutím k tomu že jsou zadány pouze jednodušší problémy a užvatel má mnoho času aby nechal evoluc běžet dostatečně dlouho (mohou to být dny, nebo týden). Od stratege A se odvozují další možné způsoby, jak průběh evoluce ovlvňovat a jak urychlt nalezení hledané mplementace spolu s ošetřením stavů kdy se evoluce předčasně zachytí v lokálním extrému a nechce se dále vyvíjet. Doporučuje se: Stratege B: Evoluc provést po menších krocích, kdy se před spuštěním evoluce do masky výstupů nastaví číslo 1, které znamená, že se bude hledat řešení pouze pro jeden výstup. Není potřeba nc dalšího nastavovat, nemusí se an měnt defnce *.fdf, změna má dopad pouze pro aktuální

66 stav hledání. Je zajímavé, jak se hledání pouze jednoho výstupu výrazně urychlí a pokud byl problém př plném počtu výstupů řešení nalézt, většnou bývá potom řešení pro jeden výstup nalezeno velm rychle. Po nalezení nejvyšší možné shody se přdá pro hledání další výstup s pomocí masky nastavené na číslo 3. Po každém nalezení nejvyšší shody se obdobně přdávají další výstupy pomocí masek 7, 15, 31, atd. až do nejvyšší možné masky 65535, která je použtelná pro 16 výstupů. Pro vyšší počet výstupů se už změna masky nedoporučuje používat a nelze tuto masku snadno měnt za provozu (kromě opětovného nahrávání nové *.fdf defnce). Číslo masky odpovídá vzorc m = 2 n 1, kde n odpovídá počtu výstupů. Jné hodnoty se nedoporučují protože s nm aplkace nepočítá. Pokud nastane podezření, že evoluce uvízla, je možné poslední výstup odebrat a nechat chvíl běžet evoluc bez něj a pozděj ho znovu přdat. Tím se obsah vektorů změnl a je možné že už k uvíznutí nedojde. Po přdání posledního výstupu je možné z uvízlé evoluce unknout tak, že se nastaví maska, jako bychom očekával o jeden výstup víc. Toto nelze provést, pokud máme 8 výstupů a chceme přdat devátý, nebo pokud máme 16 výstupů a chceme přdat 17tý protože by se musel nahrát jný *.fdf soubor který by s tím počítal. Hledání probíhá tak, že se na vrtuálním přdaném výstupu očekává po celou dobu číslo 0 a evoluce se pokouší takovou mplementac která to splňuje najít a dojde k promíchání obsahu hledaných vektorů. Tento postup má smysl pouze pro unknutí z uvízlého stavu a je dobré přdaný výstup opět odebrat, pokud se nám zdá že evoluce z uvíznutí unkla. Stratege C: V této strateg se počítá s postupnou změnou parametrů pravděpodobností pro selekc, pro adtvní mutac a pro xorovou mutac. Začneme s nastavením vysokých hodnot u adtvní a xorové mutace (kolem 17%) a s nastavením nízkých hodnot u pravděpodobnost selekce (kolem 57%). Dále necháme evoluční děj běžet tak dlouho, dokud se neustálí v nějakém rovnovážném stavu a kdy je zřejmé, že se už kvalta shody nezvyšuje. Obvykle to lze poznat podle toho, že nápadně u všech paralelně běžících evolucí je dosažena stejná hodnota míry shody (ftness) a tato se jž dále němění. Př dosažení rovnovážného stavu, které mohou být každý dosažen v rozmězí až několka hodn, se doporučuje snížt pravděpodobnost obou mutací o jedno procento níž a zvýšt pravděpodobnost selekce o jedno procento výš. Tímto způsobem dosáhneme vyšší shody (ftness) po dosažení dalšího rovnovážného stavu. Tento postup lze po různě dlouhých časových etapách opakovat až do dosažení pravděpodobnost mutací kolem 5% a pravděpodobnost selekce kolem 70% kdy ve většně případů jž bývá dosaženo nejvyšší možné shody (ftness). Pokud máme podezření na uvíznutí evolučního procesu, je možné změnt směr ve kterém jsme přdával nebo ubíral procenta u selekce nebo u mutací. Nezaškodí občas snížt pravděpodobnost selekce, nebo zvýšt pravděpodobnost mutací. Můžeme krátkodobě snížt míru shody (ftness), ale získáme tím únk z uvízlého evolučního procesu. Uvíznutí bývá často způsobeno přemnožením mplementací jednoho typu, kdy všechny paralelní evoluce jsou naplněny jednc, kteří s jsou vůč sobě přílš podobní. Genetcká dverzfkace je přílš nízká a evoluce dále

67 nepostupuje. Př zjštění, že došlo k přílšnému přemnožení a útlumu, pomůže krátkodobé snížení pravděpodobnost selekce a zvýšení pravděpodobnost mutací o několk procent. Tímto dojde k postupnému vymření jednců s majortním genetckým obsahem a můžeme pozděj posunout evoluční proces k lepším výsledkům. Př postupném čekání na ustálené stavy během změn pravděpodobností, není vhodné nechat běžet evoluční proces přílš dlouho bez kontroly, protože po několka hodnách, kdy už pravděpodobně evoluce byla v rozumném ustáleném stavu, dochází k přemnožení a přílšnému výskytu sobě podobných jednců. Tím se může velm vyčerpat potencál k dalšímu růstu shody. Pochoptelně by teoretcky mohlo být možné, nastavt rovnou parametry pro pravděpodobnost selekce na 70% a pravděpodobnost mutací na 5%. Je ale jsté, že celý evoluční proces bude trvat velce dlouho a pravděpodobně snadno uvízne bez dosažení nejvyšší shody. Postupná změna parametrů a dosahování ustálených stavů má tu výhodu, že na začátku př vysokých hodnotách mutací a snížené pravděpodobnost pro selekc se generuje velké množství nových jednců s různým genetckým materálem a rozsáhlé změny obsahu bnárních vektorů jsou žádoucí, protože se prohledává velká část stavového prostoru v kratším čase. Pozděj už rozsáhlé změny genetckého materálu nejsou tak žádoucí a jsou spíše na škodu. Postupujeme se stále menším úpravam, které nejsou tak nvazvní a tolk neohrožují jž nalezené struktury. Docílí se toho, že postupně dospějeme do cílového stavu kdy nalezení jednc dosáhnou nejvyšší možné shody. Stratege D: Tato stratege spočívá ve změně parametrů, které se týkají počtu kroků - defnované jako přechodný děj kdy se nesledují výstupy a počtu kroků kdy se výstupy sledují - defnované jako stálený stav kdy se vypočítává shoda. Pro většnu uvedených strategí by mělo stačt pevné nastavení těchto parametrů, které s zvolíme na začátku a dále je neměníme. Typcky používané hodnoty mohou být 10 kroků pro Unstable steps a 5, 8, nebo 10 kroků pro Stable steps. Př dosažení ustáleného stavu, kdy se zřejmě evoluce dále nevyvíjí, je možné snžovat, nebo zvyšovat počet kroků přechodného děje, což může mít vlv na aktuálně dosaženou míru shody. Pokud snžíme počet kroků a nejvyšší dosažená shoda se nezmění, je zřejmé, že jsme měl nastavenu rezervu a kroky přechodného dějě byly naddmenzované a je možno je snížt. Pokud se ale dosažená míra shody sníží, je zřejmé, že se pohybujeme na hranc přechodného děje a začínáme do něj zasahovat. Podle momentální stuace s můžeme vybrat jestl vrátíme hodnotu zpět jak byla předtím a délku přechodného děje akceptujeme, nebo se ponecháním snížené hodnoty pokusíme nalézt jné mplementace, které naopak budou založeny na kratším přechodném děj. Varanta s kratším přechodným dějem má tu výhodu, že by výsledná složtost nalezeného řešení mplementace měla být o něco snížena a efektvní počet buněk využívaných řešením by měl být lepší. Zkracováním přechodného děje se snžuje tedy počet pro řešení využívaných buněk a zjednodušené řešení umožňuje další růst během hledání shody. Př delších přechodných dějích se na výsledném chování obvykle podílí větší počet buněk. Z počátku tato varanta může pomoc k rychlejšímu nárustu shody, ale aktuální dílčí řešení vyčerpá více buněk

68 než by bylo nutno a tyto potom chybí pro další nárust shody. Je proto vhodné, pokud je to možné, délku přechodného děje snžovat aby se vyvnul tlak na zjednodušování aktuálních řešení. Samozřejmě pro ožvení evolučního vývoje může být vhodné občas toleranc pro délku přechodného děje zvýšt, pokud to pomůže dosáhnout vyšší shody, s tím že počítáme s pozdějším snížením počtu kroků přechodného děje opět tak aby se vyvnul tlak na zjednodušení nalezených řešení. Je dobré vyzkoušet extrémní případ, kdy se pro parametr Unstable steps nastaví číslo 2 a Stable steps se odpovídajícím způsobem zvýší například na 15 aby se dodržel celkový počet kroků jako byl předtím. Dosáhneme toho, že by se evoluční proces měl sám snažt o hledání řešení s co nejkratší délkou přechodného děje a díky tomu by měl využívat pro řešení co nejmenší počet buněk. Tato varanta do určté míry funguje a lze dosáhnout celkem optmálních počátečních řešení. Tyto je ale vhodnější použít spíše jako výchozí stav pro další hledání například s vyšším počtem výstupů, kdy první výstupy byly hledány s krátkým přechodným dějem a u dalších přdaných výstupů se přechodné děje prodlužují. Je to vlastně rozšíření stratege B o změnu délky přechodného děje. Samozřejmě je možné postupné zkracování přechodného děje použít na nalezená řešení, která mají jž nejvyšší možnou shodu dosaženu. Lze takto zjednodušovat aktuální nalezená řešení a snžovat jejch složtost. Stratege E: Tato stratege spočívá ve změně velkost bnárních vektorů ve změně počtu použtých buněk. Stratege E se kombnuje se strategí B, kdy během evolučního hledání postupně přdáváme další výstupy, ale přtom zvyšujeme počet buněk které jsou použty v bnárních vektorech. Kdykolv máme poct, že evoluce uvízla v dílčím vývojovém bodě, je možné se pokust prodloužt nalezená řešení o jednu další buňku. Není dobré ale tento postup opakovat přílš často a až když jsou vyčerpány jné možnost jak se dostat z uvízlé evoluce. Tento postup je výhodný v tom, že můžeme u evoluce začít s malým počtem výstupů a s malým počtem buněk, což má příznvý vlv na rychlost probíhající evoluce, a postupně počet buněk zvyšovat. Jsou zde však bohužel určté během praxe zjštěné nevýhody. Nedoporučuje se najednou přdávat více než jednu buňku. Vložení buňky probíhá náhodně - na náhodnou pozc se vloží buňka s náhodným obsahem u všech exstujících vektorů ve všech 8m paralelních evolučních procesech. To má za následek, že přestože struktura všech nalezených mplementací je zachována (protože se po vložení nové buňky všechny spoje všech buněk správně přepočítají), sníží se ale výrazně podobnost bnárních vektorů mez sebou každý má náhodnou buňku vloženu jnam a u každého jsou tedy spoje mez buňkam přepočítány odlšně. Vznká problém během křížení: Přestože dosažená shoda obou rodčů je vysoká, jejch podobnost je narušena odlšným posuny buněk př vkládání náhodné buňky a výslední potomc potom mívají horší vypočítanou shodu než jejch rodče. Př neuváženém použtí funkce přdávání buněk může dojít snadno k vymření v tuto chvíl nejlépe ohodnocených jednců, protože nebudou schopn se spolehlvě reprodukovat. Zvýšení počtu buněk naopak může vyřešt ty stuace, kdy máme přílš mnoho sobě podobných jednců, pokud evoluce zjevně dále

69 nepostupuje a takto lze populac sobě podobných jednců uměle pročstt po narušení schopnost jejch reprodukce jch většna vymře kvůl tomu že se jm nepodaří párovat se s podobným jednc. Pokud před použtím funkce přdání buňky bylo k dspozc velké množství podobných jednců, nemělo by se stát, že by vymřel uplně všchn a došlo tím k degradac nalezených řešení, spíše se jejch počet výrazně sníží. Je nutné mít na pamět ještě jednu nevýhodu stratege E: V současné verz aplkace GenAlg, není možné jž jednou přdanou buňku opět odebrat, lze buňky pouze přdávat. Pokud přdáme přílš mnoho buněk, můžeme dospět do bodu, kdy evoluce postupuje velce pomalu kvůl vyšší výpočetní náročnost, ale proto, že s přdáním každé další buňky rozšřujeme stavový prostor hledaných řešení. Toto může v určté chvíl být přínosem, pokud původně malý počet buněk není schopen vystačt na reprezentac hledaného řešení. Za jných okolností se ale prohledávání stavového prostoru spíš zhoršuje, protože se stane po přdání přehnaného počtu buněk přílš rozsáhlým. Stratege F: Jako velce úspěšná stratege se ukázal být postup, kdy př přítomnost většího počtu výstupů se problém rozdělí na více částí, které se budou řešt odděleně. Pokud máme například u nějakého řešeného problému 10 výstupů, lze řešení problému rozdělt na dvě část, u kterých každé řešení bude mít jen 5 výstupů. Je možné, že nalézt řešení pro všech 10 výstupů by bylo přílš obtížné, ale pro 5 výstupů už to tak težké není. Z jedné specfkace která by popsovala 10 výstupů se vytvoří dvě specfkace po 5t výstupech a musí se evoluční hledání potom nechat běžet dvakrát pro každou specfkac zvlášť. Nevýhodou je, že potřebný počet buněk které popsují nalezená řešení bude dohromady jstě vyšší než kdyby se řešení pro všechny výstupy hledalo najednou. Pokud by to bylo potřeba, je samozřejme techncky možné nalezené vektory obou řešení sloučt do jednoho velkého, jde pouze o to jakým způsobem by se oba vektory propojly a jak by se kvůl tomu přepočítal jejch spoje. Aplkace GenAlg tuto funkc nenabízí, v případě potřeby je tato varanta ale možná například v excelu pokud s vytvoříme na to vhodný algortmus podle toho jak vektory chceme propojt. Stratege G: Tato stratege spočívá v lbovolné manpulac se soubory specfkace *.fdf. Nejmocnějších manpulací probíhajícího evolučního děje lze samozřejmě docílt změnou přímo ve specfkac hledané mplementace. Je možné mít přpravenu sadu různých specfkací, které obsahují různá nastavení a popsy vstupů a výstupů jednotlvých případů. Po dosažení určtých dílčích cílů je možné specfkace lbovolně měnt a určté useky evolučního děje je možné nechat běžet s různým specfkacem. Lze tak například začít s menším počtem případů párů vstup/výstup ke kterým je možné přdávat časem další případy jakmle evoluce dosáhne určtých dílčích úspěchů. Tímto způsobem nebude hledání hned na začátku zahlceno a zbržděno přílšnou složtostí specfkace, ale lze postupně složtost stupňovat. Je možné také balancovat mez stavy kdy by evoluce uvízla v nějakém bodě. Pokud začne evoluce vykazovat známky stagnace, je možné použít mírně upravenou specfkac, která budě zaměřena na trochu jné aspekty hledaného řešení a pozděj se

70 lze opět vrátt k té původní specfkac jakmle se nám podaří unknout z vývojové stagnace. Je dobré pro různé typy problémů používat různé stratege, není vhodné však použít během evolučního procesu pouze jednu strateg ale spíše správnou kombnac několka výše uvedených typů a obměňovat je podle aktuální stuace podle toho v jakém stavu se právě evoluční proces nachází. Některé stratege mají vyšší užtnou hodnotu během počátečních fází hledání, jné více pomohou pokud jsme už například dosáhl téměř nejvyšší možné shody a hledáme už jen řešení pro několk posledních chybějících bodů shody. Z předchozího popsu všech uvedených strategí vyplývá, že hledání řešení s pomocí aplkace GenAlg nemusí být vždy tak jednoduché jak by se mohlo původně zdát. Samozřejmě nejlepší řešení by bylo všechny výše uvedené stratege naprogramovat do aplkace, aby se během evoluce prováděly sam. Potom bychom skutečně dosáhl stavu, kdy zadáme specfkac řešeného problému a řešení bude zcela samo a autonomně nalezeno v co nejkratším čase a s co neefektvnější mplementací a s rozumnou mírou složtost. Bohužel by to pravděpodobně vyžadovalo další roky vývoje aplkace. Musel by se vyvnout účnný mechanzmus vyhodnocování statstky běžící evoluce, která by sloužla pro detekc stagnujícího vývoje a následně by se podle určtých dosažených ukazatelů a vyhodnocených parametrů rozhodovalo jaká stratege bude v tu chvíl zvolena pro další vývoj. Toto není neřeštelné, ale vyžadovalo by to další a nemalou prác na vývoj aplkace. V tuto chvíl je tedy pouze vytyčen směr, kam by se mohl vývoj aplkace dál ubírat a byly vynalezeny a popsány účnné stratege, které by po úspěšném zapracování kvaltatvně vylepšl užtnou hodnotu současné verze aplkace GenAlg

71 10.6 Archtektura aplkace, pops programových bloků Aplkace pro genetcké programování popsovaná v této prác, se skládá z těchto hlavních programových bloků a umožňují tak běh celého cyklu [18]: Defnce parametrů genetckého programování, parametry pro řízení a ukončení procesu evoluce. Náhodné generování počáteční populace jednců (Generace). Populace obsahuje určtý počet bnárních vektorů, kdy každý bnární vektor odpovídá hledanému algortmu s určtou vyčísltelnou přesností a tento popsuje chování tohoto hledaného algortmu, pokud se na něj aplkuje celulární procesor logckých funkcí. Výpočet vhodnost všech jednců v rámc jedné populace (Generace). Použje se předpřpravená defnce chování hledaného algortmu, která popsuje určté hodnoty vstupů (používají se na to první buňky vektoru), aplkuje se určtý zadaný počet cyklů celulárního procesoru logckých funkcí a výstupy (používají se poslední buňky vektoru) jsou pak porovnány s očekávaným hodnotam (dle defnce hledaného algortmu). Čím více shod je dosaženo, tím vyšší je kvalta jednce (součet všech shod s výstupy v defnc hledaného algortmu). Setřídění všech jednců podle jejch vypočítané vhodnost (kvalty). Kontrola splnění ukončovacích parametrů (Jestl byl nalezen hledaný algortmus nebo ne se určuje podle bodového hodnocení vhodnost). Smulace přrozeného výběru jednců uvntř populace; jednc s nejlepší vypočítanou vhodností mají nejvyšší pravděpodobnost k přežtí. Aplkuje se pravděpodobnostní model řízený pravděpodobnostní funkcí. Označení jednců, kteří neprošl selekcí. (V dalších krocích budou odstraněn z populace a místo nch se vygenerují jednc noví). Generování párů ze seznamu jednců, kteří prošl selekcí a kteří nebyl odstraněn a určení počtu jejch potomků. Počet potomků je opět řízen kvaltou jednců méně kvaltní jednc mají nárok jen na méně potomků. Náhodný výběr operátorů pro křížení, proces křížení vznká nový jednec, jehož genetcký kód odpovídá kombnac genetckého kódu jeho rodčů. V tomto případě vznkají jednc dva, kdy po aplkování bodu křížení se využjí obě kombnace způsobu slepení rozdělených (často nestejně velkých) polovn kódů: J1:=(J1A+J2B) a J2:=(J2A+J1B), kdy (J1A+J1B) a (J2A+J2B) jsou původní jednc a A a B jsou jejch polovny genetckého kódu (Bod křížení nemusí být právě uprostřed). Jsou aplkovány náhodné operátory mutace, čímž se mění jakákolv část genetckého kódu nově vznklých jednců. Celý cyklus se opakuje od bodu, kde se vypočítává kvalta jednců, dokud není splněno nalezení vhodného jednce, který by měl požadovanou kvaltu (Např. 100% shody defnce s nalezeným algortmem). Vyvnutá aplkace nechává běžet 8 paralelně běžících evolucí [21], které jsou zpočátku vůč sobě navzájem zolovány a po uběhnutí určtého počtu evolučních cyklů se nalezení jednc mez těmto evolucem perodcky promíchávají. Tímto

72 se dosahuje lepší genetcké varablty a rychlej se daří dosáhnout požadovaného cíle, kromě toho, že počet všech jednců, se kterým se v jeden okamžk pracuje, je osmnásobný. Tato vlastnost aplkace především vynká př užtí moderních vícejádrových procesorů, kdy každá evoluce může využívat pro svůj běh jedno jádro procesoru (podle počtu jader) a opět se tím získává další nárůst výkonu a kratší hledání cílového algortmu. START 1 Vybere se specfkace, ke které se budou hledat mplementace shodující se s nadefnovaným chováním. 2 Vygeneruje se první náhodná generace obsahující náhodné mplementace. 9 Po ukončení křížení, se aplkují náhodné mutační operátory modfkující každého nového jednce. 3 Ověří se míra shody nalezených mplementací s cílovou specfkací. 8 Provede se křížení spárovaných jednců, s náhodným určením bodu křížení. 4 Podle míry shody s mplementací se seřadí všchn jednc z generace. 7 Podle počtu odstraněných jednců se vytvoří páry Jednců, kteří zbyl, podle míry jejch shody. 6 Provede se algortmus selekce, jednc s vyšší shodou mají vyšší pravděpodobnost, že nebudou vyřazen ze současné populace. 5 Pokud je dosaženo shody mplementací s výchozí specfkací u určtého množství jednců, proces se ukončí. END Obr Schematcké znázornění celého procesu hledání mplementací dle zadané specfkace Algortmus ověření shody mplementace se specfkací Velm důležtou částí celého evolučního procesu je ověřování míry shody výstupů z nalezených mplementací s jejím očekávaným výstupy, které jsou uvedeny v přdružené specfkac. Informace získané v této fáz významným způsobem ovlvňují celý další proces a způsob, jakým je s jednotlvým mplementacem zacházeno. Míra shody je oceňována počtem bodů, které odpovídají počtu bnárních výstupů shodných

73 s výstupy uvedeným ve specfkac, pro každý jednotlvý případ a v každém teračním kroku ve kterém je sledování shody aktvní. Platí, že čím vyššího bodového hodnocení shody (ftness) je dosaženo, tím více se aktuální chování právě oceňované mplementace shoduje. Pokud je dosaženo nejvyšší možné hodnoty, lze říc, že cílová mplementace byla nalezena a ze strany užvatele je možné celý evoluční proces ukončt. Obr Schematcké znázornění procesu výpočtu míry shody - ftness. Na obrázku je zobrazen příklad procesu výpočtu shody (ftness), kde je pro porovnání použta specfkace popsující 8 různých stavů (párů vstup výstup). Na první 4 buňky celulárního procesoru logckých funkcí jsou přvedeny vstupy ze specfkace X1 X4 a provede se reset čímž se všechny ostaní buňky (kromě těch vstupních) nastaví na výstupní hodnotu 0. Dále v příkladu na obrázku následuje 9 cyklů celulárního procesoru (k = 1.. k = 9), kdy se provádí v buňkách práve uložená mplementace generující výstupy na výstupních buňkách Y1 Y5. Pro výpočet míry shody se používají pouze ty výstupy, které přísluší ke krokům označené jako ustálený stav (k = 5.. k = 9) a tyto se během každého z těchto cyklů porovnávají s očekávaným výstupy které jsou uvedeny ve specfkac. Za každou takovou shodu se přčte jeden bod, v případě neshody se nepřčítá nc. Po dokončení jednoho případu specfkace, se přejde k dalšímu případu a do pracovních vstupů a výstupů specfkace se načtou nové hodnoty které budou použty pro dalších 9 teračních cyklů. Na začátku terací každého případu ze specfkace se provádí reset aby výstupy všech buněk začínaly v přesně defnovaném stavu v tomto případě budou během k = 0 na výstupech všech buněk samé nuly. Vyobrazený sumátor sečte počet všech shod během všech kroků ustálených stavů a během všech uvedených 8m případů ve specfkac a výsledná hodnota se uloží jako

74 ftness (míra shody) prověřované mplementace. Všechny hodnoty na obrázku jsou uvedeny jen jako příklad a různé specfkace mohou mít různý počet popsaných případů, je možné mít různý počet vstupů, výstupů, buněk, nebo teračních cyklů. Rovněž přechodné a ustálené stavy je možné defnovat různým způsobem a podle povahy právě řešeného problému Algortmus selekce jednců podle jejch kvalty Poté co všechny mplementace z celé právě aktuální generace byly použty pro výpočet jejch shody se specfkací a každá získala svou hodnotu míry shody ftness, tyto všechny mplementace jsou v pamět seřazeny od nejvyšší míry shody až po tu nejnžší míru shody. Následuje proces výběru (selekce), který je nsprován přrozeným výběrem probíhajícím v přírodě, kdy pro svůj žvot lépe vybavení jednc mají vyšší pravděpodobnost přežtí a pravděpodonost předání genetcké výbavy svým potomkům, nežl hůře vybavení jednc (nebo tací kteří neměl dostatek štěstí pro přežtí nebo rozmnožení) kteří jsou uloven, nebo zahynou kvůl nemoc a nepodaří se jm rozmnožt se a předat dále svou genetckou výbavu. Přesně tento mechansmus je zde smulován. Implementace s vyšší mírou shody mají vyšší předpoklady k reprodukc oprot těm které jsou po seřazení v pamět od nch vzdáleny směrem k nžším hodnotám jejch shody. Pro smulac výběru je použta funkce znázorňující pravděpodobnost přežtí jednotlvých jednců uvntř generace, kde pravděpodobnost, tradčně vyjadřována číselně procenty od 0% do 100%, je kvůl použtí celočíselných výpočtů v celém program GenAlg převedena na čísla od 0 do 400 čímž se docílí velkost nejmenší jednotky pravděpodobnost = 0,25%. Celá funkce je normalzována na počet jednců roven počtu Obr Funkce použtá pro selekc, odvozená ze vzorce p(x) =400-0,73*(400*(1-(EXP(-x/200)))+150*SIN(2*PI*(1000-x+50)/300)) normalzována na 1000 jednců a p max = 400 Zobecněný průběh pravděpodobnost normalzovaný na 1000 jednců uvedený na obrázku Obr se přepočítává na aktuální (vyšší) počet jednců tak, že vznklé mezhodnoty mají stejnou hodnotu jako jejch sousedé, nebo pokud je konečný počet nžší než 1000, některé hodnoty jsou vynechány. V programu GenAlg zvolená výběrová

75 funkce obsahuje 3 lokální maxma: Na hodnotách 215, 523 a 825. V okolí těchto extrémů výběrová funkce poskytuje jedncům v generac vyšší pravděpodobnost, že nebudou odstraněn, že se mohou rozmnožt a že postoupí do dalšího evolučního cyklu. Toto vylepšení zlepšuje genetckou dverzfkac a dává šanc jedncům s nžším ohodnocením účastnt se reprodukce. Kromě přepočítání kvůl momentálnímu počtu jednců na ose x, se upravuje pravděpodobnost na ose y tak, že se vynásobí právě nastavenou hodnotou v programu GenAlg, která je přdružena k posuvníku označeném jako p-sel.. Díky tomu se docílí toho, že v různých fázích evolučního vývoje se zvyšuje, nebo snžuje úmrtnost jednců a reguluje se tak počet odstraněných nevyhovujících mplementací během každého evolučního cyklu. V programu GenAlg byla zvolena stratege udržování konstatního počtu jednců v každé generac a právě počet odstraněných jednců určuje, kolk nových jednců (potomků), bude momentálně vygenerováno. Tuto míru lze průběžně měnt pomocí nastavení pravděpodobnost přežtí posuvníkem p-sel.. Samotný výběr je smulován tak, že pro každého jednce, který má přřazenou pravděpodobnost přežtí podle výběrové funkce, se z generátoru náhodných čísel získá náhodné číslo s hodnotou a toto číslo je odečteno od momentální pravděpodobnost přežtí. Pokud po odečtení vznkne záporné číslo, jednec je označen značkou že je určen k odstranění z generace (nepřežl) a pokud vznkne nula, nebo kladné číslo, tak jednec zůstane v generac, je označen značkou přežtí (přežl) a může se účastnt další reprodukce pokud k tomu dostane příležtost. Přežtí jednců automatcky neznamená, že jednc budou použt pro reprodukc. Pravděpodobnost počtu potomků se řídí podobným pravdly jako př pravděpodobnost přežtí. Zdatnější jednc získávají právo na vyšší počet potomků než t méně zdatní. Počet potomků je tedy rovněž regulován podle umístění v seznamu jednců mírou jejch kvalty Algortmus generování párů jednců a počty potomků Během procesu selekce byl z generace odstraněn určtý počet jednců. Protože aplkace využívá strateg udržování konstatní velkost generace, tak stejný počet jednců kolk jch bylo právě odstraněno, bude opět vygenerováno. Přednostně to budou potomc těch jednců, kteří se pohybují na horním konc žebříčku nejvyšší dosažené shody. Algortmus je navržen tak, že dochází k párování nejúspěšnějšího jednce s jeho sousedy a to tak, že počet párů, které bude tento jednec tvořt a současně počet jeho potomků je dán určtým číslem - jako příklad s vezmeme číslo 10. Takže s 10t dalším jednc kteří jsou v žebříčku pod ním utvoří páry. Každý z těchto párů vygeneruje 2 nové jednce potomky, tedy jch je celkem 20. V žebříčku se posuneme o dva jednce (ten který byl na druhém místě od shora je přeskočen) a hned ten následující jednec utvoří s ostatním, kteří jsou v žebříčku pod ním, páry stejným způsobem jako u toho prvního. Rozdíl je ale v tom, že počet párů bude o jeden méně, tedy 9 a celkový počet nových potomků bude dvojnásobek který je roven 18. Tímto způsobem postupujeme v žebříčku směrem dolů (s přeskakováním nejblžšího souseda př každém cyklu kdy se mění počet párů) tak dlouho, dokud se počet párů nesníží až na číslo 1 odpovídající dvěma novým potomkům. Když nyní sečteme všechny vznklé jednce (potomky) dojdeme k tomuto součtu: = 10 * (10 + 1) = 110 nových jednců. Pomocí vzorce n = k * ( k + 1) lze spočítat celkový počet vygenerovaných nových jednců n, pokud je předem určen počet párů k se kterým se začne u nejúspěšnějšího jednce v žebříčku

76 Celý problém se musí ale otočt, protože v našem případě vycházíme z celkového počtu jednců, kteří byly v momentálním evolučním cyklu odstraněn a vznklá mezera musí být zaplněna novým jednc jejch počet je znám. Dstrbuce párů bude stejná, ale s tím rozdílem, že předem nevíme kolk párů a kolk potomků má být vygenerováno u nejúspěšnějšího jednce, naopak známe celkový součet potomků kteří budou mez všechny páry rozděleny podle víše popsaného algortmu. Počet párů získáme vyřešením kvadratcké rovnce k * ( k + 1) n = k 2 + k n = 0. Pro určení nejvyššího počtu párů (a následného počtu potomků) u nejúspěšnějšího jednce potřebujeme kladné celočíselné hodnoty, takže výsledek by byl př řešení kvadratcké rovnce zaokrouhlován směrem nahoru nebo dolu. Abychom se během evolučního procesu vyhnul výpočtům, které by mohly zpomalovat celý algortmus, byla navržena tabulka (uložená do pamět), která má u pořadové hodnoty - odpovídající celkovému počtu nových jednců, uveden počet párů se kterým se začne u nejvyššího jednce. V tabulce je zahrnuto zaokrouhlení na nejblžší celé číslo, aby se vždy pracovalo s celým hodnotam. Nový jednc jsou generován podle algortmu párování tak dlouho, dokud se nezaplní celkový počet n. Ukázka tabulky pro určení počtu párů bez nutnost řešení kvadratcké rovnce je uvedena v tabulce Tab Hodnoty v tabulce které odpovídají výsledku k bez zaokrouhlení jsou označeny šedou barvou, kdežto k 1 a k 2 představují dvě různé stratege pro zaokrouhlování. U aplkace GenAlg se v současné době používá stratege zaokrouhlování uvedená v tabulce jako k 2. Tab Výchozí počet párů k algortmu určený z celkového počtu potomků n n k k n k k n k k n k k n k k Algortmus křížení párů jednců Jakmle jsou v generac vybrán jednc kteří se mají účastnt společného křížení, tto jsou označen jako rodč1 (parent1) a rodč2 (parent2). Cílem křížení je získat ze dvou výchozích mplementací dvě nové mplementace potomek1 (chld1) a potomek2 (chld2), které jsou genetckou kombnací těch dvou původních. Kombnují se tak jejch genetcky zakódované vlastnost, které jsou rozhodující pro chování hledaných

77 mplementací. Aby bylo možné zkřížt dva jednce, musí se v jejch buněčné reprezentac určt, kde se bude nacházet bod křížení. Pro získání bodu křížení je třeba vygenerovat náhodné číslo v rozsahu, který je roven počtu buněk vektorů křížených mplementací 1. Je to proto, že bod křížení musí být zvolen tak, aby obě část z rozdělených bnárních vektorů měly délku rovnu alespoň 1. Pokud rodč1 je rozdělen náhodně na dvě část R1a a R1b a rodč2 je rozdělen na stejně velké část jako u R1a a R1b: R2a a R2b, potom potomek1 = R1a + R2b a potomek2 = R2a + R1b. Celková buněčná délka potomků bude stejná jako byla buněčná délka jejch rodčů. Na každého z vygenerovaných potomků jsou dále aplkovány operátory mutace, které jsou posány v následující kaptole Algortmus aplkování mutačních operátorů na nové jednce Nezbytnou součástí generování nových jednců křížením je následné aplkování mutačních operátorů. V aplkac GenAlg se používají dva typy mutačních operátorů, které se aplkují s určtou pravděpodobností pro každý bt bnárního vektoru nového jednce: Adtvní mutace: Ke každé buňce jednce reprezentované 32btovým číslem se s určtou pravděpodobností přčítá jeden bt s hodnotou jedna na náhodné pozc Xorová mutace: U každé buňky jednce reprezentované 32btovým číslem se s určtou pravděpodobností provede xor jednoho btu s hodnotou jedna na náhodné pozc U aplkace GenAlg se pravděpodobnost obou typů mutací nastavuje nezávsle na sobě pomocí nastavtelných posuvníků p-add. a p-xor v rozsahu 0 100%. V případě, že máme v úmyslu měnt hodnotu těchto pravděpodobností, dokud evoluční proces běží, není možné pravděpodobnost mutací měnt. Změnu lze provést až teprve po zastavení běhu evoluce tlačítkem STOP

78 11. Příklady specfkací a nalezených mplementací 11.1 Dekodér pro převod 3-btové nformace na 8-btovou Jedním z prvních algortmů, který byl použt během vývoje aplkace GenAlg byla nadefnována specfkace pro dekodér pro převod 3-btové nformace na 8-btovou. Na obrázku Obr je zobrazen podobný dekodér, jako který je použt v tomto příkladu a jenž se běžně vyskytuje v dgtální technce. Příklad byl zjednodušen a sgnál enable zde není realzován. Počet buněk pro jednu mplementac byl nastaven na 64 a bylo použto 1000 bnárních vektorů pro hledání cílových mplementací. Obr Dekodér pro převod 3-btové nformace na 8-btovou používaný v dgtální technce Byla přpravena specfkace defnující všechny případy vstupů a očekávaných výstupů pro dekodér 74LS138. Bylo očekáváno 8 teračních kroků pro přechodný děj celé soustavy a během těchto kroků nejsou výsledné výstupy použty pro výpočet shody se zadáním ve specfkac (až po jejch odeznění). 10 následujících teračních kroků bylo nastaveno jako krtérum pro stanovení stablních výstupů, u kterých se jž shoda se specfkací vypočítává. Celkový počet shod výstupů s výstupy uvedeným ve specfkac odpovídá celkovému počtu 704 bodů. (Obrázek Obr )

79 Obr Specfkace dekodéru pro převod 3-btové nformace na 8-btovou (pops zjednodušen oprot obsahu *.fdf souboru) Poté co proces hledání běžel přblžně 5 hodn a proběhlo as 9233 evolučních kroků, bylo dosaženo nejvyšší možné shody 704 bodů shody. Po exportování jedné vybrané mplementace, tato je zobrazena na obrázku Obr Obr Obsah exportované mplementace, která se shoduje se specfkací Pro prověření správného chování výsledného bnárního vektoru (obrázek Obr ) bylo vygenerováno několk případů řešení výstupů celulárního procesoru

80 logckých funkcí ze zadaných vstupů. Tyto případy jsou zobrazeny na obrázcích Obr První 3 buňky z levé strany slouží jako 3 vstupy 3-to-8 btového dekodéru. (v opačném pořadí btů) a posledních 8 btů je určeno pro výstupy (v běžném pořadí btů). Prvních 8 teračních cyklů má nestablní výstupní hodnoty během přechodového děje a kroky 9 až 21 mají jž stablní výstupy: Obr Prověření shody s případem č.1 ve specfkac Obr Prověření shody s případem č. 5 ve specfkac

81 Obr Prověření shody s případem č. 7 ve specfkac 11.2 Dekodér číselné nformace pro 7 segmentů V tomto příkladu se hledá algortmus (reprezentovaný bnárním vektorem který je určen pro spouštění v celulárním procesoru logckých funkcí), jenž popsuje chování logckého obvodu dekodéru číselné nformace zobrazované pomocí 7m segmentů (čárkam LED zobrazovače, dspleje) [23]. 0: 1: 2: 3: 4: 5: 6: 7: 8: 9: Obr Všechny kombnace segmentů dekadckého LED dekóderu Pro běh procesu evoluce během genetckého programování byly zvoleny tyto parametry [23]: 8 paralelně běžících evolucí (na procesoru Intel CORE 5 4 jádra, 8 vláken), 2000 bnárních vektorů v každé evoluc (celkem tedy jednců), 64 buněk v každém vektoru, z defnce hledaného algortmu vyplývají 4 vstupní buňky pro kódování číslc 0 až 9 a 7 výstupních buněk pro jednotlvé LED segmenty, zvoleno 12 kroků celulárního procesoru logckých funkcí pro ustálení hodnot na výstupních buňkách (pro odeznění přechodového děje),

82 Vypočítaný počet shod, kterých musí být dosaženo, aby se chování algortmu na 100% shodovalo s hledaným algortmem, odpovídá číslu 770 bodů (= 11 cyklů pro ustálení hodnoty výstupů * 10 číslc které lze zobrazt * 7 LED segmentů). Specfkace popsující dekodér číselné nformace odpovídá tabulce Tab , která vyplývá z kombnací segmentů, patrných z obrázku Obr pro všechny zobrazované číslce 0 až 9. Tyto jsou kódovány 4m vstupy, namapovaným na začátek bnárního vektoru na jeho první buňky. Jednotlvé segmenty a až g odpovídají 7m výstupům, které jsou namapovány na konec bnárního vektoru, na jeho poslední buňky. Tab Přehled všech kombnací funkce číselného dekodéru číslce 0-9 a b c d e f g Po uplynutí přblžně evolučních cyklů byla nalezena cílová reprezentace hledaného algortmu (byl vybrán pouze jeden vektor z mnoha jných stejně kvaltních vektorů nalezených ve stejnou chvíl), kódována bnárním vektorem spusttelným v celulárním procesoru logckých funkcí a která splňuje 770 bodů shod s předlohou (čl 100%) a je znázorněna na obrázku Obr Na obrázku Obr je znázorněno dynamcké chování výsledného nalezeného algortmu pro případ zobrazení čísla 5 na LED zobrazovač. Na začátku jsou všechny výstupy z buněk ncalzovány na nulu a na první čtyř buňky je vystavena bnární reprezentace čísla 5 (1010 opačný záps: v pořadí LSB první zleva; MSB poslední). Uběhne 12 cyklů (vybráno během defnce hledaného algortmu) nutných pro přechodný děj a poté jsou už výstupní hodnoty stablní. LED segmenty a až g jsou mapovány na poslední buňky vektoru ( : a b c d e f g). Všechny ostatní buňky nepatřící an k vstupům a an k výstupům, odpovídají vntřním stavům algortmu. Obdobně lze vygenerovat ostatní kombnace pro zobrazení číslc 0, 1, 2, 3, 4, 6, 7, 8 a

83 Obr Nalezený algortmus shodující se na 100% s předloženou defncí - 64 buněk celulárního procesoru logckých funkcí, pops všech pozc v záhlaví [23] Obr Nalezený algortmus shodující se na 100% s předloženou defncí chování nalezeného algortmu pro případ číslo 5 [23] - přehled dynamckého Poznámka: Pro případ 5 je zřetelně vdět, že k ustálení stavu výstupů došlo už dříve než po 12t cyklech. To nemusí zdaleka platt pro jné případy

84 11.3 Indukce číselné řady násobení 3m Jako další příklad pro ověření správné funkčnost párovacího systému byla zvolena ndukce číselné řady [24]. Rozdílem oprot předchozím případům je to, že dle přpravené specfkace se nejedná už jen o pouhý přenos, nebo konverz nformace z jednoho formátu do druhého, dochází zde ke složtějšímu procesu. Pokud například máme popsány ve specfkac všechny možné případy, které mohou kdy nastat - formou tabulky všech možných vstupů a odpovídajících výstupů, není chování nalezené mplementace tak překvapvé. Jakmle je taková mplementace nalezena a její chování se shoduje ve všech popsaných bodech s chováním popsaným ve specfkac, bude to jen prosté opakování nalezených vzorů. Mnohem zajímavější je však případ, kdy chování hledané mplementace je ve specfkac popsáno neúplným počtem případů a nalezená mplementace se chová očekávaným a správným způsobem pro ty případy, které původně ve specfkac nebyly uvedeny. Tento mechansmus je znám jako prncp ndukce a skrývá se za ním jž chování, které se vyznačuje určtou mírou ntelgence. Toto chování nemá už nc společného s pouhým opakováním naučených vzorů. Představme s systém, který by měl v sobě naprogramovánu velkou množnu různých početních operací. Systém by měl za úkol po předložení nějaké neznámé číselné řady odvodt předps, kterým je řada vypočítána a následně dopočítat chybějící členy řady. Mohl by používat například strateg, že by zkoušel kombnovat různé početní operace ze své databáze, dokud by nenalezl správné řešení. Tímto způsobem by systém fungovat mohl. Potřeboval by k tomu mít ale naprogramovánu velkou databáz početních operací a mít schopnost je rychle spolu kombnovat a postupně ověřovat, jaké předpsy nejlépe na neznámou řadu pasují. Pravděpodobně přesto by hledání trvalo velce dlouho a s nejstým výsledkem. Podobných číselných řad lze vytvořt nekonečné množství a dříve nebo pozděj se vyskytne číselná řada, která obsahuje početní operace v databáz chybějící. U takové číselné řady by systém žádné řešení nenašel. V našem případě v systému schopném ndukce číselné řady, ale nemáme vůbec žádnou databáz početních operací a to se zdá být jako výhoda oprot předchozímu řešení. Databáze by stejně obsahovala vždy jen konečný počet operací oprot nekonečnému počtu různých číselných řad. Náš párovací systém pokoušející se o ndukc číselné řady vlastně an neví, že něco takového dělá a nekonečný počet různých případů řad zde nehraje žádnou rol. Vše funguje jen díky správné souhře několka na pouhé náhodě založených dějů př prohledávání celého stavového prostoru. Různé fáze procesu genetckého programování jsou založeny na náhodě, přesto systém může díky selekčnímu tlaku dospět ke správnému řešení, odvodt předps neznámé číselné řady a dopočítat její chybějící prvky. Identfkace řady, kde jsou prvky reprezentující násobení třem, se může zdát být příkladem jednoduchým, náš párovací systém ale prmárně žádné matematcké výpočty neprovádí. Jednoduché složtější případy řeší úplně stejným způsobem bez rozdílu a pokouší se jen nalézt procesem genetckého programování tu mplementac, která by nejlépe odpovídala zadané specfkac. Po spuštění celého procesu se tedy hledá nejpřesnější mplementace odpovídající zadané specfkac. V našem případě je specfkace defnována jako číselná řada vstupních hodnot od čísla 0 až po číslo 85. Všechny výstupní hodnoty uvedené v této specfkac jsou vždy trojnásobkem číselné hodnoty na odpovídajícím vstupu. Nejvyšší hodnota na výstupu je

85 rovna 85 * 3 = 255 což na straně výstupů celulárního procesoru logckých funkcí odpovídá 8m výstupním btům. Na straně vstupů pro vyjádření nejvyšší vstupní hodnoty rovné 85 postačí 7 btů. Aby zadání úlohy ndukce číselné řady bylo úplné, 22 párů vstupních a výstupních hodnot je z celé řady hodnot vynecháno. Je tedy uvedeno jen 64 vstupních hodnot, ke kterým je přřazeno 64 výstupních hodnot. Nalezená mplementace má potom za úkol chybějící 22 prvky dopočítat. To odpovídá 25,5%tům hodnot z celé řady - více jak jedna čtvrtna hodnot tedy chybí. Jako chybějící prvky specfkace byly zvoleny tyto páry hodnot: 10 30, 11 33, 16 48, 20 60, 22 66, 30 90, 31 93, , , , , , , , , , , , , , a Obr Tento algortmus není pro párovací systém znám a musí být nalezen, nebo spíše namodelován vntřním chováním celulárního procesoru logckých funkcí. Tab Tabulka všech vstupních a výstupních hodnot včetně chybějících výstupů, které jsou zde označeny jako? Pro běh procesu evoluce během genetckého programování byly zvoleny tyto parametry: 8 paralelně běžících evolucí (na procesoru Intel CORE 7 Ivy brdge, 8 vláken), 2000 bnárních vektorů v každé evoluc (celkem tedy jednců),

86 64 buněk v každém vektoru, z defnce hledaného algortmu vyplývá 7 vstupních buněk označených jako bt-x0 bt-x6 pro kódování vstupních hodnot 0-85, Protože bylo obtížné nalézt řešení pro všechny výstupní bty y0-y7 popsané pouze jedním bnárním vektorem, řešení bylo rozděleno na dvě část a poté řešeno odděleně ve dvou evolučních procesech: V prvním průběhu bylo hledáno řešení pro bty bt-y0 bt-y4 výstupních hodnot a tyto bty byly asocovány na 5 posledních buněk v hledaném bnárním vektoru. Ve druhém průběhu bylo hledáno řešení pro bty bt-y4 bt-y7 výstupních hodnot a tyto bty byly asocovány na 4 poslední buňky v hledaném bnárním vektoru. Z předchozích zkušeností vyplynulo, že čím více výstupních btů bude z hledaného řešení použto pro hledání cílového bnárního vektoru, tím je větší pravděpodobnost, že nalezené řešení bude spolehlvě fungovat. Př použtí pouze tří btů se po nalezení domnělého řešení zjstlo, že některá hledaná čísla (označená jako?) byla špatně spočítána. Nčemu nevadí, když se potom ten bt, který se v řešení druhého evolučního procesu vyskytuje nadbytečně podruhé (bty4), nakonec nepoužje. Zvoleno 11 kroků celulárního procesoru logckých funkcí pro ustálení hodnot na výstupních buňkách (pro odeznění přechodového děje), kdy výstupní hodnoty budou stablní nejméně dalších 11 kroků. Vypočítaný počet shod, kterých musí být dosaženo, aby se chování algortmu na 100% shodovalo s hledaným algortmem, odpovídá pro první evoluční proces číslu 3520 bodů (= 11 cyklů pro ustálení hodnoty výstupů * 5 výstupních btů * 64 vzorků číslc řady). Pro druhý evoluční proces odpovídá číslu 2816 bodů (= 11 cyklů pro ustálení hodnoty výstupů * 4 výstupní bty * 64 vzorků číslc řady). Celý proces evoluce je možné ukončt ve chvíl, kdy počet bodů, ve kterých se momentálně vypočítané výstupy shodují s předem defnovaným výstupy, dosáhne nejvyšší možné shody. V prvním průběhu evolučního procesu (myslí se tím celý dlouhý proces evoluce, ne pouze jeden cyklus) se podařlo nalézt shodu pro zadání výstupních btů y0 y4. Ve druhém průběhu se dosáhlo nejvyšší možné shody pro bty y5 y7. Nejvyšší shoda pro bt y4 ve druhém průběhu dosažena nebyla, nebylo to ale nutné, tento výstup byl použt pouze pro podporu hledání řešení btů y5 - y7. Jak se pozděj ukázalo, nalezené vektory A B (obrázek Obr a Obr ) získané během prvního a druhého průběhu pro bty y0 y7 postačly pro správné vyřešení všech případů pro prvky řady kde se nacházel?. Nyní je nejvyšší možná shoda pro vzorec y = 3*x splněna pro všechna celá čísla prvků řady na pozcích x ϵ <0; 85> včetně prvků původně v řadě chybějících. Na obrázku Obr jsou zobrazeny výstupy všech buněk u výsledných bnárních vektorů A B (prvního a druhého průběhu evolucí) pro kroky terací 0 12 pokud je zvoleno zadání vstupů btů x0 x6 číslo 57. Z obrázku je zřejmé, že po 12t krocích (v tomto případě už dříve) se na výstupních btech y0 y7 př provádění algortmu celulárního procesoru logckých funkcí vypočítá číslo 171 které správně odpovídá rovnc 171 = 3 * 57. Obdobným způsobem bylo ověřeno, že bnární vektory A B lze použít ke správnému nalezení všech hodnot řady na pozcích x ϵ <0; 85>

87 Obr Příklad 12t krokové terace, kdy na vstup je přvedeno číslo 57 a postupem teračních kroků došly celulární procesory logckých funkcí př použtí bnárních vektorů A B na výstupech k hodnotě

88 Obr Výsledný bnární vektor A nalezený během prvního průběhu evoluce př hledání mplementace pro výstupy y0 y4 specfkace hledaného algortmu

89 Obr Výsledný bnární vektor B nalezený během druhého průběhu evoluce př hledání mplementace pro výstupy y5 y7 specfkace hledaného algortmu

90 11.4 Identfkace typů ASCII znaků ze 7m bnárních vstupů Cílem hledané mplementace je v tomto příkladě to, aby mplementace dokázala spolehlvě dentfkovat ASCII znaky ze 7m bnárních vstupů a přřadt je do správné kategore znaků podle tabulky uvedené v Tab Protože se zdálo, že hledání řešení pro všechny uvedené kategore trvalo přílš dlouho a nebylo jsté, jestl se podaří nalézt řešení pro všechny kategore, byl problém zjednodušen dle tabulky Tab a závorky byly převedeny do kategore ostatní. Tab Původní rozdělení znaků základní ASCII tabulky pro dentfkac řídící kódy ASCII 0 znaky mezery ASCII 32 matematcké znaky čísla velká písmena malá písmena levé závorky pravé závorky ostatní! 0 A a ( ) " ASCII 1 _ % 1 B b [ ] # ASCII 2 & 2 C c { } $ ASCII 3 * 3 D d ASCII E e? ASCII 5, 5 F ASCII 6-6 G g \ ASCII 7. 7 H h ' ASCII 8 / 8 I ASCII 9 : 9 J j ASCII 10 ; K k ASCII 11 < L l ASCII 12 = M m ASCII 13 > N n ASCII 14 ^ O o ASCII 15 P p ASCII 16 ~ Q q ASCII 17 R r ASCII 18 S s ASCII 19 T t ASCII 20 U u ASCII 21 V v ASCII 22 W w ASCII 23 X x ASCII 24 Y y ASCII 25 - ASCII 31 Z z ASCII

91 Tab Rozdělení znaků ASCII tabulky pro dentfkac po zjednodušení řídící kódy znaky mezery matematcké znaky čísla velká písmena malá písmena ostatní ASCII 0 ASCII 32! 0 A a " ASCII 1 _ % 1 B b # ASCII 2 & 2 C c $ ASCII 3 * 3 D d ASCII E e? ASCII 5, 5 F ASCII 6-6 G g \ ASCII 7. 7 H h ' ASCII 8 / 8 I ASCII 127 ASCII 9 : 9 J j ( ASCII 10 ; K k [ ASCII 11 < L l { ASCII 12 = M m ) ASCII 13 > N n ] ASCII 14 ^ O o } ASCII 15 P p ASCII 16 ~ Q q ASCII 17 R r ASCII 18 S s ASCII 19 T t ASCII 20 U u ASCII 21 V v ASCII 22 W w ASCII 23 X x ASCII 24 Y y ASCII 25 - ASCII 31 Z z Evoluční proces hledající mplementac pro dentfkac ASCII znaků genetckým programováním byl provozován s těmto parametry: 8 evolučních procesů běžících paralelně na CPU Intel CORE 7 Ivy brdge, 2000 bnárních vektorů pro každou paralelní evoluc ( celkem), 86 buněk v každém bnárním vektoru,

92 Vstupní data reprezentující ASCII kódy v rozsahu jsou mapovány na 7 prvních buněk jako bt-x 0 bt-x 6. Výstupy jsou sledovány na posledních 6t buňkách bt-y 0 bt-y 5, které odpovídají jednotlvým kategorím: řídící kódy, znaky mezery, matematcké znaky, čísla, velká písmena a malá písmena. Každý z přdružených výstupů je nastaven na hodnotu 1 pokud je kategore nalezena, jnak na hodnotu 0. Skupna ostatní je sgnalzována tak, že všechny výstupy jsou nastaveny na hodnotu 0. Přechodový děj byl nastaven na 16 kroků aby po jejch odeznění byly výstupy stablní alespoň 5 následujících kroků. Nejvyšší možná vypočítaná shoda se specfkací je rovna: 6 stablních kroků * 6 výstupních btů * 128 defnc (vstup/výstup) = 4608 bodů shody. Během posledního pokusu pro evoluční hledání mplementace, který trval přlžně 4 dny, byla nalezena nejvyšší možná shoda rovna 4596 bodů: Jen dvě defnce nejsou splněny, znaky ^ a _ jsou nalezenou mplementací mylně přřazeny ke skupně ostatní. Všechny další ASCII znaky z tabulky Tab jsou dentfkovány jž správně, což pořád ještě vykazuje dobrou přesnost. Na obrázcích Obr a Obr se nachází první a druhá část nalezené mplementace. Pro ověření správného chování nalezené mplementace byly otestovány všechny ASCII znaky v rozsahu Byly nalezeny pouze dvě chybné dentfkace: znak ^ který měl být dentfkován jako matematcký znak a _ měl být dentfkován jako znak kategore mezery. Místo toho byly přřazeny do kategore ostatní. Na obrázcích Obr jsou znázorněny příklady ověřených dentfkací a jejch terační kroky s přechodným dějem nastaveným na 16 kroků a na posledních 6t buňkách jsou poté ustáleny stablní výstupy bt-y0 bt-y5 reprezentující dentfkované kategore

93 Obr První část výsledné nalezené mplementace: buňky

94 Obr Druhá část výsledné nalezené mplementace: buňky

95 Obr Verfkace nalezené mplementace u ASCII 17, kategore řídící kód

96 Obr Verfkace nalezené mplementace u ASCII 52, kategore číslo

97 Obr Verfkace nalezené mplementace u ASCII 115 kategore malé písmeno