Informacje ogólne - wnioskowanie w przód rozwinięte dokładne

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

1) Baza reguł rozwinięta dokładna
2) Baza modeli rozwinięta dokładna
3) Baza ograniczeń rozwinięta dokładna
4) Baza rad rozwinięta dokładna
5) Pliki rad
6) Baza grafiki rozwinięta dokładna
7) Pliki grafiki
8) Baza dźwięków rozwinięta dokładna
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 jako warunki startowe modeli.

Innymi słowy - dla baz rozwiniętych dozwolone jest zagnieżdżanie z negacją. Jest to konsekwencją założenia zamkniętego świata.

Baza reguł jest dokładna, jeżeli jej warunki i wnioski są łańcuchowymi zmiennymi logicznymi o inkludach przyjmujących dwie wartości: prawda lub nieprawda.

Baza modeli jest dokładna jeżeli warunki modeli relacyjnych i warunki startowe modeli są łańcuchowymi zmiennymi logicznymi o inkludach przyjmujących dwie wartości: prawda lub nieprawda.

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

    • wszystkich prawdziwych i nieprawdziwych wniosków reguł, oraz
    • wszystkich prawdziwych i nieprawdziwych wniosków modeli relacyjnych, oraz
    • wszystkich wyników rozwiązywalnych modeli arytmetycznych,

      na podstawie znajomości bazy reguł rozwiniętej dokładnej, bazy modeli rozwiniętej dokładnej, bazy ograniczeń dokładnej oraz wartości logicznych wszystkich warunków dopytywalnych i wartości liczbowych wszystkich argumentów dopytywalnych

      Zwraca się uwagę na to, że celem wnioskowania rozwiniętego dokładnego w przód jest również wyznaczenie tych wniosków, które są nieprawdą. Zanegowane wnioski mogą bowiem okazać się warunkami innych reguł.

      Zwraca się również uwagę na to, że wnioskowanie rozwinięte niepewne w przód wyznacza wszystko, co można wyznaczyć lub obliczyć, włączajac to, co może niezbyt nas interesuje.


Informacje ogólne - wnioskowanie wstecz rozwinięte dokładne

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

1) Baza reguł rozwinięta dokładna
2) Baza modeli rozwinięta dokładna
3) Baza ograniczeń rozwinięta dokładna
4) Baza rad rozwinięta dokładna
5) Pliki rad
6) Baza grafiki rozwinięta dokładna
7) Pliki grafiki
8) Baza dźwięków rozwinięta dokładna
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 dokładna, jeżeli jej warunki i wnioski są łańcuchowymi zmiennymi logicznymi o inkludach przyjmujących dwie wartości: prawda lub nieprawda.

Baza modeli jest dokładna jeżeli warunki modeli relacyjnych i warunki startowe modeli są łańcuchowymi zmiennymi logicznymi o inkludach przyjmujących dwie wartości: prawda lub nieprawda.

Celem wnioskowania rozwiniętego dokładnego wstecz jest sprawdzenie hipotezy wskazanej przez użytkownika, dla określonej bazy reguł, bazy modeli, bazy ograniczeń oraz wartości logicznych wszystkich warunków dopytywalnych i wartości liczbowych wszystkich argumentów dopytywalnych.

Sprawdzana hipoteza musi być wnioskiem conajmniej jednej reguły bazy reguł lub wnioskiem conajmniej jednego modelu relacyjnego bazy modeli.
Sprawdzanie hipotezy może zakończyć się w sposób:

    • pomyślny: hipoteza została uznana za prawdę;
    • niepomyślny: hipoteza została uznana za nieprawdę. Takie zakończenie jest konsekwencją założenia zamkniętego świata.

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 dokładna

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

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

i:

fakt("Warunek_dopytywalny")

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

    • Numer_Reguły jest liczbą całkowitą, różną dla różnych reguł i różną od numerów modeli;
    • "Wniosek" jest zmienną łańcuchową logiczną, przedstawiającą wniosek reguły. Np. wniosek "Udziel kredyt" oznacza, że Udziel kredyt jest zmienną logiczną, tzn. mogącą przyjmować tylko wartości prawda lub nieprawda.
    • Lista_Warunków jest listą zmiennych łańcuchowych logicznych przedstawiających warunki reguły, np.:
      Lista_Warunków = ["Warunek_1","Warunek_2","Warunek_3"], gdzie "Warunek_i" jest zmienną łańcuchową logiczną , przedstawiającą warunek Warunek_i reguły.
      Symbolem nWarunek oznacza się warunek przeciwny (zanegowany) wobec warunku Warunek. Przedrostek w postaci małej litery n jest przedrostkiem negacji. Dla uniknięcia pomyłek nie należy więc stosować nazw warunków, rozpoczynajacych się małą literą n. W tych przypadkach małe n rozpoczynajace nazwę należy zastapić dużymN.
    • 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.

Sens reguły jest następujący:

    • zmienna logiczna Wniosek ma wartość logiczną prawda, jeżeli wszystkie zmienne logiczne przedstawiane przez warunki z Listy_Warunków mają wartości logiczne prawda. Mówimy wówczas, że reguła jest spełniona;
    • jeżeli conajmniej jeden z warunków z Listy_Warunków ma wartość logiczną nieprawda, to mówimy, że reguła nie jest spełniona a jej wniosek jest nieprawdą. Założenie takie nosi nazwę założenia zamkniętego świata. Założenie to oznacza, że twórca bazy reguł dołożył wszelkich starań, by całą wiedzę dziedzinową z przedmiotu wnioskowania zawrzeć w bazie wiedzy. Jeżeli więc coś nie wynika z bazy wiedzy, należy to uznać za nieprawdę.
      Oczywiście, jeżeli Wniosek nie jest prawdą, to jego negacja nWniosek jest prawdą. Dla uniknięcia pomyłek nie należy więc stosować nazw wniosków, rozpoczynajacych się małą literą n. Gdyby jednak pierwszą literą nazwy wniosku niezanegowanego było n (np. dla wniosku niedostateczne zabezpieczenie), należy zamiast n w nazwie wniosku użyć N (tzn. pisać Niedostateczne zabezpieczenie);
    • jeżeli conajmniej jeden z warunków z Listy_Warunków jest wnioskiem modelu relacyjnego usuniętego z załadowanej bazy modeli (tzn. o nieprawdziwym warunku stosowania), reguła zostanie również usunięta i wnioskowanie ulega przerwaniu.

