Informacje ogólne - wnioskowanie w przód rozwinięte niepewne

Regułowo-modelowy skorupowy system ekspertowy dla wnioskowania rozwiniętego niepewnego (rmse_RN) umożliwia wnioskowanie w przód dla bazy wiedzy, której elementami w najbardziej ogólnym przypadku są:

1) Baza reguł rozwinięta niepewna
2) Baza modeli rozwinięta niepewna
3) Baza ograniczeń rozwinięta dokładna
3) Baza ograniczeń rozwinięta niepewna
4) Baza rad rozwinięta niepewna
5) Pliki rad
6) Baza grafiki rozwinięta niepewne
7) Pliki grafiki
8) Baza dźwięków rozwinięta niepewne
9) Pliki dźwięków
10) Plik opisu wiedzy dziedzinowej

Baza reguł wraz z bazą modeli są rozwinięte, jeżeli:

    • wnioski reguł mogą występować w postaci zanegowanej w listach warunków innych reguł, oraz
    • wnioski reguł mogą występować w postaci zanegowanej jako warunki startowe modeli, oraz
    • wnioski modeli relacyjnych mogą występować w postaci zanegowanej w listach warunków innych reguł, oraz
    • wnioski modeli relacyjnych mogą występować w postaci zanegowanej nioski reguł mogą występować w postaci zanegowanej jako warunki startowe modeli.

Innymi słowy - dla baz rozwiniętych dozwolone jest zagnieżdżanie z negacją.

Baza reguł jest niepewna, jeżeli jej warunki i wnioski są niepewnymi zmiennymi łańcuchowymi o inkludach, którym przyporządkowuje się wartości współczynników pewności, oznaczane skrótem CF (Certainty Factor) i będące liczbami rzeczywistymi z przedziału [-1, 1].

Baza modeli jest niepewna jeżeli warunki modeli relacyjnych i warunki startowe modeli są niepewnymi zmiennymi łańcuchowymi o inkludach mogących przyjmować wartości zwane współczynnikami pewności (CF), będące liczbami rzeczywistymi z przedziału [-1, 1].

Celem wnioskowania rozwiniętego niepewnego w przód jest wyznaczenie:

    • współczynników pewności dla wniosków wszystkich reguł bazy reguł, oraz
    • współczynników pewności dla wniosków wszystkich modeli relacyjnych bazy modeli, oraz
    • wartości wszystkich wyników modeli arytmetycznych bazy modeli,

na podstawie znajomości bazy reguł rozwiniętej niepewnej, bazy modeli rozwiniętej niepewnej, bazy ograniczeń rozwiniętej dokładnej, bazy ograniczeń rozwiniętej niepewnej, współczynników pewności wszystkich warunków dopytywalnych i wartości numerycznych wszystkich argumentów dopytywalnych.

Zwraca sie również uwagę na to, że wnioskowanie w przód wyznacza wszystko, co można wyznaczyć lub obliczyć, włączając to, co może niezbyt nas interesuje.


Informacje ogólne - wnioskowanie wstecz rozwinięte niepewne

Regułowo-modelowy skorupowy system ekspertowy dla wnioskowania rozwiniętego niepewnego (rmse_RN) umożliwia wnioskowanie wstecz dla bazy wiedzy, której elementami w najbardziej ogólnym przypadku są:

1) Baza reguł rozwinięta niepewna
2) Baza modeli rozwinięta niepewna
3) Baza ograniczeń rozwinięta dokładna
3) Baza ograniczeń rozwinięta niepewna
4) Baza rad rozwinięta niepewna
5) Pliki rad
6) Baza grafiki rozwinięta niepewne
7) Pliki grafiki
8) Baza dźwięków rozwinięta niepewne
9) Pliki dźwięków
10) Plik opisu wiedzy dziedzinowej

Baza reguł wraz z bazą modeli są rozwinięte, jeżeli:

    • wnioski reguł mogą występować w postaci zanegowanej w listach warunków innych reguł, oraz
    • wnioski reguł mogą występować w postaci zanegowanej jako warunki startowe modeli, oraz
    • wnioski modeli relacyjnych mogą występować w postaci zanegowanej w listach warunków innych reguł, oraz
    • wnioski modeli relacyjnych mogą występować w postaci zanegowanej nioski reguł mogą występować w postaci zanegowanej jako warunki startowe modeli.

Innymi słowy - dla baz rozwiniętych dozwolone jest zagnieżdżanie z negacją.

Baza reguł jest niepewna, jeżeli jej warunki i wnioski są niepewnymi zmiennymi łańcuchowymi o inkludach, którym przyporządkowuje się wartości współczynników pewności, oznaczane skrótem CF (Certainty Factor) i będące liczbami rzeczywistymi z przedziału [-1, 1].

Baza modeli jest niepewna jeżeli warunki modeli relacyjnych i warunki startowe modeli są niepewnymi zmiennymi łańcuchowymi o inkludach mogących przyjmować wartości zwane współczynnikami pewności (CF), będące liczbami rzeczywistymi z przedziału [-1, 1].

Celem wnioskowania rozwiniętego niepewnego wstecz jest ocena hipotezy wskazanej przez użytkownika, tzn. wyznaczenie współczynnika pewności tej hipotezy, na podstawie znajomości bazy reguł niepewnej, bazy modeli niepewnej, bazy ograniczeń dokładnej, bazy ograniczeń niepewnej oraz współczynników pewności warunków dopytywalnych i wartości liczbowych argumentów dopytywalnych.

Oceniana hipoteza musi być wnioskiem conajmniej jednej reguły bazy reguł lub wnioskiem conajmniej jednego modelu relacyjnego bazy modeli.

Ocenianie hipotezy kończy się zawsze wyznaczeniem jej współczynnika pewności.

Rozróżnia się:

    • hipotezy w sensie wąskim, którymi mogą być wnioski dowolnych reguł bazy reguł i wnioski dowolnych modeli relacyjnych bazy modeli, nie będące zarazem warunkami innych reguł i argumentami innych modeli;
    • hipotezy w sensie szerokim, którymi mogą być wnioski dowolnych reguł bazy reguł i wnioski dowolnych modeli relacyjnych bazy modeli.


Baza reguł rozwinięta niepewna

Baza reguł rozwinięta niepewna dla bazy wiedzy o nazwie NBW nazywa się RENBW.BRN i zawiera w ogólnym przypadku klauzule o postaci:

reguła(Numer_Reguły,"Wniosek",Lista_Warunków,Semafor_Wyświetlania,
"CF_Reguły")

fakt("Warunek_dopytywalny","CF_Warunku_dopytywalnego")

oraz:

reguła_dysjunktywna("Wniosek")

Argumenty reguły są następujące:

    1. Numer_Reguły jest liczbą całkowitą, różną dla różnych reguł i różną od numerów modeli;
    2. "Wniosek" jest nieukonkretniona niepewną zmienną łańcuchową, przedstawiającą wniosek reguły. Np. wniosek "Udziel kredyt" oznacza, że Udziel kredyt jest zmienną niepewną, której można przyporządkować pewna wartość współczynnika pewności, np. 0.6.
    3. Lista_Warunków jest listą nieukonkretnionych lub ukonkretnionych niepewnych zmiennych łańcuchowych przedstawiających warunki reguły, np.:

      Lista_Warunków = ["Warunek_1","Warunek_2","Warunek_3"],

      gdzie "Warunek_i" jest nieukonkretniona niepewną zmienną łańcuchową, przedstawiającą warunek Warunek_i reguły.
      Każdemu warunkowi Warunek_i zostaje koniec końców przyporządkowany współczynnik pewności CF_Warunek_i, będący liczbą rzeczywistą z przedziału [-1,1].

      Warunek zanegowany dla warunku A jest oznaczany nA. Współczynnik pewności warunku zanegowanego jest przez system przyjmowany jako ujemna wartość wsxpółczynnika pewności niezanegowanego warunku:

      CF(nA) = -CF(A)

      Dla warunków dopytywalnych współczynnik pewności jest deklarowany przez użytkownika w trakcie wnioskowania lub w trakcie konstrukcji bazy reguł za pomocą klauzuli fakt(_,_).
      Dla warunków niedopytywalnych współczynnik pewności jest wyznaczany przez system wnioskujący w trakcie wnioskowania.

      CF_Warunek_i=1 oznacza, że Warunek_i jest całkowicie prawdziwy.
      CF_Warunek_i=-1 oznacza, że Warunek_i jest całkowicie nieprawdziwy.
      Pośrednie wartości CF_Warunek_i odpowiadają sytuacjom, gdy brak nam pewności odnośnie do prawdziwości warunku Warunek_i.

      Stosowanie dodatnich i ujemnych wartości CF_Warunek_i umożliwia modelowanie zarówno sytuacji, dla których Warunek_i wspiera Wniosek jak i sytuacji, dla których Warunek_i osłabia Wniosek.

      Lista_Warunków ma współcznnik pewności CF(Lista_warunków) określony wyrażeniem::

      CF(Lista_Warunków) =
      Minimum(CF_Warunek_1,...,CF_Warunek_n)

    4. Semafor_Wyświetlania jest liczbą całkowitą, która:
      • powinna być równa 0 jeżeli nie chcemy wyświetlania informacji o stosowaniu reguły w trakcie wnioskowania,
      • powinna być równa 1 jeżeli informacja o stosowaniu reguły ma być wyświetlana w trakcie wnioskowania.
    5. "CF_Reguły" jest ukonkretnioną niepewną zmienną łańcuchową; jej wartość jest współczynikiem pewności reguły, będącym miarą pewności przywiązywanej do regułę.

      Np. dla dwóch reguł bazy reguł dotyczącej zasad przyznawania kredytów:

      reguła(1,"Udziel kredyt",["Bardzo dobre zabezpieczenie",
      "Bardzo dobra reputacja"],_,"0.9")

      reguła(2,"Udziel kredyt",["Dobre zabezpieczenie",
      "Dobra reputacja"],_,"0.4")

      wartości współczynników pewności reguł odzwierciedlają intuicyjną oczywistość tego, że jeżeli jest Bardzo dobre zabezpieczenie i Bardzo dobra reputacja, to udzielimy kredyt z większą pewnością tego, że nasza decyzja jest poprawna, aniżeli w przypadku gdy jest tylko Dobre zabezpieczenie i Dobra reputacja.

Zmienna niepewna Wniosek ma współczynnik pewności CF(Wniosek) określony następująco:

    1. Jeżeli CF(Lista_Warunków) >= 0 lub CF_Reguły >= 0 a reguła jest regułą dysjunktywną lub jeżeli (niezależnie od znaków CF(Lista_Warunków) i CF_Reguły) reguła jest kumulatywna, to:

      CF_Wniosku = CF(Lista_Warunków) * CF_Reguły.

      Tego typu wyznaczanie współczynnika pewności wniosku będzie się nazywać standardowym.

      Jeżeli CF_Wniosek > 0, to mówimy, że reguła jest niepewnie spełniona. Z powyższego wynika, że:
        • CF_Reguły=1 oznacza, że Wniosek jest prawdziwy dokładnie w takim stopniu, w jakim jest prawdziwa Lista_warunków; innymi słowy - Lista_warunków wspiera całkowicie pewność Wniosku swoją pewnością;
        • CF_Reguły=-1 oznacza, że Wniosek jest nieprawdziwy dokładnie w w tym stopniu, w jakim jest prawdziwa Lista_warunków; innymi słowy - Lista_warunków wspiera całkowicie pewność zanegowanego wniosku swoją pewnością.
        • Pośrednie wartości CF_Reguły odpowiadają pośrednim sytuacjom częściowego wspierania pewności wniosku pewnością listy warunków.
      Stosowanie dodatnich i ujemnych wartości CF_Reguły umożliwia modelowanie zarówno sytuacji, dla których Lista_warunków wspiera Wniosek jak i sytuacji, dla których Lista_warunków osłabia Wniosek.
    2. Jeżeli CF(Lista_Warunków) < 0 i CF_Reguły <= 0 a reguła jest regułą dysjunktywną, to zostaje pominięta. Ujemne CF(Lista_Warunków) i CF_Reguły nie mogą bowiem służyć dla reguł dysjunktywnych do wyznaczania dodatniego współczynnika pewności warunku.

W trakcie wnioskowania rozwiniętego niepewnego wyświetla się współczynniki pewności wniosków wszystkich reguł, niezleżnie od tego, czy CF ich wniosków są dodatnie, czy też ujemne.

Jeżeli dla reguł dysjunktywnych lub kumulatywnych został wyznaczony wypadkowy współczynnik wniosku CF(Wniosek), to system wyznacza współczynnik pewności zanegowanego wniosku nWniosek jako:

CF(nWniosek) = -CF(Wniosek)

Klauzule:

fakt("Warunek dopytywalny","CF_Warunku_dopytywalnego")

służą do zadeklarowania współczynnika pewności warunku dopytywalnego Warunek dopytywalny. Klauzulę taka umieszcza sie w bazie reguł, jeżeli przy wielokrotnym korzystaniu z bazy reguł Warunek dopytywalny ma niezmiennie tę samą wartość współczynnika pewności. Wnioskowanie rozpoczyna się zawsze od przedstawienia współczynników pewności warunków dopytywalnych zadeklarowanych w bazie reguł za pomocą klauzul fakt(_,_).

Jeżeli Warunek dopytywalny nie zostanie zadeklarowany w klauzuli fakt(_,_), to w odpowiednim miejscu system wnioskujący zapyta się użytkownika o wartość współczynnika pewności tego warunku. Wnioskowanie rozpoczyna się zawsze od przedstawienia współczynników pewności warunków dopytywalnych zadeklarowanych w bazie reguł za pomocą klauzul fakt(_,_).

Klauzule:

reguła_dysjunktywna("Wniosek")

zawierają wnioski reguł dysjunktywnych. Klauzule te informują system wnioskujący, że tylko jedna z reguł o tym samym wniosku Wniosek powinna zostać finalnie uwzględniona.

Domyślnie wszystkie reguły o jednakowych wnioskach, których wnioski nie zostały wymienione w klauzulach reguła_dysjunktywna(_), uważa się za reguły kumulatywne.

Kolejność reguł w bazie reguł może być dowolna. W szczególności, reguły dla tych samych wniosków nie muszą sąsiadować. Ze względu na przejrzystość i czytelność bazy reguł dobrze jest jednak zadbać o to, by reguły o jednakowych wnioskach sąsiadowały.

Kolejność warunków w liście warunków może być dowolna. Deklarowanie warunków nie wymaga uprzedniego deklarowania atrybutów, dla których warunki te są wartościami. Należy jednak pamiętać, że pierwszy Warunek z Listy_warunków będzie testowany jako pierwszy.

Deklarowanie warunków nie wymaga uprzedniego deklarowania atrybutów, których wartości są zawarte w warunkach. W stosowanych bazach reguł atrybuty te są częścią warunku, który jest postaci: Atrybut ma wartość jakąś tam z współczynnikiem pewności jakimś tam, np. Moc urządzenia < 20 W z CF=0.7. Dzięki temu wszystkie warunki są zmiennymi niepewnymi.

Reguły bazy reguł mogą się zagnieżdżać, tzn. Wnioski reguł mogą:

    • występować w Listach_warunków innych reguł w postaci prostej (Wniosek) oraz zanegowanej (nWniosek), oraz
    • występować jako warunki startowe modeli w postaci prostej (Wniosek) oraz zanegowanej (nWniosek). Ilustruje to następujący przykład:

      reguła(1,"Wyjadę na urlop za granicę",["Dostanę urlop",
      "Stać mnie na urlop za granicą"],1,CF_1)

      reguła(2,"Zwiększenie poziomu stresu",
      ["nWyjadę na urlop za granicę"],1,CF_2)

      dla których CF_1 > 0 i CF_2 > 0.

Głębokość zagnieżdżania może być praktycznie dowolna.

Istnieje nadal możliwość zagnieżdżania z niejawną negacją, wynikajaca z z mechanizmu prztewarzania współczynników pewności. Ilustruje to następujący przykład reguły

reguła(1,"Wyjadę na urlop za granicę",["Dostanę urlop",
"Stać mnie na urlop za granicą"],1,CF_1)

dla której oczywiście CF_1 > 0. Jeżeli zaistnieje potrzeba reguły z wnioskiem Zwiększenie poziomu stresu, dla której będzie CF(Zwiększenie poziomu stresu) > 0 jeżeli nie wyjadę na urlop za granicę, to reguła ta może mieć postać:

reguła(2,"Zwiększenie poziomu stresu",
["Wyjadę na urlop za granicę"],1,CF_2)

dla której CF_2 < 0. Wówczas bowiem dla CF(Wyjadę na urlop za granicę) < 0 będzie CF(Zwiększenie poziomu stresu) > 0.

Możliwość ta prowadzi jednak do słabo czytelnych reguł. Dlatego lepiej stosować zagnieżdżanie z negacją.

