Езиците от високо ниво дават на програмистите средства за бързо създаване на прототипи, така че да бъдат създавани и оценявани гъвкави проекти на сравнително ниска цена и с по-малко усилия. Обикновено интерфейсите за изграждане и изпълнение са близки един до друг, така че системата може да бъде непрекъснато тествана по време на нейното изграждане. Потребителският интерфейс обикновено не е така “дружелюбен” както при дадено ядро, но в противен случай програмистът не би имал възможност да изгражда бързо системата.
Обикновено продукционните системи, обектно ориентираните програмни езици и процедурните дедуктивни системи дават по-голяма свобода на конструктора на експертна система, отколкото ядрата по отношение на механизма за управление и обработване на несигурности. Както бе отбелязано по-горе, ядрата обикновено са комплектувани с определен управляващ режим – например извод в права посока, и определен подход към обработване на несигурности – например фактори на сигурност, които са “твърдо” закодиране в програмата. Тази допълнителна свобода е особено ценна при изграждане на експериментални проекти на системи, когато не е ясно предварително какви механизми ще са необходими за решаването на задачи от дадена област.
Всъщност езиците от високо ниво налагат свои собствени ограничения. Например динамичната памет е ограничена само до вектори в работната област. Това изключва рекурсивни структури от данни като графи и дървета. Някои видове управляващи режими като итерация и рекурсия е трудно да бъдат реализирани. Разбира се, това е цената, която се заплаща за простотата на програмите и ефективното им изпълнение. По-ранните експертни системи изразходват около 90 % от времето при изпълнение за съпоставяния с образци. Обаче Форги [16] отбелязва, че има няколко възможни източници на неефективност при “наивния” подход към този въпрос. Проектираният от Форги алгоритъм на съотвествие, който е използван във фамилията от продукционни езици, се основава на следните две особености:
Левите страни на продукциите в работната памет често съдържат общи условия и един “наивен” подход би съпоставил N пъти тези условия в работната памет при N срещания. Това е пример на итерация във вътрешен цикъл. Работната памет се изменя всеки път съвсем малко и въпреки това “наивният” подход се стреми да съпостави всички образци на всички елементи от работната памет за всеки цикъл. Това е пример за итерация между цикли. Алгоритъмът намалява натоварването от итерации във вътрешен цикъл върху продукции чрез използване на мрежа от сортирани дървовидни структури. Образците от левите страни на продукциите се компилират в тази мрежа и алгоритъмът за съотвествие изчислява конфликтните множества за даден цикъл чрез обработване на мрежата. Итерацията между цикли в работната памет се елиминира чрез обработване на множество от маркери, които отбелязват кои образци се съпоставят на елементите от работната памет, и само това множество се обновява, когато се промени работната памет. Наличието на единствен управляващ процес от вида “цикъл отражение – действие” улеснява обработването на полученото конфликтно множество. Прилага се алгоритъм за разширяването на конфликти към множеството, без да се засягат други страни на текущия изчислителен процес. Ясно е, че всеки опит да се въведат рекурсивни структури от данни би усложнил значително процеса на съотвествие. Също така всеки опит да се усложни управляващият режим би означавал, че алгоритъмът за разрешаване на конфликти трябва да вземе това предвид. Ясно е, че такива езици винаги трябва да избират между изразителната сила и ефективност при изпълнение. Преодоляването на недостатъците при програмирането, основано на правила, е свързано не с усложняването на тези езици (и увеличаване на тяхната сила), а с комбинирането им с други схеми на програмиране, които позволяват рекурсия на данни и изпълнение. Например комбинирането на правила с фреймове и допускането условията на правилото да се съпоставят със слотовете на фрейма дава задоволително решение на проблема с данните. Също така влагането на множеството от правила в по-обща изчислителна схема, включваща списъци от задачи и многобройни източници от знания, дава основа за решаването на проблема с управлението. Много от изследователите на експертни системи предлагат логическото програмиране като алтернативен подход към изграждане на системи, основани на знания. Например Кларк и Маккейб [12] дават предложение как всяка продукционна система, подобна на MYCIN, може лесно да бъде написана на PROLOG (PROgramming LOGic). Правилата могат да се представят като клаузи на Хорн (вж. “Елементи на математическата логика и автоматични разсъждения”), в която главата (положителният литерал) би означавала заключението, което трябва да бъде направено, а останалите (отрицателните) литерали биха означавали условията.
Вграденият управляващ режим на PROLOG се доближава до механизма за извод в обратна посока. Таблиците за знания и другите видове данни могат да се реализират чрез оператора assert. Рекурентните структури от данни като графи и дървета могат да се реализират в PROLOG, като се използват клаузи, съдържащи сложни термове. Програмистите биха могли да изградят собствена обработка на несигурностите, като използват например фактори на сигурност. От практическа гледна точка PROLOG дава наготово няколко важни характеристики:
индексирана база данни, съдържаща клаузи, които могат да се използват за представяне на правила, процедури или данни;
съпоставяне с образец от вида на най-обща унификация, което позволява на данните и на образците да съдържат променливи и връща субституция, променяща ги по един и същ начин;
управляваща стратегия (търсене в дълбочина) с ред за търсене отгоре надолу (най-горните клаузи в базата данни се проверяват първи) и правило за изчисление отляво надясно (подцелите се изпълняват в реда, в който са изброени – отляво надясно).
Много от изследователите отбелязват като едно от предимствата на тези
хакатеристики лесната реализация на фреймове и дори обекти в PROLOG. Определени факти и типове информация могат да бъдат изразени непосредствено като единични клаузи. Например:
- fact (EB-virus, sequence, [C, A, G, …, T, A, T].
- isa (EB-virus, herpes-virus).
- изразява факта от базата данни, че нуклеотидната верига на вируса ЕВ е
- [C, A, G, …, T, A, T]
…и че вирусът ЕВ е вид херпесен вирус. Допълнително може да се реализира механизъм за наследяване чрез процедури на PROLOG.
При този подход има няколко проблема, никой от които не е фатален, но също не и тривиален. Едно от нещата, които много от реализациите на PROLOG не предлагат, са обикновените структури от данни като масиви, записи или указатели за създаване на произволно сложни мрежи. Въпреки че всички те могат да бъдат симулирани чрез сложни термове или вложени списъци, достъпът и обновяването на тези структури чрез съпоставяне с образец е по принцип много по-неефективно, отколкото представянията от “по-ниско ниво”, които дават общ достъп до индексите и полетата чрез име вместо чрез позиция. Съществуват находчиви програмистни трикове, които могат да заобиколят тези проблеми, но тогава трябва да се използва “истинско програмиране”, а не да се разглеждат въпроси от по-високо ниво, с които би трябвало да има работа един специалист по обработка на знания. Също така индексирането на базата данни, както е реализирано в PROLOG, вероятно не е достатъчно прецизно, за да поддържа ефективен достъп до големи бази от фреймоподобни клаузи – това е също въпрос на “истинско програмиране”.
Вградената управляваща структура може да бъде неприемлива при нетривиални приложения. Едва ли може да се представи голяма фреймоподобна система, която функционира (ако изобщо функционира) при режим на търсене в дълбочина. Отново “истинският програмист” трябва да напише интерпретатор на PROLOG, който реализира необходимата управляваща стратегия – ефективното й осъществяване не е тривиална задача.
Нито една от горните забележки не е в сила за дедуктивни системи от вида на MRS [17] (MRS е съкращение от Meta-level Representation System – система за представяне на метаниво), които имат рекурсивни средства за създаване на потребителски структури от данни и управляващи режими. Ако е необходимо да се сравнят логически основаните подходи с тези, основаващи се на правила или обекти, тогава коректен стандарт за сравнение би трябвало да бъде някой език от високо ниво от рода на MRS, а не PROLOG. Обаче справедливостта изисква да се каже, че MRS е бил използван по-скоро като изследователско средсво, отколкото като система за изграждане на експертни системи.
Един от първите езици от високо ниво за обработване на списъци е LISP [25]. Този език е претърпял значително развитие през последните десетилетия, но е запазил повече или по-малко основните си концепции. LISP се отличава от останалите програмни езици по следните три признака:
- Главната му структура от данни е списъкът.
- Програмите също се представят чрез списъчни структури.
- Примитивните му операции са операции върху списъци.
Основният градивен елемент на структурите от данни в LISP е символният израз или накратко S-израз. Простите S-изрази са атомни символи или атоми – низове (не повече от определен брой, зависим от реализацията) от буквено цифрови символи, започващи с буква. Атомът се представя вътрешно като клетка в динамичната памет. Сложните изрази са реализирани като клетки от паметта, комбинирани така, че да образуват произволни крайни дървовидни структури. Има непосредствено съотвествие между крайните дървета и S-изразите.
Лесно е да се възприеме идеята за списъците като структури от данни. По- трудно е да се разбере, че списъкът може да бъде програма, например списъкът
(+ X Y)
е математически израз от вида
(<Функция> <1-ви аргумент> <2-ри аргумент>).
Как да се използва тази идея, без да настъпи объркване? Необходими са следните изисквания:
Трябва да може да се оценяват изразите от рода на (+ X Y). За това е необходимо да съществува някаква функционална дефиниция на +, която да покаже последователността от примитивни операции, които трябва да бъдат приложени към аргументите, за да се изчисли стойността.
Трябва да има възможност за дефиниране на функции и прилагане на техните дефиниции към аргументите (фактическите, неформалните параметри). Механизмите за дефиниране и прилагане на функция се основават на логическа система, наречена ламбдасмятане. За разлика от предикатното смятане от първи ред ламбдасмятането е функционално, а не релационна. Първично понятие е релацията от вида “много-към-едно”, а не от вида “много-към-много”. Например релацията “баща” е функционална, защото всеки има само един баща, докато релацията “брат” е по-обща, тъй като човек може да има повече от един брат.
Трябва да има достъп до текущите стойности на променливите (или на формалните параметри) като X и Y. Оценяването на всеки S-израз се извършва в среда на свързване на променливите. Трябва да може да се записват и възстановяват тези среди, когато се изчислява стойността на сложен S-израз, като се изчисляват и комбинират стойностите на съдържащите се в него подизрази.
При оценяване на сложен S-израз, което може да включва прилагане на повече от една функция, трябва да може да се съхранява текущия S-израз, т.е. този, който се оценява в даден момент. Трябва да може да се копират S-изрази, като се отлага тяхното оценяване, така че да се запазят по време на подизчисленията. Необходимо е също да може да се записват междинните изчисления.
Стандартният начин за реализиране на функционални езици от вида на LISP е, като се използва машина с четири стека, наречена SECD-машина. Тези четири стека съхраняват частните резултати, стойностите на променливите, текущия израз и копие на състоянето на изчислението за възвръщане след извършване на подизчисленията. Оценяването на един S-израз чрез такава машина реализира основните операции на приложението на функция, както е дефинирано в ламбда-смятането.
При интерес за програмиране на бизнес системи или уеб дизайн услуги за района на Пловдив, можете да се обръщате към web студио Уеб дизайн Пловдив и да разгледате техните предложения за SEO оптимизация и онлайн Интернет маркетинг, уеб дизайн услуги и изработка на сайтове, разработване на онлайн магазини, сайтове за имоти, корпоративни web сайтове и програмиране на бизнес софтуер и интерактивни системи със собствено административно управление.
Trackbacks /
Pingbacks