MetaTrader 5 / トレーディング
English Русский 中文 Español Deutsch Português 한국어 Français Italiano Türkçe
自動売買システム作成にたいする新手法としてのオートマタ準拠プログラミング

自動売買システム作成にたいする新手法としてのオートマタ準拠プログラミング

MetaTrader 5 — トレーディング | 18 11月 2015, 12:32
1 134 0
MT5
削除済み

ἓν οἶδα ὅτι οὐδὲν οἶδα ( ο φιλόσοφος Σωκράτης )

無知の知（哲学者ソクラテス）


はじめに

まずはじめに、このテーマは MetaQuotes Language 4/5 (MQL4/5)を使用してEAを開発しているトレーダーにとってはまったく新しいものです。私自身MetaQuotes のウェブサイトで適切な検索をしようとしたときにそのことがわかりました。この話題に関するものは何もないのです。

すべてのトレーダーは、プログラミングおよびひじょうに複雑なプログラムロジックに関わる数々の問題に真剣に取り組むべき自身の Expert Advisor を作成しています。一日の終わりには、いかなる標準的な状況でもまた不可抗力の事態でもプログラムは時計のように『自分自身で』実行することになっているはずです。

しかし一人ですべてをかかえこめるものでしょうか？なぜ自動制御システムは、適切なオートマタ準拠プログラミングの技術を利用するだけで一番達成することのできるすべての制御システムを適切にプログラミングすることを要求するのか理由を特定するのはひじょうに難しいことです。近年、組み込み技術のプログラミング開発とソフトウェアの質に高い要件を設定するリアルタイムシステムについて大きな注目が寄せられています。

1991年、ロシアの作家 A.A.Shalyto （小説家、DSc の工学教授、SPbSU ITMOの"Programming Technologies"部長）は名づけて『オートマタ準拠プログラミング』というプログラミング技術を開発しました。 読者のみなさんがオートマタ準拠プログラミングまたはスイッチぎじゅtsがいかにシンプルかを知ってご興味を感じられることと思います。それにより MetaQuotes言語を使用し MTSを開発することをたいへん便利にするのでもうそれ以上にはなりえないでしょう。またそれは偉大さを複合的な意思決定システムに溶け込ませます。


1. 問題への対処

すべての問題発信者とソフトウェア開発者が長く大切にしている夢は問題（アルゴリズム）に対して計画された解決法を持ち、完全にそれと一致するアルゴリズムを実装することです。しかし、発信者と開発者にとって事はそのようにはいかないものです。アルゴリズムは、開発者が実装するとき何が重要なのか見逃す傾向にあります。一方で本来プログラムテキストはアルゴリズムとはほとんど共通点はありません。

アルゴリズムは2つあります。ひとつは通常既定の結果を取得する代わりに特定デザインの結果を表す書類（設計ソリューションを登録し記録するための）にあります。一方二番目のアルゴリズムは開発者の頭の中にあります（ただしこれもまた原文通りに保存されています）。

プログラムテキストの最終版の後には多くの事柄が再び考慮されないドキュメンテーションを改良する試みが続きます。この場合、プログラムロジックはアルゴリズムロジックとは異なっているようです。応答の欠如を表示しています。私は故意に「らしい」と言います。それはだれも別のだれかのプログラムテキストをチェックしようとしないからです。

プログラムが大きければ、テキストだけによってそのプログラムがアルゴリズムに対応しているか確認するのは不可能です。実装精度は「検証」と呼ばれる手順によってチェックすることができます。それは基本的に開発者がアルゴリズム（書類にある）をどのように把握し、頭の中で別のアルゴリズムに変換sし、プログラムとしてアウトプットするかをチェックします。最終的に開発者はロジックについて価値ある情報を持つ唯一の人で、その情報はすべて実装が絶対的に意味のないものになる前に新しく作り直されます。

それは開発者が病気になる（または引退する）ということですらありません。重要なことは基本的なプログラムロジックは開発者によって異なるだろうということです。開発者のプログラム言語についての知性と知識によるのです。いずれにしても開発者が適切であると思ったら数多くの中間変数を 導入し使用します。そしてプログラムが大きくロジックが複雑であれば、より質の高い専門家が問題（ここで言うのは OS 問題や誤った言語関数を使用することではなく、ロジックに関して不適切な実装を意味します。）を見つけ、プログラムテキスト自体を通して動作するか見るるために必要とされます。

開発者の大多数は, 控えめに言ってもプログラミング（または紙の上にスケッチすることさえ）前にアルゴリズムを書くことにあまり熱心ではありません。それは途中で自身でまだなにかを考え出す必要があるからのようです。実際、すぐにプログラミングに進んだ方がよいときに長方形やひし形や矢印を描いて時間を無駄にし、いくらか似ている、またはひじょうに一般的なアルゴリズムをドキュメンテーションにレイアウトするのはなぜでしょうか。

みながそれに慣れているからです。開発者はそうすることが簡単な方法だからそれをするのです。一方で問題提唱者 は要求されるレベルのプログラムスキルがかならずしもあるとは限らず、スキルがあったとしてもただ開発者が考え出したことに対して時に応じた変更をすることができません。都合のよいプログラム環境もまた、指定された開発注文の期限を守ることにつながります。高度なデバッグツールと変数のモニター値がロジックのあらゆるエラーの検出を可能にするかもしれないと思わせてくれます。

時間ばかり流れていき、プロジェクトの期限が迫ってきていル中で開発者は座って「ナプキン」に既定のロジック問題に対する解決法をスケッチしています。それはところでまだ実装する必要があるもので、いうまでもなく検証中テストフローに対して見逃されたエラーも似たような（混沌とした）なりゆきになります。。。これが現状です。解決法はあるのでしょうか？少なくとも改善されるのでしょうか？標準的な方法でレイアウトされたアルゴリズムからプログラムコードに変遷する際何か需要なことが見落とされているような気がします。


2. プログラムの理論部分

"automata-based programming" の著者はプログラムの理想的な理論部分に次のコンセプトを提案しています。プログラムロジックは全体にスイッチに基づく。簡単に言えばあらゆる制御アルゴリズム（オートマトン）は下に示すように実装されることができます。（この時点ではコメントの意味は深く詮索せずストラクチャだけ見ます。）