Możliwość zagnieżdżania reguł sprawia, że wszystkie warunki można przydzielić do jednej z dwóch kategorii:

    1. Warunki dopytywalne są warunkami nie będącymi wnioskami innych reguł. System szuka wartości CF dla warunków dopytywalnych w deklaracjach fakt(_,_), a jeżeli ich tam nie znajdzie, to pyta o nie użytkownika w odpowiednim miejscu wnioskowania.
    2. Warunki niedopytywalne są warunkami będącymi wnioskami innych reguł. Wartości CF dla warunków niedopytywalnych nie są deklarowane przez użytkownika, lecz wynikają z wnioskowania.

Jest oczywiste, że aby rozpocząć wnioskowanie w przypadku braku bazy modeli, baza reguł musi zawierać przynajmniej jedną regułę zawierającą tylko warunki dopytywalne.

Wnioskowanie rozpoczyna się zawsze od przedstawienia współczynników pewności warunków dopytywalnych zadeklarowanych w bazie reguł za pomocą klauzul fakt(_,_). Klauzule:

regula_dysjunktywna("Wniosek")

zawierają wnioski reguł dysjunktywnych. Klauzule te informują system wnioskujący, że tylko jedna z reguł o tym samym wniosku Wniosek powinna zostać finalnie uwzględniona.

Domyślnie reguły o jednakowych wnioskach, których wnioski nie zostały wymienione w klauzulach regula_dysjunktywna(_) uważa się za reguły kumulatywne.

Każda baza wiedzy musi zawierać bazę reguł. W szczególnym przypadku, gdy cała wiedza dziedzinowa jest zawarta w bazie modeli, baza reguł może zawierać jedną "regułę trywialną":

reguła(0," ",["bez warunku"],0,"1")

Zerowy Semafor wyświetlenia sprawi, ze "reguła" ta nie bedzie cytowana.


Algebra współczynników pewności

Obliczanie współczynników pewności wniosków reguł jest dokonywane w oparciu o zmodyfikowaną stanfordzką algebrę współczynników pewności.

Jej stosowanie wymaga następujących założeń:

    1. Każda reguła bazy reguł ma odpowiadający jej współczynnik pewności reguły CF_reguły, będący liczbą rzeczywistą z przedziału [-1, 1]. Współczynnik ten jest subiektywną miarą pewności reguły.
    2. Użytkownik systemu musi każdemu warunkowi dopytywalnemu przyporządkować współczynnik pewności warunku CF_warunku, będący liczbą rzeczywistą z przedziału [-1, 1]. Współczynnik ten jest subiektywną miarą pewności tego, że warunek jest niepewnie prawdziwy (CF_warunku>0) lub niepewnie nieprawdziwy (CF_warunku<=0).
    3. Użytkownik systemu musi każdemu wnioskowi spełnionego modelu relacyjnego przyporzadkować współczynnik pewności wniosku CF_wniosku>0, będący subiektywną miarą jakości spełnienia relacji.
    4. Użytkownik systemu musi dla każdego wniosku Wniosek niespełnionego modelu relacyjnego określić współczynnik pewności wniosku nWniosek modelu odwrotnego, którego ujemna wartość zostanie przez system wykorzystana do wyznaczenia współczynnika pewności wniosku pierwotnego, jak poniżej:

      CF("Wniosek") = - CF("nWniosek")

Definiuje się następujące działania:

    1. Wyznaczenie współczynnika pewności listy warunków.
      Jeżeli:

      Lista_warunków = ["Warunek_1,...,Warunek_i",...,"Warunek_n"]

      a kolejne warunki mają następujące współczynniki pewności:

      CF_Warunek_1,...,CF_Warunek_i,...,CF_Warunek_n

      to najmniejsza wartość współczynnika pewności warunków z listy warunków określa współczynik pewności całej listy:

      CF_Listy_Warunkow =
      Minimum(CF_Warunek_1,...,CF_Warunek_i,...,CF_Warunek_n)

      Nazywa się to często zasadą łańcucha: wytrzymałość łańcucha jest określana wytrzymałością jego najsłabszego ogniwa.
    2. Wyznaczenie współczynnika pewności wniosku pojedynczej reguły:
      • Jeżeli CF_Listy_Warunkow >= 0 lub CF_Reguły >= 0 a reguła jest regułą dysjunktywną lub jeżeli (niezależnie od znaków CF_Listy_Warunkow i CF_Reguły) reguła jest kumulatywną, to:

        CF_Wniosku = CF_Listy_Warunkow * CF_Reguły

        Sens pojedynczej reguły jest więc następujący:
        Wniosek jest niepewnie prawdziwy z współczynnikiem pewności CF_Wniosku.
        Jeżeli CF_Wniosek > 0, to mówimy, że reguła jest niepewnie spełniona.
        Jeżeli CF_Wniosek <=0, to mówimy, że reguła jest niepewnie niespełniona.
      • Jeżeli CF_Listy_Warunkow < 0 i CF_Reguły < 0, a reguła jest regułą dysjunktywną, to zostaje pominięta. Dla reguł dysjunktywnych jest bowiem niedopuszczalne, by ujemny współczynnik pewności reguły i ujemny współczynnik pewności listy warunków dał dodatni współczynnik pewności wniosku: reguły dysjunktywne o ujemnych współczynnikach pewności reguły służą bowiem tylko do generowania ujemnych współczynników pewności wniosków.
    3. Reguły o tym samym wniosku.
      W przypadku dwóch (lub więcej) reguł o tym samym Wniosku, należy je sformułować tak, by były one albo kumulatywne, albo dysjunktywne:
      • Reguły o tym samym wniosku są regułami kumulatywnymi jeżeli mają niezależne listy warunków. Niezależność list warunków oznacza że współczynniki pewności warunków tych list mogą mieć dowolne dopuszczalne wartości, np.:

        reguła(20,"Zaproponują mi awans do centrali",
        ["Odpowiedni współczynnik inteligencji"],_,"0.3")

        reguła(21,"Zaproponują mi awans do centrali",
        ["Odpowiednia znajomość angielskiego"],_,"0.2")

        Niezależność oznacza, że współczynnik pewności warunku Odpowiedni współczynnik inteligencji nie ma żadnego wpływu na współczynnik pewności warunku Odpowiednia znajomość angielskiego i vice versa.

        Z niezależności list warunków wynika kumulatywność: wypadkowy współczynnik pewności wniosku zależy od współczynnika pewności wniosku każdej z reguł kumulatywnych.

        Za szczególny przypadek reguł kumulatywnych uważa się reguły o pojedynczym wniosku. Reguła taka jest więc przetwarzana zgodnie z zasadami sformułowanymi dla reguł kumulatywnych.

      • Reguły o tym samym wniosku są regułami dysjunktywnymi jeżeli mają wyłącznie zależne listy warunków. Zależność list warunków oznacza, że współczynniki pewności list warunków nie mogą przyjmować całkowicie dowolnych wartości. Przykładem mogą być reguły dysjunktywne:

        reguła(4,"Efekty finansowe",
        ["Bardzo duży zysk"],1,"0.5")

        reguła(5,"Efekty finansowe",["Duży zysk"],1,"0.4")

        reguła(6,"Efekty finansowe",["Mały zysk"],1,"0.2")

        reguła(7,"Efekty finansowe",["Strata"],1,"-0.8")

        Zależność list warunków dla tego przykładu oznacza, że współczynniki pewności warunków Bardzo duży zysk, Duży zysk, Mały zysk i Straty nie mogą być całkowicie dowolne; np. jeżeli CF(Straty)>0, to CF(Bardzo duży zysk)=-1, CF(Duży zysk)=-1 i CF(Mały zysk)=-1. Nie może zaś być CF(Straty)>0, CF(Bardzo duży zysk)>0, CF(Duży zysk)>0 i CF(Mały zysk)>0.

      Należy podkreślić, że:
      • stosowanie reguł o wspólnym wniosku, nie będących ani kumulatywnymi ani dysjunktywnymi, prowadzi do błędnych wniosków;
      • na drodze odpowiedniego wyboru reguł i definiowania wniosków pośrednich można zawsze otrzymać reguły o tym samym wniosku będące albo kumulatywnymi albo dysjunktywnymi. Ilustruje to np. tworzenie - z bazy REDYR.BED - bazy REDYR.BRN.

    4. Wyznaczenie współczynnika pewności dla wspólnego wniosku dwóch reguł kumulatywnych odbywa się na drodze działania zwanego kumulowaniem współczynników pewności. Kumulowanie odbywa się następująco:
      • Jeżeli dla dwóch reguł kumulatywnych:

        reguła(N1,"Wniosek",Lista_Warunków_1,_,
        "CF_Reguły_N1")

        reguła(N2,"Wniosek",Lista_Warunków_2,_,
        "CF_Reguły_N2")

        współczynniki pewności wspólnego wniosku są równe odpowiednio CF_N1_Wniosek > 0 i CF_N2_Wniosek > 0, to wypadkowy CF_Wniosek będzie równy:

        CF_Wniosek = CF_N1_Wniosek + CF_N2_Wniosek - CF_N1_Wniosek * CF_N2_Wniosek.

        A więc:
        Dodatkowy wniosek z dodatnią wartością CF dla reguły kumulatywnej zwiększa pewność zaistnienia tego wniosku. Pewność ta nie będzie jednak nigdy większa od wartości CF=1.
      • Jeżeli dla dwóch reguł kumulatywnych:

        reguła(N1,"Wniosek",Lista_Warunków_1,_,
        "CF_Reguły_N1")

        reguła(N2,"Wniosek",Lista_Warunków_2,_,
        "CF_Reguły_N2")

        współczynniki pewności wspólnego wniosku są równe odpowiednio CF_N1_Wniosek < 0 i CF_N2_Wniosek < 0, to wypadkowy CF_Wniosek będzie równy:

        CF_Wniosek = CF_N1_Wniosek + CF_N2_Wniosek + CF_N1_Wniosek * CF_N2_Wniosek.

        A więc:
        Dodatkowy wniosek z ujemną wartością CF dla reguły kumulatywnej zmniejsza pewność zaistnienia tego wniosku. Pewność ta nie może jednak nigdy być mniejszą od wartości CF=-1.
      • Jeżeli dla dwóch reguł kumulatywnych:

        reguła(N1,"Wniosek",Lista_Warunków_1,_,
        "CF_Reguły_N1")

        reguła(N2,"Wniosek",Lista_Warunków_2,_,
        "CF_Reguły_N2")

        współczynniki pewności wspólnego wniosku są równe odpowiednio CF_N1_Wniosek > 0 i CF_N2_Wniosek < 0, lecz CF_N1_Wniosek to wypadkowy CF_Wniosek będzie równy:

        CF_Wniosek = (CF_N1_Wniosek + CF_N2_Wniosek)/
        [1-min(|CF_N1_Wniosek|,|CF_N2_Wniosek|)]

        A więc, zgodnie z intuicynym oczekiwaniem:
        • Im większa pewność, tym mniejszy wpływ ma na nią niewielka niepewność. Na całkowitą pewność nie ma żadnego wpływu niepewność niecałkowita.

        • Im większa niepewność, tym mniejszy wpływ ma na nią niewielka pewność. Na całkowitą niepewność nie ma żadnego wpływu pewność niecałkowita.

      • Jeżeli dla dwóch reguł kumulatywnych:

        reguła(N1,"Wniosek",Lista_Warunków_1,_,
        "CF_Reguły_N1")

        reguła(N2,"Wniosek",Lista_Warunków_2,_,
        "CF_Reguły_N2")

        współczynniki pewności wspólnego wniosku są równe odpowiednio CF_N1_Wniosek = 1 i CF_N2_Wniosek = -1, to wypadkowy CF_Wniosek będzie równy:

        CF_Wniosek = 0

        A więc, zgodnie z intuicynym oczekiwaniem:
        Jeżeli z równą pewnością wniosek jest całkowicie prawdziwy dla jednej reguły kumulatywnej i całkowicie nieprawdziwy dla drugiej reguły kumulatywnej, to nic nie można powiedzieć o pewności wniosku.
      • W przypadku większej liczby reguł kumulatywnych o współczynnikach pewności wniosku z tym samym znakiem korzysta się z wymienionej zasad najpierw dla dwóch reguł, otrzymany współczynnik pewności kumuluje się z współczynnikiem pewności wniosku dla trzeciej reguły, itd.
      • IW przypadku większej liczby reguł kumulatywnych o współczynnikach pewności wniosku z różnymi znakam,i postępuje się następująco:
        • kumuluje się współczynnik pewności wniosku dla reguł, dla których jest on dodatni, otrzymując CF_wypadkowy_dodatni;
        • kumuluje się współczynnik pewności wniosku dla reguł, dla których jest on ujemny, otrzymując CF_wypadkowy_ujemny;
        • kumuluje się współczynniki pewności CF_wypadkowy_dodatni i CF_wypadkowy_ujemny, otrzymując CF_wypadkowy.
        Takie postępowanie zapewnia jednoznaczność wypadkowego współczynnika pewności. Przedstawione działania uzasadniają jeszcze jedną interpretację współczynników pewności w przypadku reguł kumulatywnych można uważać je za współczynniki wagi, określające względny wpływ, który ma Lista_Warunków_1 i Lista_Warunków_2 na wspólny Wniosek.

    5. Wyznaczenie współczynnika pewności dla wspólnego wniosku reguł dysjunktywnych odbywa się zgodnie z następującymi zasadami:
      • Jak już wspomniano, reguły dysjunktywne o ujemnych współczynnikach pewności, dla których w trakcie wnioskowania współczynnik pewności listy warunków przyjmuje wartości ujemne, są w dalszym ciągu wnioskowania pomijane. Zasadę tę można prosto uzasadnić na przytoczonym już przykładzie reguł dysjunktywnych:

        reguła(4,"Efekty finansowe",
        ["Bardzo duży zysk"],1,"0.5")

        reguła(5,"Efekty finansowe",["Duży zysk"],1,"0.4")

        reguła(6,"Efekty finansowe",["Mały zysk"],1,"0.2")

        reguła(7,"Efekty finansowe",["Strata"],1,"-0.8")

        Jeżeli CF(Strata)=-1, CF(Mały zysk)=0.3, CF(Duży zysk)=-1 and CF(Bardzo duży zysk)=-1, wtedy CF(Efekty finansowe) należy wyznaczyć z reguły 3 jako równe 0.06, natomiast nie z reguły 4 jako równe 0.8.
        Innymi słowy: reguła dysjunktywna o ujemnym współczynniku pewności nie może być stosowana do generowania dodatniego współczynnika pewności wniosku, lecz jedynie do generowania ujemnego współczynnika pewności wniosku. Będziemy to nazywać zasadą równoczesnej nieujemności CF reguły i CF warunków reguł dysjunktywnych.
      • Jeżeli dla reguł dysjunktywnych, które nie zostały pominięte w wyniku zastosowania zasady równoczesnej nieujemności, listy warunków mają współczynniki pewności jednakowych znaków, wypadkowy współczynnik pewności wniosku jest największym z pośród współczynników pewności wniosków reguł (zasada maksymalnego współczynnika pewności dla wszystkich reguł). Zasadę tę ilustrują następujące przykłady:

        Przykład 1:

        reguła(2,"Wniosek",["A"],1,"0.9") --> CF("Wniosek")=0.63

        reguła(3,"Wniosek",["B","C"],1,"0.8") --> CF("Wniosek")=0.64

        reguła(4,"Wniosek",["D"],1,"0.6") --> CF("Wniosek")=0.3

        reguła_dysjunkitywna("Wniosek")

        fakt("A","0.7")

        fakt("B","0.8")

        fakt("C","0.9")

        fakt("D","0.5")

        Wnioski wszystkich reguł mają dodatni CF wniosku, maksymalny jest dla reguły 3 równy 0.64; dlatego wypadkowy współczynnik pewności CF(Wniosek)=0.64.

        Przykład 2:

        reguła(2,"Wniosek",["A"],1,"0.9") --> CF("Wniosek")=0.63

        reguła(3 "Wniosek",["B", "C"],1,"0.8") --> CF("Wniosek")=0.63

        reguła(4 "Wniosek",["D"],1,"0.6") --> CF("Wniosek")=0.63

        reguła_dysjunkitywna("Conc")

        fakt("A","-0.7")

        fakt("B","-0.8")

        fakt("C","-0.9")

        fakt("D","-0.5")

        Wnioski wszystkich reguł mają ujemny CF wniosku, maksymalny jest dla reguły 3 równy -0.3; dlatego wypadkowy współczynnik pewności CF(Wniosek_)=-0.3.

        Przykład 3 jest mniej abstrakcyjny i nawiązuje do sytuacji z bazy REKRE.BRN:

        reguła(26,"Złe zabezpieczenie",
        ["Zabezpieczenie I klasy (%)<60"],1,"0.9")

        reguła(27,"Złe zabezpieczenie",
        ["Zabezpieczenie I klasy (%)<70",
        "Zabezpieczenie II klasy (%)<10",],1,"0.8")

        reguła(28,"Złe zabezpieczenie",
        ["Zabezpieczenie I klasy (%)<70",
        "Zabezpieczenie III klasy (%)<30"],1,"0.7")

        reguła(29,"Złe zabezpieczenie",
        ["Zabezpieczenie I klasy (%)<100",
        "Zabezpieczenie II klasy (%)<30",
        "Zabezpieczenie III klasy (%)<30"],1,"0.4")

        reguła_dysjunkitywna("Złe zabezpieczenie")

        Jeżeli np.:

        Zabezpieczenie I klasy (%) = 50 oraz

        Zabezpieczenie II klasy (%) = 5 oraz

        Zabezpieczenie III klasy (%) = 20,

        to z każdej reguły wynika CF(Złe zabezpieczenie)>0 i wartość CF dla wspólnego wniosku będzie równa największej z tych wartości.

        Jeżeli zaś:

        Zabezpieczenie I klasy (%) = 80

        oraz

        Zabezpieczenie II klasy (%) = 35

        to z każdej reguły wynika CF(Złe zabezpieczenie)<0 i wartość CF dla wspólnego wniosku będzie także równa największej z tych wartości.
      • Jeżeli dla reguł dysjunktywnych, które nie zostały pominięte w wyniku zastosowania zasady równoczesnej nieujemności, listy warunków mają współczynniki pewności różnych znaków, wypadkowy współczynnik pewności wniosku jest największym z pośród współczynników pewności wniosków reguł o dodatnich współczynnikach pewności list warunków (zasada maksymalnego współczynnika pewności dla reguł o dodatnim CF_warunków). Zasadę tę ilustrują następujący przykład:

        Przykład 1:

        reguła(1,"Efekty finansowe",["Bardzo duży zysk"],1,"0.5")

        reguła(2,"Efekty finansowe",["Duży zysk"],1,"0.4")

        reguła(3,"Efekty finansowe",["Mały zysk"],1,"0.2")

        reguła(4,"Efekty finansowe",["Strata"],1,"-0.8")

        reguła_dysjunktywna("Efekty finansowe")

        fakt("Bardzo duży zysk","-1")

        fakt("Duży zysk","-1")

        fakt("Mały zysk","-1")

        fakt("Strata","0.6")

        Z reguł wynika:

        reguła 1 --> CF(Efekty finansowe) = –0.5

        reguła 2 --> CF(Efekty finansowe) = –0.4

        reguła 3 --> CF(Efekty finansowe) = –0.2

        reguła 4 --> CF(Efekty finansowe) = –0.48

        Uwzględniając tylko regułę 4 ako jedyną o dodatniej wartości CF listy warunków, otrzymuje się:

        CF(Efekty finansowe) = –0.48

        Wynik ten jest poprawny: mamy bowiem straty i współczynnik pewności dla efektów finansowych powinien być wyznaczony tylko dla reguły 4.

    6. System wnioskujący jest informowany o regułach dysjunktywnych na drodze wprowadzania do bazy reguł deklaracji reguła_dysjunktywna("Wniosek"). Reguły o wspólnym wniosku nie wyróżnione taką deklaracją są uważane za reguły kumulatywne. Dlatego reguły o pojedynczym wniosku są przez system przetwarzane tak, jak reguły kumulatywne.
    7. Współczynnik pewności warunku dopytywalnego negowanego jest równy dopełnieniu do zera współczynnika pewności warunku nienegowanego:

      CF("Negowany Warunek Dopytywalny") =
      CF("Warunek Dopytywalny")

    8. Ponieważ wartości CF pochodzą zazwyczaj z dosyć prymitywnego pomiaru, nadmierna liczba znaczących pozycji po przecinku, uzyskana w wyniku wykonywania na wartościach CF operacji arytmetycznych, jest bez sensu. Dlatego też wyniki tych operacji bedą zaokrąglane i obcinane do dwóch pozycji po przecinku.


