さて前回は、 「旧SmoothMADIシステム 」の「ウォークフォワード分析 」結果を纏めようとしたところ、設定ミスがあり再スキャン中でForexTester2が使えないので、MT4EA開発に向けて、「SmoothMADI 」「SmoothMABand 」という2つの独自インジケータを作っている様子を書きました。
今回は、実際にEAを開発するにあたっての方針について考えている様子を書いてみたいと思います。
売買ルールの検証としてのForexTester2でのプログラミングとは異なり、MetaTrader4(以下MT4)でのEA開発では、実際に通信しながら売買し、売買リスクが発生し、異常系やタイミングのズレへの考慮、そして運用性を考慮しなきゃいけない点。
今までForexTester2でのプログラミングでは多少異常発生時のプログラムがいい加減でも大丈夫だったのですが、今回のMT4でのEA開発では、大切なお金を本当にやりとりすることになるので、ここをおろそかにするととんでもない事になりそう。
なので、EA開発において売買ルール以外で考慮すべき観点を纏めてみた。
【EA開発時の考慮すべき観点】
---------------
1.コンテンジェンシー・プラン/可用性
2.EAプログラム品質
3.障害対策
4.タイミングのズレ
5.運用性
6.処理性能
---------------
なんか堅苦しいなぁ。。
では、さっそくひとつずつ。
【コンテンジェンシー・プラン /可用性】
-------------------
リンク先 にも書いている通り、不測の事態が発生したときどうするか、という事。
トレードで言い換えると、たとえば以下の様な例。
●不測の事態の例
1.FX業者の破産
2.サーバ障害による長時間トレード不可
3.MT4クライアントをインストールしているPCが立ち上がらない。
4.自宅ルータ等の通信機器が故障
5.インタネットプロバイダが長期間不通。
6.ライフラインの長時間停止
7.自宅が火災や地震により崩壊
つまり、上記の様な事が発生した場合、どう行動する予定にしておくのかを決める必要があるという事。
上記「1.」に関しては、FX業者と契約するときに、約款等を熟読して、FX業者が破産したときにどうできるのかを理解し、リスクが顕在化した時にとる行動を事前に纏めておく事しかないかな。なので、FX会社選定はかなり気をつけなければ。。。これは前々回の記事 に書いた通り。
上記「1.」を除いて、ポジションを持っていなければ、トレードに関して言うと問題無いけど、問題はポジションを持っている時。つまり、リスクにさらされた状態で何もできないという状態。
#だからかならずストップロスを入れておくんですけど。。
じゃぁ、「2.」以下についてどうするかというと、「ポジションを閉じ、新規ポジションを取らない事」に注力することに。
→サーバ側障害はFX業者の問題なので、FX業者の資質や約款次第。
他に関しては、トレードに関して言うと、ウチらの問題なので自分で考えなきゃいけない。
上記「3.」~「5.」に関しては、機器類を二重化して、いざというときに待機系に切り替えれる様にする。FX業者によっては、もしかしたら電話でポジションを決済することを依頼する事ができるのかもしれないけど、そこまではまだ知らない。。。。
私はとりあえず、モバイルノートPCを持っているので、後は以前の災害対策の記事 で検討しているモバイル通信のUQ-WiMAXを用意する予定。
問題は、「6.」「7.」が発生したとき。たとえばインタネットカフェにいって、とにかくポジションをはずすとか、ライフラインが生きている所に移動して、ノートPC+モバイル通信でポジションを閉じるとか、公衆電話でFX業者に連絡するとかを決めておく。
で、この時無いと困るのが、FX業者への連絡先とアカウント情報。これは、紙に印刷して非難袋にいれておくとか、貸金庫に入れておくとか。
つまり有事の際は、ポジションを閉じる事に注力するという方針。
-------------------
これがEA開発に一体なんの関係があるのかというと、EAのプログラミングでも「障害対策」も同じ考え方を踏襲して、システムとして一貫性を持たせる必要があるという点。
そして、対策の思想がしっかりしていても、プログラム(つまりEA)が意図した通りに動かなければ意味が無い。。なので、EAのプログラム品質も重要。
【EAプログラム品質】
-------------------
今回はForexTester2でのバックテスト時とは異なり、サーバと通信しながら売買をし、その結果に取り返しがつかない。「あ、プログラムミスで破産しちゃった!」とかは、バックテスト中はいいけど、実際の売買では目も当てられない。。
「プログラム品質」はそのテーマだけで本が書けるぐらいのテーマ。かなり大雑把に言うと、具備すべき機能を日本語で設計書として書き出し、レビューする。次にその設計書を元にプログラミングして、目視によるプログラムチェック。次は、最初に書いた設計書を基にテスト項目を洗い出し、テストを実施。テストで出たプログラム・ミスについては、同じ様なミスが無いか、チェックする。
しかし実際問題、個人でここまでするのは大変なのも事実。
なので、それぞれの工程を意識しつつ、形式にこだわらずにするのがポイントかも。
--------------------
相変わらず面白くない内容だ。。。
こんどはちょっとEAのプログラミング話題に入っていきます。
つぎは、具体的なエラー発生時処理の考え方についてです。
「FXメタトレーダー実践プログラミング」にもエラー時処理の例が書かれていて、サンプルもダウンロードできるみたいなんですが、書籍に載っているサンプルソースを見ると、正直、エラー発生時処理は実際の運用には耐えられない。
#書籍としてはとても参考になって良いのですが、そのまま使うとダメってこと。
【障害対策】
--------------------
異常系のプログラムを書くためには、使用する関数が返すエラーコードの一覧を把握すること。これらについてひとつずつ、発生した場合にどういうリスクになるかを考え、そのリスクを回避/軽減するにはどうするのかを考える。
ちなみに、実際問題エラーコード毎にプログラムで分岐していたら大変なので以下の様に分類してみた。
●エラーコードの分類例
1.プログラムミス起因によるもの
2.原因不明なエラー
3.サーバ/ネットワーク障害起因によるもの
4.サーバ処理遅延に起因するもの
5.サーバ側とクライアント側のデータ不整合によるもの
6.実は問題ないもの
で、今回どうする予定かというと。
・上記「1.」、「2.」の場合
エラーが発生した処理は中断。その後は、新規発注しない様にする。
ポジションを閉じる/トレーリングは継続。要は意図しない動きをしているプログラムは
何をしでかすかわからないから危険という事。
・上記「3.」、「4.」の場合
一定期間スリープしたときリトライする。リトライアウトした場合は、以下の様な感じ。
・新規オーダ発注で発生した場合 → あきらめる。
・トレーリングで発生した場合
発注よりかは眺めにリトライするけど、リトライアウトしたら、やっぱりあきらめる。
・手仕舞いで発生した場合
新規発注と比較して長時間続ける様にする。リトライアウトした場合、MT4を
再起動しても大丈夫な様に、手仕舞いに失敗した場合は、その旨を大域変数やファイル
に保存しておいて、再起動したら手仕舞いロジックが動き始めれる様にする。
そして、手仕舞いが成功するまで新規発注しない。
(一定間隔でPC再起動が必要だし、別の要因でMT4が終了してしまう事も想定)
・上記「5.」の場合
・RefreshRates()APIにて、クライアント側の情報を最新化してリトライ。
・上記「6.」の場合
特になにもしない。
--------------------
今回の方針が正しいかどうかは、実際EAを動かしてみないとわからないけど、「コントロールできるのはリスクだけ」という言葉を考えると、用心するに越したことは無い。
#コンピュータシステムはなんでもそうだけど、プログラムの大半は異常系に関するロジック。きっとEAも同じ。
そんだけリスクが嫌なら
FXするな
という話もありますが。。。
あのパルドも「マーケットの魔術師 システムトレーダー編」で、「リスクが嫌い」と言ってるし。。
そして記事が長くなった事を理由に、中途半場な状態のまま「FXシステムトレード初心者奮闘記」は、MT4のEA開発での「EA開発で考慮すべき観点」が続くのでした。
#「ウォークフォワード分析 」のスキャン5/5完了!集計作業しなきゃ。
0 件のコメント:
コメントを投稿