こんばんは。
最近のリアル取引の履歴を見ていて、「んん？」と感じることがあったので書こうと思います。
下の画像を見てください。
これは、今朝の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さん、
以上の６名を当サイトの研究員として認定致します。よろしくお願いいたします。
engineeeerさん、こんばんは。
RefreshRates()で指標から判断したプライスと異なるプライスを取らせるというのは、おっしゃるように特にスキャルでは影響が大きいものになりそうですね。
この辺りは研究員のデータが活躍することになりそうです。
ブローカーが意図的な操作をしているかどうかは分かりませんが、engineeeerさんのようにEA側で対抗してやろうという姿勢にはまったく同意です。
engineeeerさん、こんばんは。
まだ、非研究員ですが、コメントさせて頂きます。（認定楽しみにしています。^^）
この問題ですが、昨日、ちょうど私も、自作EAを検証している時に同じ問題にぶち当たりました。とてもタイムリーな話題で驚きました。^^;
短時間の検証ですが、RefreshRates() の挙動は、次の値が更新されるまで、つまり Tickが更新されるまで待たされるように思えます。
シグナルを読み取ってから、RefreshRates()⇒Order～() は、次の Start() 直後に Order～() するのと同じではないのかと…。
まだまだ検証不足ですが、私の見解でした。
いいえ、refaerenceを約した限りそうではないと思います。更新されなくてもすぐにfalseが返ってきます。
私が以前作ったEAでEA内にデフォルトループでこの関数を10回以上読むものがありましたが、スクリーン表示はきちんとTick毎に更新されていたことからも更新を待つ関数ではないことがわかります。
Refreshing of data in pre-defined variables and series arrays. This function is used when expert advisor has been calculating for a long time and needs data refreshing. Returns TRUE if data are refreshed, otherwise returns FALSE. The only reason for data cannot be refreshed is that they are the current data of the client terminal.
日本語訳：
定義済み予約変数と直列配列のデータを最新の状態にする。
この関数はEAが計算に長い時間を要したり、データの更新が必要になった時に使われます。
もしデータの更新が成功すればTRUEを、できなかった場合はFALSEを返す。
データの更新ができない時は、クライアント端末内の現在のデータ値となる。
ブローカーによっては、明らかに数ヶ月前と違うのがわかります。FXCM-NYとFXCM-UKをよく比較しているのでわかります。配布時には検証お願い致しますね。
さっそくのレスありがとうございます。
自分でもログ出力（Print()）するプログラムで検証してみました。
確かに、engineeeerさんが仰るとおりの結果でした。次回からちゃんとした結果を出してからコメントさせて頂きます。申し訳ありませんでした。
もうひとつ検証してみました。
Start()が開始してから、１秒毎にRefreshRates()を行いながら現在値をログ出力するプログラムを動かしてみました。このプログラム起動中は、Start() から抜ける事はありません。
結果、当然ながら、正しく現在値を取得できています。ちなみにブローカーはFXDDです。
この検証の意味は、Start() の制御から抜けてしまうと、次の Tick更新までの間、身動きが取れなくなってしまうという事です。（今回の記事の通りですね）
シグナルが確定したのであれば、Order～() が確定するまでは、その Start() から抜けてしまうと（制御を手放すと）勿体無いという事です。
最初の私が作った自作EAが、RefreshRates() で固まってしまったように感じたのは、シグナル発生から、Order～() までの時間が、次の Tick時に実行されていたためでした。つまりバグですね。
普通のEAは、Order～() が、成立するまで、何度もループするような仕組みになっているのでしょうか？
当たり前の事が出来てなくて、次元の低い話になってしまい、申し訳ありません。ひとつ賢くなりました。ありがとうございました。^^
>>この検証の意味は、Start() の制御から抜けてしまうと、次の Tick更新までの間、身動きが取れなくなってしまうという事です。（今回の記事の通りですね）
？？私はそういうことを記事にしたのではないです。なにか勘違いをされているような気がします。確かに、start()から抜けると、次Tick更新までstart()が呼ばれることはありませんが・・・。
>>普通のEAは、Order～() が、成立するまで、何度もループするような仕組みになっているのでしょうか？
Ordersend()関数は、サーバーからの応答を待ちますので、その間は止まります。
そして、その返りがfalseだった場合、同start()内でリトライ注文を出すか、もしくは注文に失敗したことを時間・価格と共にグローバルなレジスタに保存して、次start()の時に許容値（これも別パラメータ）であればリトライするようにします。前者の場合は、拒否ループにはまると他の処理ができない（特に困るの決済か？）ので危険だと私は思います。
プログラムが判らない方が多いのでこの辺で勘弁して下さい。
>>この検証の意味は、Start() の制御から抜けてしまうと、次の Tick更新までの間、身動きが取れなくなってしまうという事です。（今回の記事の通りですね）
> ？？私はそういうことを記事にしたのではないです。
うぅ…。すみません。主旨とズレていますね…。
せっかくなので、記事についてもう少しコメントさせて下さい。
少しEAから離れますが、M1のヒゲは一分間かけてジワジワとヒゲを作る時もあれば、一瞬で行って返ってくるようなヒゲもあります。
リアルで値動きを見てないので推測になりますが、記事の画像にある③は、後者のパターンではないのでしょうか？約定数が非常に少なくて、「指値をしていても普通に買う事が出来ない」というのも考えられませんか？
ブローカーの対策うんぬんの話題から離れてしまいますが、売買取引きとはそういうものではないのでしょうか？
それにしても、ヒゲを捕まえようとするengineeeerさんのEAってすごいですね。アルゴリズムが想像付きません。^^;
その場合は、約定拒否のエラーが返ってきますので確実にわかります。 頑張っていきましょう！
初めまして。以前からとても真剣に拝見させていただいおります。
>>>約定拒否を防ぐ対策としてSlippageを10倍？だのと不思議なサポートやレビューが某有名EAでありました
M16A4のことですね。私もここはどうも信用できません。
私はM16A4を以前購入しましたが、それまで購入に踏み入るまで参考にしていたサイトが二つほどありまして、そのブロガーの名前がなんとEAの説明書PDFタグに残されていました。PCの経験の浅い不慣れな人が説明書を作ったんでしょうね。EAに関しても、プログラムが粗すぎます。バグだらけでした。使える人は使えるEAって感じでしたね。ただ FAPよりは成績・機能が良かったと思います。
インドネシアのプログラマーがどうのって言ってますが、実際運営しているのは皆日本人のようですし、そのプログラマーさんが無料配布していたEAの名前も日本人が付けたような名前ですよね。税金や法律の問題で海外に拠点を置くことにしたのでしょうけど、OFFICEの所在地がフィリピンとなっていますが、ブログを見る限り日本にいることが想像できますし。。。 発売して1ヶ月も無いうちにそのブログのフォーラムに多くあった書き込み者が一斉にいなくなりました。明らかな自演が多かったのですね。運営側からもサポートのメールなどは一度もありませんしね。
つい先日から、PROSPECというEAを発売したみたいですが、あれから数ヶ月経過しているのに、未だ4桁5桁の対策ができていなかったり、ECNの対応ができていなかったりと、とても製品としては深部が欠落していると思います。サポートメール（営業メールが多いですが・・・）が突然来るようになったので以前よりは多少いいのかな？この新EAの中身自体も新通貨ペアはどれもカーブフィッティングにしか見えません（レビューを見ての感想です）。
よくM16との比較を記事にされているので、このような見解を持っている私はengineeer様には特別な期待をしております。是非これからも頑張ってください。
engineeer様のEAは先ほどの対策はすべてカバーしているのでしょうか？重ねてお返事をいただければと思います。
どうもはじめまして。よくこのサイトをROMっていますFXXAと言います。
賛同できるお話が仕事人さんから出たので、私もコメントさせていただきます。
H●●●さんと言う人が経営人の一人であることが、コメントや動きでやはっきりとわかります。ネットでの経営戦略としては不慣れな人には効果的なのかなと思いますが、よくもまぁあんなに売れるものだなぁと感心しております。確かにM16はFAPよりは良かったのかもしれません。それは通貨を絞ったからだと思います。FAPが出たときは既に、USDCADとGBPCHFは混迷していましたから足を引っ張っていました。
それにしても、販売対象が日本人のみでありながら、あのサポートの悪さはないですよね。バグ情報を知っている人だけが得をするという状態になってましたからね。
私はそれからというもの、有料EAを購入する気がおきません。どうにかして自分で作れないものかと参考書を片手に勉強しては見ましたが、プログラムはやはり素質な無いと無理ですね。そんな中、EAラボラトリーでは自分のアイデアが本当にEAに反映されていくのならそれはすごいことだと思っています。それは売りっぱなしとは間逆のことです、タイムリーなサポートも期待できるのではとBBSを見て感じております。EAラボラトリーさんに期待することは、まさにその部分の継続です。
ちょっと慎重になっていますので、もう少し様子を見させていただいてから研究員への申請を行いたいと思います。
これからも耳寄りな情報を期待しております。
一部批判的な文もございますが、誹謗中傷ではございません。顧客からの切実な意見ですのでどうかご理解下さい。
engineeeerさん、こんにちは。
この度は研究員に認定いただき真にありがとうございます。
話の内容が高度でついていけませんが、少しでもお役に立てるように検証を行っていきたいと思います。
今後とも宜しくお願いします。
engineeeerさん
こんばんは、O'Shoです。
初めてこの関数知りました。いつも勉強になります。
しかし、だいぶ議論されてますね。
まあ個人的な感想として、ドレード自体、裁量や自動を問わず速さは様々ですが、動いている的に矢を当てる感じなので、こうやって的に当てる精度を上げるのは重要な事だと思います。
でも、もともと狙っていた的じゃない事になるのは、言われているように、ちょっとした矛盾に少し不満が募りそうですね・・・。
そういう意味で「使う使わない」の選択は、個人個人のリスク面やメンタル面の許容度になりそうですので、そこでパラメータで選択できるところは、いい判断だと思います。
まあ、検証結果から見れば「使う」が正解でしょうから、今度自分のEAにも組み込んでみます。
いつも有用な研究を発表して頂きありがとうございます！！
O'Sho
>>仕事人さん、FXXAさん
HPへのアクセスいつもありがとうございます。
私と同じ考察をしている方がいたのにはちょっとビックリしました。それらのことは感じますし、PDFは私も受け取って驚きましたが、ネット上での販売戦略ではそのようなことはよくあることかなぁと思います。
仰います様にEA自体はFAPTURBOよりも単純に良くできていた感はあります。これも、その通り通貨ペアの問題だと思います。
私は既に同手法のEAを作成し使用していましたので、あちらの対応等を直接感じる暇がありませんでしたが、思い返せばサポートと言うものはありませんでしたね。
私は本職でもそうですが、0と1の話をよくするように、曖昧なのは嫌な性格です。バグなんかもすごく嫌です。バグ報告などがあると、すぐに対応してしまいたくなります。バグを抱えたままではなかなか寝付けません。その日のことはその日のうちにです。また、100の要求には必ず101以上で返します。ただの負けず嫌いの現れかもしれませんがねｗ 私自身のわがままで勝手にやっていることなので、よく「たまには休養を♪」って気遣ってくれる人がいますが、解決したりやり遂げた達成感を味わうのが最高の保養でもあるのですよねｗ 私が楽しくサポートできる範囲でEAラボラトリーの歴史を作って行きたいと思っています。これからも応援をよろしくお願い致します。
>>shin研究員
これからよろしくお願い致しますね。ブログは極力初心者向けに書いて行こうと思いますので今回はすみませんｗ
>>O'Shoさん
そうです。自分にあったセッティングでEA自動トレードを行うべきですね。私の性格上なんでも詰め込んでしまうので、そのうち公開パラメータがウン百にもなって皆さんが困ってしまわないか心配ですｗ