switch(int STATUS ) // Мulti-valued global state variable of the automaton.
{
  case 0:  // start

  // Checking arc and loop conditions (in order of priority),
  // transition (change of the value of the variable STATUS)
  // and execution of arc and loop actions (output function execution);
  // logging transitions and actions if the condition is met. 0

  // Calling nested automata.
  // Execution of output functions in the state.
  break ;
  
  case 1:
  // Checking arc and loop conditions (in order of priority),
  // transition (change of the value of the variable STATUS)
  // and execution of arc and loop actions (output function execution);
  // logging transitions and actions if the condition is met. 

  // Calling nested automata.
  // Execution of output functions in the state.
  break ;
  
*********
*********
*********

 case N-1:
  // Checking arc and loop conditions (in order of priority),
  // transition (change of the value of the variable STATUS)
  // and execution of arc and loop actions (output function execution);
  // logging transitions and actions if the condition is met. 

  // Calling nested automata.
  // Execution of output functions in the state.
  break ;

 case N:
  // Checking arc and loop conditions (in order of priority),
  // transition (change of the value of the variable STATUS)
  // and execution of arc and loop actions (output function execution);
  // logging transitions and actions if the condition is met.

  // Calling nested automata.
  // Execution of output functions in the state.
  break ;
}


3. 作家 A.A.Shalytoによって説明されるオートマタ準拠プログラミング

開発テクニックがなんであれ、どんなプログラムもあらゆる特定の時間におけるデータ値によって決められる状況があります。大きなアプリケーションプログラムには何百何千と変数があり、複数の制御フローがあります。これら変数セットは特定時間におけるアプリケーションプログラムの状態を述べます。

プログラム状態はすべての制御変数、すべての変換条件に入る値の収集としてシンプルな方法で処理されます。制御変数の一つの値変更はプログラム状態の変更を意味します。またプログラム状態の数値は、プログラム処理中に発生する可能な制御変数値の最大数の組合せによって決められます。プログラムでバイナリ制御変数（フラグ）だけ使われているとします。バイナリ制御変数 n を持つプログラム状態の数値はこの場合、n ～ 2nの範囲内にあります。

開発者がすべての制御変数値に対する反応を与えているかもしれません。（われわれの場合は2n 個の組合せです。）ただし、制御変数値（2n-nまでの）は指定されていないとわかるものもありそうです。予想外のインプットの組合せが発生すると、プログラムは未確定状態に変遷する可能性があります。

それはトレーダーにとって以下のイベントでEA の無為 と同じ効果があります。

  • ギャップ
  • デポジットの損失
  • マージンコールに続く負の残高状態に陥る
  • ゼロからのちに赤字になるかなりの収益を得る
  • ロングおよびショートの誤った開始と終了
  • その他明らかに困難な状況

そのような状態は『非表示』と呼ばれます。複雑さが列挙の難しさの原因となります。ましては非表示に導く可能なプログラム状態すストラクチャの複雑さは安全トラップドアを構築する非表示状態の源です。不特定状態のプログラムの振る舞い範囲はメモリ保護誤りから新しい関数へのプログラム拡張および様々な性質の副作用を起こすことに及びます。

多くの PC ユーザーとおそらくすべてのソフトウェア開発者は使用中または開発中のプログラムが未指定状態に陥る状況に遭遇したことがあるものです。

プログラムで不特定状態の可能性を排除するには、すべての要求される状況が設計段階のなるべく早い時期に明確に指定される必要があり、変数間の識別のためにマルチバリュー制御変数は一つだけ使用します。それからすべての状態の間の可能な遷移を特定し「行方不明」にならないプログラムを作成することが必要です。

プログラムの振る舞いを開発する中での厳格さを達成するにはコンポーネントが3つ要求されます。

  • プログラム状態とプログラム間の可能な遷移を一義的に特定できるようにする数学モデル。
  • そのモデルのグラフィカルな表記法
  • この表記に著されるアルゴリズム実装のユニバーサルメソッド

数学的モデルとして使用するのに「状態」の表記に基づく有限のオートマトンが提案されます。オートマタ準拠プログラミングはそのようなソフトウェア開発の設計、実装、デバッグ、ドキュメンテーションの段階をサポートします。

「イベント」という語は近年プログラミングに一般的に使われるようになってきており、 提案される方法は「状態」の表記に基づきます。インプット変数かイベントのどちらかになる「入力処理」の語でコンパイルしたら、「アウトプットなしのオートマトン」 が使われます。後者には「アウトプット処理」が続き、そのあとにオートマトンの記述（決定性有限）がきます。よってこのコンセプトに基づくプログラミング領域はオートマタ準拠プログラミングと呼ばれ、個別の開発プロセスがオートマタ準拠プログラム設計と呼ばれます。

指定の方法は適用されるときそこに特有のオートマタは遷移グラフで表されます。ノード間で識別するためには「ステートアサインメント」が使われます。「多値ステートアサインメント」を選択するときは、選択された変数が取得可能な値数に一致する数を持つ状態は変数を一つだけ使用して差別化されます。このことで「プログラムの観測性」を取り入れることができるようになります。

提案された方法のプログラミングはよりよい理解と問題とそのコンポーネントを指定するのに役立つ「変数」（フラグ）ではなく「状態」によって実行されます。この場合のデバッグはオートマタの項にログすることで行われます。

上記方法は遷移グラフから規則に従った同型のメソッドを使用するプログラムコードまで移動することを提案するので、そのメソッドは、ハイレベルなプログラミング言語が使用されるときスイッチストラクチャを適用するのがより合理的なようです。それがオートマタ準拠プログラミングパラダイムを参照するとき「SWITCH テクノロジー」を使うことに決めた理由です。


4. 明確な記述に基づくプログラミング

オートマタ準拠方法のアプリケーションはさらに「リアクティブ」とも呼ばれるイベント駆動型システムに拡張されました。リアクティブシステムは環境（EA は同じクラスにインクルードすることが可能です。）によって設定される比率でメッセージを使用する環境に連動します。

オートマタを使用するイベント駆動型システムの開発により段階的手法を採用することが可能となりました。そこから明示的プログラミングという名前がつけられました。アウトプット処理はこのメソッドでは遷移グラフの弧、ループ、ノードに割り当てられています。（混成オートマタ、 - ムーアモデルとミーリーモデルのオートマタが使用されています。）これにより適切なインプット処理に対するリアクションとしての処理シーケンスを端的に表すことができます。

