Niniejszy projekt obejmuje fragmenty teorii automatów. W teorii

Nr wniosku: 200046, nr raportu: 19300. Kierownik (z rap.): dr Paweł Parys
Niniejszy projekt obejmuje fragmenty teorii automatów. W teorii automatów poszukuje si˛e modeli automatów, które z jednej strony dobrze opisuja˛ ciekawe procesy, a z drugiej strony sa˛ na tyle proste, że rozstrzygalne
sa˛ podstawowe problemy obliczeniowe ich dotyczace.
˛ Przykładowo, z naszego punktu widzenia program komputerowy jest obiektem zbyt skomplikowanym do analizy. Program taki możemy uruchomić i obserwować jak
si˛e zachowuje, ale niewiele wi˛ecej da si˛e z nim zrobić. Tymczasem cz˛esto chcielibyśmy si˛e upewnić co do
pewnych własności programu, dotyczacych
˛
jego poprawności, na przykład, że po otwarciu pliku zawsze nast˛epuje zamkni˛ecie tego pliku. Możemy sprawdzić ta˛ własność wielokrotnie uruchamiajac
˛ program i patrzac,
˛
że zawsze tak robi, ale mimo to nie mamy pewności, że za kolejnym razem także tak b˛edzie, na przykład gdy
użytkownik wpisze jakieś dziwne dane. Aby mieć pewność, musimy przeanalizować kod programu, a nie tylko
obserwować jego działanie. W dodatku, aby była możliwa jakaś sensowna automatyczna analiza tego kodu,
musi być on najpierw uproszczony. Jako wst˛epny etap takiej analizy, z programu zostana˛ usuni˛ete pewne szczegóły; zapomnimy o tym, jakie konkretnie obliczenia wykonuje, itp. B˛edziemy wiedzieli tylko przez jakie po
kolei instrukcje program przechodzi, nie wiedzac
˛ co te instrukcje tak naprawd˛e robia.˛ W ten sposób dostajemy
automat: ma on najcz˛eściej skończenie wiele stanów (czyli miejsc, w których wykonanie programu obecnie
si˛e znajduje), mi˛edzy którymi istnieja˛ jakieś przejścia, mówiace
˛ jaki stan może być nast˛epny. Zauważmy, że
instrukcje niekoniecznie sa˛ wykonywane po kolei od poczatku
˛ do końca, gdyż w programie moga˛ być p˛etle,
jak również instrukcje warunkowe (if-y); w szczególności może być wiele nast˛epników danego stanu.
Majac
˛ dany taki automat, możemy pytać o jakieś jego własności, zapewne zapisane w jakiejś logice (takie
jak wspomniana własność, że po otwarciu pliku zawsze nast˛epuje zamkni˛ecie tego pliku). Myślimy tutaj o tym,
że chcielibyśmy mieć program, który dostajac
˛ automat oraz formuł˛e logiczna˛ sprawdza, czy ta formuła jest zawsze spełniona dla tego automatu (jest to tak zwany problem spełnialności). To czy taki program może istnieć,
czy nie, zależy od tego na jakie konkretnie automaty i formuły logiczne pozwalamy. Oczywiście im prostsze
automaty i formuły logiczne, tym łatwiej można stworzyć taki program. Z drugiej strony chcemy pozwalać na
jak najbardziej skomplikowane automaty, które moga˛ jak najwierniej odzwierciedlać symulowany program, a
także na jak najbardziej skomplikowane formuły logiczne, b˛edace
˛ w stanie wyrazić jak najwi˛ecej interesuja˛
cych własności, które ktoś chciałby sprawdzać. Jeśli jednak dozwolimy na zbyt skomplikowane automaty badź
˛
zbyt skomplikowane formuły, to nasz problem spełnialności stanie si˛e nierozstrzygalny. Nierozstrzygalność
oznacza, że nie istnieje program, który dany problem rozwiazuje
˛
(i w pewnych sytuacjach można rzeczywiście
udowodnić, że żaden program nie jest w stanie wykonać jakiegoś zadania).
Szczególna˛ logika˛ do służac
˛ a˛ do opisywania własności automatów jest logika˛ MSO+U. Ciekawym jej
elementem jest kwantyfikator U, który jest w stanie wyrazić, że pewne wielkości sa˛ ograniczone, badź
˛ nieograniczone. Ma to głównie sens dla automatów, które działaja˛ w nieskończoność (automat taki może symulować
zachowanie jakiegoś serwera, którego działanie si˛e nie kończy, lecz odpowiada on nieustannie na otrzymywane
zapytania). Możemy na przykład chcieć wyrazić, że rozmiary kolejno wysyłanych przez serwer odpowiedzi
b˛eda˛ ograniczone, a nie b˛eda˛ rosły w nieskończoność. Logika MSO+U została zaproponowana w roku 2004,
lecz do tej pory nie było wiadomo, czy problem spełnialności dla niej jest rozstrzygalny. Udało nam si˛e odpowiedzieć na to pytanie, niestety negatywnie: udowodniliśmy, że problem ten jest nierozstrzygalny. Choć odpowiedź taka nie daje jakichkolwiek nowych możliwości w praktyce, to odpowiada na istotne pytanie otwarte i
poszerza nasze zrozumienie rzeczywistości. Sugeruje też, że trzeba rozważać inne (słabsze) logiki. Istotnie, dla
pewnych fragmentów MSO+U problem spełnialności jest rozstrzygalny; my także w ramach naszego projektu
zajmowaliśmy si˛e takimi fragmentami.
Badaliśmy także automaty ze stosem wyższego rz˛edu; sa˛ to automaty symulujace
˛ programy, w których
procedury moga˛ otrzymywać inne procedury jako argumenty. Jest to tak zwana rekurencja wyższego rz˛edu
i wyst˛epuje w wielu współczesnych j˛ezykach programowania. Dla tych automatów udało nam si˛e stworzyć
algorytm rozstrzygajacy
˛ tzw. problem przekatniowy.
˛
Ogólnie rzecz ujmujac,
˛ problem ten pyta, czy może si˛e
zdarzyć, że każde zdarzenie z zadanego zbioru zdarzeń wystapi
˛ dowolnie wiele razy. Pytanie to jest naturalne
samo w sobie (można si˛e spodziewać, że ktoś b˛edzie chciał zapytać właśnie o taka˛ własność dla jakiegoś automatu), jak również ujawnia si˛e ono jako składowa innych problemów. Dzi˛eki naszemu algorytmowi dostajemy
wi˛ec możliwość obliczania paru innych rzeczy dla automatów ze stosem wyższego rz˛edu.