Turing-Maschine als Modell von Automatenprogrammen

Turing-Maschine als Modell von Automatenprogrammen


1. Einleitung


Die Programmierung erfordert neue universelle algorithmische Modelle, und die Hardware implementiert Algorithmen nicht nur in einer anderen Form, sondern auch auf der Grundlage eines anderen algorithmischen Modells - automatisch. Die Übernahme von Technologien aus dem Bereich der Hardwareentwicklung ist eine Schlüsselidee der automatisierten Programmierung. Die Synthese digitaler Geräte unterscheidet sich jedoch von der Programmierung. Ein Modell auszuleihen, ist einerseits nicht ratsam, es grundlegend zu ändern, andererseits kann man die bestehende Theorie und Praxis der Programmierung nicht ignorieren.

Als nächstes betrachten wir die SWITCH-Technologie zum Entwerfen automatisierter Programme, in denen Sie ständig auf solche Prozesse stoßen. Zum einen hat es das Zustandsmaschinenmodell so verändert, dass es tatsächlich über den Rahmen der Automatentheorie hinausging. Zum anderen führt es in Programmierkonzepte ein, die für Programmierer nur schwer erkennbar und mitunter einfach überflüssig sind, weil Es gibt bekanntere Gegenstücke aus der Programmtheorie und der Programmierpraxis.

Als Grundlage für die Diskussion von Problemen der automatischen Programmierung nehmen wir den jüngsten Vortrag von A. Shalyto [1] und seine „programmatischen“ Artikel zur Definition des Paradigmas der automatischen Programmierung [2, 3].

1. Automatisierte Objekte, Programmschemata

Das Erreichen der automatischen Programmierung ist in der Vorlesung die Einführung in das Konzept der automatisierten Steuerungsobjekte, das der Theorie der automatischen Steuerung (TAU) entlehnt ist. Denken Sie jedoch daran, dass in der TAU nicht so viele Objekte, sondern Systeme betrachtet werden, von denen die folgenden unterschieden werden [4]:

Bild

Auf dieser Grundlage wäre es richtiger, von automatischen Steuersystemen (ACS) zu sprechen. Betrachten wir nun das typische Funktionsdiagramm der in Abb. 1 gezeigten selbstfahrenden Pistolen. 1. Wenn das Band der Turingmaschine als Steuerobjekt betrachtet wird, sind die Betätigungsvorrichtungen (IS) MT-Elemente, die das Ändern des Bandinhalts und das Bewegen des Kopfes implementieren, und Messvorrichtungen (IS) sind die Elemente, die Informationen vom Band lesen.

Bild
1. Funktionsschema selbstfahrender Geschütze

Aber warum wenden Sie sich an die TAU, wenn es eine Praxis gibt, die der Programmierung des Entwurfs von Computersystemen näher kommt, bei der Betriebsgeräte (OS), zu denen natürlich auch MT gehört, als eine Kombination von Betriebs- (OA) und Steuerungsmaschinen (UA) betrachtet werden. Und das ist näher an dem, was wir letztendlich anstreben - die Berechtigung der automatischen Programmierung. In Abb. 2 zeigt einen Bildschirm mit Text aus einer Monographie von Mayorov S.A., Novikov G.I. Die Struktur elektronischer Computer [5], in der die Designaspekte von Operationsverstärkern im Detail betrachtet werden.

Bild
2. Das Konzept des Managers und des Bedienens von Maschinen

Vergleicht man jedoch die Theorie des Computerdesigns und die Theorie der Programme, so lässt sich eine offensichtliche strukturelle Analogie zwischen ihnen feststellen. In der Programmiertheorie kann das Modell jedes Programms auf struktureller Ebene als Programmschema S = (M, A, C) dargestellt werden, wobei M die Menge der Speicherelemente ist, A die Menge der Operatoren ist und C die Steuerung ist [10]. Nach diesem Ansatz kann jedes Turing-Maschinenprogramm auch als ein Programmschema definiert werden, bei dem die Menge M durch Bandzellen dargestellt wird, wobei die Menge der Operatoren durch MT-Aktionen mit 1) Zellanalyse, 2) Ändern von Zeichen in den Bandzellen und 3) Bewegen des Kopfes verbunden ist.

Somit ist das Konzept eines Programmschemas völlig analog zu dem betrachteten Konzept von Betriebs- und Steuerautomaten, wobei das Modell von UA ​​das Modell der unten betrachteten strukturellen Finite-State-Maschine (SKA) ist und OA eine Struktur zum Ausführen von Aktionen auf Informationen ist. In diesem Fall enthält OA Datenspeicherelemente (oben ist der Speicher) und Blöcke zur Verarbeitung von Informationen, die die Berechnung logischer Bedingungen und die Implementierung bestimmter Aktionen (oben - viele Operatoren) implementieren.