システムの既定クラスをプログラムするのに提案されている方法は、イベントハンドラから除外されていることによるロジックの中央化増加、およびハンドラから呼ばれる相互関連のオートマタシステム作成の特徴があります。 そのようなシステムのオートマタ間連携は状態数のネスト、呼び出し、交換によって行うことができます。

相互関連オートマタシステムはシステム独立プログラム部を形成し、一方でシステム依存パートはインプット処理およびアウトプット処理関数、ハンドラなどで形成されます。

既定の方法の別の主要機能はオートマタが適用されるとき三位一体の方法で使用されることです。

  • 仕様のため
  • 実装のため（プログラムコードとして残ります。）
  • オートマタタームへのログのため（上で指定されているとおり）

後者によってオートマタシステム処理の精度を制御することができます。ログは開発されるプログラムに基づき自動で処理されます。また複合的プログラムロジックを伴う大型問題に対しても使用可能です。この場合ログはそれぞれ適切なスクリプトとみなされます。

ログにより処理中のプログラムをモニターしたり、オートマタが「絵」ではないが実際にアクティブな実体であることを説明することができます。オートマタ準拠方法は制御システムを作成するときだけでなく、制御オブジェクトをモデル化するときにも使うことを提案します。


5. オートマタ準拠プログラミングの基本コンセプト

オートマタ準拠プログラミングの基本コンセプトは STATEです。あらゆる特定時刻 0におけるシステム状態の主要なプロパティは現状にはあらゆる既定時刻 t0において生成されるインプット処理に対するリアクションを決定するのに必要なシステムの過去に関するあらゆる情報が含まれるという意味ですべての将来(t > t0)を過去(t < t0)かた「分離する」ことです。

STATEという語を使う場合、履歴データの知識は要求されません。状態は明確に現時点のエンティティのリアクションに影響する過去におけるすべてのインプット処理とみなすことができます。ここでのリアクションはインプットと現状にのみ依存します。

「入力処理」表記はまたオートマタ準拠プログラミングの主要な表記のひとつでもあります。インプットは通常はベクトルです。そのコンポーネントは意味と生成メカニズムに応じてイベントとインプット変数に分割されます。

有限な記述セットと有限なインプット処理の組合せがアウトプットなしの（有限）オートマトンを形成します。そのようなオートマトンは特定の方法でその現在状態を変更することでインプット処理に対して反応します。記述を変更することのできるルールはオートマトン翻訳機能と呼ばれています。

オートマタ準拠プログラミングにおいて（有限）オートマトンと呼ばれるものは、基本的に「アウトプットなしのオートマトン」 と 「インプット処理」の組合せです。そのようなオートマトンはその状態を変えるだけでなくアウトプットに特性値を生成することでインプットに反応します。アウトプットを生成するルールは オートマトンアウトプット機能と呼ばれます。

復号的な振る舞いをするシステムを設計する際、出発点として処理の特定セットと外部既存の制御オブジェクト(market) 環境で起こる既定のイベントセットを持つ既存の制御オブジェクトを取ることが必要です。

実際にはデザインは一般的に制御オブジェクトとイベントを前提としています。

  1. 問題の初期値はただシステムの目標とする振る舞いの言葉による記述なだけではなく、外部環境からシステムに着信するイベントセットの（多少）正確な仕様であり、すべての制御オブジェクトの多数のリクエストとコマンドでもあります。

  2. 制御記述セットが構築されます。

  3. 制御オブジェクトのすべてのリクエストがオートマトンインプット変数の対応して割り当てられ、またすべてのコマンドがアウトプット変数に対応して割り当てられます。要求されるシステムの振る舞いを確証するオートマトンは制御記述、イベント、インプットおよびアウトプット関数を基に構築されます。


6. プログラムの特徴とメリット

オートマタ準拠プログラミングの最初の特徴は外部ループがあることが基本であることです。基本的に新しいことは何もありません。ここで主要なことはこのループはプログラム全体で唯一のロジカルな部分ということです！(たとえば新規受信チック.)

二番目の特徴は一番目に続くものです。すべてのオートマトンにはすべてのロジカル処理を構成するスイッチストラクチャ（実際それは仮想のものです）が含まれています。オートマトンが呼ばれるとき、コントロールは「ケース」ラベルの一つに変換され、それに適切な処理が続きます。オートマトン（サブプログラム）処理はつぎの起動までに完了します。これら処理は変換条件確認と特定の条件が満たされれば、適切なアウトプット関数が呼ばれオートマトン状態が変化します。

上の記述すべての主要なコンセクエンスはオートマトンの実装はシンプルなだけでなくもっとも重要なことにプログラムがすべてのオートマトンにおける木城がマルチバリューの記述変数によって提供される仲介の閉じカル変数（フラグ）なして行えることです。

最後の記述はあまり考えずに数多くのグローバル変数やローカル変数（フラグ）を使うのに慣れているため信じがたいものです。それなしでどのように行うことができるのでしょうか？これらは条件が満たされたことをプログラムに信号を送るフラグであることが多いです。開発者が必要だと思ったときフラグは設定（TRUEに）されますが、それから（通常フラグが常にTRUEであることで望む効果をあげ始めたあとにだけ）プログラムのあらゆる箇所でFALSE に再設定しようとします。

聞き覚えありますよね？それでは例を見て確認します。ここでは追加の変数は使用しません。変更はただロジカルな条件が満たされる場合の状態数の値だけです。それはフラグに対して価値ある置換ではないのでしょうか？

アルゴリズムはプログラムのロジカル部分を作成する主要な役割を果たします。ここで憶えるキーフレーズは「ロジカルパート」です。この場合、記述はすべての根底にあります。別に追加の必要がある語は「ウェイティング」です。私の意見では、ひじょうに適切な 「ウェイティング状態」の定義を得ます。その状態にあるときはインプットが行われるのを待ちます。（属性、値、イベント）ウェイティングは短い場合も長い場合もあります。別の言い方をすれば、不安的な状態と安定した状態があります。

状態の最初のプロパティは制限されたインプットセットはその状態が待たれるのです。どのアルゴリズム（そして明らかにどのプログラム）もインプット情報とアウトプット情報を持っています。アウトプットは2タイプに分けられます。変数（すなわちオブジェクトプロパティ処理）と関数（すなわちアプリケーション起動関数、レポート関数等）です。