Implikację będącą wynikiem stosowania tego założenia będziemy nazywać implikacją regułową dla wnioskowania rozwiniętego.
Pojedynczą regułę stosuje się więc do zadeklarowania, że zmienna logiczna Wniosek jest implikacją regułową koniunkcji zmiennych logicznych przedstawianych przez Warunki z Listy_Warunków.

Reguła jest więc regułą typu JEżELI ... TO ... o następujących właściwościach:

    • JEżELI prawdą są wszystkie Warunki z Listy_Warunków, TO prawdą jest Wniosek.
    • JEżELI nieprawdą jest conajmniej jeden Warunek z Listy_Warunków, TO Wniosek jest nieprawdą.

Jeżeli Wniosek można wyrazić jako dyzjunkcję dwóch (lub więcej) implikacji regułowych dla koniunkcji dwóch (lub więcej) zbiorów całkowicie lub częściowo niezależnych warunków, to trzeba w tym celu użyć dwóch (lub więcej) reguł, np.

reguła(N,"Wniosek", Lista_1_Warunków,_)

reguła(N+1,"Wniosek", Lista_2_warunków,_)

gdzie każda lista warunków zawiera warunki całkowicie lub częściowo niezależne od warunków drugiej listy.
Sens powyższych dwóch reguł jest następujacy:

    • JEżELI prawdą są wszystkie Warunki z Listy_1_Warunków
      lub
      JEżELI prawdą są wszystkie Warunki z Listy_2_Warunków
      TO prawdą jest Wniosek
    • JEżELI nieprawdą jest conajmniej jeden Warunek z Listy_1_Warunków
      i conajmniej jeden Warunek z Listy_2_Warunków
      TO Wniosek jest nieprawdą.

Przykładem może być baza reguł:

reguła(1,"kupię dobry samochód",["dostanę poważną podwyżkę"],1)

reguła(2,"kupię dobry samochód",["dostanę znaczny spadek"],1)

reguła(3,"kupię dobry samochód",["wygram w Toto-Lotka"],1)

Jeżeli żadna z reguł 1, 2 i 3 nie będzie spełniona, system wnioskujący - zgodnie z założeniem zamkniętego świata - określi wartość logiczną wniosku kupię dobry samochód jako nieprawda. Zakłada się bowiem, że nie ma innych okoliczności (poza wymienionymi trzema), które sprawią, że jednak dobry samochód kupię. Negacja wniosku zostanie przez system zasygnalizowana przedrostkiem negacji n przed nazwą wniosku: nkupię dobry samochód. Gdyby jednak pierwszą literą nazwy wniosku niezanegowanego było n (np. dla wniosku niedostateczne zabezpieczenie), należy zamiast n w nazwie wniosku użyć N (tzn. pisać Niedostateczne zabezpieczenie).

Dla baz rozwiniętych dokładnych dopuszczalne jest więc stosowanie zanegowanych warunków niedopytywalnych: warunkami reguł mogą więc być negacje wniosków innych reguł.
Jeżeli więc zaistnieje potrzeba dysponowania zanegowanym wnioskiem którejś z reguł, nie ma potrzeby (jak w przypadku baz elementarnych) generowania tej negacji za pomocą oddzielnej reguły. Na przykład jeżeli żadna z reguł 1, 2 i 3 nie będzie spełniona, będę musiał kupić stary używany samochód. Można to zapisać za pomocą reguły:

reguła(1,"kupię stary używany samochód",["nkupię dobry samochód"],1)

Oczywiście, dla baz rozwiniętych dopuszczalne jest stosowanie reguł zarówno z prostymi warunkami dopytywalnymi (np. A) jak i z zanegowanymi warunkami dopytywalnymi, które można teraz zapisywać za pomocą litery 'n' przed nazwą warunku (np. nA). Dla baz tych nie ma więc potrzeby definiowania warunków dopytywalnych zanegowanych za pomocą dychotomicznego ograniczenia w bazie ograniczeń, jak to robiono w przypadku baz elementarnych dokładnych. Definiowanie takie jest jednak możliwe i bywa czasem stosowane ze względu na estetykę językową.

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.

Warunki Listy_warunków mogą mieć dowolną kolejność. Należy jednak pamiętać, że pierwszy Warunek z Listy_waruunkó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ść, np. Moc urządzenia < 20 W. Dzięki temu wszystkie warunki są zmiennymi logicznymi.

Reguły bazy reguł mogą się zagnieżdżać z regułami oraz modelami, tzn. wnioski reguł mogą:

    • występować, w postaci prostej lub zanegowanej, w Listach_warunków innych reguł, lub
    • występować, w postaci prostej lub zanegowanej, jako Warunki_startowe modeli.

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

Dopuszczalność 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ł lub wnioskami modeli relacyjnych. System pyta użytkownika o wartości logiczne (prawda,nieprawda) warunków dopytywalnych.
    2. Warunki niedopytywalne są warunkami będącymi wnioskami innych reguł lub wnioskami modeli relacyjnych. Wartości logiczne 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.

Klauzule:

fakt("Warunek_dopytywalny")

