Machine de Turing, comme modèle de programmes d'automates

Machine de Turing, comme modèle de programmes d'automates


1. Introduction


La programmation nécessite de nouveaux modèles algorithmiques universels et le matériel implémente des algorithmes non seulement sous une forme différente, mais également sur la base d'un autre modèle algorithmique - automatique. L'adoption de la technologie dans le domaine du développement matériel est une idée clé de la programmation automatisée. Cependant, la synthèse des appareils numériques est différente de la programmation. Mais, en empruntant un modèle, d'une part, il n'est pas conseillé de le modifier substantiellement, mais, d'autre part, on ne peut ignorer la théorie et la pratique existantes de la programmation.

Ensuite, nous considérerons la technologie SWITCH pour concevoir des programmes automatisés, dans lesquels vous rencontrez de tels processus tout le temps. D'une part, il a tellement changé le modèle de machine à états qu'il l'a en fait dépassé le cadre de la théorie des automates. Et, d'autre part, il introduit dans la programmation des concepts qui sont difficiles à percevoir par les programmeurs et, parfois, sont simplement superflus, car il existe des homologues plus familiers de la théorie des programmes et de la pratique de la programmation.

Comme base de discussion des problèmes de programmation automatique, nous prenons la récente conférence de A. Shalyto [1] et ses articles «programmatiques» sur la définition du paradigme de la programmation automatique [2, 3].

1. Objets automatisés, schémas de programme

Dans la conférence, la réalisation de la programmation automatique est l'introduction du concept d'objets de contrôle automatisé, emprunté à la théorie du contrôle automatique (TAU). Mais, rappelons que dans TAU ils ne considèrent pas tant les objets, mais les systèmes, parmi lesquels se distinguent les suivants [4]:

image

Sur cette base, il serait plus correct de parler de systèmes de contrôle automatique (ACS). Examinons maintenant le schéma fonctionnel typique des canons automoteurs illustrés à la Fig. 1. Si le ruban de la machine de Turing est considéré comme l'objet de contrôle, alors les dispositifs d'actionnement (IS) seront des éléments MT qui implémenteront la modification du contenu du ruban et le déplacement de la tête, et les dispositifs de mesure (IS) seront les éléments qui liront les informations du ruban.

image
Fig.1. Schéma fonctionnel des canons automoteurs

Mais pourquoi se tourner vers TAU, s'il existe une pratique plus proche de la programmation de la conception de systèmes informatiques, dans laquelle les dispositifs d'exploitation (OS), qui, bien sûr, incluent MT, sont considérés comme une combinaison de machines d'exploitation (OA) et de contrôle (UA). Et cela est plus proche de ce que nous visons en fin de compte - justifier la puissance de la programmation automatique. Dans la fig. 2 montre un écran de texte d'une monographie de Mayorov S.A., Novikov G.I. La structure des ordinateurs électroniques [5], dans laquelle les problèmes de conception des amplificateurs opérationnels sont examinés en détail.

image
Fig.2. Le concept de gestionnaire et d'exploitation des machines

Mais, si nous comparons la théorie de la conception informatique et la théorie des programmes, une analogie structurelle évidente peut être tracée entre eux. En théorie de la programmation, le modèle de tout programme au niveau structurel peut être représenté comme un schéma de programme S = (M, A, C), où M est l'ensemble des éléments de mémoire, A est l'ensemble des opérateurs, C est le contrôle [10]. Suivant cette approche, tout programme de machine de Turing peut également être défini comme un schéma de programme dans lequel l'ensemble M est représenté par des cellules de bande, l'ensemble d'opérateurs par des actions MT associées à 1) l'analyse des cellules, 2) le changement de caractères dans les cellules de bande et 3) le déplacement de la tête.