状態の二番目のプロパティはアウトプット変数の正確な値セットの予想です。これはひじょうにシンプルですが極端に重要な状況を表します。 - すべてのアウトプット半数値はあらゆる既定時刻で判断されうる。これはアルゴリズム（プログラム）が時間のすべての点における特定の状態にあるからです。

記述数はアウトプット変数値であるため、制限があります。ログトランザクション用の関数はオートマトン関数と状態の間のトランザクションシーケンスにスムーズに統合されます。またアウトプットのデリバリーはその結果として常に判断されます。

特徴の完全なリストはセクション2. 「提案される技術」の特徴およびメリットの完全リストはセクション3. 「提案される技術のメリット」にあります。本稿はテーマに関する大量の情報を取り上げ切れてはいません。Anatoly Shalyto著の研究文献の調査を終えて、理論的質問はshalyto@mail.ifmo.ruまで彼個人宛てにしてください。

彼の科学的発想のユーザーとしてわれわれの目標と課題を胸に抱きつつ、以下に私のオートマタ準拠プログラミング技術の例を3件提供します。


7. オートマタ準拠プログラミングの例

7.1. 理解のための例

状態はシステムが存在するモードに過ぎません。たとえば水は3種類の状態で存在します。すなわち固体、液体、気体です。ある変数の影響を受けてある状態から別の状態に変わります。温度（一定の圧力の下で）です。

時間を基にした温(t)グラフ（われわれの場合は価格値）があるとします。

int STATUS=0; // a global integer is by all means always a variable !!! STATUS is a multi-valued flag
//----------------------------------------------------------------------------------------------//
int start() // outer loop is a must
  {
   switch(STATUS)
     {
      case 0:  //--- start state of the program
         if(T>0 && T<100) STATUS=1;
         if(T>=100)       STATUS=2;
         if(T<=0)         STATUS=3;
         break;

      case 1:  //---  liquid
         // set of calculations or actions in this situation (repeating the 1st status -- a loop in automata-based programming) //
         // and calls of other nested automata A4, A5;
         if(T>=100 )      { STATUS=2; /* set of actions when transitioning, calls of other nested automata A2, A3;*/}
         if(T<0)          { STATUS=3; /* set of actions when transitioning, calls of other nested automata A2, A3;*/}
         // logging transitions and actions when the condition is met.
         break;

      case 2:  //--- gas
         // set of calculations or actions in this situation (repeating the 2nd status -- a loop in automata-based programming) //
         // and calls of other nested automata A4, A5;
         if(T>0 && T<100) { STATUS=1; /* set of actions when transitioning, calls of other nested automata A2, A3;*/}
         if(T<=0)         { STATUS=3; /* set of actions when transitioning, calls of other nested automata A2, A3;*/}
         // logging transitions and actions when the condition is met.
         break;

      case 3:  //--- solid
         // set of calculations or actions in this situation (repeating the 3rd status -- a loop in automata-based programming) //
         // and calls of other nested automata A4, A5;
         if(T>0 && T<100) {STATUS=1; /* set of actions when transitioning, calls of other nested automata A2, A3;*/}
         if(T>=100)       {STATUS=2; /* set of actions when transitioning, calls of other nested automata A2, A3;*/}
         // logging transitions and actions when the condition is met.
         break;
     }
   return(0);
  }

プログラムは気圧パラメータ P と新しい状態を追加し、グラフに表示されている複合的依存性を導入することより洗練されたものにすることができます。

このオートマトンには 32 = 9 変遷条件がありどれも取り残されたり見過ごされることはありません。このスタイルはまたインストラクションと法則を書くのにも好都合です。ここでは法則のループホールやバイパスは許可されません。 - イベントの引き継がれるバリアントの組合せはすべて取り扱われるすべてのケースが記述されます。

オートマタ準拠プログラミングはすべてを考慮することを要求します。たとえイベント引継ぎバリアントがいくつかなぜそれが定常性と統合性に対する法則、インストラクション、制御システムをチェックするときの主要ツールなのかを考えません。数学的法則もあります。

システムに N 状態が（0 スタート以外）あった場合、変遷条件のトータルは N2である。

変遷ダイアグラム：状態N = 3、変遷およびループ数は N2 = 9 （矢の数に等しい）。

例の変数の数が異なっている場合、

表にあるすべての計算された値は 急激に上がっているのを示しています。設計は主要なシステム的変数を選択する場合 徹底を要求する複雑なプロセスです。

パラメータが2個しかなかったとしてもすべてを述べるのはひじょうに難しいことです。ただし実際にはずっと簡単です！ロジックと意味に応じて 50-95% の変遷は物理的に存在するはずがなく、状態数も 60-95% 少なくなります。このロジックの分析と意味はすべての遷移と状態を語る難しさを大幅に低くします。

より複雑なケースではEAにおける既知のインプットデータとアウトプットデータに対する状態の最大数を計算することが求められます。この問題の解決法は組合せアルゴリズムとフォーミュラ 組合せ、 順列、整列 と列挙組合せ を応用することで見つけることができます。

7.2. ヒステリシスとのリレー

リレー、トリガー、登録、カウンター、デコーダ、 コンパレータ、その他のノンリネアデジタル、アナログ制御システム要素は EAにおいてひじょうに都合のよいものです。

  • xmax = 100 - 最大ピックアップ値
  • xmin = -100 - 最小ピックアップ値
  • x = x(t) - インプット時のシグナル
  • Y = Y(t) - アウトプット時のシグナル
int   status=0;  // at the beginning of the program we globally assign
//------------------------------------------------------------------//
switch(status)
  {
   case 0: //  start  
      Y=x;
      if(x>xmax)  {status=1;}
      if(x<xmin)  {status=2;}
      break;

   case 1: //++++++++++++++++++++
      if(x>xmax)  Y=x;
      if(x<xmax)  Y=xmin;
      if(x<=xmin) {status=2; Y=xmin;}
      break;

   case 2: //--------------------
      if(x<xmin)  Y=x;
      if(x>xmin)  Y=xmax;
      if(x>=xmax) {status=1; Y=xmax;}
      break;
  }

リレーの特性

