こんばんは。

最近のリアル取引の履歴を見ていて、「んん？」と感じることがあったので書こうと思います。

下の画像を見てください。

これは、今朝のFXCM-UKでの当サイト配布の無料EA、Clab_EURGBPによるEURGBPの取引結果です。

エントリー②はよろしいのですが、エントリー①がengineeeer的によろしくありません。

engineeeerが期待するエントリーは③辺りになります。

これはスリップを広くしているからではありません。

今日だけではありません。最近良く遭遇します。研究員の皆さんもこの経験をしているのではないでしょうか？

では、なぜとても乖離とは思えないこの①の場所でエントリーしてしまっているのでしょう？

原因はプログラムにあります。でもバグではないです。

このEAを開発するにあたって、以前から申していますように、

同手法の他EA（FAPTURBOやM16など）に負けないというのが絶対の目標でした。

その中で、重要なポイントの一つにここが関係していました。

プログラムのお話になるのでちょっと専門的な言葉が出てくるかもしれないので難しく読みにくくなってしまったらゴメンナサイ。なるべく気をつけて書きます。

EAはTickが更新されるたびに呼び出されます。（これはインジケータも同じです）　そして、時間計算や指標などのチェック、決済エンジンのチェック、既存オーダーのチェックなどを行い、だいぶ後のほうで注文を計ります。これが通常だと思います。

engineeeerは、このような単純な流れではなくちょっと変えていまして、オーダーが入る可能性が高いとき意外は余計なルーチンを呼び出さないようにしています。他の処理のときもそうです。長い関数の結果で判断するようなプログラムを作ると動作が重くなります。Tickが更新された後、EAのstart()関数が終了するまで次のTickは受け付けません。状況に応じて必要な関数だけが呼び出されるようにプログラムすることが高速化・トレードの効率化を図る上で求められます。（未だにあまり褒めてもらえませんが、バックテストの高速化もここが関係しています。他EAと大分差があると思うのですがねｗ）

そして、EA内部でオーダーを出すときの注文価格は、通常Tick更新時の価格を利用することになります。

ここです。うまくスリム化してオーダーを出す関数までたどり着くのですが、それでもやはりTick更新時との時間差があります。よって、オーダーの判断を指標で行った後、そのまま価格データを使用しても、既にブローカーのサーバー側では価格が更新されてしまい価格差が生まれ、オーダーが通らないことになってしまいます。その許容をSlippageに入力してオーダーを出すのですね。
他のEAでは、Slippgageオーバーで約定拒否がかなり起きていました。また、それによって約定拒否を防ぐ対策としてSlippageを10倍？だのと不思議なサポートやレビューが某有名EAでありました^^;

そこでengineeeerは、注文直前に価格データを取り直そうと考えました。そうすれば約定拒否が少しは改善するかなと。それには、　RefreshRates()　という関数を使用します。この関数は、価格データを更新（リフレッシュ）してくれます。

しかし、この関数をオーダー関数前に記述することは半分ナンセンスなことでもあるのです。指標などでオーダーを出すかどうかを計算した価格データとは違う価格をオーダーで使用することになるからです。

そこでengineeeerはリアルで検証をしました。

オーダーに該当する乖離があった場合にその価格がどれくらいの時間有効なことが多いのかを。

その結果、注文直前に　RefreshRates()　を記述したほうが成績が良いということになりました。検証には当時から使用していますFXCM-NYとFXDDを使いました。

ところが、最近様子が変わってきているように思います。画像のようなオーダーを最近良く目にするようになりました。（engineeeerの所持口座の中では、特にAlpariが多いです。FXCM-NYでは未だにほとんど見られません。Alpariのリアル取引結果が他ブローカーと比べて悪い？事もこれが原因していると思われます。）

勝手な推測ですが、

ブローカーが、オーダーできないくらい長短時間の髭を意図的に作り出しているのかもしれません。乖離したときの価格の保持時間があまりにも短すぎるのです。スプレッドが小さいブローカーではこのような巧みなコントロールをしているのでしょうね。

ブローカーもあの手この手と対策を打ってきます。engineeeerも負けてはいられませんｗ　どんどんこちらもバージョンアップを計ります。

この違いは、バックテストでは分かりません。バックテストではstart()関数が終了するまで価格データが更新されないからです。さらには、バックテストではTickデータは勝手に生成されます。どのような計算式なのか知りたいですね。何度テストをしても同じTickの動きになります。

オーダー直前に価格データをリフレッシュするかどうかのパラメータを次バージョンアップで出そうと思います。お楽しみに。

今日でアンケート回答は締め切りです。今週末、集計するのが楽しみです。こちらもお楽しみに！

＜＜新規認定研究員＞＞

投機小僧さん、masakiさん、shinさん、burikiさん、kapiさん、taatanさん、

以上の６名を当サイトの研究員として認定致します。よろしくお願いいたします。