こんばんは。

昨日、夕方にパラランシステムのモニター参加者様へPandeeeemicⅡの配布を開始致しました。
現在何も問題なく順調に稼働しているようです。一安心です。

最初はDemoで構いませんと告げたのですが、ほとんどの研究員がリアル運用です。。。　あまり私のプログラムを過信し過ぎないでくださいねｗ　あと、デフォルトでの運用をなさる方が多く見受けられますが、これもお勧めはできません。現行のPandeeeemic 3.1.0 Beta とは違い、パラランシステム起用にあたり敢えて、内部のパラメータをリセット＆公開しています。この辺はパラメータを弄るのか得意な方はメリットですが、そうでない方はデメリットになろうかと思います。これは、これまで研究員の皆様に行ったアンケートを基にとった策ですので以後お気を付け下さい。
 

もう少しパラランシステムのテストの様子を見て、すべての研究員の方に新ラボのご案内資料をお配りする予定です。新ラボ切り替えはまた少々延期されまして、11月15日辺りでしょうか。全力を挙げて頑張っていきます。

今日は一つご忠告がございます。
新ラボの発表が遅れた理由の一つに、配布しているEA等プログラムのセキュリティ強化及び逆コンパイルやリバースエンジニアリングへの自動対応機能の準備というのがありました。今回パラランシステムのモニター用に配布しているPandeeeemicⅡにもそれは組み込まれており、そのような利用規約の禁止事項を守れない方へは今後厳格な対応を行っていきますので、くれぐれも各利用規約は厳守していただくことをお願いと、お勧めを致します。私も一プログラマーなので、他人の技術は覗いてみたくなるものです。しかし、それを実行に移すこと。さらにはその行為で得られた情報を転用したり、悪意のある行動を起こしたり、またはそれらに利用したりすることは決してあってはならないことです。プログラムとはモノにしてみれば、EAなどは特にたったフロッピーディスク1枚（ドクター中松氏に怒られちゃいますかねｗ）に収まる小さなものですが、それを開発するのにはとてつもない時間がかかっています。その辺の気持ちを察していただければ幸いです。

新たに研究員への申請をされた方の対応を随時行っていきます。しばらくお待ちいただきますようお願い致します。

こんばんは。

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

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

これは、今朝の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さん、

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