Ainsi, le concept de schéma de programme est complètement analogue au concept considéré d'automates opérationnels et de contrôle, où le modèle d'UA est le modèle de la machine à états finis structurels (SKA) examinée ci-dessous, et OA est une structure pour effectuer des actions sur les informations. Dans ce cas, OA comprend des éléments de stockage de données (ci-dessus est la mémoire) et des blocs pour le traitement des informations qui implémentent le calcul des conditions logiques et la mise en œuvre de certaines actions (ci-dessus - beaucoup d'opérateurs).

D'après ce qui précède, on peut comprendre que la bande ne peut être considérée que conditionnellement comme l'objet de contrôle pour MT. Ne serait-ce que parce que le dispositif de commande de la machine de Turing n'y a pas d'accès direct, car toutes les opérations avec des cellules sont réalisées indirectement par des blocs OA. De plus, il semble qu'il ne soit pas très familier ou, pour ne pas dire, il est étrange de considérer comme le but de la gestion de programme, comme système de contrôle, un objet représentant une mémoire (bande).
Ainsi, pour une définition formelle d'une machine de Turing, et dans son contexte une place pour un modèle de machine à états finis, les concepts de la théorie des programmes sont suffisants. Maintenant, contrairement à la définition très vague des programmes d'automates donnée dans le cadre de la technologie SWITCH, nous pouvons dire qu'un programme d'automates est un programme qui a le contrôle sous la forme d'un modèle de machine à états finis.

Quel sera le programme lui-même - avec un comportement simple ou complexe, quelle est sa «variété» - avec un contrôle logique, «avec une allocation d'état explicite», etc. etc. n'a pas vraiment d'importance. L'essentiel est le type de gestion. Les éléments restants du programme peuvent être déterminés dans une large gamme - du plus simple, comme, par exemple, avec une machine de Turing, au plus complexe - toute forme d'opérateurs, de fonctions et de structures de données des langages de programmation - assembleur, langage de haut niveau, etc.

On peut également rappeler qu'une machine de Turing a longtemps été considérée comme un tapis automatique [6] ou, dans les cas extrêmes, sa simple extension [7]. Mais vous devez comprendre de quel type d'automate il s'agit, de quel type d'extension il s'agit et si elles sont équivalentes aux modèles de machines à états finis classiques. Essayons de clarifier cela.

2. Programmation de Turing dans un environnement de programmation automatisé

Dans la fig. La figure 3 montre l'automate pour la fonction d'incrémentation MT de la monographie [8]. Dans la forme, ce n'est clairement pas un programme MT, mais déjà pas une machine à états finis classique. Dans la fig. La figure 4 montre le graphique de la machine à états finis structurels classique (SKA) et son implémentation dans l'environnement VKPa (l'environnement de programmation automatisée des composants visuels en C ++ dans le cadre de la bibliothèque Qt et de l'environnement Qt Creator), qui implémente le même algorithme d'unité de contrôle MT.

image
Fig.3. Augmentez le nombre par unité en utilisant une machine de Turing

image
Fig.4 Modèle de programme d'incrémentation pour MT sous forme de SKA

Vous pouvez voir que la machine structurelle a quatre canaux d'entrée et cinq canaux de sortie. Chacun de ces canaux est associé à une fonction de programme du même nom - un prédicat ou une action. Ici, les prédicats sont des fonctions sans paramètres qui renvoient une valeur booléenne en fonction de la valeur de la cellule de bande qu'ils consultent, et les actions sont des fonctions sans paramètres qui effectuent l'une ou l'autre action pour changer la cellule de bande et déplacer la tête de la machine de Turing.

Ce SKA a le même ensemble d'états que l'automate de la figure 3. De plus, en plus du mappage d'automate lui-même, présenté par SKA, il implémente deux autres mappages: mappage de l'ensemble des prédicats (x1, ..., xM) sur l'ensemble des canaux d'entrée de la même machine, et l'ensemble des canaux de sortie de la machine sur l'ensemble des mêmes actions - y1, ..., yN. Par exemple, le prédicat x3 retournera vrai (valeur 1 pour le signal d'entrée du même nom), s'il y a un 1 dans la cellule courante, et l'action y4, qui sera déclenchée lorsque le même signal de sortie de la machine prendra la valeur 1, correspondra à déplacer la tête vers la gauche (L) et etc. etc.

Notez que le SKA ne contrôle pas directement la bande, mais implémente des mappages [supplémentaires], reliant les signaux de l'automate aux fonctions qui déterminent les nombreuses opérations de la machine de Turing. Cela nous convainc encore une fois qu'il n'est pas nécessaire d'introduire le concept d'un objet de contrôle automatisé dans une situation où le concept de cartographie «à l'ancienne», mais mathématiquement rigoureux est suffisant.

Comparaison des automates de la Fig. 3 et fig. 4, on peut voir que SKA n'utilise pas la commande «*» (voir Fig. 1). Dans une situation similaire, il lui suffit de ne pas émettre de signal lié à cette commande. De plus, deux signaux ou plus (entrée et sortie) à la même transition sont parallèles. Par conséquent, en cas de conflit d'accès aux objets partagés (par exemple, vous devez changer la cellule et déplacer la tête), un accord est utilisé: les actions sur une transition sont exécutées séquentiellement dans l'ordre de leur nombre, c'est-à-dire une action avec un nombre supérieur est exécutée après une action avec un nombre inférieur. Cet accord ne s'applique pas aux prédicats, car ils ne changent pas la bande. Nous rendons donc la machine plus compacte et intuitive (pas besoin d'introduire des états intermédiaires).

Au cours du test du programme d'incrémentation, des situations ont été identifiées où des problèmes peuvent survenir pendant le fonctionnement du MT. Premièrement, la vraie bande n'est pas infinie et aller au-delà peut entraîner le plantage d'un programme. Deuxièmement, il est nécessaire d'indiquer la position initiale de la tête. Sans cela, si, par exemple, le nombre est à un endroit arbitraire de la bande et que l'état initial de la tête est à gauche du nombre et en face de l'espace, alors la tête commencera immédiatement à se déplacer vers la gauche. Ensuite, il peut aller au-delà des limites de la bande, provoquant le "plantage" du programme, ou, après avoir fait un pas vers la gauche, il écrit dans la cellule 1 et, suspendu, termine l'opération "réussie". Ou, si le numéro contient 1 dans tous les chiffres et est écrit depuis le début de la bande, la dernière tentative de transfert de 1 vers le chiffre principal entraînera le même «crash».

2.1. Implémentation d'objet de MT en C ++

Considérez l'implémentation du logiciel objet d'une machine Turing en C ++ dans l'environnement VKPa, qui implémente n'importe quel programme pour MT, y compris le programme de calcul d'incrément.

À cet effet, une classe de base a été créée qui représente n'importe quelle machine Turing, héritée par des objets logiciels qui implémentent l'un ou l'autre programme MT. Celui-ci est illustré dans le listing 1, et le programme qui implémente la tâche d'incrémentation est indiqué dans le listing 2.

Listing 1. Implémentation logicielle de la classe de base MT

#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. Programme d'incrémentation pour une machine de Turing

 #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. Exemples de programmes pour MT avec implémentation en C ++

Prenons un exemple de programme pour MT qui "agit comme un accepteur de langage, c'est-à-dire il peut reconnaître la langue »de [9]. Sa fonction de transition est représentée sur la Fig. 5, et l'automate équivalent sous forme de SKA sur la 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) 

Fig. 5. La fonction de transition de la machine de Turing, reconnaissant le langage {anbn: n≥1}

image
Fig. 6. Graphique SKA d'une machine de Turing qui reconnaît le langage {anbn: n≥1}

L'unité de contrôle MT sous forme de SKA a 6 canaux d'entrée et 7 canaux de sortie. Le programme accepteur comprend également le nombre correspondant de prédicats et d'actions, qui sont présentés dans la figure à droite du graphique de l'automate. L'implémentation du programme C ++ dans l'environnement VKPA est illustrée dans le Listing 3.

Listing 3. Programme pour une machine Turing qui reconnaît la langue {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; } } 