7.3. イベント継承の9状態および81バリアント用テンプレート

Y は1～9のオートマトンの現在のインプット状態です。値 Y は既定のサブプログラムの外部 EA にて作成されます。MEGASTATUS は Yの過去の状態です。

int MEGASTATUS=0; // at the beginning of the program we globally assign
//---------------------------------------------------------------------//
void A0(int Y) // automaton template
  {
   switch(MEGASTATUS)
     {
      case 0:  // start
          MEGASTATUS=Y;
          break;

      case 1: // it was the past
          // it became current, repeating
          if(Y=1) { /*set of actions in this situation, calls of other nested automata A2, A3, ... */ } // Loop//
          // new current
          if(Y=2) { /* set of actions in this situation */ }
          if(Y=3) { /* set of actions in this situation */ }
          if(Y=4) { /* set of actions in this situation */ }
          if(Y=5) { /* set of actions in this situation */ }
          if(Y=6) { /* set of actions in this situation */ }
          if(Y=7) { /* set of actions in this situation */ }
          if(Y=8) { /* set of actions in this situation */ }
          if(Y=9) { /* set of actions in this situation */ }
          // logging transitions and actions when the condition is met.
          break;

      case 2: // it was the past
          // it has become current
          if(Y=1) { /* set of actions in this situation */ }
          if(Y=2) { /* set of actions in this situation */ } //Loop//
          if(Y=3) { /* set of actions in this situation */ }
          if(Y=4) { /* set of actions in this situation */ }
          if(Y=5) { /* set of actions in this situation */ }
          // e.g. if the transition from 2 to 6 is in essence impossible or does not exist, do not write anything
          if(Y=6) { /* set of actions in this situation */ }
          // the automaton will then be reduced but the automaton template shall be complete to count in everything
          if(Y=7) { /* set of actions in this situation */ }
          if(Y=8) { /* set of actions in this situation */ }
          if(Y=9) { /* set of actions in this situation */ }
          // logging transitions and actions when the condition is met.
          break;

      case 3: // it was the past
          // it has become current
          if(Y=1) { /* set of actions in this situation */ }
          if(Y=2) { /* set of actions in this situation */ }
          if(Y=3) { /* set of actions in this situation */ } //Loop//
          if(Y=4) { /* set of actions in this situation */ }
          if(Y=5) { /* set of actions in this situation */ }
          if(Y=6) { /* set of actions in this situation */ }
          if(Y=7) { /* set of actions in this situation */ }
          if(Y=8) { /* set of actions in this situation */ }
          if(Y=9) { /* set of actions in this situation */ }
          // logging transitions and actions when the condition is met.
          break;

      case 4: // it was the past
          // it has become current
          if(Y=1) { /* set of actions in this situation */ }
          if(Y=2) { /* set of actions in this situation */ }
          if(Y=3) { /* set of actions in this situation */ }
          if(Y=4) { /* set of actions in this situation */ } //Loop//
          if(Y=5) { /* set of actions in this situation */ }
          if(Y=6) { /* set of actions in this situation */ }
          if(Y=7) { /* set of actions in this situation */ }
          if(Y=8) { /* set of actions in this situation */ }
          if(Y=9) { /* set of actions in this situation */ }
          // logging transitions and actions when the condition is met.
          break;

      case 5: // it was the past
          // it has become current
          if(Y=1) { /* set of actions in this situation */ }
          if(Y=2) { /* set of actions in this situation */ }
          if(Y=3) { /* set of actions in this situation */ }
          if(Y=4) { /* set of actions in this situation */ }
          if(Y=5) { /* set of actions in this situation */ } //Loop//
          if(Y=6) { /* set of actions in this situation */ }
          if(Y=7) { /* set of actions in this situation */ }
          if(Y=8) { /* set of actions in this situation */ }
          if(Y=9) { /* set of actions in this situation */ }
          // logging transitions and actions when the condition is met.
          break;

      case 6: // it was the past
          // it has become current
          if(Y=1) { /* set of actions in this situation */ }
          if(Y=2) { /* set of actions in this situation */ }
          if(Y=3) { /* set of actions in this situation */ }
          if(Y=4) { /* set of actions in this situation */ }
          if(Y=5) { /* set of actions in this situation */ }
          if(Y=6) { /* set of actions in this situation */ } //Loop//
          if(Y=7) { /* set of actions in this situation */ }
          if(Y=8) { /* set of actions in this situation */ }
          if(Y=9) { /* set of actions in this situation */ }
          // logging transitions and actions when the condition is met.
          break;

      case 7: // it was the past  
          //it has become current  
          if(Y=1) { /* set of actions in this situation */ }
          if(Y=2) { /* set of actions in this situation */ }
          if(Y=3) { /* set of actions in this situation */ }
          if(Y=4) { /* set of actions in this situation */ }
          if(Y=5) { /* set of actions in this situation */ }
          if(Y=6) { /* set of actions in this situation */ }
          if(Y=7) { /* set of actions in this situation */ } //Loop//
          if(Y=8) { /* set of actions in this situation */ }
          if(Y=9) { /* set of actions in this situation */ }
          // logging transitions and actions when the condition is met.
          break;

      case 8: // it was the past
          // it has become current
          if(Y=1) { /* set of actions in this situation */ }
          if(Y=2) { /* set of actions in this situation */ }
          if(Y=3) { /* set of actions in this situation */ }
          if(Y=4) { /* set of actions in this situation */ }
          if(Y=5) { /* set of actions in this situation */ }
          if(Y=6) { /* set of actions in this situation */ }
          if(Y=7) { /* set of actions in this situation */ }
          if(Y=8) { /* set of actions in this situation */ } //Loop//
          if(Y=9) { /* set of actions in this situation */ }
          // logging transitions and actions when the condition is met.
          break;

      case 9: // it was the past
         // it has become current
          if(Y=1) { /* set of actions in this situation */ }
          if(Y=2) { /* set of actions in this situation */ }
          if(Y=3) { /* set of actions in this situation */ }
          if(Y=4) { /* set of actions in this situation */ }
          if(Y=5) { /* set of actions in this situation */ }
          if(Y=6) { /* set of actions in this situation */ }
          if(Y=7) { /* set of actions in this situation */ }
          if(Y=8) { /* set of actions in this situation */ }
          if(Y=9) { /* set of actions in this situation */ } //Loop//
          // logging transitions and actions when the condition is met.
          break;
     }
   MEGASTATUS=Y;
  }

