joi: こんにちは、MT4（v4,670）で4GB以上のTickstory FXT-fileを使用した場合のバグを確認しました：20070101-20140719の8GBのEURUSDファイルを持っています。バックテストは20110429で壊れました。私は20110401から20110429まで再び開始しました。結果は同じで、20110429で壊れました。20110428-20110429からも始めてみましたが、同じ結果でした。エラーメッセージはありませんでしたが、最後のオープンポジションは「close at stop」というメッセージで閉じられました。その後、20110101から20140719までのticksotryデータをMT4にエクスポートしたところ（4GBだけ）、うまくいきました。したがって、間違いなくエラーはEAではなく、データにあります。また、FXTファイル、MT4、Tickstoryのいずれかにエラーがありますが、Win 7/8/8.1ではNTFSを使用しており、25テラバイトのファイル制限があるため、間違いなくエラーはありません。この問題をデバッグするためのinforme/askeをお試しください（Metaquotesまたはticksory）！！。より多くのユーザーからの問い合わせがあれば、すぐに解決できるはずです。上記の解決策は、2つまたは3つの部分でテストする場合、それはテストの最初の部分のEAの設定がうまく動作しているが、あなたのEAは、2番目または3番目の時間領域で100％を失う可能性があること、であるため、糞です^^誰か何か解決策？
このようなバックテスト(tick by tick計算)を実行するにはどれくらいの時間がかかりますか？ 全長バックテストを実行するのは便利ですが、ファイルを2年単位に分割した方が早いかもしれません。 そうすると、fxtファイルの生成に時間がかかるので、現在の日付までの過去2年間の生成はかなり早くなります。
Raptorさん、こんにちは。 やっとデータをcsvに再出力できました。 2013年4月22日全体（FXCMサーバー時間7:00～20:00）のティック数をカウントしてみたところ、合計4690ティックで、あなたが見ているものとは全く違っています。
このような場合、スプレッドベット用とCFD用のフィードがあり、私たちはそれぞれ別のものを見ているとしか思えません。
編集 - あなたのチャートをもう一度見たら、朝早い時間のデータがありますね。 FXCMは英国のオープンからしかFTSEを提供していません。 私たちは違う商品を見ているに違いありませんね(笑)。
Raptorさん、こんにちは。 やっとデータをcsvに再出力できました。 2013年4月22日全体（FXCMサーバー時間7:00～20:00）のティック数をカウントしてみたところ、合計4690ティックで、あなたが見ているものとは全く違っています。
このような場合、スプレッドベット用とCFD用のフィードがあり、私たちはそれぞれ別のものを見ているとしか思えません。
編集 - あなたのチャートをもう一度見たら、朝早い時間のデータがありますね。 FXCMは英国のオープンからしかFTSEを提供していません。 私たちは違う商品を見ているに違いありませんね(笑)。
そうですね、良いビジュアル化です。
この写真に写っているのはサーキット走行中のあなたですか？ 何を運転していますか？
そうですね、良いビジュアル化です。
この写真に写っているのはサーキット走行中のあなたですか？ 何を運転していますか？
その後、20110101から20140719までのticksotryデータをMT4にエクスポートしたところ（4GBだけ）、うまくいきました。したがって、間違いなくエラーはEAではなく、データにあります。また、FXTファイル、MT4、Tickstoryのいずれかにエラーがありますが、Win 7/8/8.1ではNTFSを使用しており、25テラバイトのファイル制限があるため、間違いなくエラーではありません。この問題をデバッグするためのinforme/askeをお試しください（Metaquotesまたはticksory）！！。より多くのユーザーからの問い合わせがあれば、すぐに解決できるはずです。上記の解決策は、2つまたは3つの部分でテストする場合、それはテストの最初の部分のEAの設定がうまく動作しているが、あなたのEAは、2番目または3番目の時間領域で100％を失うことができることができるので、糞です^^誰か解決策をお持ちですか？
こんにちは、MT4（v4,670）で4GB以上のTickstory FXT-fileを使用した場合のバグを確認しました：20070101-20140719の8GBのEURUSDファイルを持っています。バックテストは20110429で壊れました。私は20110401から20110429まで再び開始しました。結果は同じで、20110429で壊れました。20110428-20110429からも始めてみましたが、同じ結果でした。エラーメッセージはありませんでしたが、最後のオープンポジションは「close at stop」というメッセージで閉じられました。その後、20110101から20140719までのticksotryデータをMT4にエクスポートしたところ（4GBだけ）、うまくいきました。したがって、間違いなくエラーはEAではなく、データにあります。また、FXTファイル、MT4、Tickstoryのいずれかにエラーがありますが、Win 7/8/8.1ではNTFSを使用しており、25テラバイトのファイル制限があるため、間違いなくエラーはありません。この問題をデバッグするためのinforme/askeをお試しください（Metaquotesまたはticksory）！！。より多くのユーザーからの問い合わせがあれば、すぐに解決できるはずです。上記の解決策は、2つまたは3つの部分でテストする場合、それはテストの最初の部分のEAの設定がうまく動作しているが、あなたのEAは、2番目または3番目の時間領域で100％を失う可能性があること、であるため、糞です^^誰か何か解決策？
このようなバックテスト(tick by tick計算)を実行するにはどれくらいの時間がかかりますか？ 全長バックテストを実行するのは便利ですが、ファイルを2年単位に分割した方が早いかもしれません。 そうすると、fxtファイルの生成に時間がかかるので、現在の日付までの過去2年間の生成はかなり早くなります。
ちなみに、私はTDSを使っているので、ファイルサイズ制限の問題は回避しています。 しかし、バックテストのスピードという点では、ファイルが大きくなると大変だと思いました。 1回の-8年バックテストよりも、2年バックテストを実行して、それをつなぎ合わせる方が簡単でした。また、日中のシグナルとエントリー/イグジットのセットアップにティックデータが必要なストラテジーのためでもあります。 そして、私は可変スプレッドを得ています。 私は今でもcsvファイルを生成するためにtickstoryを使用しています。
[mt4がcsvファイルを直接操作するための独自のティックデータ 履歴インポーターを持っていれば、この無意味なことのほとんどはずっと簡単になります。 彼らはすべての変更を行ったが、バックテストを実行するための正確なティックデータの重要性を無視しています。[mt4を使って定期的にバックテストを行いたいのであれば、Birt's Tick Data Suiteが答えです。
こんにちは、MT4(v4,670)で4GB以上のTickstory FXT-fileで使用すると不具合があることを確認しています。
バグではなく、制限です......ご不満ならサービスデスクに言ってください。
[mt4がcsvファイルを直接扱える独自のティックデータ 履歴インポーターを持っていれば、この無意味なことの大半はもっと簡単になります。 彼らはすべての変更を行ったが、バックテストを行うための正確なティックデータの重要性を軽視しています。[mt4を使って定期的にバックテストを行いたいのであれば、Birt's Tick Data Suiteが答えです。