Aus dem Vorstehenden kann verstanden werden, dass das Band nur bedingt als das Steuerobjekt für MT betrachtet werden kann. Schon allein deshalb, weil das Steuergerät der Turingmaschine keinen direkten Zugriff darauf hat, weil Alle Operationen mit Zellen werden indirekt durch OA-Blöcke realisiert. Darüber hinaus scheint es nicht sehr vertraut oder, um es nicht zu sagen, seltsam zu sein, ein Objekt, das einen Speicher (ein Band) darstellt, als Ziel des Programmmanagements als ein Steuersystem zu betrachten.
Für eine formale Definition einer Turing-Maschine und in ihrem Kontext einen Platz für ein Finite-State-Machine-Modell reichen daher die Konzepte der Programmtheorie aus. Im Gegensatz zu der sehr vagen Definition von Automatenprogrammen im Rahmen der SWITCH-Technologie kann man nun sagen, dass ein Automatenprogramm ein Programm ist, das die Kontrolle in Form eines endlichen Automatenmodells hat.

Was wird das Programm selbst sein - mit einfachem oder komplexem Verhalten, was ist seine "Vielfalt" - mit logischer Kontrolle, "mit expliziter Zuweisung von Zuständen" usw. usw. spielt absolut keine rolle. Die Hauptsache ist die Art des Managements. Die übrigen Elemente des Programms lassen sich über einen weiten Bereich bestimmen - vom einfachsten wie zum Beispiel mit einer Turing-Maschine bis zum komplexesten - jede Form von Operatoren, Funktionen und Datenstrukturen von Programmiersprachen - Assembler, Hochsprache usw.

Sie können sich auch daran erinnern, dass eine Turing-Maschine lange als automatische Matte [6] oder im Extremfall als einfache Erweiterung [7] galt. Aber Sie müssen verstehen, um welche Art von Automat es sich handelt, um welche Art von Erweiterung es sich handelt und ob sie den Modellen klassischer endlicher Automaten entsprechen. Versuchen wir dies zu klären.

2. Programmierung in einer automatisierten Programmierumgebung

In Abb. Abbildung 3 zeigt den Automaten für die MT-Inkrementfunktion aus der Monographie [8]. In der Form ist dies eindeutig kein MT-Programm, sondern bereits keine klassische Finite-State-Maschine. In Abb. Abbildung 4 zeigt den Graphen der klassischen strukturellen Finite-State-Maschine (SKA) und ihre Implementierung in der VKPa-Umgebung (die Umgebung der automatischen Programmierung visueller Komponenten in C ++ im Rahmen der Qt-Bibliothek und der Qt Creator-Umgebung), in der derselbe MT-Steuergerätealgorithmus implementiert ist.

Bild
3. Erhöhen Sie die Anzahl pro Einheit mit einer Turing-Maschine

Bild
Abb. 4 Modell des Inkrementprogramms für MT in Form von SKA

Sie sehen, dass die Strukturmaschine vier Eingangs- und fünf Ausgangskanäle hat. Jedem dieser Kanäle ist eine gleichnamige Programmfunktion zugeordnet - ein Prädikat oder eine Aktion. In diesem Fall sind Prädikate Funktionen ohne Parameter, die abhängig vom Wert der angezeigten Bandzelle einen Booleschen Wert zurückgeben, und Aktionen sind Funktionen ohne Parameter, die die eine oder andere Aktion ausführen, um die Bandzelle zu ändern und den Kopf der Turing-Maschine zu bewegen.

Diese SKA hat den gleichen Satz von Zuständen wie der Automat in Fig. 3. Zusätzlich zu der von SKA präsentierten Automatenzuordnung selbst werden zwei weitere Zuordnungen implementiert: die Zuordnung der Menge von Prädikaten (x1, ..., xM) zu der Menge von Eingangskanälen derselben Maschine und die Menge von Ausgangskanälen der Maschine zu der Menge derselben Aktionen - y1, ..., yN. Beispielsweise gibt das Prädikat x3 true zurück (Wert 1 für das gleichnamige Eingangssignal), wenn die aktuelle Zelle eine 1 enthält, und die Aktion y4, die ausgelöst wird, wenn dasselbe Ausgangssignal der Maschine den Wert 1 annimmt, entspricht dem Bewegen des Kopfes nach links (L) und etc. usw.

Beachten Sie, dass die SKA das Band nicht direkt steuert, sondern [zusätzliche] Zuordnungen implementiert, die die Signale des Automaten mit den Funktionen verknüpfen, die die vielen Operationen der Turing-Maschine bestimmen. Dies überzeugt uns erneut davon, dass es nicht erforderlich ist, das Konzept eines automatisierten Steuerobjekts in einer Situation einzuführen, in der das „altmodische“, aber mathematisch strenge Mapping-Konzept ausreicht.

