記事"自動売買システム作成にたいする新手法としてのオートマタ準拠プログラミング"についてのディスカッション - ページ 3

新しいコメント
 
Rorschach:

「3.私は好奇心が強く、本物のダニのホワイトノイズを聞きたかったのですが、WaveLab6.0ソフトウェアを使ってそれができました。

へー。こんな変人は僕だけではないことがわかった。）これが その結果だ。僕はAdobe Audienceでやったんだ。

どうやって価格を正規化したんですか？

いつものように、長い尾を切ることによって、3*skoを超えるものはすべてこの値になる。
 

車1台分の感情

1) ブカブカで何もない...。

2) これを見ると、なぜ今アメリカ人が火星にいて、私たちではないのかが分かってくる。

3) それ以外のことは黙っていたい（感情だけのために）。

 

私はこの記事、特にプログラム開発と文書化の現代的な実践について気に入った。その通りだ。

もちろん、オートマトンの手法に基づく最も単純なExpert Advisorくらいは記事で紹介すべきだった。それとも次の記事で紹介する予定なのだろうか。

そして、オートマタ手法の大きな問題点が一つある。実際のExpert Advisorでは、状態を明確に定義することは不可能です。エキスパートアドバイザーの状態は、ユーザーのコンピューター上の内部変数と、サーバー上のポジションの状態（現在のレート、エクイティ、注文の執行）によって決まります。内部状態は一義的に決定されますが、サーバー上のポジションの状態は不明であったり、遅れて判明したり、不明確な状態であったりします（ある注文やリクエストは実行され、ある注文やリクエストは実行されず、その理由は誰も知りません）。

また、アドバイザーの現在の状態が不明であるため、オーダーやリクエストが実行されず、オートマトンの明確なロジックを構築することは不可能である。現実には、このようなアルゴリズムになる：

comp: サーバー、数百ユーロ買ってくれ。

サーバー：くそったれ、コンプ、リクエストのストップが間違ってるぞ。

なんで間違ってるんだ？

サーバー：だから値段が跳ね上がったんだ。

コンプ: じゃあ、ストップなしで買ってくれ。

サーバーは黙っている。

コンプ：じゃあ、何を買ったんだ？

サーバーは沈黙

コンプ：まあ、クソ食らえだ。8分間仮眠しよう。

8分後にコンプ：どう？

サーバー：ユーロバックスを買ったんだけど、買ってる間に値段が変わっちゃったんだ。

コンプ：くそったれ。もう1時間仮眠しよう。

などなど。

 
進化は堂々巡りである。今こそ（非）有限オートマトンに戻り、チューリングマシンを作る時なのだ。
 
Virty:

...

そして、オートマトン法の大きな問題点が一つある。実際のExpert Advisorでは、状態を明確に定義することは不可能です。Expert Advisorの状態は、ユーザーのコンピュータ上の内部変数とサーバー上のポジションの状態（現在のレート、エクイティ、注文の執行）によって決定されます。内部状態は一義的に決定されますが、サーバー上のポジションの状態は、わからない、遅れてわかる、不明確な状態（ある注文やリクエストは実行され、ある注文やリクエストは実行されない。）

まあ、EAの現在の状態が不明で、 注文やリクエストが実行されないので、オートマトンの明確なロジックを構築することは不可能である。

...

これは新しいことだ。ちょうどANY（例外なく）TSは、分析とTSの状態の明確な理解に基づいています。最も単純な状態：注文の新規/決済/変更のためのシグナルの処理などなど。

EAの現在の状態が明確に知られていない」のであれば、それは間違いなくEAではなく、間違いなくプログラムでもなく、EAに関連する「アルゴリズム」という言葉は抹消され、永遠に忘れ去られるべきです。

 

多くの感情

よし、議論を現実的な方向に向けよう。有限オートマトンの理論に基づいた具体的なアルゴリズムを分析しよう。その長所と短所を議論しよう。私自身はこの方法で書いているわけではないが、この問題やアルゴリズムには少し詳しいので、この制御の一般的な原理をスケッチしてみよう：