służą do zadeklarowania wartości logicznej prawda dla warunku dopytywalnego Warunek_dopytywalny. Klauzulę taka umieszcza sie w bazie reguł, jeżeli przy wielokrotnym korzystaniu z niej Warunek_dopytywalny ma niezmiennie wartość logiczną prawda. Wnioskowanie rozpoczyna się zawsze od przedstawienia 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ść logiczną tego warunku.


Baza modeli rozwinięta dokładna

Baza modeli rozwinięta dokładna dla bazy wiedzy o nazwie NBW nazywa się MONBW.BRD 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 dokładny 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 dokładnych:

    • 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ą logiczną, decydującą o stosowaniu modelu. Stosowanie modelu (tzn. wyznaczenie wartości zmiennej Wynik/Wniosek) jest możliwe jeżeli:
      • Warunek Startowy ma wartość logiczną prawda 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 unikatowego modelu rozwiniętego dokładnego skutkuje przerwaniem wnioskowania w momencie przejścia do obliczania tego modelu; towarzyszy temu odpowiedni komunikat.
      W bazach modeli rozwiniętych dokładnych 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 zanegowanym 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)

      gdzie:
      • "Wynik"/"Wniosek" jest zmienną łańcuchową:
        • rzeczywistą Wynik w przypadku modelu arytmetycznego;
        • logiczną 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 pojedynczym argumentem. Możliwymi operacjami wykonywanymi na wartości Pierwszy Argument są: "sqrt", "sin", "cos", "tan", "arctan", "log", "ln", "exp", "round", "trunc", "abs" ,"liczba_warunków_reguły", "Ocena_nazwa_zmiennej", przy czym "Drugi Argument"="0.0".
        • symbol relacji arytmetycznej Relacja dla modeli relacyjnych. Możliwymi relacjami pomiędzy Pierwszym Argumentem a Drugim Argumentem są: ">", "==", "<", ">=", "<=", "><", "<>";
      • 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.

      Sens modelu podstawowego jest następujący:
      • dla modelu arytmetycznego z dwoma argumentami: jeżeli Warunek Startowy jest prawdą, 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 prawdą, a Drugi Argument = 0, to Wynik przedstawia liczbę rzeczywistą wyznaczoną przez Operację wykonaną na wartości Pierwszego Argumentu.
        Rozpatrzmy kilka mniej oczywistych przykładów:

        W modelu arytmetycznym z jednym argumentem

        model(Nr_modelu,"Warunek Startowy","Liczba","Nr_reguły","liczba_warunków_reguły","0",1)

        wynik Liczba jest liczbą warunków w liście warunków reguły o numerze Nr_reguły. Aby model wyznaczył tę liczbę, reguła o numerze Nr_reguły musi być w bazie reguł. Model ten jest alternatywą dla "ręcznego" liczenia warunków reguły, co może w przypadku dużej liczby warunków być kłopotliwe.

        Model arytmetyczny z jednym argumentem

        model(Nr_modelu,"Warunek Startowy","Wartość_zmienna","Ocena_zmienna","=","0",1)

        zawiera niecodzienną operację Ocena_, konkatenowaną z nazwą zmiennej zmienna. Model ten generuje zapytanie:

        Określ wartość argumentu: zmienna

        na które np. odpowiadamy:

        zmienna = 5.

        Zadeklarowana wartość 5 zostanie przyporządkowana zmiennej Wartość_zmienna.
        W odróżnieniu od bezpośredniego wprowadzania wartości Wartość_zmienna, model z operacją Ocena_zmienna sprawdza, czy zadeklarowana ocena mieści się w przedziale [0,10].
      • dla modelu relacyjnego: jeżeli Warunek Startowy jest prawdą, to zmiennej logicznej Wniosek zostaje przyporządkowana stała logiczna określająca wartość logiczną relacji:
        - jeżeli relacja jest spełniona, to Wniosek jest prawdą;
        - jeżeli relacja nie jest spełniona, to Wniosek jest nieprawdą, tzn. prawdą jest nWniosek. Założenie takie nosi nazwę założenia zamkniętego świata. Założenie to jest uznaniem, iż dysponujemy pełną wiedzą w temacie wnioskowania: żaden inny model relacyjny z identyczną relacją nie może się juz pojawić.
        Jeżeli Warunek Startowy nie jest prawdą, to Wniosek jest nieukonkretniony.

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

    2. Klauzule modeli rozszerzonych są postaci:

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

      gdzie:
      • "Wynik"/"Wniosek" jest zmienną łańcuchową:
        • rzeczywistą Wynik w przypadku modelu arytmetycznego;
        • logiczną Wniosek w przypadku modelu relacyjnego;
      • "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;

      Sens modelu rozszerzonego jest następujący:
      • dla modelu rozszerzonego arytmetycznego: jeżeli Warunek Startowy jest prawdą, 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 prawdą, to zmiennej łańcuchowej logicznej Wniosek zostaje przyporządkowana stała logiczna określającą wartość logiczną relacji arytmetycznej zachodzącej pomiędzy wartościami liczbowymi zmiennych rzeczywistych:
        Ograniczeniem Dolnym, Wartością Testowaną, Ograniczeniem Górnym z Listy_Argumentów:
        • jeżeli relacja jest spełniona, to Wniosek jest prawdą;
        • jeżeli relacja nie jest spełniona, to Wniosek jest nieprawdą, tzn. prawda jest 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)

      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;

      Sens modelu liniowego jest następujący:
      • jeżeli Warunek Startowy jest prawdą, 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 ma wartość logiczną nieprawda, to model zostaje pominięty w trakcie wnioskowania.
      • dla unikatowego modelu liniowego, jeżeli Warunek_Startowy ma wartość logiczną nieprawda, 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)

      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.

      Sens modelu wielomianowego jest następujący:
      • jeżeli Warunek_Startowy jest prawdą, 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]
      • dla wielokrotnego modelu wielomianowego, jeżeli Warunek_Startowy ma wartość logiczną nieprawda, to model zostaje pominięty w trakcie wnioskowania.
      • dla unikatowego modelu wielomianowego, jeżeli Warunek_Startowy ma wartość logiczną nieprawda, 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ł. Ze względu na rozwiniety charakter baz, dopuszczalne jest zagnieżdżanie z negacją.W szczególnosci:

    • wyniki modeli arytmetycznych mogą być warunkami innych modeli arytmetycznych lub relacyjnych;
    • wnioski modeli relacyjnych lub ich negacje mogą być warunkami startowymi innych modeli;
    • wnioski modeli relacyjnych lub ich negacje mogą być warunkami reguł;
    • wnioski reguł lub ich negacje mogą być warunkami startowymi 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")