Dans le Listing 3, l'action y18 représente une variante du programme MT conformément à l'approche technologique SWITCH. Dans le cadre de la mise en œuvre de la programmation automatique de l'environnement VKPA, dans ce cas, au lieu de l'automate de la Fig. 6, il sera nécessaire de mettre en œuvre un automate à un état, qui émet un signal y18 dans le cycle. Il correspond à la ligne commentée de la table de conversion du listing 3. Pour que la machine automatique fonctionne comme SWICH, vous devez supprimer le commentaire de cette ligne et commenter les lignes restantes.

Prenons un autre exemple de programme pour une machine de Turing de [7], où MT est défini comme «une extension très simple d'un modèle de machine à états finis». Dans ce cas, le programme de la machine de Turing est une liste finie de cinq fonctions partiellement définies des transitions et des sorties δ: S × XS × X × G.

Le programme MT, qui trouve le plus grand diviseur commun (GCD) de deux nombres, est illustré à la Fig. 7. Le graphique SKA équivalent à celui-ci est présenté à la Fig. 8. Notez que la commande de réécriture n'est pas utilisée ici non plus. L'implémentation C ++ est présentée dans le Listing 4.

image
Fig. 7. Le graphique de transition d'une machine de Turing qui calcule le GCD de deux nombres et plusieurs de ses configurations lors du traitement d'une paire de nombres <4, 6>