Baza modeli rozwinięta niepewna

Baza modeli rozwinięta niepewna dla bazy wiedzy o nazwie NBW nazywa się MONBW.BRN i składa się w ogólnym przypadku z modeli rozwiniętych podstawowych, rozwiniętych rozszerzonych, rozwiniętych liniowych i rozwiniętych wielomianowych oraz ze znanych wartości argumentów dopytywalnych i prawdziwych faktów modelowych.

Model rozwinięty niepewny jest:

    • unikatowy, jeżeli baza modeli nie zawiera innego modelu o tym samym Wyniku/Wniosku;
    • wielokrotny, jeżeli w bazie modeli jest conajmniej jeden inny model o tym samym Wyniku/Wniosku.

Dla wszystkich modeli rozwiniętych niepewnych:

    • Numer_Modelu jest liczbą całkowitą, różną dla różnych modeli i różną od numerów reguł;
    • "Warunek Startowy" jest zmienną łańcuchową niepewną, decydującą o stosowaniu modelu. Stosowanie modelu (tzn. wyznaczenie wartości zmiennej Wynik/Wniosek) jest możliwe jeżeli:
      • CF(Warunek Startowy) > 0 lub jeżeli
      • "Warunek Startowy" = "bez warunku";
      Warunek Startowy uważa się wówczas za spełniony. W przeciwnym przypadku jest niespełniony. Niespełnienie warunku startowego modelu rozwiniętego niepewnego skutkuje przerwaniem wnioskowania w momencie przejścia do obliczania tego modelu; towarzyszy temu odpowiedni komunikat.
      W bazach modeli rozwiniętych niepewnych Warunek startowy różny od bez warunku może być stosowany tylko dla modeli wielokrotnych, dla których wskazuje ten z modeli, który w danej sytuacji należy zastosować.

      Warunek Startowy danego modelu może być zarówno prostym jak i zanegfowanym wnioskiem reguły lub modelu relacyjnego.
    • Semafor_Wyświetlania jest liczbą całkowitą, równą:
      • 0 jeżeli nie chcemy wyświetlania informacji o stosowaniu modelu w trakcie wnioskowania
      • 1 jeżeli informacja to stosowaniu modelu ma być wyświetlana w trakcie wnioskowania.
------------------------------------------------------------------------------------
    1. Klauzule modeli podstawowych są postaci:

      model(Numer_Modelu,"Warunek Startowy","Wynik"/"Wniosek",
      "Pierwszy Argument","Operacja"/"Relacja","Drugi Argument",
      Semafor_Wyświetlania,"CF_Modelu")

      gdzie:
      • "Wynik"/"Wniosek" jest zmienną łańcuchową:
        • rzeczywistą Wynik w przypadku modelu arytmetycznego;
        • niepewną Wniosek w przypadku modelu relacyjnego;
      • "Pierwszy Argument" i "Drugi Argument" są zmiennymi łańcuchowymi rzeczywistymi, zarówno dla modeli arytmetycznych jak i dla modeli relacyjnych;
      • "Operacja"/"Relacja" jest łańcuchem znaków przedstawiającym:
        • symbol operacji arytmetycznej "Operacja" dla modeli arytmetycznych z dwoma argumentami. Możliwymi operacjami są: "+", "-" ,"*", "/", "=","div", "mod", "min", "max","%", "zaokrąglenie_do_N","A^N";
        • symbol operacji arytmetycznej Operacja dla modeli arytmetycznych z jednym argumentem. Możliwymi operacjami wykonywanymi na wartości Pierwszy Argument są: "sqrt", "sin", "cos", "tan", "arctan", "log", "ln", "exp", "round", "trunc", "abs" while "Second Argument"="0.0".
        • symbol relacji arytmetycznej Relacja dla modeli relacyjnych. Możliwymi relacjami pomiędzy Pierwszym Argumentem a Drugim Argumentem są: ">", "==", "<", ">=", "<=", "><", "<>";
      • CF_Modelu jest:
        • liczbą 1 w przypadku modeli arytmetycznych;
        • dowolnym stringiem, przedstawiającym nazwę współczynnika pewności relacji, którego wartość jest deklarowana przez użytkownika w trakcie wnioskowania (tzn. po obejrzeniu sposobu spełnienia relacji), w przypadku modeli relacyjnych.

      Sens modelu podstawowego jest następujący:
      • dla modelu arytmetycznego z dwoma argumentami: jeżeli Warunek Startowy jest spełniony, Wynik przedstawia liczbe rzeczywistą wyznaczoną przez Operację wykonaną na wartościach Pierwszego Argumentu i Drugiego Argumentu.
        Dla modelu arytmetycznego, dla którego Pierwszy Argument = Liczba_niezaokrąglona i Drugi Argument = N oraz Operacja = zaokrąglenie_do_N, Wynik przedstawia Pierwszy_Argument po zaokrągleniu (w górę lub w dół, zależnie od jego wartości) do N pozycji po kropce dziesiętnej;
      • dla modelu arytmetycznego z jednym argumentem: jeżeli Warunek Startowy jest spełniony, a Drugi Argument = 0, to Wynik przedstawia liczbę rzeczywistą wyznaczoną przez Operację wykonaną na wartości Pierwszego Argumentu;
      • dla modelu relacyjnego:
        • jeżeli Warunek Startowy jest spełniony i Relacja jest spełniona, to Wnioskowi zostaje przyporządkowana wartość CF_Modelu>0, zadeklarowana przez użytkownika w trakcie wnioskowania. Wartość ta jest dobierana przez użytkownika w zależności od stopnia spełnienia relacji.
        • jeżeli Warunek Startowy jest spełniony i Relacja nie jest spełniona, to Wnioskowi zostaje przyporządkowana ujemna wartość współczynnika pewności, zadeklarowanego przez użytkownika dla relacji przeciwnej określającej nWniosek
        • dla dowolnego modelu wielokrotnego: jeżeli Warunek_Startowy ma wartość logiczną nieprawda, zostaje pominięty w trakcie wnioskowania.
        • dla dowolnego modelu unikatowego: jeżeli Warunek_Startowy ma wartość logiczną nieprawda, następuje przerwanie wnioskowania w momencie przejścia do obliczania tego modelu; towarzyszy temu odpowiedni komunikat.

      -----------------------------------------------------------------------------------------

    2. Klauzule modeli rozszerzonych są postaci:

      model_r(Numer_Modelu,"Warunek Startowy","Wynik"/"Wniosek",
      "Operacja"/"Relacja",Lista_Argumentów,
      Semafor_Wyświetlania,"CF_Modelu")

      gdzie:
      • "Operacja"/"Relacja" jest łańcuchem znaków przedstawiającym:
        • symbol operacji arytmetycznej "Operacja" dla dowolnej liczby argumentów z Listy_Argumentów dla modeli arytmetycznych. Możliwymi operacjami są: "+", "*" ,"max_list","min_list";
        • symbol dwustronnej relacji arytmetycznej Relacja pomiędzy trzema elementami Listy_Argumentów dla modeli relacyjnych. Możliwymi relacjami są: "<,<", "<=,<", "<,<=", "<=,<=";
      • Lista_Argumentów jest:
        • listą zmiennych łańcuchowych rzeczywistych dla modelu arytmetycznego. Lista ta może byc dowolnie długa;
        • listą trzech zmiennych łańcuchowych rzeczywistych
          ["Ograniczenie Dolne",
          "Wartość Testowana",
          "Ograniczenie Górne"]
          charakteryzujących dwustronną relację dla modelu relacyjnego;
      • CF_Modelu jest:
        • liczbą 1 w przypadku modeli arytmetycznych;
        • dowolnym stringiem, przedstawiającym nazwę współczynnika pewności relacji, którego wartość jest deklarowana przez użytkownika w trakcie wnioskowania (tzn. po obejrzeniu sposobu spełnienia relacji), w przypadku modeli relacyjnych.

      Sens modelu rozszerzonego jest następujący:
      • dla modelu rozszerzonego arytmetycznego: jeżeli Warunek Startowy jest spełniony, to Wynik przedstawia liczbę rzeczywistą wyznaczoną przez Operację wykonaną na wartościach liczbowych wszystkich zmiennych łańcuchowych rzeczywistych z Listy_Argumentów;
      • dla modelu rozszerzonego relacyjnego:
        • jeżeli Warunek Startowy jest spełniony i Relacja jest spełniona, to Wnioskowi zostaje przyporządkowany współczynnik pewności równy wartości CF_Modelu>0, zadeklarowanej przez użytkownika w trakcie wnioskowania. Wartość ta jest dobierana przez użytkownika w zależności od stopnia spełnienia relacji;
        • jeżeli Warunek Startowy jest spełniony i Relacja nie jest spełniona, to Wnioskowi zostaje przyporządkowana ujemna wartość współczynnika pewności, zadeklarowanego przez użytkownika dla relacji przeciwnej określającej nWniosek
      • dla dowolnego modelu wielokrotnego: jeżeli Warunek_Startowy ma wartość logiczną nieprawda, zostaje pominięty w trakcie wnioskowania.
      • dla dowolnego modelu unikatowego: jeżeli Warunek_Startowy ma wartość logiczną nieprawda, następuje przerwanie wnioskowania w momencie przejścia do obliczania tego modelu; towarzyszy temu odpowiedni komunikat.

      ----------------------------------------------------------------------------------------

    3. Klauzule modeli liniowych są postaci:

      model_liniowy(Numer_Modelu,"Warunek Startowy","Wynik",
      Lista_Współczynników,Lista_Zmiennych,Semafor_Wyświetlania,"CF_Modelu")

      gdzie:
      • "Wynik" jest zmienną łańcuchową rzeczywistą odpowiadającą wartości formy liniowej;
      • Lista_Współczynników jest listą zmiennych łańcuchowych rzeczywistych, odpowiadających kolejnym współczynnikom formy liniowej. Liczba tych współczynników może być dowolna. Lista_Współczynników może być mieszana: część zmiennych rzeczywistych może być już ukonkretniona a część - nieukonkretniona;
      • Lista_Zmiennych jest listą zmiennych łańcuchowych rzeczywistych odpowiadających kolejnym zmiennym formy liniowej. Liczba tych zmiennych musi być równa liczbie współczynników z Listy_Współczynników
        Lista_Zmiennych może być mieszana: część zmiennych rzeczywistych może być już ukonkretniona a część - nieukonkretniona;
      • CF_Modelu jest liczbą 1. W przypadku modeli liniowych wyklucza się niepewność wyniku.

      Sens modelu liniowego jest następujący:
      • jeżeli Warunek Startowy jest spełniony, a wartości współczynników i wartości zmiennych zostały ukonkretnione, to:
        Wynik = A1*X1 + A2*X2 + ... + AN*XN
        gdzie:
        Lista_Współczynników = ["A1", "A2",...,"AN"]
        Lista_Zmiennych = ["X1", "X2",...,"XN"]
      • dla wielokrotnego modelu liniowego , jeżeli Warunek Startowy nie jest spełniony, to model zostaje pominięty w trakcie wnioskowania.
      • dla unikatowego modelu liniowego, jeżeli Warunek Startowy nie jest spełniony, następuje przerwanie wnioskowania w momencie przejścia do obliczania tego modelu; towarzyszy temu odpowiedni komunikat.

      --------------------------------------------------------------------------------------

    4. Klauzule modeli wielomianowych są postaci:

      model_wielomianowy(Numer_Modelu,"Warunek Startowy","Wynik",
      "Zmienna Wielomianu",Lista_Współczynników,Lista_Potęg,
      Semafor_Wyświetlania,"CF_Modelu")

      gdzie:
      • "Wynik" jest zmienną łańcuchową rzeczywistą odpowiadającą wartości wielomianu;
      • "Zmienna Wielomianu" iest zmienną łańcuchową rzeczywistą, odpowiadającą zmiennej rzeczywistej, dla której model wyznacza wartość "Wyniku";
      • Lista_Współczynników jest listą zmiennych łańcuchowych rzeczywistych, odpowiadających kolejnym współczynnikom wielomianu. Lista_Współczynników może być mieszana: część zmiennych rzeczywistych może być już ukonkretniona a część - nieukonkretniona;
      • Lista_Potęg jest listą liczb całkowitych, będących wykładnikami potęg, do których jest podnoszona Zmienna Wielomianu. Elementy tej listy odpowiadają kolejnym elementom Lista_Współczynników.
      • CF_Modelu jest liczbą 1. W przypadku modeli wielomianowych wyklucza się niepewność wyniku.

      Sens modelu wielomianowego jest następujący:
      • jeżeli Warunek Startowy jest spełniony, a wartości współczynników i wartość zmiennej zostały ukonkretnione, to:
        Wynik = A0 + A1*X + A2*X^2 + ... + AN*X^N
        gdzie
        Lista_Współczynników = ["A0","A1","A2",...,"AN"]
        Zmienna Wielomianu = X
        Lista_Potęg = [0, 1, 2,...,N]
      • jeżeli Warunek Startowy nie jest spełniony lub wartości współczynników i wartości zmiennych nie zostały ukonkretnione, to Wynik pozostaje nieukonkretniony.
      • dla wielokrotnego modelu wielomianowego, jeżeli Warunek Startowy nie jest spełniony, to model zostaje pominięty w trakcie wnioskowania.
      • dla unikatowego modelu wielomianowego, jeżeli Warunek Startowy nie jest spełniony, następuje przerwanie wnioskowania w momencie przejścia do obliczania tego modelu; towarzyszy temu odpowiedni komunikat.