gdzie Dopytywalny_warunek_startowy jest zmienną logiczną uznaną za prawdziwą.

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ę)

Ilustruje to przykład:

model(1,"stosuj A","Wynik","A","+","10",1),

model(2,"stosuj B","Wynik","B","-","5",1),

model(2,"stosuj C","Wynik","C","*","12",1),

modele_ekskluzywne(["stosuj A","stosuj B","stosuj C"]),

Często ten sam wniosek może być prawdą dla szeregu różnych relacji. Możemy to zapisać za pomoca odpowiednich modeli relacyjnych:

model(1,"bez warunku","Wniosek","A",">=","10",1)

model_r(2,"bez warunku","Wniosek","<=,<=",["15","B","20"],1)

Takie modele relacyjne nie wymagają żadnych innych deklaracji: Wniosek jest prawdą, jeżeli dla dowolnego z modeli 1 lub 2 relacja jest spełniona. Istnieje tu pełna analogia z regułami elementarnymi dokładnymi o tym samym wniosku.

------------------------------------------------------------------------------------
W przypadku omyłkowego wprowadzenia błędnej wartości argumentu istotnym jest możliwość poprawy błędnej wartości bez konieczności rozpoczynania całego wnioskowania od początku. Umożliwiają to modele relacyjne z wnioskiem - słowem kluczowym:

"Pomyłka we wprowadzonych danych"

Ilustruje to model relacyjny:

model(1,"warunek stosowania","Pomyłka we wprowadzonych danych", "Liczba","<","0",1)

Jeżeli pomyłkowo zadeklarujemy ujemną wartość zmiennej "Liczba", wyświetlony zostanie komunikat komunikat o treści:

Błędne dane zostały usunięte. Wnioskuj dalej i w odpowiednim miejscu wprowadź poprawione dane.

sygnalizujący usunięcie ujemnej wartosci zmiennej "Liczba" i informujący użytkownika, ze dla jakiegoś przyszłego skanowania bazy modeli może ponownie zadeklarować poprawną wartość tej zmiennej.

------------------------------------------------------------------------------------
W przypadku modeli relacyjnych może zaistnieć potrzeba zadeklarowania oceny stopnia spełnienia relacji,zwanej w dalszym ciągu oceną relacji. Ilustruje to następujący przykład:

model(101,"bez warunku","Bardzo dobre zabezpieczenie a)","Zabezpieczenie I kasy(%)",">=","100",1)

dla którego może być np.:

    1. Zabezpieczenie I kasy(%) = 105, lub;
    2. Zabezpieczenie I kasy(%) = 200.

W przypadku 2 Zabezpieczenie I kasy(%) jest w sposób oczywisty lepsze aniżeli w przypadku 1. Aby to uwzględnić przy wnioskowaniu, można modelowi dla wniosku Bardzo dobre zabezpieczenie a) przyporządkować ocenę relacji będącą liczbą rzeczywistą z przedziału 0 - 10. Można to uczynić za pomocą modelu arytmetycznego oceniającego o postaci:

model(102,"Bardzo dobre zabezpieczenie a)","Ocena finalna Bardzo dobre zabezpieczenie","Ocena_Bardzo dobre zabezpieczenie a)","=","0.0",1)

gdzie Ocena_ jest słowem kluczowym łączonym od przodu z nazwą relacji Bardzo dobre zabezpieczenie a) w modelu arytmetycznym dla pojednczego argumentu dopytywalnego Ocena_Bardzo dobre zabezpieczenie a), dla której chcemy zadeklarować ocenę.
Jeżeli relacja ta będzie spełniona, system wnioskujący zażąda od użytkownika zadeklarowania wartości oceny, którą przyporządkuje zmiennej Ocena finalna Bardzo dobre zabezpieczenie.


Baza ograniczeń rozwinięta dokładna

Baza ograniczeń rozwinięta dokładna dla bazy wiedzy o nazwie NBW nazywa się OGNBW.BRD 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ą zmiennych łańcuchowych logicznych będących nazwami warunków dopytywalnych wzajemnie 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(1,["Wiek <= 20","20 < Wiek <= 40","Wiek > 40"])

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

Celem bazy ograniczeń jest :

    • informowanie użytkownika o zakresie warunków dopytywalnych wykluczających się dla określonego atrybutu;
    • zapobieżenie zadawaniu przez system pytań o warunki, których wartości logiczne wynikają z odpowiedzi już poprzednio udzielonych.

Bazy ograniczeń rozwinięta dokładna nie służy w zasadzie do definiowania warunków dopytywalnych wzajemnie wykluczających się o charakterze dychotomicznym. Jeżeli np. dla pewnych reguł warunkiem dopytywalnym jest dostanę urlop, a dla innych potrzebna jest negacja tego warunku, to uzyskuje się ją korzystając z przedrostka n (małe!), pisząc ndostanę urlop. Ze względu na estetykę językową można jednak posłużyć się bazą ograniczeń, w której będzie ograniczenie dychotomiczne:

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

Obecność bazy ograniczeń 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 grafiki rozwinięta dokładna