//СХЕМА + ПСВЕДОКОД
enum eTradeState {NoTradeRegim, BuyRegim, SellRegim, WaitRegim};
eTradeState TradeState = eTradeState.NoTradeRegim;
int Trade()
{
   switch (TradeState)
   {
       case eTradeState.NoTradeRegim:
          NoTradeRegim();
          break;
       case eTradeState.WaitRegim:
          WaitRegim();
          break;
       case eTradeState.SellRegim:
          SellRegim();
          break;
       case eTradeState.BuyRegim:
          BuyRegim();
          break;
   }
}
//ここでは、Expert Advisor が取引を開始する条件を記述します。例えば
void NoTradeRgim()
{
   //さらなる擬似コードは以下の通り。 
   if(CurrentDay == WorksDays && Market.Enable = true)
      TradeState = eTradeState.WaitRegim;
}
//ここで、ロングまたはショートのポジションに入るシグナルをキャッチする。
void WaitRegim()
{
   if(CheckForNoTrade() == true)
   {
      TradeState = eTradeState.NoTradeRegim;
   }
   if(CheckForBuy() == true)
   {
      BuyAtStop(...)
      TradeState = eTradeState.BuyRegim;
   }
   if(CheckForSell() == true)
   {
      SellAtStop(...);
      TradeState = eTradeState.SellRegim;
   }
}
//この関数では、長い取引に同行する
void BuyRegim()
{
   //取引終了、ストップロス、その他のパラメータ変更などの条件をここに書く。
   if(StopLossChanged() == true)
      NewStop = ...;
   if(profit >= takeprofit)
   {
      CloseDeal(...);
      TradeState = eTradeState.WaitRegim;
   }

}
//この関数では、ショート・トレードに同行する
void SellRegim()
{
   //取引が成立する、あるいはストップ・ロスが移動するなどの条件をここに書く。
   if(StopLossChanged() == true)
      NewStop = ...;
   if(profit >= takeprofit)
   {
      CloseDeal(...);
      TradeState = eTradeState.WaitRegim;
   }

}

図式的に説明しますが、基本的な考え方は明らかだと思います。Expert Advisorは各時点で1つの状態（非市場モード、シグナル待機モード、買いモード、売りモード）しか持たない。各状態には、現在の状態から別の状態への遷移が発生するアクションと条件のセットがあります。各状態を明確に制御することで、内部ロジックが厳密に局所化され、存在しない取引やすでに決済された取引を決済するような論理エラーは発生しないという考え方だ。

私自身はこの手法で書いているわけではないし、すべてのアルゴリズムに適しているわけではないと思う。しかし、それでも古典的なアプローチよりもうまく解決できるタスクもある。

専門家はどう考えるか？

 
C-4:
...

私自身はこの手法で書いているわけではないので、すべてのアルゴリズムに適しているわけではないと思う。しかし、それでも古典的なアプローチよりもうまく解決できる問題もある。

専門家の方々はどう思われますか？

また、「古典的アプローチ」とはどういう意味か聞いてもいいですか？

現実の反映は人それぞれですからね。

 
Urain:

古典的なアプローチ」とはどういう意味ですか？

現実の反映は人それぞれですから

言い間違えたようだ。もちろん、誰もが自分のやり方で書いている。私が言いたかったのは、各ステップにおけるシステムの状態が明確に定義されていない場合のほとんどのアプローチのことだ。それはExpert Advisorの実行 中だけでなく、決定する必要がある。最も単純な例は、1つのブロックOnTick()で書かれたコードです。モードは分析されていません。解決策の選択は、ブロック分岐 if(...)に基づいて行われます。
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
  • www.mql5.com
Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров - Документация по MQL5
 
C-4:
私が言いたかったのは、各ステップにおけるシステム状態が明確に定義されていない場合の ほとんどのアプローチについてです。それはEA実行 時に決定される必要があります。

状態が「明確に定義されていない」場合、何が「明確に定義されていない」のかをどのように定義できるのでしょうか？注文/ポジションを扱う場合、各ティックでEAがどのような状態にあるかを理解する必要はないのでしょうか？それとも、EAはすべてのティックで「定義されていない状態」にあるのでしょうか。ティックごとに何をすべきかわからないEAとはどのようなものでしょうか？

 

この記事では、スイッチがあるということ以外はまったく取り上げられていない。存在するかどうかは問題ではなく、ifで切り替えることができる。

あるEAを書いていたとき、注文のある非常に複雑なシステムがあった。私はそれを真剣に分析し、注文なし、1つの未決注文、1つの成行注文、2つの未決注文、1つの未決注文と1つの成行注文などの状態のリストを作らなければなりませんでした。こうすることで、なんとか克服することができた。しかし、このように普遍的で、すぐにプログラムし直せるものであることが判明した。記事のネタになりそうだ。

1234567
新しいコメント