------------------------------------------------------------------------------------

Model jest rozwiązywalny, jeżeli wszystkie jego argumenty zostały ukonkretnione.

Modele bazy modeli mogą zagnieżdżać się wewnątrz bazy modeli jak również zagnieżdżać się z regułami bazy reguł:

    • wyniki modeli arytmetycznych mogą być warunkami innych modeli arytmetycznych lub relacyjnych;
    • wnioski modeli relacyjnych mogą być warunkami startowymi innych modeli;
    • wnioski modeli relacyjnych mogą być warunkami reguł;
    • wnioski reguł mogą być warunkami startowymi modeli.

Jednakże dla baz rozwiniętych niepewnych wnioski modeli relacyjnych nie mogą występować w postaci zanegowanej w listach warunków reguł lub jako warunki startowe modeli.

Dopuszczalność zagnieżdżania modeli sprawia, że wszystkie argumenty bazy modeli można przydzielić do jednej z dwóch kategorii:

    1. Argumenty dopytywalne są argumentami nie będącymi wynikami innych modeli. System pyta użytkownika o wartości liczbowe argumentów dopytywalnych.
    2. Argumenty niedopytywalne są argumentami będącymi wynikami innych modeli. Wartości liczbowe argumentów niedopytywalnych nie są deklarowane przez użytkownika, lecz wynikają z wnioskowania.

Dopuszczalność zagnieżdżania modeli sprawia, że wszystkie warunki startowe bazy modeli można przydzielić do jednej z dwóch kategorii:

    1. Warunki startowe dopytywalne są warunkami nie będącymi wnioskami innych modeli relacyjnych ani wnioskami reguł bazy reguł. System pyta użytkownika o wartości logiczne dopytywalnych warunków startowych.
    2. Warunki startowe niedopytywalne są warunkami będącymi wnioskami innych modeli relacyjnych lub wnioskami reguł bazy reguł. Wartości logiczne niedopytywalnych warunków startowych nie są deklarowane przez użytkownika, lecz wynikają z wnioskowania. Warunek bez warunku. jest uznawany przez system ekspertowe za zawsze ptrawdziwy warunek niedopytywalny.

Jest oczywiste, że aby rozpocząć wnioskowanie, albo baza reguł musi zawierać przynajmniej jedną regułę zawierającą tylko warunki dopytywalne, albo baza modeli musi zawierać przynajmniej jeden model zawierający tylko argumenty i warunki dopytywalne.

Jeżeli wartości pewnych argumentów dopytywalnych nie ulegają zmianie w trakcie wielokrotnego korzystania z bazy modeli, można te wartości zadeklarować w bazie modeli za pomocą klauzul:

argument_znany("Argument_dopytywalny",Wartość)

gdzie:

    • Argument_dopytywalny jest zmienną łańcuchową rzeczywistą przedstawiającą nazwę tego argumentu stosowaną w bazie modeli;
    • Wartość jest wartością zmiennej rzeczywistej, przyporządkowaną wzmiankowanemu argumentowi dopytywalnemu.

Np.:

argument_znany("średnie zarobki w 2003 r.", 2200).

Jeżeli wartość argumentu dopytywalnego nie zostanie zadeklarowana za pomocą klauzuli argument_znany(_,_), to w odpowiednim miejscu system wnioskujący zapyta się użytkownika o wartość tego argumentu.

Wnioskowanie rozpoczyna się zawsze od przedstawienia wartości argumentów dopytywalnych zadeklarowanych w bazie modeli za pomocą klauzul argument_znany(_,_).

Jeżeli wartości pewnych dopytywalnych warunków startowych nie ulegają zmianie w trakcie wielokrotnego korzystania z bazy modeli, można je zadeklarować jako fakty modelowe za pomocą klauzul:

m_fakt("Dopytywalny_warunek_startowy","CF_warunku_dopytywalnego")

gdzie:

    • Dopytywalny_warunek_startowy jest zmienną niepewną;
    • CF_warunku_dopytywalnego jest współczynnikiem pewności
      Dopytywalnego_warunku_startowego

Jeżeli grupa modeli relacyjnych dla tej samej zmiennej ma wnioski wykluczające się do jednego lub wnioski wykluczające się do żadnego, a wnioski te są warunkami startowymi innych modeli, należy to zadeklarować za pomocą klauzuli:

modele_ekskluzywne(Lista_wniosków_wykluczających_się).


Baza ograniczeń rozwinięta niepewna

Baza ograniczeń rozwinięta dokładna

Baza ograniczeń rozwinięta dokładna dla bazy wiedzy niepewnej o nazwie NBW nazywa się OGNBW.BRN i zawiera klauzule:

ograniczenie(Numer_Ograniczenia, Lista_warunków)

gdzie:

      • Numer_Ograniczenia jest liczbą całkowitą, różną dla różnych ograniczeń lecz niekoniecznie różną od numerów reguł i modeli;
      • Lista_warunków jest listą niepewnych zmiennych łańcuchowych będących nazwami warunków dopytywalnych wzajemnie wykluczających się w sposób dokładny i całkowicie wyczerpujących zbiór możliwych wartości atrybutu (często domyślnego), któremu odpowiadają.

Przykładem może być:

ograniczenie(1,["Wiek <= 20","20 < Wiek <= 40","Wiek > 40"])

zawierające warunki dopytwalne wzajemnie wykluczające się w sposób dokładny i całkowicie wyczerpujące dla atrybutu Wiek. Oczywiście, tylko jeden z tych warunków może być dla konkretnej osoby prawdą.

Cel bazy ograniczeń jest dwojaki:

    1. Umożliwienie użytkownikowi definiowanie zbiorów dokładnych wykluczających się warunków dopytywalnych. Jeżeli potrzebne są dokładne warunki dopytywalne, należy je zdefiniować korzystając z bazy ograniczeń dokładnych. Dotyczy to również warunków dychotomicznych. Przykładem może być ograniczenie:

      ograniczenie(1,"dostanę urlop","nie dostanę urlopu")

      Jeżeli zrezygnujemy z tego ograniczenia korzystając z przedrostka n i posługując się warunkami dopytywalnymi dostanę urlop oraz ndostanę urlop, zmienne te nie będą przez system wnioskujący rozwinięty niepewny uważane za zmienne dokładne którym można przyporządkować tylko wartości CF równe 1 lub -1; będą mogły im zostać przyporządkowane (w wyniku nieuwagi uzytkownika) wartości CF z pełnego zakresu
      [-1,...,1], co może skutkować błędnym wnioskowaniem.

    2. Zapobieżenie zadawaniu przez system pytań o warunki,których wartości CF wynikają z odpowiedzi już poprzednio udzielonych.

Obecność bazy ograniczeń dokładnych nie jest konieczna dla przeprowadzania wnioskowania. Przebieg wnioskowania może jednak wtedy być irytujący ze względu na zadawanie przez system niepotrzebnych pytań.


Baza ograniczeń rozwinięta niepewna

Baza ograniczeń rozwinięta niepewna dla bazy wiedzy o nazwie NBW nazywa się ONNBW.BRN i zawiera klauzule:

ograniczenie_n(Numer_Ograniczenia, Lista_warunków_niepewnych)

gdzie:

    • Numer_Ograniczenia jest liczbą całkowitą, różną dla różnych ograniczeń lecz niekoniecznie różną od numerów reguł i modeli;
    • Lista_warunków_niepewnych jest listą niepewnych zmiennych łańcuchowych będących nazwami warunków dopytywalnych wzajemnie niepewnie wykluczających się i całkowicie wyczerpujących zbiór możliwych wartości atrybutu (często domyślnego), któremu odpowiadają.

Przykładem może być:

ograniczenie_n(1,["Brak znajomości angielskiego","Słaby angielski",
"Dostateczny angielski","Dobry angielski","Bardzo dobry angielski"])

zawierająca warunki dopytywalne niepewne dla domyślnego atrybutu znajomość angielskiego. W odróżnieniu od bazy ograniczeń dokładnej, użytkownik jest tym razem pytany o wartości CF dla wszystkich warunków dopytywalnych z Listy_warunków_niepewnych, każdy z których może przyjmować wartości CF z całego przedziału [-1.1].

Najczęściej tylko jeden z warunków wymienionych w Liście_warunków będzie zazwyczaj miał najwiekszą wartość CF w porównaniu z pozostałymi.

Celem bazy ograniczeń niepewnej jest :

    • poinformowania użytkownika o zbiorze niepewnych warunków dopytywalnych charakterzyujących określony niepewny atrybut;
    • definiowanie par dychotomicznych warunków dopytywalnych. Jeżeli np. dla pewnych reguł warunkiem dopytywalnym jest dobra reputacja, a dla innych zła reputacja, i nie ma innych warunków dla atrybutu reputacja, to moźna utworzyć ograniczenie niepewne:

      ograniczenie_n(2,["dobra reputacja","zła reputacja"])

      informujące system ekspertowy, że niepewny warunek dopytywalny zła reputacja jest negacją niepewnego warunku dopytywalnego dobra reputacja i vice versa. To znaczy, że:

      CF(zła reputacja) = - CF(dobra reputacja)

Obecność bazy ograniczeń niepewnej nie jest konieczna dla przeprowadzania wnioskowania, lecz upraszcza je.


Baza grafiki rozwinięta niepewna

Baza grafiki dla bazy wiedzy o nazwie NBW nazywa się GRNBW.BRN i zawiera klauzule:

grafika(Numer,"Nazwa_grafiki.bmp")

ngrafika(Numer,"Nazwa_ngrafiki.bmp")

gdzie:

    • Numer jest liczbą naturalną równa numerowi reguły bądź modelu relacyjnego, dla którego ma być wyświetlana grafika w trakcie procesu wnioskowania;
    • Nazwa_grafiki.bmp jest nazwą pliku graficznego z rozszerzeniem .bmp zawierającego grafikę, wyświetlaną dla wniosku, którego CF jest nieujemne.
    • Nazwa_ngrafiki.bmp jest nazwą pliku graficznego z rozszerzeniem .bmp zawierającego grafikę, wyświetlaną dla wniosku, którego CF jest ujemne.

Z każdą regułą i modelem relacyjnym mogą (lecz nie muszą) w przypadku baz rozwiniętych niepewnych być związane conajwyżej dwa pliki graficzne, dla grafiki i grafiki. Pliki graficzne dla bazy wiedzy NBW umieszczone są w podkatalogu .\GRAFIKI\NBW.

Bazę grafik można załadować tylko wtedy, gdy istnieje odpowiadający jej podkatalog grafik z plikami grafik.

System wnioskujący odróżnia grafiki dla reguł od grafik dla modeli relacyjnych dzięki stosowaniu różnych numerów dla reguł i modeli.


Baza dźwięków rozwinięta niepewna

Baza dźwięków dla bazy wiedzy o nazwie NBW nazywa się DŹNBW.BRN i zawiera klauzule:

dźwięk(Numer,"Nazwa_dźwięku.wav")

ndźwięk(Numer,"Nazwa_ndźwięku.wav")

gdzie:

    • Numer jest liczbą naturalną równa numerowi reguły bądź modelu relacyjnego, dla którego ma być przesłuchany dźwięk w trakcie procesu wnioskowania;
    • Nazwa_dźwięku.wav jest nazwą pliku dźwięku z rozszerzeniem .wav zawierającego dźwięk dla wniosku, którego CF jest nieujemne.
    • Nazwa_ndźwięku.wav jest nazwą pliku dźwięku z rozszerzeniem .wav zawierającego dźwięk dla wniosku, którego CF jest ujemne.

Z każdą regułą i modelem relacyjnym mogą (lecz nie muszą) w przypadku baz rozwiniętych niepewnych być związane conajwyżej dwa pliki dźwięków, dźwięk i ndźwięk. Pliki dźwięków dla bazy wiedzy NBW umieszczone są w podkatalogu .\DŹWIĘKI\NBW.

Bazę dźwięków można załadować tylko wtedy, gdy istnieje odpowiadający jej podkatalog dźwięków z plikami dźwięków.

System wnioskujący odróżnia pliki dźwięków dla reguł od plików dźwięków dla modeli relacyjnych dzięki stosowaniu różnych numerów dla reguł i modeli.


Zasada rozdziału wiedzy dziedzinowej

Zasadę rozdziału wiedzy dziedzinowej pomiędzy bazę reguł i ograniczeń z jednej strony a bazą modeli z drugiej strony można sformułować następująco:

    • wszelka wiedza faktograficzna o charakterze niepewnym (niepewne reguły, niepewne dopytywalne fakty) powinna znaleźć się w bazie reguł niepewnej i w bazie ograniczeń niepewnej;
    • wszelka wiedza relacyjna o charakterze niepewnym (niepewne relacje jedno- i dwustronne) powinna znaleźć się w bazie modeli niepewnej;
    • wszelka wiedza faktograficzna o charakterze dokładnym (dokładne dopytywalne fakty) powinna znaleźć się w bazie ograniczeń dokładnej;
    • wszelka wiedza proceduralna o charakterze dokładnym (modele arytmetyczne, argumenty) powinna znaleźć się w bazie modeli niepewnej.


Baza rad rozwinięta niepewna

Baza rad dla bazy wiedzy o nazwie NBW nazywa się RANBW.BRN i zawiera klauzulę:

rada(Numer,"Nazwa_Rady_dla_reguły/modelu.hlp")

gdzie:

    • Numer jest liczbą całkowitą, będącą numerem tej reguły lub modelu relacyjnego, której (którego) spełnienie generuje propozycję wyświetlenia rady. Użytkownik systemu ekspertowego może - lecz nie musi - z tej propozycji skorzystać.
    • Nazwa_Rady_dla_reguły/modelu.HLP jest nazwą odpowiedniego pliku rady.

Z każdą regułą i modelem relacyjnym może (lecz nie musi) w przypadku baz rozwiniętych niepewnych być związany tylko jeden plik rady. Pliki rad dla bazy wiedzy NBW umieszczone są w podkatalogu .\RADY\NBW.

W przypadku baz rad rozwiniętych niepewnych istota rady zależy oczywiście od wartości współczynnika pewności, jaki ma konkretny wniosek. Wartość ta nie jest znana a priori lecz obliczana w trakcie wnioskowania. Dlatego wszystkie rady w bazach rozwiniętych niepewnych powinny być sparametryzowane współczynnikiem pewności, np. zawierać różne pod-rady dla różnych przedziałów zmian współczynnika pewności głównych wniosków.

Dlatego też w przypadku reguł dysjunktywnych oraz reguł kumulatywnych o wspólnym wniosku wystarczy zamieszczenie w bazie rad jednej i tej samej rady z kolejnymi numerami reguły z wymienionym wnioskiem.

Bazę rad można załadować tylko wtedy, gdy istnieje odpowiadający jej podkatalog rad z plikami rad.

System wnioskujący odróżnia rady dla reguł od rad dla modeli relacyjnych dzięki stosowaniu różnych numerów dla reguł i modeli.


Pliki rad

Każdej bazie wiedzy o nazwie NBW można przyporządkować podkatalog rad o nazwie NBW, znajdujący sie w katalogu .\RADY i zawierający pliki tekstowe rad dla tej bazy wiedzy. Pliki tekstowe rad mają rozszerzenie .hlp. Tworzenie, edytowanie i kasowanie plików tekstowych rad jest inicjowane na drodze wyboru odpowiedniej opcji z menu Baza Rad Niepewna.


Pliki opisów

Każdej bazie wiedzy o nazwie NBW można przyporządkować plik tekstowy opisu wiedzy dziedzinowej o nazwie NBW.OPI, znajdujący się w katalogu .\OPISY. Plik opisu - jeżeli istnieje w odpowiedniej kartotece - jest ładowany automatycznie po przejściu do wnioskowania z bazą wiedzy, do której należy. Jego zawartość jest wyświetlania z chwilą przystąpienie do wnioskowania w przód lub wnioskowania wstecz. Istnienie pliku opisu nie jest konieczne dla przeprowadzenie wnioskowania. Czytanie, tworzenie, edytowanie i kasowanie plików opisów jest inicjowane na drodze wyboru odpowiedniej opcji z menu Opisy i raporty.


Zasady tworzenia nazw i stosowane katalogi

Nazwy baz reguł, baz modeli, baz ograniczeń dokładnych, baz ograniczeń niepewnych, baz rad, baz grafik i baz dźwięków powstają w wyniku łączenia standardowych 2-literowych przedrostków identyfikujacych rodzaj bazy (RE, MO, OG, ON, RA, GR, DŹ) z nazwą bazy wiedzy NBW i dodania rozszerzenia .BRN (Baza Rozwinięta Niepewna).

Nazwy baz reguł rozwiniętych niepewnych mają więc postać:
RENBW.BRN,

Nazwy baz modeli rozwiniętych niepewnych mają postać::
MONBW.BRN,

Nazwy baz ograniczeń rozwiniętych dokładnych mają postać:
OGNBW.BRN,