image
Fig. 8. Le graphique SKA, équivalent au graphique de la Fig. 7

Listing 4. Programme pour une machine de Turing pour trouver le GCD de deux nombres

 #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; } 

En conclusion, un autre programme MT des développeurs de la technologie SWITH, considéré dans l'article [11], qui présente la tâche de reconnaître les crochets en deux versions. L'un est sous la forme d'une machine Miley, le second est une machine mixte (respectivement sur la figure 9 et la figure 11). Les automates structurels qui leur correspondent sont représentés sur la Fig. 10 et fig. 12. L'implémentation du programme C ++ est présentée dans le Listing 5.

image
Fig. 9. Reconnaissance de crochets d'une profondeur arbitraire. Graphique de conversion de miles

image
Fig. 10. Reconnaissance de crochets d'une profondeur arbitraire. Earl SKA Miles

image
Fig. 11. Reconnaissance de crochets d'une profondeur arbitraire. Graphique de transition d'un automate mixte

image
Fig. 12. Reconnaissance de crochets d'une profondeur arbitraire. Graphique SCA des transitions d'un automate mixte

Listing 5. Programme pour une machine de Turing pour reconnaître les parenthèses

 #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(); } //  } 

Depuis l'automate de la Fig. 12 a refusé de travailler, il a été décidé d'aller à la machine de la Fig. 9. Une machine automatique équivalente à celle-ci sous la forme d'un SKA est illustrée à la Fig. 10. Certes, formellement, il s'agit également d'un automate mixte, à partir duquel le signal à l'état "0" et le signal y15 à l'état "1" ont été laissés par la première implémentation (Fig. 12). Le premier est nécessaire lors de l'installation initiale, et le signal y15 implémente un décalage de tête vers la droite afin de lire le caractère de bande suivant. Le reste du SKA correspond à la machine Miles de la Fig. 9.

Après l'automate de la fig. 10 a été testé avec succès, retourné à la machine de la Fig. 11. Et il est devenu clair que le signal z1_1 avec l'état "1" lui est superflu (pour l'automate de la figure 12 c'est le signal y2). Le problème est que lorsqu'il trouve le "crochet gauche", il incrémente le compteur de deux unités, et quand il trouve le "crochet gauche" il ne le change pas du tout. Ainsi, lorsque le «crochet gauche» est détecté, il est appelé deux fois - une fois sur la boucle marquée x2 / y2, et la deuxième fois en entrant dans l'état. Et quand un «crochet droit» est détecté, le compteur diminue d'abord sur la boucle, puis augmente en entrant dans l'état.