Vergleich der Automaten in Abb. 3 und fig. In 4 ist zu sehen, dass SKA den Befehl „*“ nicht verwendet (siehe 1). In einer solchen Situation reicht es aus, dass er kein mit diesem Befehl verbundenes Signal ausgibt. Außerdem sind zwei oder mehr Signale (sowohl Eingang als auch Ausgang) am selben Übergang parallel. Wenn daher ein Konflikt beim Zugriff auf gemeinsam genutzte Objekte besteht (z. B. müssen Sie die Zelle wechseln und den Kopf bewegen), wird eine Vereinbarung verwendet: Aktionen für einen Übergang werden nacheinander in der Reihenfolge ihrer Nummern ausgeführt, d. H. Eine Aktion mit einer höheren Nummer wird nach einer Aktion mit einer niedrigeren Nummer ausgeführt. Diese Vereinbarung gilt nicht für Vergleichselemente wie Sie wechseln das Band nicht. So machen wir die Maschine kompakter und intuitiver (keine Notwendigkeit, Zwischenzustände einzuführen).

Beim Testen des Inkrementierungsprogramms wurden Situationen identifiziert, in denen Probleme während des Betriebs des MT auftreten können. Erstens ist das reale Band nicht unendlich, und wenn Sie darüber hinausgehen, kann ein Programm abstürzen. Zweitens muss die Ausgangsposition des Kopfes angegeben werden. Befindet sich zum Beispiel die Nummer an einer beliebigen Stelle des Bandes und befindet sich der Anfangszustand des Kopfes links von der Nummer und gegenüber dem Leerzeichen, beginnt der Kopf sofort, sich nach links zu bewegen. Dann kann es über die Grenzen des Bandes hinausgehen und das Programm zum „Absturz“ bringen. Wenn es einen Schritt nach links verschoben wird, schreibt es in Zelle 1 und schließt den „erfolgreichen“ Vorgang ab. Wenn die Zahl eine 1 in allen Ziffern enthält und vom Bandanfang an geschrieben wird, führt der letzte Versuch, eine 1 auf die übergeordnete Ziffer zu übertragen, zum gleichen „Absturz“.

2.1. Objektimplementierung von MT in C ++

Betrachten Sie die Implementierung der Objektsoftware einer Turing-Maschine in C ++ in der VKPa-Umgebung, die ein beliebiges Programm für MT implementiert, einschließlich des Inkrementberechnungsprogramms.

Zu diesem Zweck wurde eine Basisklasse erstellt, die jede Turing-Maschine darstellt, die von Softwareobjekten geerbt wird, die das eine oder andere MT-Programm implementieren. Diese grundlegende Aufgabe wird in Listing 1 gezeigt, und das Programm, das die Inkrementierungsaufgabe implementiert, wird in Listing 2 gezeigt.

Listing 1. Software-Implementierung der MT-Basisklasse

#include "lfsaappl.h" class FTuringMashine : public LFsaAppl { public: FTuringMashine(string strNam, CVarFsaLibrary *pCVFL, LArc* pTBL); protected: int x15(); int x16(); void y14(); void y15(); void y16(); void y17(); QString strSrc; //    QString strTape; //  QString strHead; //  int nIndexHead{0}; //   bool bRestart{false}; //   int nHeadPosition{0}; //    }; #include "stdafx.h" #include "FTuringMashine.h" FTuringMashine::FTuringMashine(string strNam, CVarFsaLibrary *pCVFL, LArc* pTBL): LFsaAppl(pTBL, strNam, nullptr, pCVFL) { nHeadPosition = 0; strHead = "________________________________________"; nIndexHead = nHeadPosition; } //============================================================== //  //  ? int FTuringMashine::x15() { return strTape[nIndexHead] == '#'; } // ? int FTuringMashine::x16() { return bRestart; } //============================================================== //  //      void FTuringMashine::y14() { strTape[nIndexHead] = '#'; } //    ( ) void FTuringMashine::y15() { nIndexHead++; } //    ( ) void FTuringMashine::y16() { nIndexHead--; } //     void FTuringMashine::y17() { strTape = strSrc; nIndexHead = 0; bRestart = false; nIndexHead = nHeadPosition; } 

Listing 2. Inkrementierungsprogramm für eine Turingmaschine

 #include "FTuringMashine.h" class FTIncrement : public FTuringMashine { public: LFsaAppl* Create(CVarFSA *pCVF) { Q_UNUSED(pCVF)return new FTIncrement(nameFsa, pCVarFsaLibrary); } FTIncrement(string strNam, CVarFsaLibrary *pCVFL); protected: int x1(); int x2(); int x3(); void y1(); void y2(); }; #include "FTIncrement.h" static LArc TBL_TIncrement[] = { // . . , .   , 2- , 2011 ., // .17-18 //=====    (. ..   , - .: , 2003. - 208 .) ============== // f(,^` `) = (,`*`,R) // f(,` `) = (,` `,L) // f(,`1`) = (,`0`,L) // f(,` `) = (,`1`,R) // f(,`0`) = (,`1`,R) //========================================= LArc(" ", " ", "^x1", "y15"), LArc(" ", " ", "x1", "y16"), LArc(" ", " ", "x2", "y2y16"), LArc(" ", "", "x1", "y1"), LArc(" ", "", "x3", "y1"), LArc("", " ", "x16", "y17"), LArc() }; FTIncrement::FTIncrement(string strNam, CVarFsaLibrary *pCVFL): FTuringMashine(strNam, pCVFL, TBL_TIncrement) { strSrc = "11011110011111 "; strTape = strSrc; } //  int FTIncrement::x1() { return strTape[nIndexHead] == ' '; } int FTIncrement::x2() { return strTape[nIndexHead] == '1'; } int FTIncrement::x3() { return strTape[nIndexHead] == '0'; } //  void FTIncrement::y1() { strTape[nIndexHead] = '1'; } void FTIncrement::y2() { strTape[nIndexHead] = '0'; } 