Nazwy baz ograniczeń rozwiniętych niepewnych mają postać:
ONNBW.BRN,

Nazwy baz rad rozwiniętych niepewnych mają postać:
ADNBW.BRN,

Nazwy baz grafik rozwiniętych niepewnych mają postać:
GRNBW.BRN,

Nazwy baz dźwięków rozwiniętych niepewnych mają postać postać:
DŹNBW.BRN.

Wszystkie bazy reguł, modeli, ograniczeń, rad, grafik i dźwięków są w katalogu .\BAZY. Nazwa bazy wiedzy NBW służy również do tworzenia:

    • nazwy podkatalogu plików tekstowych rad dla tej bazy wiedzy. Podkatalogiem tym jest .\RADY\NBW;
    • nazwy podkatalogu plików graficznych dla tej bazy wiedzy. Podkatalogiem tym jest .\GRAFIKA\NBW;
    • nazwy podkatalogu plików dźwięków dla tej bazy wiedzy. Podkatalogiem tym jest .\DŹWIĘKI\NBW;
    • nazwy pliku opisu bazy wiedzy. Opis wiedzy dziedzinowej stosowanej w bazie wiedzy NBW znajduje się w pliku OPISY\NBW.OPI.
    • nazwy podkatalogu plików graficznych dla tej bazy wiedzy. Podkatalogiem tym jest .\GRAFIKA\NBW;

Raporty przebiegu wnioskowania o nazwach *.RPT mogą być generowane do/czytane z katalogu .\RAPORTY\*.RPT.

Raporty podsumowania wyników wnioskowania nazwach *.TXT mogą być generowane do/czytane z katalogu .\PODSUMY\*.TXT.

Warunki i argumenty dopytywalne dla okreslonej bazy wiedzy mogą być generowane w postaci plików *.TXT do katalogu .\DOPYT\*.TXT i stamtąd czytane.


Tryby ładowania baz

Dostępne są dwa tryby ładowania baz:

    1. Ładowanie dla zastosowań (diagnostyka, analiza, wnioskowania), jest incjowany na drodze wybory opcji Ładowanie Bazy .... w menu Baza .... W trybie tym nie można załadować bazy modeli, bazy ograniczeń lub bazy rad, jeżeli odpowiednia bazy reguł nie została załadowana uprzednio. Wnioskowanie nie jest więc możliwe w przypadku niezaładowanej bazy reguł. Ładowanie baz należy zawsze rozpocząć od ładowanie bazy reguł.

      Załadowanie bazy reguł inicjuje pierwszą serię testów diagnostycznych. Negatywny wynik któregoś z tych testów powoduje usunięcie załadowanej bazy reguł z roboczej bazy danych i wyświetlenie komunikatu informującego o istocie błędu i sposobach jego usunięcia. W przypadku pozytywnych wyników wszystkich testów bazy reguł, wszystkie (lub tylko niektóre z pozostałych baz) mogą zostać załadowane, jeżeli odpowiadają tej samej bazie wiedzy co załadowana baza reguł. Dla kolejno ładowanych baz wykonywane są odpwiadające im serie testów diagnostycznych. Bazy nie spełniające tych testów są usuwane z roboczej bazy danych, czemu również towarzyszy odpowiedni komunikat.

    2. Ładowanie dla edycji jest inicjowany wyborem opcji Edycja Bazy ... w menu Baza .... Ładować można dowolną bazę. Wybór tej opcji wywołuje przeglądarkę plików odpowiednich baz, umożliwiającą załadowanie wybranej bazy jako zwykłego pliku tekstowego, a więc niezależnie od liczby i istoty zawartych w niej błędów syntaktycznych.


Testy diagnostyczne