La raison de ce travail du contrôle MT est dans l'interprétation incorrecte par les auteurs du fonctionnement d'un automate de type Moore. Apparemment, ils croient qu'un signal avec un état sur l'automate Moore n'est exécuté que lorsqu'il entre dans cet état (voir la transition de l'état «0» à «1»), mais en fait, il est émis chaque fois que vous entrez dans cet état. Y compris lors du passage en boucle. Il ne s'agit donc pas d'une erreur (qui ne s'est pas trompé?), Mais d'un problème plus grave - une interprétation incorrecte dans le cadre de la technologie SWITH de fonctionnement des automates de type Moore. Le test du modèle équivalent l'a montré.

3. Conclusion

Pour résumer, nous pouvons dire qu'il n'y a pas de différences formelles entre Turing et la programmation automatique, comme La machine de Turing est un modèle abstrait de programmes d'automates. Dans ce dernier cas, un ensemble plus large d'opérateurs et de structures de données (mémoire) sont utilisés. Nous pouvons maintenant répondre en toute confiance à la question de savoir comment la machine Post, en tant que modèle de programmes ordinaires, diffère de la machine Turing, le modèle des programmes automatiques. Modèle de gestion et seulement cela, car le reste - la mémoire et les opérateurs peuvent être les mêmes.
Par conséquent, la programmation ordinaire ne diffère de la programmation automatique que par une chose: le modèle de contrôle. Ainsi, alors que pour la mise en œuvre d'automates, des opérateurs de commande ordinaires du type commutateur sont utilisés et similaires ne peuvent pas être utilisés, à proprement parler, une telle programmation est considérée comme automatique. Cela peut être une imitation d'automates avec la perte de leurs propriétés spécifiques et rien de plus.

Ainsi, en donnant une définition des concepts de programme d'automate et de programmation d'automate, il ne faut pas parler d '«objets de contrôle automatisés», mais de programmes et uniquement de programmes qui ont le contrôle sous la forme d'une machine à états finis classique.
Et un autre fait intéressant sur lequel je voudrais attirer l'attention. Au début des années 2000, les auteurs ont exprimé leur compréhension de la programmation automatique pour un large public. Leurs articles sur les machines abstraites ont été publiés dans le magazine PC World n ° 2 de 2002 [11, 12, 13]. On peut affirmer qu'au fil des ans, les condamnations des parties n'ont pas été affectées. Bien que cela ne reflète peut-être que le degré de leur confiance dans les décisions choisies.

Par exemple, dans «une nouvelle conférence sur la programmation automatique» A. Shalyto Par rapport à la précédente «conférence avec diapositives» (il y a dix ans), seule une vidéo de l'exemple basé sur le «package de pointe» Stateflow a été ajoutée. Il semblerait que cela confirme l'exactitude des idées d'A. Shalyto, car ce qui n'a pas pu être implémenté au sein d'UniMod (le projet semble «gelé»), incarnent les développeurs de Stateflow. Et, probablement, ce n'est pas si important qui l'a fait ...

Cependant, au moment de la publication des articles mentionnés, les auteurs de la technologie SWITCH en connaissaient déjà les critiques. Ce n'était pas un secret puisque il était disponible sur le site Web de SoftCraft [14]. Il a également créé des sections consacrées à la programmation automatique en général et à la technologie SWITH et à la technologie KA en particulier. Les positions des auteurs ont été discutées sur le forum du site (il était ouvert à l'époque). Mais tous ne sont pas convaincus.