Baza grafiki dla bazy wiedzy o nazwie NBW nazywa się GRNBW.BRD. Ponieważ w trakcie wnioskowania rozwiniętego dokładnego wyznaczane są nie tylko wnioski prawdziwe, lecz również nieprawdziwe, baza grafiki rozwinięta dokładna zawiera klauzule dwojakiego rodzaju:

    1. Klauzule wskazujące na plik graficzny w sytuacji gdy odpowiednia reguła lub model relacyjny są spełnione:

      grafika(Numer,"Nazwa_grafiki.bmp")

      gdzie:
        • Numer jest numerem tej reguły (względnie modelu relacyjnego), której (którego) spełnienie generuje propozycję wyświetlenia grafiki o nazwie zawartej w łańcuchu znaków Nazwa_grafiki.bmp;
        • Nazwa_grafiki.bmp jest nazwą pliku graficznego z rozszerzeniem .bmp zawierającego odpowiednią grafikę dla określonej reguły bądź modelu.
    2. Klauzule wskazujące na plik graficzny w sytuacji gdy odpowiednia reguła lub model relacyjny nie są spełnione:

      ngrafika(Numer,"Nazwa_ngrafiki.bmp")

      gdzie:
        • Numer jest numerem tej reguły (względnie modelu relacyjnego), której (którego) niespełnienie generuje propozycję wyświetlenia grafiki o nazwie zawartej w łańcuchu znaków Nazwa_ngrafiki.bmp;
        • Nazwa_ngrafiki.bmp jest nazwą pliku graficznego z rozszerzeniem .bmp zawierającego odpowiednią grafikę dla określonej reguły bądź modelu.

      Użytkownik systemu ekspertowego może - lecz nie musi - skorzystać z propozycji wyświetlenia grafiki.

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

      Bazę grafiki można załadować tylko wtedy, gdy istnieje odpowiadająca jej podkatalog grafik z plikami grafik. Pliki graficzne bazy grafiki GRNBW.BRD umieszczone są w podkatalogu .\GRAFIKA\NBW:


Baza dźwięków rozwinięta dokładna

Baza dźwięków dla bazy wiedzy o nazwie NBW nazywa się DŹNBW.BRD. Ponieważ w trakcie wnioskowania rozwiniętego dokładnego wyznaczane są nie tylko wnioski prawdziwe, lecz również nieprawdziwe, baza dźwięków rozwinięta dokładna zawiera klauzule dwojakiego rodzaju:

    1. Klauzule wskazujące na plik dźwięku w sytuacji gdy odpowiednia reguła lub model relacyjny są spełnione:

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

      gdzie:
        • Numer jest numerem tej reguły (względnie modelu relacyjnego), której (którego) spełnienie generuje propozycję przesłuchania dźwięku o nazwie zawartej w łańcuchu znaków Nazwa_dźwięku.wav;
        • Nazwa_dźwięku.wav jest nazwą pliku dźwięku z rozszerzeniem .wav zawierającego odpowiedni dźwięk dla określonej reguły bądź modelu.
    2. Klauzule wskazujące na plik dźwięku w sytuacji gdy odpowiednia reguła lub model relacyjny nie są spełnione:

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

      gdzie:
        • Numer jest numerem tej reguły (względnie modelu relacyjnego), której (którego) niespełnienie generuje propozycję przesłuchania dźwięku o nazwie zawartej w łańcuchu znaków Nazwa_ngrafiki.bmp;
        • Nazwa_ndźwięku.wav jest nazwą pliku dźwięku z rozszerzeniem .wav zawierającego odpowiedni dźwięk dla określonej reguły bądź modelu.

      Użytkownik systemu ekspertowego może - lecz nie musi - skorzystać z propozycji przesłuchania dźwiękui.

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

      Bazę dźwięków można załadować tylko wtedy, gdy istnieje odpowiadająca jej podkatalog dźwięków z plikami dźwięków. Pliki dźwięków bazy dźwięków DŹNBW.BRD umieszczone są w podkatalogu .\DŻWIĘKI\NBW:


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 o charakterze logicznym (koniunkcje, dyzjunkcje, negacje) powinna znaleźć się w bazie reguł i bazie ograniczeń;
    • wszelka wiedza o charakterze obliczeniowym i relacyjnym powinna znaleźć się w bazie modeli.


Baza rad rozwinięta dokładna

Baza rad dla bazy wiedzy o nazwie NBW nazywa się RANBW.BRD. Ponieważ w trakcie wnioskowania rozwiniętego dokładnego wyznaczane są nie tylko wnioski prawdziwe, lecz również nieprawdziwe, baza rad rozwinięta dokładna zawiera klauzule dwojakiego rodzaju:

    1. Klauzule wskazujące na plik rady w sytuacji gdy odpowiednia reguła lub model relacyjny są spełnione:

      rada(Numer,"Nazwa_rady.hlp")

      gdzie:
        • Numer jest numerem tej reguły (względnie modelu relacyjnego), której (którego) spełnienie generuje propozycję wyświetlenia rady o nazwie zawartej w łańcuchu znaków Nazwa_rady.hlp;
        • Nazwa_rady.hlp jest nazwą pliku rady z rozszerzeniem .hlp zawierającego odpowiedni tekst rady dla określonej reguły bądź modelu.
    2. Klauzule wskazujące na plik rady w sytuacji gdy odpowiednia reguła lub model relacyjny nie są spełnione:

      nrada(Numer,"Nazwa_nrady.hlp")

      gdzie:
        • Numer jest numerem tej reguły (względnie modelu relacyjnego), której (którego) niespełnienie generuje propozycję wyświetlenia rady o nazwie zawartej w łańcuchu znaków Nazwa_nrady.hlp;
        • Nazwa_nrady.hlp jest nazwą pliku rady z rozszerzeniem .hlp zawierającego odpowiednią grafikę dla określonej reguły bądź modelu.

      Użytkownik systemu ekspertowego może - lecz nie musi - skorzystać z propozycji wyświetlenia rady.

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

      Bazę rad można załadować tylko wtedy, gdy istnieje odpowiadająca jej podkatalog grafik z plikami raD. Pliki RAD bazy RAD RANBW.BRD umieszczone są w podkatalogu .\RADY\NBW:


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 Dokładna.


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. 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ń, 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, RA, GR, DŹ) z nazwą bazy wiedzy NBW z nazwą bazy wiedzy NBW i dodania rozszerzenia .BRD (Baza Rozwinięta Dokładna).