Testy diagnostyczne baz wiedzy rozwiniętych niepewnych są inicjowane po załadowaniu bazy reguł dla zastosowań. Obejmują one:

    1. Test poprawności syntaktycznej reguł. Test ten wykrywa np. brak cudzysłowia dla zmiennej łańcuchowej, brak nawiasu kwadratowego dla listy, niepotrzebne puste linie. Obecność błędu syntaktycznego generuje odpowiedni komunikat z informacją o istocie błędu i sposobie jego usunięcia oraz powoduje usunięcie załadowanej bazy reguł z dynamicznej bazy danych. Aby usunąć błędy syntaktyczne bazy reguł należy przejść do opcji Edycja bazy reguł w menu Baza reguł niepewna i załadować korygowaną bazę. Ładowanie dla wymienionej opcji odbywa się zawsze w trybie edycji, a więc może być wykonane dla bazy reguł z dowolnymi błędami syntaktycznymi.

    2. Jeżeli załadowana baza reguł nie zawiera błędów syntaktycznych, system przechodzi do obligatoryjnego testu obecności sprzeczności zewnętrznych typu SRN1, tzn. sprzeczności pomiędzy warunkami reguł a ich wnioskami. Jeżeli załadowana baza reguł zawiera sprzeczności zewnętrzne typu SRN1, to system powiadamia o tym użytkownika odpowiednim komunikatem. Dla baz reguł zawierających sprzeczności SRN1 nie dopuszcza się możliwości wnioskowania. Może ono bowiem spowodować powstanie pętli sukcesywnie i bezwnioskowo testowanych reguł, co objawia się zawieszeniem komputera. Takich baz nie można również spłaszczać. Użytkownik może natomiast zażądać diagnozy tych sprzeczności (opcja Diagnostyka sprzeczności zewnętrznych bazy reguł w menu Baza reguł niepewna, usunąć je za pomocą edytora i ponownie przejść do wnioskowania z poprawioną bazą reguł.

    3. Jeżeli załadowana baza reguł nie zawiera sprzeczności zewnętrznych, system przechodzi do obligatoryjnego testu obecności sprzeczności wewnętrznych typu SRN1, tzn. sprzeczności pomiędzy warunkami reguł.Sprzeczności wewnętrzne nie są krytyczne, tzn. ich obecność nie prowadzi do zawieszenia wnioskowania. Mogą jednak bardzo poważnie i w sposób trudny do przewidzenia zafałszować przebieg wnioskowania. Dlatego dla baz reguł zawierających sprzeczności wewnętrzne typu SRN1 nie dopuszcza się możliwości wnioskowania. Użytkownik może natomiast zażądać diagnozy tych sprzeczności (opcja Diagnostyka sprzeczności wewnętrznych bazy reguł w menu Baza reguł niepewna, usunąć je za pomocą edytora i ponownie przejść do wnioskowania z poprawioną bazą reguł.

    4. Jeżeli załadowana baza reguł nie zawiera sprzeczności wewnętrznych typu SRN1, to system proponuje sprawdzenie obecności w bazie nadmiarowości typu NRN1 (występowanie reguł o jednakowych wnioskach i warunkach, reguł subsumowanych lub reguł o niepotrzebnych warunkach).
      Dla baz reguł zawierających nadmiarowości typu NRN1 dopuszcza się możliwość wnioskowania. Nie zaleca się jednak tego, gdyż nadmiarowość bazy reguł może uzależnić wynik wnioskowania od niepotrzebnych warunków. Dlatego użytkownik może zażądać diagnozy nadmiarowości typu NRN1, usunąć je za pomocą edytora i przejść do wnioskowania z poprawioną bazą reguł.
      Testowanie nadmiarowości reguł wymaga ich spłaszczenia; stąd test ten może - dla silnie zagnieżdżonych baz reguł - trwać bardzo długo. Dlatego również użytkownik bazy reguł uprzednio już testowanej na obecność nadmiarowości typu NRN1 może z tego testu zrezygnować. Jeżeli użytkownik zażąda wykonania testu, to zostaje powiadomiony odpowiednim komunikatem o braku lub obecności nadmiarowości. W przypadku wykrycia nadmiarowości użytkownik może przejść do jej diagnostyki (opcja Diagnostyka nadmiarowości bazy reguł w menu Baza reguł niepewna), usunąć je za pomocą edytora i ponownie przejść do wnioskowania z poprawioną bazą reguł.

    5. Jeżeli załadowana baza reguł nie zawiera sprzeczności zewnętrznych typu SRN1, to po zakończeniu testu nadmiarowości system sprawdza, czy w klauzulach fakty(_) nie zadeklarowano warunków niedopytywalnych. Jeżeli tak, to generuje odpowiedni komunikat uniemożliwiając zarazem korzystanie z bazy reguł dla wnioskowania.

    6. Jeżeli baza reguł przeszła pomyślnie wszystkie poprzednie testy, to system proponuje sprawdzenie, czy baza nie zawiera reguł z pojedynczymi warunkami. Reguły takie mogą być tautologiami zmniejszającymi przejrzystość i czytelność bazy reguł. Użytkownik jest o istnieniu takich reguł informowany i może je obejrzeć. Dla baz reguł zawierających reguły o pojedynczych warunkach dopuszcza się możliwość wnioskowania.

    7. Jeżeli baza reguł została przez system ekspertowy zaakceptowana jako pozbawiona błędów formalnych, można przystąpić do ewentualnego ładowania bazy modeli.
      Baza modeli jest w trakcie ładowania poddawana testowi poprawności syntaktycznej modeli. Test ten wykrywa np. niewłaściwe symbole operacji i relacji, modele o błędnej strukturze, niepotrzebne puste linie. Obecność błędu syntaktycznego generuje odpowiedni komunikat z informacją o istocie błędu i sposobie jego usunięcia oraz powoduje usunięcie załadowanej bazy modeli z dynamicznej bazy danych, uniemożliwiając wnioskowanie. Aby usunąć błędy formalne bazy modeli należy przejść do opcji Edycja bazy modeli w menu Baza modeli niepewna i załadować korygowaną bazę. Ładowanie dla wymienionej opcji odbywa się zawsze w trybie edycji, a więc może być wykonane dla bazy modeli z dowolnymi błędami syntaktycznymi.

    8. Jeżeli baza modeli nie ma błędów syntaktycznych, to system przechodzi do obligatoryjnego testu obecności sprzeczności bazy modeli, charakteryzujących się:
      • tożsamością wyniku modelu arytmetycznego z jednym z jego argumentów, bezposrednio lub pośrednio, przez łańcuch zagnieżdżeń;
      • tożsamością wniosku modelu relacyjnego z jego warunkiem stosowania, bezposrednio lub pośrednio, przez łańcuch zagnieżdżeń;
      Występowanie sprzeczności jest sygnalizowane i może być diagnozowane; system blokuje dalsze stosowanie bazy modeli dla wnioskowania. Jeżeli baza modeli nie jest sprzeczna, system przechodzi do testu obecności sprzeczności łącznych pomiedzy bazą modeli a bazą reguł. Sprzecznosci te charakteryzują się obecnością modeli relacyjnych, których warunek stosowania jest wnioskiem reguły, której jeden z warunków jest (bezpośrednio lub poprzez łańcuch zagnieżdżeń, tożsamy z wnioskiem wymienionego modelu relacyjnego. Obecność wymienionych sprzeczności uniemożliwia korzystanie z bazy modeli w trakcie wnioskowania.

    9. Jeżeli baza modeli nie jest sprzeczna i nie jest łącznie sprzeczna z bazą reguł, system przeprowadza dla niej serię testów sprawdzających obecność bardziej subtelnych błędów syntaktycznych:
      • obecność jednakowych nazw dla wniosków reguł i wniosków modeli relacyjnych;
      • obecność jednakowych nazw dla warunków reguł i argumentów modeli arytmetycznych;
      • obecność jednakowych nazw dla wniosków modeli relacyjnych i argumentów modeli arytmetycznych.
      System nie dopuszcza do wnioskowania z bazami modeli zawierającymi tego typu błędy i generuje komunikaty informujące o istocie błędu i sposobie jego usunięcia.

    10. Jeżeli baza modeli nie jest sprzeczna i nie zawiera błędów syntaktycznych, to system sprawdza, czy w klauzulach m_fakt(_) nie zadeklarowano warunków niedopytywalnych i czy w klauzulach argument_znany(_,_) nie zadeklarowano argumentów niedopytywalnych. Jeżeli tak, to generuje odpowiedni komunikat uniemożliwiając zarazem korzystanie z bazy modeli dla wnioskowania.

    11. Jeżeli baza modeli została przez system ekspertowy zaakceptowana jako pozbawiona sprzeczności i błędów formalnych lub nie zażądano ładowania bazy modeli, to można przystąpić do ładowania bazy ograniczeń dokładnej.
      Baza ograniczeń dokładna jest w trakcie ładowania poddawana testowi poprawności syntaktycznej ograniczeń. Test ten wykrywa np. błędną strukturę bazy ograniczeń i niepotrzebne puste linie. Obecność błędu syntaktycznego generuje odpowiedni komunikat z informacją o istocie błędu i sposobie jego usunięcia oraz powoduje usunięcie załadowanej bazy ograniczeń dokładnej z dynamicznej bazy danych. Aby usunąć błędy formalne bazy ograniczeń należy przejść do opcji Edycja bazy ograniczeń w menu Baza ograniczeń dokładna i załadować korygowaną bazę. Ładowanie dla wymienionej opcji odbywa się zawsze w trybie edycji, a więc może być wykonane dla bazy ograniczeń z dowolnymi błędami syntaktycznymi.

    12. Jeżeli syntaks bazy ograniczeń jest poprawny, system testuje obecność w bazie ograniczeń list warunków wykluczajacych się z tylko jednym warunkiem. System nie dopuszcza do wnioskowania z bazami ograniczeń zawierającymi listy ograniczeń z pojedynczym warunkiem i generuje komunikaty informujące o takich przypadkach, wskazujące na lokalizację tych warunków i informujące o sposobach ich usunięcia.

    13. Po załadowaniu bazy ograniczeń dokładnej system sprawdza ponownie bazę modeli (jeżeli takowa istnieje) z punktu widzenia obecności modeli arytmetycznych o jednakowych wynikach. Jeżeli takowe modele są w bazie, ich warunki startowe muszą się wzajemnie wykluczać do jednego lub wzajemnie wykluczać do żadnego. Wymaga to obecności odpowiedniej bazy ograniczeń dokładnej i dlatego test ten jest przeprowadzany dopiero po załadowaniu bazy ograniczeń. Jeżeli w bazie modeli są modele o jednakowych wynikach lub wnioskach, a ich warunki startowe nie wykluczają się, odpowiedni komunikat o istocie błędu zostaje wyświetlony, a stosowanie bazy modeli do wnioskowania zostaje uniemożliwione.

    14. Jeżeli w bazie ograniczeń dokładnej nie ma list z pojedynczym warunkiem, system przechodzi do testowania dopytywalności warunków bazy ograniczeń dokładnej. System nie dopuszcza do wnioskowania z bazami ograniczeń zawierającymi listy ograniczeń z warunkami niedopytywalnymi i generuje komunikaty informujace o takich przypadkach, wskazujące na lokalizację tych warunków i informujące o sposobach ich usunięcia. Możliwe jest jednakże również wnioskowanie tylko z uprzednio załadowaną poprawną bazą ograniczeń.

    15. Jeżeli baza ograniczeń dokładna nie ma błędów syntaktycznych, warunków pojedynczych i warunków niedopytywalnych, system testuje obecność sprzeczności łącznych reguł i ograniczeń dokładnych typu SRN/D2. Sprzeczności takie nie są krytyczne, tzn. nie doprowadzają do zawieszania sie procesu wnioskowania. Mogą jednak doprowadzić do nieoczekiwanych, błędnych wniosków. Dlatego wnioskowania z takimi bazami jest blokowane. Po wykonaniu testu użytkownik zostaje powiadomiony odpowiednim komunikatem o braku lub obecności sprzeczności.
    16. Po teście sprzeczności łącznych typu SRN/D2 system proponuje testowanie obecności nadmiarowości łącznych typu NRN/D2 bazy reguł i bazy ograniczeń dokładnej. Istotą nadmiarowości łącznych jest zaistnienie - w wyniku interakcji bazy reguł i bazy ograniczeń dokładnej - reguł o niepotrzebnych warunkach lub reguł niepotrzebnych.
      Testowanie nadmiarowości łącznych wymaga spłaszczenia bazy reguł; dlatego test ten może - dla silnie zagnieżdżonych baz reguł - trwać bardzo długo. Dlatego również użytkownik bazy reguł i bazy ograniczeń uprzednio już testowanej na obecność nadmiarowości łącznych typu NRN/D2 może z tego testu zrezygnować. Jeżeli użytkownik zażąda wykonania testu, to zostaje powiadomiony odpowiednim komunikatem o braku lub obecności nadmiarowości.
      Dla bazy reguł i bazy ograniczeń dokładnej zawierających nadmiarowości łączne typu NRN/D2 dopuszcza się możliwość wnioskowania. Nie zaleca się jednak tego, gdyż nadmiarowość NRN2 może uzależnić wynik wnioskowania od niepotrzebnych warunków. Dlatego użytkownik może zażądać diagnozy nadmiarowości typu NRN/D2, usunąć je za pomocą edytora i przejść do wnioskowania z poprawioną bazą reguł.

    17. Jeżeli z kolei przystapimy do ładowania bazy ograniczeń niepewnej, to zostana dla niej przeprowadzone wszystkie testy przeprowadzane po załadowaniu bazy ograniczeń dokładnej.
    18. W celu ułatwienia prześledzenia przebiegu diagnostyki sprzeczności i nadmiarowości, szczególnie gdy trwa ona długo, po jej zakończeniu może być utworzony raport diagnostyki. Raporty diagnostyki mogą być przechowywane, czytane i kasowane.

    19. Po załadowaniu poprawnej bazy reguł zostają wyznaczone warunki dopytywalne bazy reguł. Użytkownik może zapoznać się z warunkami dopytywalnymi bazy reguł wybierając odpowiednią opcję w menu Baza reguł niepewna.

    20. Po załadowaniu poprawnej bazy modeli zostają wyznaczone argumenty dopytywalne i zaktualizowane warunki dopytywalne. Użytkownik może zapoznać się z argumentami dopytywalnymi bazy modeli oraz z łącznymi warunkami dopytywalnymi bazy reguł i bazy modeli wybierając odpowiednie opcje w menu Baza modeli niepewna.

    21. Po załadowaniu poprawnej bazy reguł i poprawnych baz modeli oraz ograniczeń (lub w przypadku gdy nie zażądano ładowania bazy modeli i ograniczeń), a w kartotce .\RADY są odpowiednie pliki tekstowe rad, można przystąpić do ładowania bazy rad. Brak wymienionych plików tekstowych uniemożliwia ładowania bazy rad. Jeżeli załadowano bazę rad lub nie zażądano ładowania bazy rad, system jest gotowy do wnioskowania.


Edycja baz i plików tekstowych

System udostępnia następujące opcje edycyjne:

    1. Opcje tworzenia nowych baz i plików tekstowych.
    2. Opcje edycji baz i plików tekstowych. Opcja ta umożliwia m. in. ładowanie baz z błędami syntaktycznymi w celu ich korekty.
    3. Opcje kasowania baz i plików tekstowych.

Wszystkie grupy opcji są dostępne dla dowolnej bazy z odpowiednich podmenu w menu Baza Reguł Niepewna, Bazie Modeli Niepewna, Baza Ograniczeń Dokładna, Baza Ograniczeń Niepewna, Baza Rad Niepewna i Opisy i raporty.

Możliwe jest multiedytowanie polegające na równoczesnym otwarciu dla edycji większej liczby baz i plików opisu.


Raportowanie

Po załadowaniu bazy wiedzy można - korzystając z odpowiedniej podopcji opcji Dopytywalne w Menu Głównym - wygenerować plik tekstowy zawierający nazwy wszystkich warunków i argumentów dopytywalnych dla załadowanej bazy wiedzy. Plik ten jest przechowywany w kartotece DOPYT.

Pliki warunków i argumentów dopytywalnych mogą być czytane lub kasowane korzystając z innych podopcji wymienionej opcji. Wszystkie komunikaty wyświetlane w trakcie wnioskowania można przechować w raporcie wnioskowania.

Wszystkie komunikaty wyświetlane w trakcie diagnozowania sprzeczności i nadmiarowości można również przechować w raporcie diagnostyki.

Raporty wnioskowania i diagnostyki są przechowywane w tej samej kartotece .\RAPORTY i mają to samo rozszerzenie .RPT. Raporty wnioskowania i diagnostyki mogą być czytane lub kasowane na drodze wyboru podopcji Czytanie raportu wnioskowania/diagnostyki lub Kasowanie raportu wnioskowania/diagnostyki z opcji Opisy i raporty w Menu Głównym.

Po zakończeniu wnioskowania można generowac raport podsumowania, zawierający dowolną liczbę etykiet, określające bliżej przedmiot wnioskowania, zestawienie wszystkich warunków i wniosków uznanych za prawdę oraz wszystkich zmiennych rzeczywistych i całkowitych, zadeklarowanych oraz wyznaczonych w trakcie wnioskowania. Raport podsumowania *.TXT jest przechowywanyw kartotece .\PODSUMY.


Reguły płaskie i spłaszczanie reguł

Regułami płaskimi nazywa się reguły, których wszystkie warunki są dopytywalne.

Jeżeli baza reguł nie zawiera sprzeczności zewnętrznych, to jej reguły nie będące regułami płaskimi można spłaszczać na drodze sukcesywnego zastępowania jej niedopytywalnych warunków przez warunki reguł, dla których owe niedopytywalne warunki są wnioskami. W trakcie spłaszczania pomija sie semafory wyświetlania. W trakcie spłaszczania pomija się semafory wyświetlania. Np. spłaszczenie reguły:

reguła(i,"Wniosek_i",["Warunek_i1","Warunek_i2"],1,_)

w sytuacji istnienia reguł:

reguła(m, "Warunek_i1", ["Warunek_m1","Warunek_m2"],1,_)

reguła(n, "Warunek_i2", ["Warunek_n1","Warunek_n2"],1,_)

których wszystkie warunki są dopytywalne, daje regułę spłaszczoną i za pomocą reguł m and n:

reguła_spłaszczona(i,"Wniosek_i",
["Warunek_m1","Warunek_m2","Warunek_n1","Warunek_n2"],[m,n])

Po załadowaniu bazy reguł można obejrzeć wszystkie możliwe spłaszczenia wszystkich reguł. Należy w tym celu wybrać opcję Analiza bazy wiedzy w MRNU GŁOWNYM, udostępniającą opcje umożliwiające wybór pojedynczej reguły do spłaszczenia lub sukcesywne spłaszczanie wszystkich reguł.

Wyniki spłaszczania są wyświetlane w następującej postaci:

Numer_pierwotnej_reguły, Wniosek_pierwotnej_reguły,
Lista_warunków_reguły_spłaszczonej,
Lista_numerów_reguł_użytych_przy_spłaszczaniu

W przypadku reguł, które zostały przez użytkownika sformułowane jako płaskie,
Lista_numerów_reguł_użytych_przy_spłaszczaniu = [].
Ponieważ liczba reguł splaszczonych może dla silnie zagnieżdżonej bazy reguł być ogromna (i nie mieścić się w pamięci operacyjnej komputera), spłaszczone reguły są tylko kolejno wyświetlane, natomiast nie są przechowywane.

Z tych samych powodów testowanie nadmiarowości baz reguł, nadmiarowości łącznych baz reguł i baz ograniczeń oraz sprzeczności łącznych baz reguł i baz ograniczeń jest opcjonalne: w przypadku silnie zagnieżdżonych baz reguł, których spaszczanie jest bardzo czasochłonne, odpowiednie testy mogą trwać bardzo długo.

Reguły spłaszczone umożliwiają analizę bazy reguł. Reguły spłaszczone są potrzebne dla:

    • wykrywania i diagnozowania nadmiarowości baz reguł;
    • wykrywania i diagnozowania nadmiarowości łącznych bazy reguł i bazy ograniczeń;
    • wykrywania i diagnozowania sprzeczności łącznych baz reguł i baz ograniczeń.


Zmienne

W systemach ekspertowych rmse_RN stosowane są zmienne łańcuchowe. Dowolny typ zmiennej łańcuchowej ma postać ciągu znaków, rozpoczynającego i kończącego się cudzysłowem ". Element pomiędzy cudzysłowami nazywa się inkludem zmiennej łańcuchowej:

Zmienna łańcuchowa = "Inklud_zmiennej_łańcuchowej"

Zmienne łańcuchowe w bazach rozwiniętych niepewnych mogą być niepewne, rzeczywiste i całkowite. Elementarne niepewne systemy ekspertowe nie stosują zmiennych logicznych. W przypadku zaistnienia potrzeby stosowania takich zmiennych, posługujemy się wskaźnikami pewności o wartościachj 1 oraz -1 i bazami ograniczeń dokładnych.

    1. Zmienne łańcuchowe niepewne mają inkludy będące zmiennymi niepewnymi, tzn. zmiennymi przyjmującymi wartości z przedziału współczynników pewności [-1, 1]. Np. zmienna łańcuchowa "Dobra znajomość angielskiego" jest zmienną łańcuchową niepewną, gdyż jej inkludem jest zmienna niepewna Dobra znajomość angielskiego, której można przyporządkować współczynnik pewności z przedziału [-1, 1].

      Dopytywalna zmienna niepewna może być ukonkretniona lub nieukonkretniona. Zmienna niepewna może być ukonkretniona:
      • deklarując w klauzuli fakt(_,_) bazy reguł wartość współczynnika pewnosci tej zmiennej. Wówczas system ekspertowy nie pyta już użytkownika o współczynnik pewności warunku tej zmiennej w trakcie wnioskowania;
      • za pomocą deklaracji użytkownika w trakcie wnioskowania w przypadku braku odpowiedniej klauzuli fakt(_,_). Wówczas system ekspertowy pyta użytkownika o współczynnik pewności warunku dopytywalnego w odpowiednim miejscu wnioskowania.

      Jeżeli zmienna niepewna nie została ukonkretniona, jest uważana za nieukonkretnioną.

    2. Rzeczywiste lub całkowite zmienne łańcuchowe mają inkludy będące odpowiednio zmiennymi rzeczywistymi lub całkowitymi. Inkludy te :
      • mogą być ukonkretnione, tzn. być liczbami rzeczywistymi lub całkowitymi, np.67.85, 16. Ukonkretnienia dokonuje się za pomocą klauzuli argument_znany(_,_) albo - w przypadku braku takiej kaluzuli - za pomocą deklaracji użytkownika w trakcie wnioskowania;
      • mogą być nieukonkretnione, tzn. być nazwami zmiennych rzeczywistych lub całkowitych, np. Maksymalna temperatura, Wiek kandydata.
      Rzeczywiste i całkowite zmienne są przetwarzane następująco:
        1. Jeżeli zmienna rzeczywista lub całkowita jest nieukonkretnionym argumentem dopytywalnym, system ekspertowy zapyta się w odpowiednim miejscu wnioskowania o jego wartość.
        2. Jeżeli zmienna rzeczywista lub całkowita jest nieukonkretnionym argumentem niedopytywalnym, system ekspertowy wyznaczy - jeżeli to jest możliwe - jej wartość liczbową w trakcie wnioskowania.
        3. Jeżeli zmienna rzeczywista lub całkowita jest ukonkretniona, system ekspertowy nie pyta się o nic, lecz stosuje jej wartość w modelach, w których występuje.
        4. Niedopytywalnych zmiennych rzeczywistych lub całkowitychnie wolno ukonkretniać za pomocą klauzul argument_znany(_,_). Ukonkretnienia takie nie są akceptowane przez system ekspertowy.
        5. Jeżeli zmienne łańcuchowe rzeczywiste lub całkowite są elementami list, to listy te mogą być mieszane: część zmiennych może już być w bazie modeli ukonkretniona, a część - nieukonkretniona.

    Stosowanie zmiennych łańcuchowych czyni reguły i modele czytelnymi i elastycznymi:

      • nazwy warunków i argumentów nie muszą być atomami, lecz mogą być wieloczłonowymi nazwami, spotykanymi w języku naturalnym;
      • argumentami modeli mogą bowiem być zarówno zmienne łańcuchowe (rzeczywiste lub całkowite) ukonkretnione jak i nieukonkretnione;
      • zmienne łańcuchowe mogą przedstawiać zarówno wyniki (w przypadku modeli arytmetycznych), wnioski (w przypadku modeli relacyjnych i reguł) oraz warunki (w przypadku reguł);
      • dla bardzo szerokiego wachlarza problemów rozwiązywanych przez systemy ekspertowe nie ma potrzeby stosowania innych typów danych.


Komentarze w bazach

Każdą z baz można uzupełnić tekstami komentarzy znajdującymi się w dowolnym miejscu pomiędzy elementami bazy (regułami, modelami, ograniczeniami).

Każdy komentarz jest łańcuchem znaków, stanowiącym argument odpowiedniej klauzuli. Komentarze zapisuje sie następująco:

    1. Dla baz reguł za pomocą klauzul:

      rem_regula("Tekst komentarza").

    2. Dla baz modeli za pomocą klauzul:

      rem_model("Tekst komentarza");

      rem_model_b("Tekst komentarza");

      rem_model_liniowy("Tekst komentarza");

      rem_model_wielomianowy("Tekst komentarza");

    3. Dla baz ograniczeń dokładnych za pomocą klauzul:

      rem_ograniczenie("Tekst komentarza").

    4. Dla baz ograniczeń niepewnych za pomocą klauzul:

      rem_ograniczenie_n("Tekst komentarza").

    5. Dla baz rad za pomocą klauzul:

      rem_rada("Tekst komentarza").

Dowolny element bazy wiedzy można z niej chwilowo usunąć na drodze odmiennego zakomentowania. Stosuje sie w tym celu podkreślnik _, umieszczamy przed tym elementem bazy:

    1. Zakomentowana reguła wygląda następująco:

      _regula(Nr,"Wniosek",Lista_warunków,_)

      a zakomentowany fakt:

      _fakt("Warunek dopytywalny").

    2. Zakomentowane modele wyglądają następująco:

      _model(Nr, "War_stos","Wynik",
      "Arg1","Operacja","Arg2",Semafor).

    3. W podobny sposób można chwilowo usunąć z bazy inne modele.
    4. Zakomentowany m_fakt wygląda następująco:

      _m_fakt("Warunek_dopytywalny").

    5. Zakomentowany znany argument wygląda następująco: :

      _argument_znany("Nazwa",Wartość).

    6. Zakomentowane ograniczenie dokładne wygląda następująco: :

      _ograniczenie(Nr,Lista_warunków).

    7. Zakomentowane ograniczenie niepewne wygląda następująco: :

      _ograniczenie_n(Nr,Lista_warunków).

    8. Zakomentowana rada wygląda następująco:

      _rada(Nr,"Nazwa_rady"),

      lub:

      _nrada(Nr,"Nazwa_rady"),

    9. Zakomentowana grafika wygląda następująco:

      _grafika(Nr,"Nazwa_grafiki),

      lub:

      _ngrafika(Nr,"nNazwa_grafiki).

    10. Zakomentowany dźwięk wygląda następująco:

      _dźwięk(Nr,"Nazwa_dźwięku"),

      lub:

      _ndźwięk(Nr,"nNazwa_dźwięku").

Edycję komentarzy wykonuje się tak jak edycję baz, patrz Edycja baz i plików tekstowych.


Sprzeczności w bazach reguł

Bazy reguł rozwinięte niepewne mogą zawierać sprzeczności zewnętrzne i wewnętrzne, oznaczane skrótem SRN1, oznaczającym Sprzeczności Rozwinięte Niepewne generowane przez pojedynczą bazę.

    1. Sprzeczności zewnętrzne są sprzecznościami zachodzącymi pomiędzy warunkami reguły a jej wnioskiem (są na zewnątrz listy warunków).

      Bezpośrednia sprzeczność zewnętrzna jest ilustrowana przykładem reguły:

      reguła(Nr_R, "Wniosek", ["Wniosek", "Warunek_1",...],_,_)

      dla której Wniosek jest zarazem wnioskiem reguły, jak i jej warunkiem. Ponieważ semafory wyświetlania nie wpływają na sprzeczności, będą one w dalszym ciągu pomijane.

      Bezpośrednie sprzeczności zewnętrzne są przypadkiem kanonicznym. Oznacza to, że wszystkie inne sprzeczności zewnętrzne dadzą się do bezpośrednich sprzeczności zewnętrznych sprowadzić.

      Dwie reguły są wzajemnie zewnętrznie sprzeczne, jeżeli wniosek pierwszej jest warunkiem drugiej, a wniosek drugiej jest warunkiem pierwszej:

      reguła(Nr_1, "Wniosek_1",
      ["Wniosek_2", "Warunek_11"],_,_)

      reguła(Nr_2, "Wniosek_2",
      ["Wniosek_1","Warunek_21"],_,_)

      Jeżeli w miejsce warunku Wniosek_2 reguly Nr_1 wprowadzić warunki reguły Nr_2, to otrzymuje się regułę bezpośrednio sprzeczną zewnętrznie:

      reguła(Nr_1,"Wniosek_1",["Wniosek_1","Warunek_21",
      "Warunek_11"],_,_).

      Bardziej złożonym przykładem mogą być następujące trzy reguły zewnętrznie pośrednio sprzeczne:

      reguła(1,"H",["K","B"],_,_)

      reguła(2,"K",["C","D","X"],_,_)

      reguła(3,"X",["H","A"],_,_).

      Reguła n jest zewnętrznie pośrednio SRN1-sprzeczna z regułą m, jeżeli podstawienie reguły m do innej reguły, tej zaś do jeszcze innej itd., doprowadza do reguły bezpośrednio SRN1-sprzecznej z regułą n. Np. reguła 1 jest zewnętrznie pośrednio SRN1-sprzeczna z regułą 3, gdyż podstawienie warunków reguły 3 w miejsce X do reguły 2 i podstawienie warunków tak zmodyfikowanej reguły 2 w miejsce K do reguły 1 daje regułę bezpośrednio sprzeczną zewnętrznie o postaci:

      reguła(1,"H",["C","D","H","A","B"],_,_)

      Sprzeczności zewnętrzne mają charakter krytyczny: ich obecność moze doprowadzić do zawieszenia się procesu wnioskowania. Dlatego obecność sprzeczności zewnętrznych jest automatycznie wykrywana i diagnozowana, a system nie zezwala na wnioskowanie z bazami reguł zawierającymi reguły zewnętrznie sprzeczne.

    2. Sprzeczności wewnętrzne są sprzecznościami warunków spłaszczonych reguł. Ponieważ reguły bazy reguł rozwiniętej można często spłaszczać na szereg różnych sposobów, należy zdefiniować bardziej precyzyjnie kryterium sprzeczności wewnętrznej:
      1. Reguła bazy reguł rozwiniętej niepewnej uważa się za wewnętrznie sprzeczną, jeżeli wszystkie możliwe spłaszczenia tej reguły są regułami wewnętrznie sprzecznymi, tzn. zawiera zarówno jakiś warunek Warunek jaki i jego negację nWarunek.
      2. W odróżnieniu od baz rozwiniętych dokładnych, reguła wewnętrznie sprzeczna nie jest automatycznie eliminowana z bazy reguł; Warunek i nWarunek mają bowiem jakieś różne od zera współczynniki pewności. Stąd obecność takiej reguły może być źródłem nieprzewidywalnych błędów wnioskowania.
      3. Jeżeli przynajmniej jedno spłaszczenie reguły nie jest wewnętrznie sprzeczne, regułę nie jest wewnętrznie sprzecznaczyli jest wewnętrznie zgodną. Reguła ta bowiem będzie mogła w przypadku odpowiadającym temu spłaszczeniu być stosowana.
      Oczywiście, samo stwierdzenie braku sprzeczności wewnętrznych nie jest jeszcze świadectwem absolutnej poprawności bazy reguł.

      Rozróżnia się następujące sprzeczności wewnętrzne:
      1. Reguła jest wewnętrznie SRD1-samosprzeczna, jeżeli ma warunki wykluczające się i nie istnieje inna reguła dla tego samego wniosku o warunkach niewykluczajacych się. Np.:

        reguła(1,"X",["nA","N","A"],1)

        jest wewnętrznie samosprzeczna, jeżeli baza reguł nie zawiera innej reguły dla wniosku X o niesprzecznych warunkach.
      2. Reguła jest pośrednio wewnętrznie SRD1-sprzeczna, jeżeli jej spłaszczenie daje regułę SRD1-samosprzeczną i nie istnieje inna reguła dla tego samego wniosku o warunkach niewykluczajacych się. Np. spłaszczenie reguły 1 dla pary reguł:

        reguła(1,"X",["C","B","Y"],1)

        reguła(2,"Y",["A","nB"],1)

        daje regułę splaszczoną:

        reguła_spłaszczona(1,"X",["C","B","A","nB"],1)

        która jest wewnętrznie samosprzeczna.

        Rozpatrzmy następujący przykład:

        reguła(1,"W",["A","B"],1)

        reguła(2,"W",["X","E"],1)

        reguła(3,"X",["C","nE"],1)

        reguła(4,"Z",["nW","B"],1)

        Spłaszczenie tych reguł daje następujący wynik:

        Numer reguły | Wniosek | Lista warunków | Reguły stosowane dla spłaszczania
        1 W ["B","A"] []
        2 | W | ["E","C","nE"] | [3]
        3 X ["nE","C"] []
        4 | Z | ["B","nB"] | [1]
        4 | Z | ["B","nA"] | [1]
        4 | Z | ["B","nE"] | [2]
        4 | Z | ["E","B"] | [2,3]
        4 | Z | ["nC","B"] | [2,3]

        Reguła 1, reguła 3 oraz reguła 4 są regułami wewnętrznie zgodnymi. Reguła 2 jest regułą wewnętrznie sprzeczną. Dlatego powyzszą bazę reguł uważa się za wewnętrznie sprzeczną. Sprzeczności wewnętrzne mają nie mają charakteru krytycznego, tzn. nie doprowadzaja do zawieszania procesu wnioskowania. Ich obecność może jednak poważnie zniekształcić proces wnioskowania. Dlatego nie dopuszcza sie wnioskowania z regułami wewnętrznie sprzecznymi.

        Wykrywanie sprzeczności wewnętrznych baz reguł może trwać bardzo długo. Wymaga ono bowiem spłaszczenia wszystkich reguł na wszystkie możliwe sposoby i badania, czy spłaszczone reguły mają listy warunków o wykluczających się warunkach dopytywalnych.


Sprzeczności łączne w bazach reguł i ograniczeń

    1. Bazy reguł rozwinięte niepewne i bazy ograniczeń dokładne mogą zawierać sprzeczności łączne, oznaczane skrótem SRN/D2, oznaczającym Sprzeczności Elementarne Niepewne/Dokładne generowane przez dwie bazy.
      Istotą sprzeczności łącznych jest sprzeczność warunków reguł spowodowana ograniczeniami z bazy ograniczeń.

      Przykładem może być baza reguł zawierająca regułę:

      reguła(Nr,"Wniosek",["A","B","C","D"],_,CF_reguła)

      i odpowiadająca jej baza ograniczeń dokładnych zawierająca ograniczenie:

      ograniczenie(Nr_og,["A","C","F"])

      Ograniczenie to sprawia, że zawsze będzie CF_Wniosek = -CF_Reguła Być może twórcy bazy wiedzy nie o to chodziło: stałość współczynnika pewności wniosku i uniezależnienie tego wniosku od jakichkolwiek warunków sprawia, że ów wniosek może byc uznany za warunek dopytywalny o stałym i znanym współczynniku pewności.

    2. Bazy reguł rozwinięte niepewne i bazy ograniczeń niepewne mogą zawierać sprzeczności łączne, oznaczane skrótem SRN/N2, oznaczającym Sprzeczności Elementarne Niepewne/Niepewne generowane przez dwie bazy.
      Istotą sprzeczności łącznych jest to, że obecność ograniczeń niepewnych powoduje pojawienie sie dla pewnych reguł list warunków które wykluczają sie w sposób niepewny.

      Przykładem może być baza reguł zawierająca regułę:

      reguła(Nr,"Wniosek",["A","B","C","D"],1,CF_reguła)

      i odpowiadająca jej baza ograniczeń niepewnych zawierająca ograniczenie:

      ograniczenie_n(Nr_og,["A","C","F"])

      Nie bardzo wiadomo, co projektant bazy chciał uzyskać za pomocą takiej struktury. Wynik wnioskowania przeprowadzonego przy użyciu tej reguły i tego ograniczenia jest bardzo słabo przewidywalny. Obecność warunków częściowo niepewnie wykluczających się (A i C) w regule świadczy najprawdopodobnie o pomyłce projektanta.

Sprzeczności łączne baz reguł rozwiniętych niepewnych i baz ograniczeń wszelakich nie mają charakteru krytycznego, tzn. nie doprowadzają do zawieszenia wnioskowania. Ich obecność może jednak doprowadzić do nieoczekiwanych wniosków. Dlatego istnienie takich sprzeczności jest użytkownikowi sygnalizowane, a dalsze stosowanie systemu zostaje przerwane.

Wykrywanie sprzeczności łącznych może trwać bardzo długo. Wymaga ono bowiem spłaszczenia wszystkich reguł na wszystkie możliwe sposoby i badania, czy warunki wzajemnie wykluczające się z bazy ograniczeń nie są podzbiorem płaskich warunków tych reguł.


Sprzeczności w bazach modeli

Baza modeli jest bezpośrednio sprzeczna, jeżeli wynik modelu arytmetycznego jest tożsamy z jednym z jego argumentów. Np.:

model(N,"bez warunku","Wynik","A","+","Wynik",1,"1")

Baza modeli jest głęboko sprzeczna, jeżeli wynik modelu arytmetycznego jest tożsamy z jednym z argumentów modeli z nim się zagnieżdżających. Np.:

model(N,"bez warunku","Wynik","A","+","B",1,"1")

model(M,"bez warunku","B","C","*","Wynik",1,"1")

Sprzeczności baz modeli mają charakter krytyczny: ich obecność może doprowadzić do zawieszenia się procesu wnioskowania. Dlatego obecność sprzeczności baz modeli jest automatycznie wykrywana i diagnozowana, a system nie zezwala na wnioskowanie z bazami modeli zawierającymi modele bezpośrednio lub głęboko sprzeczne.


Sprzeczności łączne w bazach modeli i reguł

Baza modeli jest bezpośrednio łącznie sprzeczna z bazą reguł, jeżeli warunek stosowania modelu relacyjnego jest wnioskiem reguły, której warunkiem jest wniosek tego modelu relacyjnego. Np.:

model(N, "Warunek stosowania", "Wniosek modelu","A","<=","B",1,"CF_N")

reguła(M,"Warunek stosowania",["Wniosek modelu",....],1,"1")

Baza modeli jest pośrednio łącznie sprzeczna z bazą reguł, jeżeli warunek stosowania modelu relacyjnego jest wnioskiem reguły, zagnieżdżonej z regułą, której warunkiem jest wniosek tego modelu relacyjnego. Np.:

model(N, "Warunek stosowania", "Wniosek modelu","A","<=","B",1,"CF_N")

reguła(M,"Warunek stosowania",["Warunek",....],1,"1")

reguła(P,"Warunek",["Wniosek modelu",....],1,"1")

Sprzeczności łączne baz modeli i reguł mają charakter krytyczny: ich obecność moze doprowadzić do zawieszenia się procesu wnioskowania. Dlatego obecność sprzeczności łącznych baz modeli i reguł jest automatycznie wykrywana i diagnozowana, a system nie zezwala na wnioskowanie z bazami modeli i reguł, zawierającymi sprzeczności łączne.


Nadmiarowości w bazach reguł

Bazy reguł rozwinięte niepewne mogą zawierać nadmiarowości, oznaczane skrótem NRN1, który znaczy Nadmiarowości Elementarne Niepewne generowane przez pojedynczą bazę. Rozróżnia się następujące nadmiarowości:

    1. Nadmiarowości typu NRN1_1: występowanie reguł o jednakowych wnioskach i jednakowych warunkach. Np.w przypadku reguł:

      reguła(1,"Y",["A","B","G"],1,"CF_1")

      reguła(2,"A",["C","D"],1,"CF_2")

      reguła(3,"B",["E","F"],1,"CF_3")

      reguła(4,"Y",["C","D","E","F","G"],1,"CF_4")

      reguła_dysjunktywna("Y")

      Reguła 4 ma takie same warunki i taki sam wniosek jak reguła 1 wraz z regulami 2 i 3. Jednakże ze względu na różne współczynniki pewności, reguły te nie mogą zostać bezzwłocznie (jak w przypadku reguł dokładnych) uznane za redundantne: współczynnik pewności CF(Y) obliczony dla reguły 4 może być mocno różny od tegoż współczynnika, wyznaczonego dla reguł 1, 2 i 3. Z tego wypływa wniosek o potrzebie bliższej analizy semantyki tych reguł.
    2. Nadmiarowości typu NRN1_2: występowanie reguł subsumowanych. Np. w przypadku reguł:

      reguła(1,"W",["A","B","C","D"],1,"CF_1")

      reguła(2,"W",["A","B"],1"CF_2")

      reguła_dysjunktywna("W")

      Reguła 1 jest - być może - subsumowana (zawarta) w regule 2, gdyż obydwie mają taki sam wniosek, a warunki reguły 2 są podzbiorem warunków reguły 1. Niepewny charakter reguł sprawia jednak, że konieczność usunięcia reguły 1 jest mniej oczywista: być może dodatkowe dane o C i D wpływają na pewność W.

      Usunięcie reguły 1 jako redundantnej - jak to czyniliśmy w przypadku baz dokładnych - może jednak być niewłaściwe. Różnica współczynników pewności warunków C i D może wpłynąć na różnicę współczynników pewności wniosków obydwu reguł.

Powyższe dwa przykłady wskazują, że istnienie redundancji nie da się rozstrzygnąć na drodze czysto formalnej analizy bazy reguł rozwiniętej niepewnej, lecz wyłącznie na drodze wniknięcia w semantykę tej bazy. Dlatego też sytuacja taka jest użytkownikowi sygnalizowana jako potencjalny nadmiar, wymagający dokładnego przemyślenia zaistniałej sytuacji.

Nadmiarowości baz reguł nie mają charakteru krytycznego: ich obecność nie doprowadza do zawieszenia się procesu wnioskowania, lecz jedynie do uzależnienia wniosku od niepotrzebnych warunków.

Wykrywanie nadmiarowości baz reguł może trwać bardzo długo. Wymaga ono bowiem spłaszczenia wszystkich reguł na wszystkie możliwe sposoby i badania, czy płaskie reguły o tych samych wnioskach nie mają jednakowych list warunków dopytywalnych.

Dlatego testowanie nadmiarowości baz reguł nie jest obligatoryjne; użytkownik może z tego testu zrezygnować.

Zaleca się diagnozowanie nadmiarowości baz reguł nowych lub zmodyfikowanych. Przy kolejnym stosowaniu tych baz można test nadmiarowości pominąć.


Nadmiarowości łączne w bazach reguł i ograniczeń

    1. Źródłem nadmiarowości łącznych w bazach reguł niepewnych i bazach ograniczeń dokładnych, oznaczanych skrótem NRN/D2, jest interakcja bazy reguł i bazy ograniczeń dokładnych. Skrót NRN/D2 oznacza Nadmiarowości Elementarne Niepewne/Dokładne generowane przez dwie bazy.

      Np. fragment bazy reguł:

      reguła(1,"Y",["A","B","C"],_,"CF_1")

      reguła(2,"Y",["A","B","D"],_,"CF_2")

      reguła(3,"Y",["A","B","E"],_,"CF_3")

      reguła_dysjunktywna("Y")

      w przypadku obecności, w bazie ograniczeń dokładnej, ograniczenia:

      ograniczenie(1,["C","D","E"])

      może (w przypadku gdy CF_1 = CF_2 = CF_3 = CF oraz CF > 0) zostać zredukowany do pojedynczej reguły:

      reguła(123,"Y",["A","B"],"CF")

      Niezależnie bowiem od tego, czy jest prawdą C, D lub E, wypadkowy współczynnik pewności dla wniosku Y będzie determinowany przez tę regułę, w której jeden z warunków C, D lub E wystąpi z współczynnikiem pewności 1 i można go wtedy uzaleźnić tylko od współczynników pewności dla A i B.

      W przypadku gdy współczynniki pewności reguł 1, 2 i 3 są różne, konieczna jest analizy semantyki tych reguł: twórca bazy reguł musi ponownie udzielić odpowiedzi na pytanie o cel omawianego fragmentu bazy.

    2. Źródłem nadmiarowości łącznych w bazach reguł niepewnych i ograniczeń niepewnych, oznaczanych skrótem NRN/N2, jest interakcja bazy reguł i bazy ograniczeń niepewnych. Skrót NRN/N2 oznacza Nadmiarowości Elementarne Niepewne/Niepewne generowane przez dwie bazy.

      Obecność tych nadmiarowości jest jeszcze trudniejsza do stwierdzenia aniżeli nadmiarowości NRN/D2. Rozpatrzmy identyczny fragment bazy reguł jak poprzednio:

      reguła(1,"Y",["A","B","C"],_,"CF_1")

      reguła(2,"Y",["A","B","D"],_,"CF_2")

      reguła(3,"Y",["A","B","E"],_,"CF_3")

      reguła_dysjunktywna("Y")

      w przypadku obecnosci w bazie ograniczeń niepewnej ograniczenia:

      ograniczenie_n(1,["C","D","E"])

      W tym przypadku nawet równość współczynników pewności reguł 1, 2 i 3 nie jest podstawą dokonania redukcji liczby reguł, która byłaby poprawna dla wszystkich mogących zaistnieć sytuacji. Potrzeba uważnej analizy semantyki tych reguł jest zatem jeszcze większa aniżeli dla NRN/D2.

Nadmiarowości łączne w bazach reguł i ograniczeń nie mają charakteru krytycznego: ich obecność grozi co najwyżej pewnym sfałszowaniem wyników wnioskowania, w szczególności uzależnieniem wniosków od niepotrzebnych warunków.

Wykrywanie nadmiarowości łącznych może trwać bardzo długo. Wymaga ono bowiem spłaszczenia wszystkich reguł na wszystkie możliwe sposoby i badania, czy reguły płaskie o tych samych wnioskach nie mają warunków wzajemnie wykluczających się warunków dopytywalnych, zadeklarowanych w bazie ograniczeń dokładnych lub w bazie ograniczeń niepewnych.

Dlatego testowanie nadmiarowości łącznych baz reguł i baz ograniczeń nie jest obligatoryjne; użytkownik może z tego testu zrezygnować.

Zaleca się diagnozowanie nadmiarowości łącznych baz nowych lub zmodyfikowanych. Przy kolejnym stosowaniu tych baz można test nadmiarowości łącznej pominąć.


Wnioski wykluczające się

Często określony zbiór reguł lub modeli relacyjnych może mieć wnioski wykluczające się.

Rozróżnia się:

    1. Wykluczalność wniosków reguł
      Wykluczalność wniosków reguł musi wynikać z istoty tych reguł; nie można jej zadeklarować w bazie ograniczeń, która służy wyłacznie do deklarowania wykluczalności warunków dopytywalnych. Baza ograniczeń spełnia jednak istotną rolę przy przy deklarowaniu wykluczalności wniosków reguł.

      Wykluczalność wniosków reguł może być dwojaka:
      1. Wykluczeniem do jednego nazywa się wykluczenie, dla którego zawsze jeden i tylko jeden wniosek wymienionego zbioru reguł może być prawdą.
      2. Wykluczeniem do żadnegonazywa się wykluczenie, dla którego żaden lub conajwyżej jeden wniosek wymienionego zbioru reguł może być prawdą.
      Aby uzyskać efekt wykluczania się wniosków reguł, reguły te powinny zależeć od warunków wykluczających się. Zależność ta może mieć charakter:

      a) bezpośredni: rzeczone warunki są dopytywalne i zadeklarowane w bazie ograniczeń niepewnych jako wykluczające się;
      b) pośredni: warunki te są wykluczającymi się wnioskami innych reguł.

      Przypadek 1a) ilustruje następujący przykład:

      reguła(1,"Wniosek_1",["A","B"],_,_)

      reguła(2,"Wniosek_2",["A","nie_B"],_,_)

      reguła(3,"Wniosek_3",["nie_A","B"],_,_)

      reguła(4,"Wniosek_4",["nie_A","nie_B"],_,_)

      ograniczenie(1,["A","nie_A"])

      ograniczenie(2, ["B","nie_B"])

      Przypadek 2a) ilustruje następujący przykład:

      reguła(1,"Wniosek_1",["A","B","C"],_,_)

      reguła(2,"Wniosek_2",["A","nie_B","C"],_,_)

      reguła(3,"Wniosek_3",["nie_A","B","C"],_,_)

      reguła(4,"Wniosek_4",["nie_A","nie_B","C"],_,_)

      ograniczenie(1, ["A","nie_A"])

      ograniczenie(2, ["B","nie_B"])

      Przypadek 1b) ilustruje następujący przykład:

      reguła(1,"Wniosek_1",["A","B"],_,_)

      reguła(2,"Wniosek_2",["A","nie_B"],_,_)

      reguła(3,"Wniosek_3",["nie_A","B"],_,_)

      reguła(4,"Wniosek_4",["nie_A","nie_B"],_,_)

      reguła(5,"Opcja_1",["Wniosek_1"],_,_)

      reguła(6,"Opcja_1",["Wniosek_2"],_,_)

      reguła(7,"Opcja_3",["Wniosek_3"],_,_)

      reguła(8,"Opcja_4",["Wniosek_4"],_,_)

      ograniczenie(1, ["A","nie_A"])

      ograniczenie(2, ["B","nie_B"])

      Przypadek 2b) ilustruje następujący przykład:

      reguła(1,"Wniosek_1",["A","B","C"],_,_)

      reguła(2,"Wniosek_2",["A","nie_B","C"],_,_)

      reguła(3,"Wniosek_3",["nie_A","B","C"],_,_)

      reguła(4,"Wniosek_4",["nie_A","nie_B","C"],_,_)

      reguła(5,"Opcja_1",["Wniosek_1"],_,_)

      reguła(6,"Opcja_1",["Wniosek_2"],_,_)

      reguła(7,"Opcja_3",["Wniosek_3"],_,_)

      reguła(8,"Opcja_4",["Wniosek_4"],_,_)

      ograniczenie(1, ["A","nie_A"])

      ograniczenie(2, ["B","nie_B"])

      W ramach opcji Analiza bazy wiedzy z Menu głównego można wykonać analizę wykluczalności do jednego lub do żadnego wybranej grupy wniosków reguł.

    2. Wykluczalność wniosków modeli relacyjnych
      Często określony zbiór modeli relacyjnych powinien mieć wnioski wykluczające się i całkowicie wyczerpujących zbiór możliwych wartości występującej w nich zmiennej.
      Właściwość ta może również zapewnić wykluczalność warunków startowych dla modeli arytmetycznych o jednakowych wynikach. Ilustruje to następujący przykład:

      model(11,"bez warunku","Wniosek_1","A","<","-10",1,"CF_11")

      model_r(12,"bez warunku","Wniosek_2","<=,<",
      ["-10","A","0.0"],1,"CF_12")

      model_r(13,"bez warunku","Wniosek_3","<=,<=",
      ["0.0","A","10"],1,"CF_13")

      model(14,"bez warunku","Wniosek_4","10","<","A",1,"CF_14")

      model(15,"Wniosek_1","Wynik","AA","+","BB",1,"1")

      model(16,"Wniosek_2","Wynik","CC","+","DD",1,"1")

      model(17,"Wniosek_3","Wynik","EE","+","FF",1,"1")

      model(18,"Wniosek_4","Wynik","GG","+","HH",1,"1")

      Modele 11 - 14 mają wnioski wykluczające się do jednego i wyczerpujące zbiór możliwych wartości zmiennej rzeczywistej A. Wnioski tych modeli służą do wyboru właściwego w danej sytuacji modelu arytmetycznego spośród modeli 15 - 18 o tym samym wyniku Wynik. Aby system wnioskujący wiedział, że takie właśnie są intencje użytkownika, należy go o tym poinformować za pomocą klauzuli:

      modele_ekskluzywne(["Wniosek_1","Wniosek_2",
      "Wniosek_3","Wniosek_4"]),

      umieszczonej w bazie modeli.

      Podobnie dla przykładu:

      model(11,"bez warunku","Wniosek_1","A","<","-10",1,"CF_11")

      model_r(12,"bez warunku","Wniosek_2","<=,<",
      ["-10","A","0.0"],1,"CF_12")

      model_r(13,"bez warunku","Wniosek_3","<=,<=",
      ["0.0","A","10"],1,"CF_13")

      model(15,"Wniosek_1","Wynik","AA","+","BB",1,"1")

      model(16,"Wniosek_2","Wynik","CC","+","DD",1,"1")

      model(17,"Wniosek_3","Wynik","EE","+","FF",1,"1")

      modele 11 - 13 mają wnioski wykluczające się do żadnego, które nie wyczerpują zbioru możliwych wartości zmiennej rzeczywistej A. Celem tych wniosków jest umożliwienie odpowiedniego wyboru modelu arytmetycznego z grupy modeli 15 - 17 o tym samym wyniku Wynik. Aby poinformować system ,ze takie są intencje użytkownika, należy do bazy modeli wprowadzić kaluzulę :

      modele_ekskluzywne(["Wniosek_1","Wniosek_2","Wniosek_3"]).

      Jednakże dla przykładu:

      model(11,"bez warunku","Wniosek_1","A","<","-10",1,"CF_11")

      model_r(12,"bez warunku","Wniosek_2","<=,<",
      ["-20","A","20"],1,"CF_12")

      model_r(13,"bez warunku","Wniosek_3","<=,<=",
      ["0.0","A","10"],1,"CF_13")

      model(15,"Wniosek_1","Wynik","AA","+","BB",1)

      model(16,"Wniosek_2","Wynik","CC","+","DD",1)

      model(17,"Wniosek_3","Wynik","EE","+","FF",1),

      modele 11 and 12 oraz 12 and 13 nie mają wykluczających się wniosków: wnioski Wniosek_1 i Wniosek_2 oraz Wniosek_2 i Wniosek_3 mogą być równocześnie parami prawdziwe. Tak sformułowana baza modeli może być błędna i w rozpatrywanej sytuacji jest błędna: to, który z wymienionych alternatywnych modeli arytmetycznych 15,...,17 zostanie zastosowany, zależy bowiem od tego, które z rzeczywistych zmiennych łańcuchowych AA,..., FF będą najpierw ukonkretnione.

      Ponieważ niepoprawność modeli 11 - 13 wynika z obecności modeli 15 - 17, nie można jej automatycznie wykryć i diagnozować. Użytkownik powinien tego typu sytuację wykryć w trakcie tworzenia bazy modeli i niedopuścić do zaistnienia opisanego błędu.


