これは、以前作成した試作ＥＡのバックテストの結果です。
＜Ａ＞、＜Ｂ＞ どちらも同じテスト期間（2008年1月1日～2014年2月19日）実行し、
パラメータや実行条件なども一緒のはずなのですが・・・
なぜか結果が大きく異なります。それは何故か？？？
この２つの唯一の違いは、実行したヒストリカルデータが違うということです。
それぞれＡ社、Ｂ社からダウンロードしたデータで実行しました。
実はこれだけ大きな違いが出たのはカラクリがあって、
Ａのヒストリカルデータは、海外ＦＸ会社からダウンロードしたデータのため、米国時間で日が変わるのに対し、Ｂのヒストリカルデータは国内ＦＸ会社からダウンロードしたデータで、日本時間で日が更新します。
この試作ＥＡでは、過去の日足を参照にして売買するタイプのＥＡであったため、
結果的にここまでの差になったと考えられます。
上の例は極端な話でしたが、実はバックテストを行う上で重要なヒストリカルデータは、
データの提供元によって、差があるというだけでなく、データ自体が壊れていたり、不備があったりすることは多々あり、シストレ開発者の悩みでもあるのです。
データの不具合の割合は例え全体の１％以下であっても、
収益の結果が大きく異なってくることがあるので対策が必要と言えるでしょう。
理想は複数のヒストリカルデータで同じように利益を出すことですが、
Meta4のバックテストは、その動作や結果自体に少々信頼性が低い部分があります。
（例えば、まれにですが、最高値102円、最安値101円の日にも関わらず107円などでオーダーが入ることなどがあります。）
そのため、私の個人的な意見としては、できれば下に記載した仮想（Virtual）取引でのバックテストをお勧めしたいと思います。
『仮想（Virtual）取引でのバックテストのススメ』
ここまでバックテストについて不安を煽るようなことばかり述べてきましたが、
じつはそのようなまれに起こる異常挙動を補完できるようなバックテストの方法があるんです。
これから、その方法をお伝えしますが、
その前に、バックテストでもう一つ問題になっていることがあります。
それはMeta4がＥＡ実行時に自動作成する、「一時ファイル」の容量オーバーによる制限（取引停止）です。
MetaTrader4は実行時に、. FXT形式のファイルと、Logファイルを作成します。
これが非常にデータ量が大きいのですが、困ったことにただ単に大きいだけでなく、
（確か）２Ｇを超えるとその後、取引を停止してしまいます。
そのため、スイングトレード等の中長期のＥＡであれば長期テストをしても問題がないと思われるのですが、
取引数の多いスキャルピング手法等をM1、EveryTickで実行した日には、
下手をすると数日で取引が停止します。
この問題を解決しないことには、取引数の多いＥＡバックテストの長期テストは非常に難しくなります。
私も過去に、この解決策がないかネットを調べたりしましたが、「期間を短く取るしかない」という原始的な解決策しか見当たりませんでした。
そこで、自分自身でフォルダやファイルを書き込み禁止にしてみたりも試しましたが、
その場合、バックテストがスタートすらしないなど、このやっかいな仕組みはmeta4にとって相当深刻な問題でした。
それを見事に解決したのが、私が考案した仮想（Virtual）取引によるバックテストの実施です。
？？一体何のこと？ バックテスト自体が仮想取引じゃないか？
と疑問に思う方が大勢いらっしゃるでしょう。
確かにどちらも仮想取引なのは同じですが、私の言っている仮想（Virtual）取引とは、
Order関数を使わないバックテストのことです。（フォワードテストでも利用可能です。）
え？Order関数を使わずにバックテストが出来るの？
と疑問に思われた方・・・、
はい。大丈夫です。
このやり方を始めたのは、（たぶん）私が最初だと思いますが、このバックテストを行うと、
100万回を超えるオーダーの長期テストでも、期間分割などすることなく、一度の実行で行えることが出来ますし、
しかも、先ほど申し上げたトラブル「一日の値動き範囲外でオーダーが成立してしまう」というまれに起こるOrderSend関数のバグ（動作異常）？も回避出来るのです。
イメージとしては、リアルトレードに限りなく近い（spreadの再現は無理ですが）バックテストと言えそうです。
では、その方法とは具体的にはどうやるのかと言いますと・・・、
Bid値やASK値をtickごとに確認し、Order関数は一切使わずに、計算によって擬似的にオーダーを立てたことにするのです。
こうすれば容量オーバーによってOrder関数での取引が制限されたとしても、その後もBidやAskは値動きは続いているため、バックテスト完了まで、何十万、何百万回でも取引することが可能になります。
※その後の調べで、1,048,576行（約104万回）がexcelが開けるデータの限界であることが判明しました。
ただ、当然OrdersTotal()関数や、OrderProfit()関数も使えなくなりますから、
これらを全部計算によって行うことが必要です。
しかし、手間を掛ける分、こちらのバックテストの方が断然正確な実行結果が出ます。
場合によっては今まで「バックテストでは結果が良いのに、実トレードでは結果が悪い」ということや、
逆に「実トレードでは結果が良いのに、バックテストでは結果が悪い」といった矛盾が解消されるかも知れません。
では実際に仮想（Virtual）取引でバックテストを行った様子をご覧下さい。
下の写真は長期間（2008.1.1～2014.3.3）のバックテスト行っているところです
バックテスト実行後、グラフを開くと空っぽです
レポートを開いても「0」が並んでいます
じつは私の仮想（Virtual）取引では、全てのデータをcsvファイルに出力するようにしています
中身を開くと、この通り、何時何分にオーダー開始し、クローズしたか、
また損益がいくらかなどの情報が出力されています
下の写真では、50万回以上のオーダーでも問題なく記録出来ていることが確認できます
作成ファイルは、csvファイルですが、65536行以上でも保存が可能です
※オーダーNO. が飛んでいるのは、OrderClose順にcsvファイルに書き出したためです。当然オーダー開始順に出力することも可能です
csvファイルに出力されているので、こんな細かなデータ分析も簡単です
Meta4のレポートでは物足りなくなりますね
とまあ、こんな感じです。
一度仮想（Virtual）取引の出力の仕組みさえ作ってしまえば、どんなEAにも組み込みが出来るので大変重宝しますよ。
以上、仮想（Virtual）取引のススメの巻きでした。
他のシストレブログも要チェック !!
FC2 ＦＸ Blog Ranking
FXシステムトレード ブログランキングへ
愛知・名古屋のペット火葬なら訪問火葬の天国への扉へ