2.2. Beispiele für Programme für MT mit Implementierung in C ++

Man betrachte ein Beispiel eines Programms für MT, das "als Sprachakzeptor fungiert, d. H. es kann Sprache erkennen “aus [9]. Seine Übergangsfunktion ist in Abb. 5 und der äquivalente Automat in Form von SKA in Fig. 6.

 δ(1, a) = (2, x, R) δ(1, y) = (4, y, R) δ(2, a) = (2, a, R) δ(2, y) = (2, y, R) δ(2, b) = (3, y, L) δ(3, y) = (3, y, L) δ(3, a) = (3, a, R) δ(3, x) = (1, x, R) δ(4, y) = (4, a, R) δ(4, #) = (F, #, L) 

Abb. 5. Die Übergangsfunktion der Turingmaschine, die die Sprache erkennt {anbn: n≥1}

Bild
Abb. 6. SKA-Grafik einer Turingmaschine, die die Sprache erkennt {anbn: n≥1}

Das MT-Steuergerät in Form von SKA verfügt über 6 Eingangs- und 7 Ausgangskanäle. Das Akzeptorprogramm enthält auch die entsprechende Anzahl von Prädikaten und Aktionen, die in der Abbildung rechts neben dem Automatengraphen dargestellt sind. Die Implementierung des C ++ - Programms in der VKPA-Umgebung ist in Listing 3 dargestellt.

Listing 3. Programm für eine Turingmaschine, die die Sprache erkennt {anbn: n≥1}

 #include "FTuringMashine.h" extern LArc TBL_TAcceptor[]; class FTAcceptor : public FTuringMashine { public: LFsaAppl* Create(CVarFSA *pCVF) { Q_UNUSED(pCVF)return new FTAcceptor(nameFsa, pCVarFsaLibrary); } FTAcceptor(string strNam, CVarFsaLibrary *pCVFL, LArc* pTB = TBL_TAcceptor); protected: int x1(); int x2(); int x3(); int x4(); void y1(); void y2(); void y3(); void y18(); int nState{1}; friend class CDlgTAcceptor; }; #include "stdafx.h" #include "FTAcceptor.h" LArc TBL_TAcceptor[] = { // . .Ma  .   . 2013 ., //     , .304 //=====    ============== // f(1,a) = (2,x,R) f(1,y) = (4,y,R) // f(2,a) = (2,x,R) f(2,y) = (2,y,R) // f(2,b) = (2,x,R) f(3,y) = (3,y,L) // f(3,a) = (3,a,R) f(3,x) = (1,x,R) // f(4,y) = (4,a,R) f(4,#) = (F,#,L) //========================================= LArc("1", "2","x1", "y1y15"), // 1,a,2,x,R LArc("1", "4","x3", "y15"), // 1,y,4,R LArc("2", "2","x1", "y15"), // 2,a,2,R LArc("2", "3","x2", "y2y16"), // 2,b,3,y,L LArc("2", "2","x3", "y15"), // 2,y,2,R LArc("3", "3","x1", "y16"), // 3,a,3,L LArc("3", "3","x3", "y16"), // 3,y,3,L LArc("3", "1","x4", "y15"), // 3,x,1,R LArc("4", "4","x3", "y2y15"), // 4,y,4,a,R LArc("4", "F","x15", "-"), // 4,#,F,-,- LArc("F", "1","x16", "y17"), // LArc("1", "1","x16", "y17"), // LArc("2", "1","x16", "y17"), // LArc("3", "1","x16", "y17"), // LArc("4", "1","x16", "y17"), // // LArc("1", "1","--", "y18"), // LArc() }; FTAcceptor::FTAcceptor(string strNam, CVarFsaLibrary *pCVFL, LArc* pTB): FTuringMashine(strNam, pCVFL, pTB) { strSrc = "aaaaaaaaaabbbbbbbbbb#"; strTape = strSrc; } int FTAcceptor::x1() { return strTape[nIndexHead] == 'a'; } int FTAcceptor::x2() { return strTape[nIndexHead] == 'b'; } int FTAcceptor::x3() { return strTape[nIndexHead] == 'y'; } int FTAcceptor::x4() { return strTape[nIndexHead] == 'x'; } void FTAcceptor::y1() { strTape[nIndexHead] = 'x'; } void FTAcceptor::y2() { strTape[nIndexHead] = 'y'; } void FTAcceptor::y3() { strTape[nIndexHead] = 'a'; } void FTAcceptor::y18() { switch(nState) { case 1: if (x1()) { nState = 2; y1(); y5(); break; } if (x3()) { nState = 4; y5(); break; } break; case 2: if (x1()) { nState = 2; y5(); break; } if (x2()) { nState = 3; y2();y6(); break; } if (x3()) { nState = 2; y5(); break; } break; case 3: if (x1()) { nState = 3; y6(); break; } if (x3()) { nState = 3; y6(); break; } if (x4()) { nState = 1; y5(); break; } break; case 4: if (x3()) { nState = 4; y2(); y5(); break; } if (x5()) { nState = 5; break; } break; case 5: if (x6()) { y7(); nState = 1; break; } break; } } 

In Listing 3 repräsentiert die Aktion y18 eine Variante des MT-Programms gemäß dem SWITCH-Technologie-Ansatz. Im Rahmen der Implementierung der automatischen Programmierung der VKPA-Umgebung wird in diesem Fall anstelle des Automaten in Abb. In 6 muss ein Automat mit einem Zustand implementiert werden, der im Zyklus ein Signal y18 ausgibt. Es entspricht der auskommentierten Zeile der Konvertierungstabelle in Listing 3. Damit der Automat als SWICH arbeitet, müssen Sie den Kommentar aus dieser Zeile entfernen und die verbleibenden Zeilen auskommentieren.

Betrachten Sie ein weiteres Beispiel eines Programms für eine Turing-Maschine aus [7], in dem MT als „sehr einfache Erweiterung eines Modells einer endlichen Maschine“ definiert ist. In diesem Fall ist das Programm für die Turingmaschine eine endliche Liste von Fünfern der teilweise definierten Funktion von Übergängen und Ausgängen δ: S × XS × X × G.

Das MT-Programm, das den größten gemeinsamen Divisor (GCD) zweier Zahlen findet, ist in Abb. 2 dargestellt. 7. Das dazu äquivalente SKA-Diagramm ist in Abb. 8. Beachten Sie, dass der Befehl zum Umschreiben auch hier nicht verwendet wird. Die C ++ - Implementierung ist in Listing 4 dargestellt.

Bild
Abb. 7. Das Übergangsdiagramm einer Turing-Maschine, die den GCD aus zwei Zahlen und mehreren ihrer Konfigurationen berechnet, wenn ein Zahlenpaar <4, 6> verarbeitet wird

Bild
Abb. 8. Das SKA-Diagramm, das dem Diagramm in Abb. 7

Listing 4. Programm für eine Turingmaschine zum Auffinden des GCD aus zwei Zahlen

 #include "FTuringMashine.h" class FTGrCmDiv: public FTuringMashine { public: LFsaAppl* Create(CVarFSA *pCVF) { Q_UNUSED(pCVF)return new FTGrCmDiv(nameFsa, pCVarFsaLibrary); } FTGrCmDiv(string strNam, CVarFsaLibrary *pCVFL); protected: int x1(); int x2(); int x3(); int x4(); void y1(); void y2(); void y3(); void y17(); }; #include "FTGrCmDiv.h" static LArc TBL_TGrCmDiv[] = { //=====     (Greatest Common Divider) ============== // . ..   , - .: , 2003. - 208 . // .194 // .  ..    . .:  , 1974, - 200. // .76, 84-87 LArc("s","s","x1", "y16"), // LArc("s","s","x2", "y16"), // LArc("s","p","x3", "y1"), // LArc("s","r","x15", "y15"), // LArc("p","p","x1", "y15"), // LArc("p","p","x2", "y15"), // LArc("p","s","x3", "y2"), // LArc("p","q","x15", "y16"), // LArc("q","q","x1", "y3y16"), // LArc("q","q","x2", "y14y16"), // LArc("q","s","x3", "y15"), // LArc("q","s","x15", "y15"), // LArc("r","r","x1", "y14y15"), // LArc("r","r","x2", "y3y15"), // LArc("r","s","x3", "y16"), // LArc("r","!","x15", "--"), // LArc("!","s","x16", "y17"), // LArc() }; FTGrCmDiv::FTGrCmDiv(string strNam, CVarFsaLibrary *pCVFL): FTuringMashine(strNam, pCVFL, TBL_TGrCmDiv) { nHeadPosition = 4; strSrc = "#1111111111## "; strTape = strSrc; nIndexHead = nHeadPosition; } int FTGrCmDiv::x1() { return strTape[nIndexHead] == 'a'; } int FTGrCmDiv::x2() { return strTape[nIndexHead] == 'b'; } int FTGrCmDiv::x3() { return strTape[nIndexHead] == '1'; } int FTGrCmDiv::x4() { return strTape[nIndexHead] == '#'; } void FTGrCmDiv::y1() { strTape[nIndexHead] = 'a'; } void FTGrCmDiv::y2() { strTape[nIndexHead] = 'b'; } void FTGrCmDiv::y3() { strTape[nIndexHead] = '1'; } void FTGrCmDiv::y17() { strTape = strSrc; nIndexHead = 4; bRestart = false; nIndexHead = nHeadPosition; } 

Abschließend ein weiteres MT-Programm der Entwickler der SWITH-Technologie, das im Artikel [11] behandelt wird und die Aufgabe darstellt, Klammern in zwei Versionen zu erkennen. Eine ist in der Form einer Miley-Maschine, die zweite ist eine gemischte Maschine (jeweils in Fig. 9 und Fig. 11). Die ihnen entsprechenden Strukturautomaten sind in Abb. 10 und fig. 12. Die Implementierung des C ++ - Programms ist in Listing 5 dargestellt.

Bild
Abb. 9. Erkennung von Klammern beliebiger Tiefe. Meile Conversion Graph

Bild
Abb. 10. Erkennung von Klammern beliebiger Tiefe. Earl SKA Miles

Bild
Abb. 11. Erkennung von Klammern beliebiger Tiefe. Übergangsdiagramm eines gemischten Automaten

Bild
Abb. 12. Erkennung von Klammern beliebiger Tiefe. SCA-Diagramm der Übergänge eines gemischten Automaten

Listing 5. Programm für eine Turingmaschine zur Erkennung von Klammern

 #include "../FTuringMashine.h" class FTListing2 : public FTuringMashine { public: void MooreAction(); LFsaAppl* Create(CVarFSA *pCVF) { Q_UNUSED(pCVF)return new FTListing2(nameFsa, pCVarFsaLibrary); } FTListing2(string strNam, CVarFsaLibrary *pCVFL); protected: int x1(); int x2(); int x3(); int x4(); void y1(); void y2(); void y3(); void y4(); void y5(); int i{0}; }; #include "FTListing2.h" static LArc TBL_TListing2[] = { // .  ..,  ..     , , №2, .144-149 //=====    (. ..   , - .: , 2003. - 208 .) ============== // f(,^` `) = (,`*`,R) // f(,` `) = (,` `,L) // f(,`1`) = (,`0`,L) // f(,` `) = (,`1`,R) // f(,`0`) = (,`1`,R) //========================================= /* //  LArc("0", "1", "x2", "y2"), // '(';  LArc("0", "3", "x3", "--"), // '('; LArc("1", "1", "x2", "y2"), // '(';  LArc("1", "1", "x3", "y3"), // ')';  LArc("1", "3", "^x1x4", "--"), // i!=0;' ';  LArc("1", "3", "x1x3", "--"), // i==0;')';  LArc("1", "2", "x1x4", "--"), // i==0;' ';  LArc("2", "0", "x16", "y17"), // bRestart;  LArc("3", "0", "x16", "y17"), // bRestart;  */ //* //   - LArc("0", "1", "x2", "y2"), // '(' LArc("0", "3", "x3", "--"), // ')' LArc("1", "1", "x2", "y2"), //'(';  LArc("1", "1", "x3", "y3"), // ')';  LArc("1", "2", "x1x4", "--"), // i==0;' '; LArc("1", "3", "^x1x4", "--"), // i!=0;' '; LArc("1", "3", "x1x3", "--"), // i==0;')'; LArc("2", "0", "x16", "y17"), // bRestart;  LArc("3", "0", "x16", "y17"), // bRestart;  //*/ LArc() }; FTListing2::FTListing2(string strNam, CVarFsaLibrary *pCVFL): FTuringMashine(strNam, pCVFL, TBL_TListing2) { strSrc = "(()()) "; strTape = strSrc; } //  int FTListing2::x1() { return i == 0; } int FTListing2::x2() { return strTape[nIndexHead] == '('; } // int FTListing2::x3() { return strTape[nIndexHead] == ')'; } // int FTListing2::x4() { return strTape[nIndexHead] == ' '; } // //  void FTListing2::y1() { i = 0; } // z1_0 void FTListing2::y2() { i++; } // z1_1 void FTListing2::y3() { i--; } // z1_2 void FTListing2::y4() { strTape = ""; } // z2_0 void FTListing2::y5() { strTape = ""; } // z2_1 void FTListing2::MooreAction() { string strState = FGetState(); if (strState=="0") { y1(); } //   else if (strState=="1") { y15(); } //    else if (strState=="2") { y4(); } //  else if (strState=="3") { y5(); } //  } 

Da der Automat in Abb. 12 weigerte sich zu arbeiten, es wurde beschlossen, an die Maschine in Abb. 9. Ein dazu äquivalenter Automat in Form eines SKA ist in Abb. 9 dargestellt. Dies ist zwar formal auch ein gemischter Automat, von dem das Signal im Zustand "0" und das Signal y15 im Zustand "1" von der ersten Implementierung übrig geblieben sind (Fig. 12). Die erste ist bei der Erstinstallation erforderlich, und das y15-Signal führt eine Kopfverschiebung nach rechts durch, um das nächste Bandzeichen zu lesen. Der Rest der SKA entspricht der Miles-Maschine in Abb. 9.

Nach dem Automaten in Abb. 10 wurde erfolgreich getestet und an die Maschine in Abb. 11. Und es wurde klar, dass das Signal z1_1 mit dem Zustand "1" für ihn überflüssig ist (für den Automaten in Fig. 12 ist es das Signal y2). Das Problem ist, dass er, wenn er die „linke Klammer“ findet, den Zähler um zwei Einheiten erhöht und wenn er die „linke Klammer“ findet, ändert er sie überhaupt nicht. Wenn die „linke Klammer“ erkannt wird, wird sie zweimal aufgerufen - einmal in der mit x2 / y2 gekennzeichneten Schleife und das zweite Mal beim Eintritt in den Status. Und wenn eine „rechte Klammer“ erkannt wird, verringert sich der Zähler zuerst in der Schleife und erhöht sich dann beim Eintritt in den Zustand.

Der Grund für diese Arbeit der MT-Steuerung liegt in der falschen Interpretation der Funktionsweise einer Maschine vom Typ Moore durch die Autoren. Anscheinend glauben sie, dass ein Signal mit einem Zustand am Moore-Automaten nur ausgeführt wird, wenn es in diesen Zustand übergeht (siehe Übergang von Zustand „0“ zu „1“), aber tatsächlich wird es jedes Mal ausgegeben, wenn Sie in diesen Zustand eintreten. Einschließlich beim Durchlaufen einer Schleife. Es handelt sich also nicht um einen Fehler (wer hat sich nicht getäuscht?), Sondern um ein gravierenderes Problem - eine Fehlinterpretation im Rahmen der SWITH-Funktionstechnologie von Moore-Automaten. Das Testen des äquivalenten Modells hat dies gezeigt.

3. Fazit

Zusammenfassend kann gesagt werden, dass es keine formalen Unterschiede zwischen Turing und der automatischen Programmierung gibt Turing-Maschine ist ein abstraktes Modell von Automatenprogrammen. Nur im letzteren Fall wird ein größerer Satz von Operatoren und Datenstrukturen (Speicher) verwendet. Jetzt können wir mit Zuversicht die Frage beantworten, inwiefern sich die Post-Maschine als Modell gewöhnlicher Programme von der Turing-Maschine, dem Modell automatischer Programme, unterscheidet. Managementmodell und nur es, weil der Rest - der Speicher und die Operatoren können gleich sein.
Folglich unterscheidet sich die normale Programmierung von der automatischen Programmierung nur in einer Sache - dem Steuerungsmodell. Während also für die Implementierung von Automaten gewöhnliche Steueroperatoren des Schaltertyps verwendet werden und dergleichen nicht verwendet werden können, wird eine solche Programmierung streng genommen als automatisch angesehen. Dies kann eine Nachahmung von Automaten mit dem Verlust ihrer spezifischen Eigenschaften sein und sonst nichts.

Wenn wir also die Konzepte eines Automatenprogramms und einer Automatenprogrammierung definieren, müssen wir nicht von „automatisierten Steuerungsobjekten“ sprechen, sondern von Programmen und nur von Programmen, die eine Steuerung in Form einer klassischen endlichen Zustandsmaschine haben.
Und noch eine interessante Tatsache, auf die ich aufmerksam machen möchte. In den frühen 2000er Jahren äußerten die Autoren ihr Verständnis für automatisches Programmieren für ein breites Publikum. Ihre Artikel über abstrakte Maschinen wurden im PC World Magazin Nr. 2 von 2002 veröffentlicht [11, 12, 13]. Es kann argumentiert werden, dass im Laufe der Jahre die Überzeugungen der Parteien nicht beeinträchtigt wurden. Vielleicht spiegelt dies jedoch nur den Grad ihres Vertrauens in die gewählten Entscheidungen wider.

Zum Beispiel in „einer neuen Vorlesung über automatisches Programmieren“ von A. Shalyto Im Vergleich zur vorherigen „Vorlesung mit Folien“ (vor zehn Jahren) wurde nur ein Video des Beispiels hinzugefügt, das auf dem Stateflow „State-of-the-Art-Paket“ basiert. Es scheint, dass dies die Richtigkeit der Ideen von A. Shalyto bestätigt, weil Was in UniMod nicht implementiert werden konnte (das Projekt scheint "eingefroren" zu sein), verkörperten die Entwickler von Stateflow. Und wahrscheinlich ist es nicht so wichtig, wer es getan hat ...

Zum Zeitpunkt der Veröffentlichung der genannten Artikel war den Autoren der SWITCH-Technologie jedoch bereits Kritik daran bekannt. Dies war seitdem kein Geheimnis es war auf der SoftCraft-Website verfügbar [14]. Außerdem wurden Abschnitte erstellt, die der automatischen Programmierung im Allgemeinen und der SWITH-Technologie und der KA-Technologie im Besonderen gewidmet sind. Die Positionen der Autoren wurden im Forum der Site diskutiert (es war zu dieser Zeit offen). Aber alle blieben nicht überzeugt.

Die Ergebnisse sind im Moment wie folgt. Die Kritik an der SWITH-Technologie ist aktuell und aktuell. Dies gilt auch für das Stateflow-Paket. In der SWITH-Technologie gab es keine und es gibt keine klare Definition der automatischen Programmierung, der Ansatz für die Implementierung von Automaten hat sich nicht geändert, das Modell selbst ist nicht klassisch, es gibt kein Parallel-Computing-Modell usw. usw. Ohne diese Probleme zu beseitigen, beansprucht eine solche automatisierte Programmierung bestenfalls eine ziemlich begrenzte Rolle.

Die Gründe für die oben genannten Probleme liegen auf der Hand: Die Theorie der Programme wird ignoriert, die Theorie der Automaten wird vergessen, obwohl viele gute und korrekte Worte über die Automaten selbst und ihre wunderbaren Eigenschaften gesprochen werden. Tatsächlich handelt es sich jedoch um andere Maschinen. Der Autor ist überzeugt von der Zweifelhaftigkeit schlecht durchdachter Versuche, originelle Modelle zu schaffen. Es geht um synchrone, reaktive und andere Modelle. Sie können beim Lösen einer engen Klasse von Problemen praktisch sein und nicht mehr. Ernsthafter ist jedoch, dass sie aus der Theorie der Automaten herausfallen, ohne eine eigene Theorie zu haben. Das Modell außerhalb der Theorie ist jedoch hilflos und daher praktisch bedeutungslos.

Referenzliste
1. Shalyto A. A. Eine neue Vorlesung über automatische Programmierung. 2019, [Elektronische Ressource], Zugriffsmodus: www.youtube.com/watch?v=PPWTxceMutk&feature=youtu.be , kostenlos. Yaz. Russisch (Datum der Behandlung 5. Dezember 2019).
2. Shalyto A.A. Das Paradigma der automatischen Programmierung. Wissenschaftliches und technisches Bulletin der Staatlichen Universität für Informationstechnologien, Mechanik und Optik St. Petersburg. Vol. 53. Automatisierte Programmierung. 2008, p. 3-23.
3. Shalyto A.A. Das Paradigma der automatischen Programmierung. Tagungsband der XI. Allrussischen Konferenz für Wissenschaft und Hochschulbildung "Grundlagenforschung und Innovation an technischen Universitäten". SPbSPU. 2007, p. 202–205., [Elektronische Ressource], Zugriffsmodus: is.ifmo.ru/works/_2007_09_27_shalyto.pdf , kostenlos. Yaz. Russisch (Datum der Behandlung 5. Dezember 2019).
4. Miroshnik I.V. Theorie der automatischen Steuerung. Lineare Systeme. - St. Petersburg: Peter, 2005 .-- 336 p.
5. Mayorov S.A., Novikov G.I. Die Struktur elektronischer Computer. - L .: Engineering, 1979. - 384 p.
6. Minsky M. Berechnungen und Automaten. M .: Mir, 1971. - 364 p.
7. Karpov Yu.G. Theorie der Automaten. - St. Petersburg: Peter, 2003 .-- 208 p.
8. Polikarpova N., A. Shalyto A. Automatisierung. 2nd ed., St. Petersburg.: Peter, 2011 .-- 176 p.
9. J. MacConell-Analyse von Algorithmen. Aktiver Lernansatz. 3. Auflage. - M .: Technosphere, 2013 .-- 415 p.
10. Algorithmen, Software und Architektur von Multiprozessor-Computersystemen. M .: Nauka, 1982, - 336s.
11. Shalyto A.A., Tukkel N.I. Vom Turing-Programmieren zum automatischen // MirPK. Nr. 2. is.ifmo.ru/?i0=works&i1=turing
12. Lyubchenko V.S. Experimente an abstrakten Maschinen. "PC World", Nr. 2,3 / 02. www.osp.ru/pcworld/2002/02/162923 , www.osp.ru/pcworld/2002/03/163137
13. Lyubchenko V.S. Von einer Turingmaschine zu einem Miley-Auto. "PC World", Nr. 8/02. www.osp.ru/pcworld/2002/08/163856
14. SoftCraft-Website. Verwendung der Automatentheorie in der Programmierung. [Elektronische Ressource], Zugriffsmodus: www.softcraft.ru/auto , kostenlos. Yaz. Russisch (Datum der Behandlung 5. Dezember 2019).

Source: https://habr.com/ru/post/de481998/


All Articles