Modele arytmetyczne wielokrotne

Często występuje potrzeba sformułowania kilku modeli arytmetycznych o jednakowych nazwach wyników, wyznaczanych jednak w różny sposób, zależnie od sytuacji.

Poprawna konstrukcja bazy modeli wymaga poinformowania systemu wnioskującego o tym, który model ze zbioru modeli o jednakowych wynikach powinien w danej sytuacji użyć.

Można to uzyskać przez odpowiedni dobór warunków startowych tych modeli: warunki te powinny się wykluczać do jednego lub wykluczać do żadnego i zarazem odpowiadać sytuacjom wymagającym stosowania określonego modelu.

Pierwszą część wymienionego wymogu można spełnić:

    1. Bezpośrednio: definiując warunki startowe tych modeli jako dopytywalne wzajemnie wykluczające się, za pomocą przedrostka n lub w odpowiedniej bazie ograniczeń dokładnych.
    2. Pośrednio: definiując warunki startowe tych modeli jako odpowiednio wykluczające się wnioski pewnych reguł.
    3. Pośrednio: definiując warunki startowe tych modeli jako odpowiednio wykluczające się wnioski pewnych modeli relacyjnych. W tym przypadku system wnioskujący musi zostać poinformowany o wykluczaniu się tych wniosków za pomocą klauzuli:

      modele_ekskluzywne(Lista_wniosków_wykluczających_się).