Nazwy baz reguł rozwiniętych dokładnych mają więc postać:
RENBW.BRD,

Nazwy baz modeli rozwiniętych dokładnych mają postać::
MONBW.BRD,

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

Nazwy baz rad rozwiniętych dokładnych mają postać:
ADNBW.BRD,

Nazwy baz grafik rozwiniętych dokładnych mają postać:
GRNBW.BRD,

Nazwy baz dźwięków rozwiniętych dokładnych mają postać postać:
DŹNBW.BRD.

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 dokładnych 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ł 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 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 SRD1, tzn. sprzeczności pomiędzy warunkami reguł a ich wnioskami. Jeżeli załadowana baza reguł zawiera sprzeczności zewnętrzne typu SRD1, to system powiadamia o tym użytkownika odpowiednim komunikatem. Dla baz reguł zawierających sprzeczności SRD1 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ł dokładna, 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 typu SRD1, to system proponuje testowanie obecności sprzeczności wewnętrznych typu SRD1, tzn. obecności reguł o sprzecznych listach warunków. Opcjonalny charakter testu obecności sprzeczności wewnętrznych wynika z dwóch powodów:
      1. Sprzeczności wewnętrzne nie są tak katastrofalne w skutkach jak sprzeczności zewnętrzne. Obecność sprzeczności wewnętrznych sprawia tylko, że pewne reguły nie będą nigdy stosowane.
      2. Test sprzeczności wewnętrznych wymaga spłaszczenia wszystkich reguł, co w przypadku silnie zagnieżdżonych baz może trwać bardzo długo.
      Użytkownik bazy reguł uprzednio już testowanej na obecność sprzeczności wewnętrznych może więc z tego testu zrezygnować. Jeżeli użytkownik zażąda wykonania testu sprzeczności wewnętrznych, to zostaje powiadomiony odpowiednim komunikatem o braku lub obecności sprzeczności wewnętrznych. Dla baz reguł zawierających sprzeczności wewnętrzne typu SRD1 możliwe jest wnioskowanie. Należy jednak pamietać, że reguły wewnętrznie sprzeczne są niedostrzegalne przez system wnioskujący, co może wpłynąć na wnioskowanie.
    4. Jeżeli załadowana baza reguł nie zawiera sprzeczności zewnętrznych typu SRD1, to system proponuje sprawdzenie obecności w bazie nadmiarowości typu NRD1 (występowanie reguł o jednakowych wnioskach i warunkach, reguł subsumowanych lub reguł o niepotrzebnych warunkach).
      Dla baz reguł zawierających nadmiarowości typu NRD1 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 NRD1, 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 NRD1 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ł dokładna), 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 SRD1, 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 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 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ń.
      Baza ograniczeń 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ń 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ń 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ń i dlatego test ten jest przeprowadzany dopiero po załadowaniu bazy ograniczeń. Jeżeli w bazie modeli są modele o jednakowych wynikach, 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ń nie ma list z pojedynczym warunkiem, system przechodzi do testowania dopytywalności warunków bazy ograniczeń. 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ń nie ma błędów syntaktycznych, warunków pojedynczych i warunków niedopytywalnych, system proponuje testowanie obecności sprzeczności łącznych typu SRD2 (baza reguł i baza ograniczeń tworzą reguły o warunkach wzajemnie wykluczających się). Opcjonalność tego testu wynika z dwóch powodów:
      1. Sprzeczność łączna baz reguł i ograniczeń nie doprowadza do powstania nieskończonych pętel, lecz jedynie czyni pewne reguły martwymi, tzn. nigdy nie stosowanymi.
      2. Test ten wymaga również spłaszczania wszystkich reguł i dlatego może - dla silnie zagnieżdżonych baz reguł - trwać bardzo długo.
      Użytkownik bazy reguł i bazy ograniczeń uprzednio już testowanej na obecność sprzeczności łącznych może więc z tego testu zrezygnować. Jeżeli użytkownik zażąda wykonania testu, to zostaje powiadomiony odpowiednim komunikatem o braku lub obecności sprzeczności.
      Dla baz reguł i baz ograniczeń zawierających sprzeczności łączne typu SRD2 możliwe jest wnioskowanie. Należy jednak pamietać, że reguły sprzeczne łącznie są niedostrzegalne przez system wnioskujący, co może wpłynąć na wnioskowanie. Użytkownik może zażądać diagnozy sprzeczności łącznych, usunąć je za pomocą edytora i ponownie przejść do wnioskowania z poprawioną bazą reguł i bazą ograniczeń.

    16. Po teście sprzeczności łącznych typu SRD2 system proponuje testowanie obecności nadmiarowości łącznych typu NRD2 bazy reguł i bazy ograniczeń. Istotą nadmiarowości łącznych jest zaistnienie - w wyniku interakcji bazy reguł i bazy ograniczeń - 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 NRD2 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 baz reguł i ograniczeń zawierających nadmiarowości łączne typu NRD2 dopuszcza się możliwość wnioskowania. Nie zaleca się jednak tego, gdyż nadmiarowość NRD2 może uzależnić wynik wnioskowania od niepotrzebnych warunków. Dlatego użytkownik może zażądać diagnozy nadmiarowości typu NRD2, usunąć je za pomocą edytora i przejść do wnioskowania z poprawioną bazą reguł.

    17. 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.

    18. 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ł dokładna.

    19. 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 dokładna.

    20. 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ł Dokładna, Bazie Modeli Dokładna, Baza Ograniczeń Dokładna, Baza Rad Dokładna 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", ["nWarunek_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 dwie reguły spłaszczone i za pomocą reguł m i n:

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

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