7.4. オーディオプレーヤーオートマトン

シンプルなオーディオプレーヤーを振り返ります。

このデバイスは6つの状態です。

  1. 準備
  2. トラックなし
  3. 再生中
  4. 早送り
  5. 巻き戻し
  6. 一時停止

オーディオの制御システムはオートマトンによって表されます。押されたボタンはオートマトンに影響を与えるイベントに従っています。トラック間の遷移、再生、表示制御等はアウトプットです。

switch(STATUS)
  {
   case 0: //--- "Ready"
      if(Event == 3) { STATUS = 3; } //«>>» button pressed
      if(Event == 6) { STATUS = 1; } //Audio file not found 
      if(Event == 1) { STATUS = 2; } //«PLAY» button pressed
   
      z1();  // Set the indicator to the initial state
      break;

   case 1: //--- "No Track"
      z6();  // Give the «No Track» message
      break;

   case 2: //--- "Playing"
      if(Event == 4) { STATUS = 4; } //«<<» button pressed
      if(Event == 5) { STATUS = 5; } //«PAUSE»( | | ) button pressed
      if(Event == 3) { STATUS = 3; } //«>>» button pressed
      if(Event == 2) { STATUS = 0; } //«STOP» button pressed
      z2(); // Playing
      break;

   case 3: //--- "Fast-Forward"
      z3();  // Next track
      { STATUS=2; }
      break;

   case 4: //--- "Rewind"
      z4(); // Previous track
      { STATUS=2; }
      break;

   case 5: //--- "Pause"
      if(Event == 5) { STATUS = 2; } //«PAUSE» button pressed
      if(Event == 1) { STATUS = 2; } //«PLAY» button pressed
      if(Event == 2) { STATUS = 0; } //«STOP» button pressed
      if(Event == 3) { STATUS = 3; } //«>>» button pressed
      if(Event == 4) { STATUS = 4; } //«<<» button pressed
      z5(); //Pause
      break;
  }

理論ではこのオートマトンは36の背に変数を持ち得ますが、実在するのは15だけですべての詳細は私が提供する記述にあります。


8. プロジェクト実行に従ったА.А.Shalytoの奨励

プロジェクトドキュメンテーションの準備の仕方と書き方はこちらにあります。http://project.ifmo.ru/books/3,よって本稿では短い引用だけをします。

  1. А.А.Shalytoの著書"Logic Control. Methods of Hardware and Software Implementation of Algorithms. SPb.: Nauka, 2000"は『書籍』項の指定のウェブサイトで利用可能んもので、プロトタイプとして取得可能です。それはお樹法の適切な表現をIt embodies しています。ロシアでもっとも古く評判のよい出版社から発行されているからです。
  2. イントロは選択されるテーマの適切性に対する基礎知識を提供し、検証対称の問題を完結に述べ、プロジェクトで使用されるプログラム言語とオペレーティングシステムを指定します。
  3. 手元の問題の詳細な言葉の記述が述べられる問題を解りやすくしている図、ダイアグラム、スクリーンショットに従って「問題の記述」項で提供されます。
  4. オブジェクト指向のプログラミングを使用する場合、『設計』項はクラスのダイアグラムも含みます。主要なクラスは注意深く記述する必要があります。「クラスのブロック図」はオートマタ準拠プログラミングオートマタ準拠プログラミングの指示に従って使用されるインターフェースとメソッドを紹介することを目指してそれぞれに対して準備されます。
  5. 『オートマタ』項のすべてのオートマトンに対して3件のドキュメントが提供されます。：言葉による記述、オートマトンのリンクダイアグラム。遷移グラフです。
  6. 言葉の記述はかなり詳細ですが、複合的なオートマトンの振る舞いを明確な方法で述べるのが難しいとして、それは通常目的の宣言」を表します。
  7. オートマトンリンクのダイアグラムはそのインターフェースの詳細な記述を提供します。図の左側は以下のような内容です。
    • データソース
    • 各インプット変数の名前
    • 各イベントのフルネーム
    • 入力として与えられるオートマトン内で使用される他のオートマタの状態数をpredicates E.g. the Y8 == 6 述部が使用可能です。それは8番目のオートマトンが6番目の状態に遷移すると1に等しい値を取るものです。
    • インプット変数は適切な指数を持つ x として示されます。
    • 適切な指数を持つ e として示されるイベント
    • 数 N、 YNとして示されるオートマトンの状態を格納する変数

    図の右側は以下のような内容です。

    • 適切な指数を持つz として示されるアウトプット変数
    • 各アウトプット変数のフルネーム
    • 既定のオートマトン（あれば）によって作成されるイベント
    • 作成される各イベントのフルネーム
    • データのレシーバー
  8. 復号的な計算アルゴリズムがノートや遷移で使用されると、「計算アルゴリズム」項がアルゴリズムの選択を説明し、その記述を提供します（数学的記述含む）。これらアルゴリズムは変数 x および zによって指定され、それは計算がインプットまたはアウトプットの差異行われたかによります。
  9. プログラム実装の特殊性は「実装」項で述べられています。それは特に規定に従った同形のオートマタの実装です。オートマタの自走はまたこちらでも提供されています。
  10. 「おわりに」は完成したプロジェクトのメリットとデメリットを取り上げます。またプロジェクトの改善方法も提供します。


9. おわりに

みなさんに推奨することは以下です。

  • このプログラミングに対する新しいアプローチを調査してみる。
  • みなさんのプログラミングの考え方やトレーディング戦略、にこのまったく新しくひじょうにおもしろいアプローチを実装する。.

オートマタ準拠プログラミングは以下であることを望んでいます。

  • はそのうちすべてのトレーダー、またMetaQuotes言語開発者にとってさえプログラミングとデザインの標準になります。
  • EAをデザインする際、複合意思決定において基本になる。
  • 将来新しい言語 、オートマタ準拠プログラミング方法と新しいプラットフォームMetaTrader 6をサポートしているMetaQuotes Language 6で開発する。

すべてのトレーディング開発あはがこのプログラム方法をおこなったらノーロス EA の目標達成が可能です。この初稿ではみなさんにオートマタ準拠デザインと新しい発明と発見の創造性とimpulse としてのプログラミング分野の研究に対してまったく新しい出口を示そうとしました。

