エコノメトリックス:一歩先の予測 - ページ 38

 
-Aleksey-:
この問いに興味があります。テスターチェックを成熟させ、その結果がトレードで単純に51/49、プラスへのピップスで51/49だったとしても、その微々たる統計的優位性を実感するには100トレード日ほど待たなければならない。取引回数を増やし、この時間枠を短くするには - より小さな時間枠に移行する必要があります。そこに手動でお気に入りの番組を使うのは不便なことが多いからです。実は、質問なのですが、何か適切なモデルが見つかった場合、使用しているすべてのE-viewsアルゴリズムをトレーディングロボットのコードに実装するつもりなのでしょうか?2、3年かけてもいいのか?
これを実施しました。コードは記事に 添付しています。
 
faa1947:
これを実施しました。コードは記事に 添付しています。
ありがとうございます、コードで見つけました。E-viewsのMQLプログラムを実行すると、便利ですね、それなら質問はありません。
 
-Aleksey-:
引用のエクスポートと結果の読み取りができます。E-viewsのプログラム自体を手動で起動するのか、それとも自動モードで動作し、データを読み込んで一定時間後に結果を書き込むのか、それとも時間内に書き込まないのか?自動運転モードはどのように構成されているのですか?ただ、プログラムに慣れていないだけです。

自動的に起動します。記事を読むそこにMQL4テスターでのテスト 結果があります。

それがないのであれば、E-viewsがやっていることをすべてMQLのコードやC++のライブラリに移し替えるという質問だったのですが......。

いずれにせよ移植に関する質問です。ただ、今は何を移植すればいいのかわからない。まずモデルを作らなければならない。

 

faa1947:

いずれにせよリスケジュールの問題である。ただ、現時点では、何を移せばいいのかがわからないのです。まずモデルを構築する必要があります。

自動化が進んでいるのに、なぜ移植が必要なのでしょうか?
 
-Aleksey-:
自動化が進んでいるのに、なぜポータビリティの問題があるのか、今一つはっきりしない。
EViewsは恐ろしく遅いワゴンです。
 
faa1947:
EViewsは恐ろしく遅いワゴンです。
数値の遅さについて、例を挙げていただけますか - 興味深いのは......。
 
-Aleksey-:
遅さという点での例を教えてください - 興味深い...
記事中の具体的なEViewsの呼び出し方の話なら。118本のバーでモデルを動かすと、最大で5分かかります。最適化は問題ではない
 
faa1947:
記事中の具体的なEViewsの呼び出しスキームについて言えば118本のバーでモデルを動かすと、最大で5分かかります。最適化は問題ではない
そして、より小さな時間枠に移行するときは、何とかして数ステップ分予測しないと、分単位では1ステップの予測がプレ・スプレッドになる可能性があります。この問題を解決するために、スピードと多段階をどのように考えていますか?
 
-Aleksey-:
また、小さい時間軸に切り替えた場合、数ステップ分の予測をしなければならず、そうでなければ1ステップ分の予測はスプレッドの限界になる可能性があります。この問題を解決するために、スピードと多段階をどのように考えていますか?

予測ステップ数は計算の結果であって、願望ではありません。Kotierはある時点では全く予測できないかもしれませんし、予測できるようになるまで待つ必要があります。

向こうの脅威予測誤差はローソクの長さに匹敵するようになる。これはすでにH1にも表れています。

 
faa1947:

予測ステップ数は計算の結果であって、願望ではありません。Cotierはある時点では全く予測できず、予測できるようになるまで待つ必要があるかもしれません。

一方、脅威は。予測誤差はローソク足の長さと同程度になります。すでにH1では表示されています。

誤差の値にこだわるのは?1000点かもしれません。その使い方や大きさを自分で調節することができます。バーのオープニングではなく、エラー境界付近のペンディングオーダーでエントリーすることができます。平均して、大量の取引において、価格は予測値に近くなり、すなわち、あなたの注文から利益へと離れていくでしょう。信頼区間の境界線だけが上がるか、水平になる--買いへ。しかし、この方法を使うには、信頼区間の 境界を推定するために、少なくとも500-1000ステップの予測をする必要があります。何はともあれ数分、そうでなければ取引はほとんどないでしょう。それに、性能がないと、計算するまで機関車が逃げてしまいますからね :)