Przypadek 1 ilustruje następujący przykład:

model(10,"A","Wynik",_,"Operacja_10",_,1,"1")

model_lin(11,"nA","Wynik",_,_,1,"1")

Przypadek 2 ilustruje następujący przykład:

model(10,"War_1","Wynik",_,"Operacja_10",_,_,"CF_10")

model_liniowy(11,"War_2","Wynik",_,_,_,"CF_11")

model_liniowy(12,"War_3","Wynik",_,_,_,"CF_12")

model_r(13,"War_4","Wynik","Operacja_13",_,_,_)

reguła(1,"War_1",["A","B"],_,"CF_1")

reguła(2,"War_2",["A","nB"],_,"CF_2")

reguła(3,"War_3",["nA","B"],_,"CF_3")

reguła(4,"War_4",["nA","nB"],_,"CF_4")

Przypadek 3 ilustruje następujący przykład:
dane są cztery modele relacyjne z wnioskami (Wniosek_1, Wniosek_2, Wniosek_3 i Wniosek_4), zależnymi od pozycji zmiennej rzeczywistej A na osi liczbowej:

model(11,"bez warunku","Wniosek_1","A","<","-10",1,"CF_11")

model_r(12,"bez warunku","Wniosek_2","<=,<",["-10","A","0.0"],1,"CF_12")

model_r(13,"bez warunku","Wniosek_3","<=,<=",["0.0","A","10"],1,"CF_13")

model(14,"bez warunku","Wniosek_4","10","<","A",1,"CF_14")

Wymienione wnioski wykluczają się do jednego i wyczerpują zbiór możliwych wartości zmiennej A; a więc tylko jeden wniosek może byc prawdą. Takie wnioski mogą być użyteczne jako warunki startowe dla wyboru jednego z czterech modeli arytmetycznych o tym samym wyniku Wynik, liczonym jednak na różne sposoby:

model(15,"Wniosek_1","Wynik","AA","+","BB",1,"1")

model(16,"Wniosek_2","Wynik","CC","+","DD",1,"1")

model(17,"Wniosek_3","Wynik","EE","+","FF",1,"1")

model(18,"Wniosek_4","Wynik","GG","+","HH",1,"1")

System wnioskujący nie potrafi sam stwierdzić, czy wnioski modeli 11 - 14 wykluczają się wzajemnie. Aby system wnioskujący zaakceptował te wnioski jako wzajemnie wykluczające się i wyczerpujące zbiór możliwych wartości zmiennej A, należy go o tym poinformować za pomocą klauzuli:

modele_ekskluzywne(["Wniosek_1","Wniosek_2","Wniosek_3","Wniosek_4"])

w bazie modeli. Tylko wówczas system wnioskujący zaakceptuje obecność w bazie modeli czterech różnych modeli arytmetycznych 15, 16, 17 and 18 o tym samym wyniku Wynik, stosowanych w różnych sytuacjach okreslonych przez modele 11 - 14. Odpowiedzialnym za właściwe sformułowanie wykluczających się modeli relacyjnych jest twórca bazy wiedzy. Jeżeli dla modeli arytmetycznych o tym samym wyniku nie zadeklarowano wzajemnie wykluczajacych sie warunków startowych za pomocą deklaracji modele_ekskluzywne(_), wnioskowanie nie zostaje przeprowadzone.

Jeżeli deklaracja modele_ekskluzywne(_) nie odpowiada stanowi faktycznemu, wnioskowanie będzie błędne: system ekspertowy nie ma możliwości stwierdzenia samemu, czy dany zbiór wniosków modeli relacyjnych wyklucza się, czy też nie wyklucza się.


Konwersja dokładne - niepewne

Przed wykonaniem bazy wiedzy niepewnej dobrze jest wykonać bazę wiedzy dokładną. Umożliwia to zorientowanie się w złożoności relacji zachodzących pomiędzy wnioskami reguł, wnioskami modeli relacyjnych, warunkami i wartościami argumentów. Z kolei należy wykonaną bazę reguł dokładną sprowadzić do postaci bazy reguł niepewnej. Można to dokonać na trzy sposoby, zilustrowane na przykładzie reguły dokładnej:

reguła(1,"Wniosek",["Warunek_1","Warunek_2"],1)

    1. Sposób pesymistyczny (konserwatywny) polega na uzupełnieniu reguły dokładnej odpowiednio dobranym (ukonkretnionym) współczynnikiem pewności reguły CF_1:

      reguła(1,"Wniosek",["Warunek_1","Warunek_2"],1,"CF_1")

      Pesymizm (konserwatyzm) tego podejścia wynika stąd, że współczynnik pewności Wniosku jest współokreślany przez najmniejszy z współczynników pewności warunków. Świadczy to o pewnej ostrożności twórcy bazy, który uważa, że dla rozpatrywanej aplikacji lepiej wziąć pod uwagę sytuację najgorszą. Sposób ten był stosowany przy tworzeniu rozwiniętej niepewnej bazy kredytowej REKRE.BRN z rozwiniętej dokładnej bazy kredytowej REKRE.BRD, gdyż chcieliśmy wykazać się maksymalną ostrożnością przy ocenie kredytobiorcy.
    2. Sposób zrównoważony polega na zastąpieniu reguły elementarnej dokładnej pewną liczbą reguł niepewnych kumulatywnych:

      reguła(2,"Wniosek",["Warunek_1"],1,"CF_2")

      reguła(3,"Wniosek",["Warunek_2"],1,"CF_3")

      Równowaga tego podejścia wynika stąd, że wypadkowy współczynniku pewności Wniosku jest uzależniony od współczynników pewności wniosków obydwu reguł kumulatywnych, dzięki czemu mamy prostą możliwość deklarowania preferencji decyzyjnych. Sposób ten był stosowany przy tworzeniu rozwiniętej niepewnej bazy dyrektorskiej REDYR.BRN z rozwiniętej dokładnej bazy dyrektorskiej REDYR.BRD, gdyż chcieliśmy uzależnić wniosek Pozostanę dyrektorem od szeregu warunków (Efekty finansowe, Nie podpadłem i Odpowiedni wiek), jednakże z różną wagą, wyrażoną przez współczynniki pewności reguł.
    3. Sposób optymistyczny (zachłanny) polega na zastąpieniu reguły elementarnej dokładnej pewną liczbą reguł niepewnych dysjunktywnych:

      reguła(2,"Wniosek",["Warunek_1"],1,"CF_2")

      reguła(3,"Wniosek",["Warunek_2"],1,"CF_3")

      reguła_dysjunktywna("Wniosek")

      Optymizm tego podejścia wynika stąd, że wypadkowy współczynniku pewności Wniosku może być współokreślany przez największy z współczynników pewności warunków. Świadczy to o optymiźmie twórcy bazy, który uważa, że dla rozpatrywanej aplikacji można wziąć pod uwagę sytuację najlepszą.

Konwersja dokładnej bazy modeli do postaci niepewnej bazy modeli jest znacznie prostsza, gdyż wymaga jedynie uzupełnienia modeli bazy dokładnej współczynnikami pewności:

    • ukonkretnionymi na wartości 1 dla modeli arytmetycznych;
    • nieukonkretnionymi dla modeli relacyjnych.


ROZWINIĘTE NIEPEWNE

REGUŁOWO - MODELOWE

SYSTEMY EKSPERTOWE

rmse_RN


Plik pomocy CHM dla Rozwiniętych Niepewnych
Regułowo-Modelowych Systemów Ekspertowych rmse_RN