もう一点あります。 - 私は著者の記事にまったく賛成で、コンサイスな形でそれを皆さんに提供することが重要だと感じています。（テキスト全貌はこちらにあります。http://is.ifmo.ru/works/open_doc/）


プログラム理解にソースコードがソリューションにならない理由

実践的プログラミングにおける中心的問題はプログラムコード理解の問題です。いつもソースコードを手元におくのはよいことですが、問題はこれが不十分なことがよくある、ということです。そして通常非自明のプログラムを理解するために追加のドキュメンテーションが必要です。このニーズはコード量が増えるに従い急激 に膨らみます。

開発者が開発した元のデザイン判断を復元することが目標であるプログラムコード分析やプログラム理解がプログラム理解のためのソースコードの不十分を伴ってそれの存在が手から手へ渡されるプログラミング技術の重要な枝はとなっています。

大きなソフトウェア再構築プロジェクトに関わったことのある方ならつねに最初に適切に文書化されていない（つねに買い方が悪いわけではありませんが）なソースコードを多量に見るときたよりない、当惑 の感覚を思い出されるでしょう。ソースコードのが利用できても主要なデベロッパーへのアクセスがなければあまり役に立ちません。プログラムが比較的低いレベルの言語で書かれており、 適切に文書化されていない場合、通常主要なデザイン判断はすべてプログラミング詳細で消失され再構築が要求されます。そのような場合、インターフェース仕様書やアーキテクチャ記述といったより高いレベルのドキュメンテーションの値はソースコード自体の値を上回るかもしれません。

ソースコードはプログラム理解に不適切だと認識すると、コードと高レベルドキュメンテーションを組合せようとするようになります。

プロジェクトの初期段階を逃したら、高レベルドキュメンテーションは 存在しないとき、複合性と仕事量がみなさんからソースコードをかくしてしまいます。 プロジェクトや適切なアーキテクト記述について元から作業をする開発者がいない中、「有史以前の」コードを理解することはおそらくプログラマが出会うもっとも困難な挑戦の一つです。


プログラムがデザイン欠く理由

ソースコードの不在は悪い可能性がある一方、その利用可能性はまたメリットに乏しい可能性があります。「末永く幸せにくらす」生活のためにまだかけているものはなんでしょうか？答えは簡単です。コンポーネントの一つとしてのプログラムドキュメンテーションを含む正確なデザインドキュメンテーション。

橋、道路、構想ビルはふつうドキュメンテ―ションを手にしていなければ作ることはできません。がプログラムではそれは真実ではありません。

プログラミングに関する状況は次のように定義することができます。：「プログラマーがプログラムを書くように建築者がビルを建てたら、最初のウッドペッカーが文明を破壊してしまうかもしれない。」

ハードウェアについての詳細で明快なデザインドキュメンテーションが数多く発行されそれは比較的簡単に理解できますが、そのようなドキュメンテーションは存在しないか、ソフトウェアか、または純粋に正式な方法で書かれているため、変更しようとするとスキルの高い専門家が要求されます。

明らかにこの状況は下のように説明されます。まず開発とハードウェアの製造は異なる2つのプロセスで、異なる組織によって実行されます。よってドキュメンテーションの質が悪ければ、開発エンジニアは望んでいるものとまったく違う「プラント」での作業に生涯をささげることになってしまいます。ソフトウェアの開発に関しては、状況は変わります、理由はこの場合負ソフトウェアの開発者と製造者が通常同じ会社でよってドキュメントリストに関わらずその内容はルールとしてひじょうに表面的です。

二番目にハードウェアが「ハード」、一方ソフトウェアは「ソフト」です。それによりプログラムの変更は簡単になりますが、設計のドキュメンテーションが一緒に発行されないわけにはいきません。 ほとんどのプログラマーが読むので、それ以上のプログラマーはいわゆるドキュメンテーションを書きます。

経験から新規に資格を取得するプログラマーはひとりも、最も優秀な人でさえ、ドキュメンテーションのデザインを準備できません。またその多くが数学の長くややこしいコースを取ったのに、その人達のロジックにほとんど何の影響も与えず、ドキュメンテーションを書く活力ににも影響を与えません。全ドキュメンテーション（そのサイズに関わらず）をとおして彼らは一つの同じことに異なる表記を使用するかもしれません。呼び方をたとえば. the bulb、the light bulb、the lamp、Lamp。好きなときに大文字、小文字を使って書くなどです。そして夢のような 全貌を与えれば何が起こるか想像してください。

明らかにそれは、コンパイラフラグの矛盾をプログラミングするとき、一方でデザインのドキュメンテーションがプロンプトのなんであるかなしに書かれるのです。

ソフトウェアドキュメンテーションの質は増加する社会的意義の問題になりつつあります。ソフトウェア開発は発展的に強い収益の動機があるビジネスを示すのと似てきました。すべてが慌てて行われ、将来製品になるのは何かなど考えられていません。芸能界のようにプログラミングが「良いと悪い」ではなくすべてを「収益と損失」に関して計測するのです。主要な場合では、すぐれた技術が実用的に良いものではありませんが、人はそれにお金を払います。

設計ドキュメンテーションを書く気が進まないというのはおそらくプロジェクトに制約（アンドキュメント）があるほど著者は 欠くことができないという事実に関連しています。

そのような動作は残念ながらひじょうに重要なシステム用ふぉすとウェアの開発に広まっています。それはひろくぷろぐらむはほとんどの場合、デザインされるのではなく書かれるという事実に負うものです。「デザインするとき、CRC カードより複雑なあらゆる技術や使用事例図は複雑すぎるとみなされ、よって使用されません。プログラマーは期限に間に合わないかもしれないと上司に報告することで既定の技術を適用することをつねに拒むことができます。」.

このことは「ユーザーが何かが通常と異なるソフトウェアにおけるエラーを考慮しない」状況につながります。

デザインと適切なドキュメンテーションはソフトウェアでなく大きなビルドに関する時に起こる必要がある、と現在広く考えられています。

結論として、そのような状況は過去にプログラミングに存在するため使われませんでした。 - 初期の大型コンピュータは使用されていました。エラーのケースではプログラムはひじょうに注意してデザイン、または開発され、次の試みがつうじょう一日でなるべく早く行われます。よって技術の進歩が注われわれを意の少ないプログラミングに導くのです。