Wynika to stąd, że nWarunek_i1 jest prawdą dla dwóch przypadków:

    • gdy prawdą jest nWarunek_m1, lub
    • gdy prawdą jest nWarunek_m2.

Nawet w przypadku braku zanegowanego warunku niedopytywalnego można spłaszczyć regułę na szereg sposobów. Np. reguła:

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

w sytuacji istnienia reguł:

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

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

których wszystkie warunki są dopytywalne, daje dwie reguły spłaszczone:

reguła_splaszczona(i,"Wniosek_i",["nWarunek_i1","Warunek_m1",
"Warunek_m2"],[m])

reguła_splaszczona(i,"Wniosek_i",["nWarunek_i1","Warunek_n1",
"Warunek_n2"],[n])

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

    • wykrywania i diagnozowania sprzeczności wewnętrznych baz reguł;
    • 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ń.

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 MENU 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.


Zmienne

W systemach ekspertowych rmse_RD 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 elementarnych dokładnych mogą być logiczne, rzeczywiste i całkowite.

    1. Zmienne łańcuchowe logiczne mają inkludy będące zmiennymi logicznymi, tzn. zmiennymi przyjmującymi tylko dwie wartości (prawda i nieprawda). Np. zmienna łańcuchowa Wiek > 45 lat jest zmienną łańcuchową logiczną, gdyż wiek może być albo większy, albo niewiększy niż 45 lat. Zmienne łańcuchowe logiczne służą do zapisu wniosków, warunków dopytywalnych i warunków niedopytywalnych.
      Zmienne logiczne przedstawiające warunki dopytywalne mogą być ukonkretnione lub nieukonkretnione. Zmiena Warunek_dopytywalny może być ukonkretniona:
      • jako prawda za pomocą klauzuli fakt("Warunek_dopytywalny") w bazie reguł.
      • jako nieprawda za pomocą klauzuli fakt("nWarunek_dopytywalny") w bazie reguł.

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

      Zmienne logiczne są przetwarzane następująco:
      1. Jeżeli dopytywalna zmienna logiczna jest nieukonkretniona, system ekspertowy zapyta się użytkownika o jej wartość logiczną w odpowiednim miejscu wnioskowania.
      2. Jeżeli dopytywalna zmienna logiczna jest ukonkretniona, system ekspertowy nie pyta się o nic, lecz stosuje jej wartość w regułach, w których występuje.
      3. Jeżeli niedopytywalna zmienna logiczna jest nieukonkretniona, system ekspertowy wyznaczy - jeżeli to jest możliwe - jej wartość logiczną w trakcie wnioskowania.
      4. Niedopytywalnych zmiennych logicznych nie wolno ukonkretniać za pomocą klauzul fakt(_). Ukonkretnienia takie nie są akceptowane przez system ekspertowy.

    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ń za pomocą klauzul:

      rem_ograniczenie("Tekst komentarza").

    4. 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 wygląda następująco: :

      _ograniczenie(Nr,Lista_warunków).

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

      _rada(Nr,"Nazwa_rady"),

      lub:

      _nrada(Nr,"Nazwa_rady"),

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

      _grafika(Nr,"Nazwa_grafiki),

      lub:

      _ngrafika(Nr,"nNazwa_grafiki).

    9. 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 dokładne mogą zawierać sprzeczności zewnętrzne i wewnętrzne, oznaczane skrótem SRD1, oznaczającym Sprzeczności Rozwinięte Dokładne 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).

      Najprostszym przypadkiem sprzeczności zewnetrznej jest samosprzeczność. Reguła jest zewnętrznie SRD1-samosprzeczna, jeżeli jednym z jej warunków jest jej wniosek lub zanegowany wniosek, co ilustrują dwa poniższe przykłady:

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

      dla której Wniosek jest zarazem wnioskiem reguły, jak i jej warunkiem, oraz:

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

      dla której zanegowany wniosek nWniosek jest 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 SRD1-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 SRD1-sprzecznej z regułą n. Np. reguła 1 jest zewnętrznie pośrednio SRD1-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"],1)

      Sprzeczności zewnętrzne mają charakter krytyczny: ich obecność może doprowadzić do zawieszenia się procesu wnioskowania. Reguł zewnętrznie sprzecznych nie można również z spłaszczać z powodu zawieszenia się procesu spłaszczania. 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 preyzyjnie kryterium sprzeczności wewnętrznej:
      1. Regułę bazy reguł rozwiniętej dokładnej uważa się za wewnętrznie sprzeczną, jeżeli wszystkie możliwe spłaszczenia tej reguły są regułami wewnętrznie sprzecznymi i nie ma innej reguły z identycznym wnioskiem, której wszystkie możliwe spłaszczenia ą również regułami wewnętrznie sprzecznymi. Tylko bowiem wtedy reguła ta jest definitywnie eliminowana z bazy reguł.
      2. Jeżeli przynajmniej jedno spłaszczenie tej reguły nie jest wewnętrznie sprzeczne,lub istnieje inna reguła z identycznym wnioskiem i przynajmniej jednym spłaszczeniem nie będącym wewnętrznie sprzecznym, reguły nie uważa się za wewnętrznie sprzeczną. Reguła ta (lub reguła o identycznym wniosku) bowiem będzie mogła dla jakiegoś spłaszczenia być stosowana.
      Oczywiście, samo stwierdzenie braku sprzeczności wewnętrznych nie jest jeszcze świadectwem absolutnej poprawności bazy reguł: test sprzeczności wewnętrznych ma na celu jedynie wykazanie, czy dana reguła jest całkowicie eliminowana z bazy reguł, czy też nie jest.

      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ły 1 i 2 mają jednakowy wniosek W. Dla reguły 2 istnieje spłaszczenie ze sprzeczną lista warunków ["E","C","nE"]. lecz dla reguły istnieje spłaszczenie ["B","A"] z niesprzeczną listą warunków, a więc reguła ta nie jest wewnętrznie sprzeczna. To samo zachodzi dla reguły 4, która tylko dla jednego spłaszczenia ["B","nB"] ma sprzeczną liste warunków. Pozostałe cztery spłaszczenia mają niesprzeczne listy warunków. Dlatego omawiana baza reguł nie ma wewnętrznych sprzeczności.

        Sprzeczności wewnętrzne nie mają charakteru krytycznego: ich obecność nie doprowadza do "zawieszenia się" procesu wnioskowania,lecz jedynie do 'usunięcia' wewnętrznie sprzecznych z bazy reguł. 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ń

Bazy reguł rozwinięte dokładne i bazy ograniczeń dokładne mogą zawierać sprzeczności łączne, oznaczane skrótem SRD2, oznaczającym Sprzeczności Rozwinięte 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"],_)

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

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

Ograniczenie to sprawia, że koniunkcja warunków reguły będzie zawsze nieprawdziwa, tzn. z reguły tej nie będzie można nigdy korzystać.

Sprzeczności łączne bazy reguł i bazy ograniczeń nie mają charakteru krytycznego: ich obecność nie doprowadza do zawieszania się procesu wnioskowania, lecz jedynie do faktycznego usunięcia reguły łącznie sprzecznej z bazy.

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ł.

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

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


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)

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)