Les résultats pour le moment sont les suivants. La critique exprimée à propos de la technologie SWITH était une fois pertinente et actuelle. Il s'applique également au package Stateflow. Dans la technologie SWITH, il n'y en avait pas, et il n'y a pas de définition claire de la programmation automatique, l'approche de la mise en œuvre des automates n'a pas changé, le modèle lui-même n'est pas classique, il n'y a pas de modèle de calcul parallèle, etc. etc. Sans éliminer ces problèmes, une telle programmation automatisée revendique au mieux un rôle assez limité.

Les raisons des problèmes mentionnés ci-dessus sont assez claires: la théorie des programmes est ignorée, la théorie des automates est oubliée, bien que beaucoup de bons et corrects mots soient dits sur les automates eux-mêmes et leurs merveilleuses propriétés. Mais en fait, ce sont d'autres machines. L'auteur est convaincu de la doutes des tentatives mal conçues de créer des modèles originaux. Il s'agit de modèles synchrones, réactifs et autres. Ils peuvent être pratiques pour résoudre une classe étroite de problèmes et rien de plus. Mais ce qui est plus grave, c'est qu'ils sortent de la théorie des automates sans avoir leur propre théorie. Mais le modèle en dehors de la théorie est impuissant, et donc pratiquement dénué de sens.

Les références
1. Shalyto A. A. Une nouvelle conférence sur la programmation automatique. 2019, [Ressource électronique], Mode d'accès: www.youtube.com/watch?v=PPWTxceMutk&feature=youtu.be , gratuit. Yaz. Russe (date du traitement 5 décembre 2019).
2. Shalyto A.A. Le paradigme de la programmation automatique. Bulletin scientifique et technique de l'Université d'État des technologies de l'information, de la mécanique et de l'optique de Saint-Pétersbourg. Vol. 53. Programmation automatisée. 2008, p. 3-23.
3. Shalyto A.A. Le paradigme de la programmation automatique. Actes de la XIe Conférence panrusse sur la science et l'enseignement supérieur "Recherche fondamentale et innovation dans les universités techniques". SPbSPU. 2007, p. 202–205., [Ressource électronique], Mode d'accès: is.ifmo.ru/works/_2007_09_27_shalyto.pdf , gratuit. Yaz. Russe (date du traitement 5 décembre 2019).
4. Miroshnik I.V. Théorie du contrôle automatique. Systèmes linéaires. - Saint-Pétersbourg: Peter, 2005 .-- 336 p.
5. Mayorov S.A., Novikov G.I. La structure des ordinateurs électroniques. - L.: Ingénierie, 1979. - 384 p.
6. Minsky M. Calculs et automates. M .: Mir, 1971. - 364 p.
7. Karpov Yu.G. Théorie des automates. - Saint-Pétersbourg: Peter, 2003 .-- 208 p.
8. Polikarpova N., A. Shalyto A. Programmation des automates. 2e éd., Saint-Pétersbourg.: Peter, 2011 .-- 176 p.
9. J. MacConell Analyse des algorithmes. Approche d'apprentissage actif. 3e édition. - M.: Technosphère, 2013 .-- 415 p.
10. Algorithmes, logiciels et architecture des systèmes informatiques multiprocesseurs. M.: Nauka, 1982, - 336s.
11. Shalyto A.A., Tukkel N.I. De la programmation Turing à // MirPK automatique. N ° 2. is.ifmo.ru/?i0=works&i1=turing
12. Lyubchenko V.S. Expériences sur des machines abstraites. "PC World", n ° 2,3 / 02. www.osp.ru/pcworld/2002/02/162923 , www.osp.ru/pcworld/2002/03/163137
13. Lyubchenko V.S. D'une machine Turing à une voiture Miley. «PC World», n ° 8/02. www.osp.ru/pcworld/2002/08/163856
14. Site Web de SoftCraft. Utilisation de la théorie des automates dans la programmation. [Ressource électronique], Mode d'accès: www.softcraft.ru/auto , gratuit. Yaz. Russe (date du traitement 5 décembre 2019).

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


All Articles