残念ながらわれわれの問題と関心は A.A.Shalytoが働く研究所のウェブサイトには見受けられません。彼らには彼らの問題と目標があり、それらはわれわれのコンセプトと定義は理解せず、気づかず、そのためわれわれのテーマに対して適切な例はありません。

A.A.Shalytoによるおもな著書／テキスト

  1. Automata-Based Programming. http://is.ifmo.ru/books/_book.pdf
  2. Using Flow Graphs and Transition Graphs in Implementation of Logic Control Algorithms. http://is.ifmo.ru/download/gsgp.pdf
  3. Automata-Based Programming. http://is.ifmo.ru/works/_2010_09_08_automata_progr.pdf
  4. Transformation of Iterative Algorithms into Automata-Based Algorithms. http://is.ifmo.ru/download/iter.pdf
  5. Switch-Technology: Automata-Based Approach to Developing Software for Reactive Systems. http://is.ifmo.ru/download/switch.pdf
  6. Automata-Based Program Design. Algorithmization and Programming of Logic Control Problems. http://is.ifmo.ru/download/app-aplu.pdf
  7. Using Genetic Algorithm to Design Autopilot for a Simplified Helicopter Model. http://is.ifmo.ru/works/2008/Vestnik/53/05-genetic-helicopter.pdf
  8. Explicit State-Based Programming. http://is.ifmo.ru/download/mirpk1.pdf
  9. Algorithmization and Programming for Logic Control and Reactive Systems. http://is.ifmo.ru/download/arew.pdf
  10. Object-Oriented Approach to Automata-Based Programming. http://is.ifmo.ru/works/ooaut.pdf
  11. Graphical Notation for Inheritance of Automata-Based Classes. http://is.ifmo.ru/works/_12_12_2007_shopyrin.pdf
  12. Programming in... 1 (One) Minute. http://is.ifmo.ru/progeny/1minute/?i0=progeny&i1=1minute

プロジェクト

  1. Modeling Operation of ATMs. http://is.ifmo.ru/unimod-projects/bankomat/
  2. Modeling Nuclear Reactor Control Process. http://is.ifmo.ru/projects/reactor/
  3. Elevator Control System. http://is.ifmo.ru/projects/elevator/
  4. Automata-Based Development of Coffee Maker Control System. http://is.ifmo.ru/projects/coffee2/
  5. Design and Research of Automata for Driving. http://is.ifmo.ru/projects/novohatko/
  6. Modeling a Digital Camera Using Automata-Based Programming. http://project.ifmo.ru/shared/files/200906/5_80.pdf
  7. Using Automata-Based Programming to Model a Multi-Agent System for Unmanned Vehicles. http://project.ifmo.ru/shared/files/200906/5_41.pdf
  8. Visual Rubik's Cube Solution System. http://is.ifmo.ru/projects/rubik/

その他興味深い記事やプロジェクト： http://project.ifmo.ru/projects/、http://is.ifmo.ru/projects_en/、http://is.ifmo.ru/articles_en/.


追記

ルービックキューブ可能な異なるイベント数 は (8!× 38−1) × (12!× 212−1)/2 = 43 252 003 274 489 856 000. ただこの数値は中央四角が異なる方向性を持つことに配慮していません。

中央フェースの方向性を考慮するとイベント数は2,048倍大きくなります。例： 88 580 102 706 155 225 088 000.

外為マーケットと交換はそれほど継承のバリアントはありませんが、それに関わる問題は簡単に100～200ステップでこのプログラムパラダイムを使って解決できます。ほんとうです！マーケットとEAは絶え間ない競争をしています。それは敵の次の一手が何か誰も知らないチェス をするようなものです。（われわれのように）ただし印象的なコンピュータプログラムもがあります。 Rybka （ひじょうに力強いチェスエンジン） α-βpruning アルゴリズムを基に設計されたものです。

プログラミングの他の分野で成功している人からみなさんにエネルギーを与え、われわれの作業に約束がもたらされますように！そしてわれわれは全員が未知の知だと解っていることを知っておきます。

MetaQuotes Ltdによってロシア語から翻訳されました。
元の記事: https://www.mql5.com/ru/articles/446

警告: これらの資料についてのすべての権利はMetaQuotes Ltd.が保有しています。これらの資料の全部または一部の複製や再プリントは禁じられています。
ディスカッションに移動
経験的モード分解メソッドのイントロダクション 経験的モード分解メソッドのイントロダクション
この記事は、経験的モード分解メソッド（EMD）に読者が慣れ親しむことが目的です。Hilbert-HUang変換の基礎部分であり、非定常・非線形的プロセスからデータを分析することを意図されています。この記事はこのメソッドの実装について紹介し、また、その特徴や使用例も提示しています。
購入前に売買ロボットを検証する方法 購入前に売買ロボットを検証する方法
MQL5 マーケットで売買ロボットを買うことは似たような選択肢をしのぐ明らかなメリットがあります。提供される自動化されたシステムを MetaTrader 5 ターミナルで直接徹底的に検証することができるのです。購入前にシステムを完全に把握するため、内蔵ストラテジーテスタで Expert Advisor を不都合なモードで注意して実行することができる／する必要があるのです。
MQL5.community 人名鑑 MQL5.community 人名鑑
MQL5.com ウェブサイトはみなさんのことをとてもよく覚えています！何本のスレッドがすばらしい出来か、記事がどれほど人気か、「コードベース」のプログラムがどのくらいの頻度でダウンロードされるか。これは MQL5.comで記憶されていることのほんの小さな一部にしかすぎません。みなさんの実績はプロフィールで確認可能ですが、全体像はどうでしょうか？本稿では全 MQL5.community メンバーの実績概要を示します。
MetaTrader 5での自己組織化機能マップ(Kohonenマップ)の使用 MetaTrader 5での自己組織化機能マップ(Kohonenマップ)の使用
自己組織化機能マップ（Kohonenマップ）の最も興味深い特徴に一つとして、データを監視することなく分類するという点です。基礎的な形式では、入力データの類似マップを作成します。SOMマップは、高次元のデータの分類とビジュアル化のために使用することができます。この記事では、Kohnenマップのいくつかの簡単な使用方法を紹介します。