model(M,"bez warunku","B","C","*","Wynik",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)

reguła(M,"Warunek stosowania",["Wniosek modelu",....],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)

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

reguła(P,"Warunek",["Wniosek modelu",....],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 dokładne mogą zawierać nadmiarowości, oznaczane skrótem NRD1, który znaczy Nadmiarowości Rozwinięte Dokładne generowane przez pojedynczą bazę. Rozróżnia się następujące nadmiarowości:

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

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

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

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

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

      reguła 4 ma takie same warunki i taki sam wniosek jak reguła 1 wraz z regulami 2 i 3. Można więc z bazy reguł usunąć albo regułę 4 albo reguły 1, 2 i 3. Bardziej wskazane będzie zapewne usunięcie reguły 4 gdyż reguły 1, 2 i 3 dostarczają informacji o warunkach pośrednich A i B, która to informacja może w konkretnym przypadku być użyteczna.
    2. Nadmiarowości typu NRD1_2: występowanie reguł subsumowanych. Np. w przypadku reguł:

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

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

      reguła 1 jest subsumowana (zawarta) w regule 2, gdyż obydwie mają taki sam wniosek, a warunki reguły 2 są podzbiorem warunków reguły 1. Regułę 1 można więc usunąć z bazy reguł. Jeżeli bowiem reguła 1 jest spełniona, to również reguła 2 jest spełniona. Jednakże pozostawienie reguły 1 w bazie reguł może zafałszować wyniki wnioskowania, uzależniając wniosek W od niepotrzebnych warunków C i D.

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ń

Źródłem nadmiarowości łącznych w bazach reguł i bazach ograniczeń, oznaczanych skrótem NRD2, jest interakcja bazy reguł i bazy ograniczeń. Skrót NRD2 oznacza Nadmiarowości Rozwinięte Dokładne generowane przez dwie bazy.
Np. fragment bazy reguł:

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

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

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

w przypadku obecnosci w bazie ograniczeń ograniczenia:

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

redukuje się do pojedynczej reguły:

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

Niezależnie bowiem od tego, czy jest prawdą C, D lub E, aby było prawdą Y wystarczy, że prawdą są A i B.

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 sie, zadeklarowanych w bazie ograniczeń.

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ę

Rozróżnia się:

    1. Wykluczalność wniosków reguł
      Często określony zbiór reguł powinien mieć wnioski wykluczające się. 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. Nie można jej również zadeklarować korzystając z dychotomii generowanych przez przedrostek negacji n. Baza ograniczeń i przedrostki negacji spełniają 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 jako wykluczające się albo za pomocą przedrostka n albo za pomocą bazy ograniczeń dokładnych;
      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","nB"],_)

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

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

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

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

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

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

      reguła(4,"Wniosek_4",["nA","nB","C"],_)

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

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

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

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

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

      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"],_)

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

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

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

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

      reguła(4,"Wniosek_4",["nA","nB","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"],_)

      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)

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

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

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

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

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

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

      model(18,"Wniosek_4","Wynik","GG","+","HH",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)

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

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

      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 - 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ć klauzulę :

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

      Jednakże dla przykładu:

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

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

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

      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.
Klauzulę:

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

można również stosować gdy wnioski w niej zawarte są wykluczającymi się wnioskami reguł.


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 spełnienia pewnych warunków.

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ąc ym 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ę albo, za pomocą przedrostka n (w przypadku pary warunków) albo za pomocą bazy 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 przykład dwóch modeli tym samym wyniku i wykluczających się warunkach startowych:

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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)

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

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

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

Aby jednak system wnioskujący zaakceptował wnioski modeli 11 - 14 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 określonych przez modele 11 - 14.

Jeżeli modele arytmetyczne o tym samym wyniku nie mają wzajemnie wykluczających się warunków startowych, wnioskowanie nie zostaje przeprowadzone.


ROZWINIĘTE DOKŁADNE

REGUŁOWO - MODELOWE

SYSTEMY EKSPERTOWE

rmse_RD


Plik pomocy CHM dla Rozwiniętych Dokładnych
Regułowo-Modelowych Systemów Ekspertowych rmse_ED