テスターは正常に動作していますか? - ページ 5

 
Integer:
ああ...飛びつきましたね...。始値が直前の終値と等しいバーがあることがわかった。MTがどのようなシステムでバーを描画しているかは知らない。開発者にしか説明できないと思います。ぜひとも理解したいと思います。オフクォータ期間があった場合、クォートの出現時にブローカーは同じ価格のティックを与える可能性があります。しかし、これはあくまで推測に過ぎない。



セッション間のギャップやサーバーの再起動がない場合、あるバーの終値と次のバーの始値を一致させることはできません。インポートデータを 使用する場合、可能です。
 
Renat:
整数値
うん...焦りました...。始値が直前の終値と等しいバーがあることがわかった。MTがどのようなシステムでバーを描画しているのか推測しています。開発者にしか説明できないと思います。ぜひとも理解したいと思います。

オフクォータ期間があった場合、クォートの出現時にブローカーは同じ価格のティックを与える可能性があります。しかし、これはあくまで推測に過ぎない。

セッション間のギャップやサーバーの再起動がない場合、あるバーの終値と次のバーの始値を一致させることはできません。インポートデータを使用した場合、発生する可能性があります。 。
これは、分単位の時間枠の任意のデータで発生する - 自分自身のために、私はアルパリからダウンロードしているこれらの引用符、で、私は思う、また参照してください。



ここでは、その一例として、リアルタイムの相場、あなたのデモサーバーを紹介します。ハイライトされたバーとその上の2つのバーを見てください。ハイライトされたバーでは、ティックボリュームの値が0になるはずです。このレベルまでの価格変動は、直前のバーのティックボリュームで 説明されるためです。
1より2つ上のバーが正解です。

そして、これは孤立したケースではないのです。歴史に目を通す。リクオートのせいではないと思います。

という質問が登場したわけです。

頑張ってください。敬具、ウラジスラフ。

ZS すみません - この例は正しくありません - 見る場所を間違えました。これから他で探します。
ZZZYはあなたのスクリプトデータを実行した - 目は再び間違いを犯すことを恐れていた - 私はあなたのサーバーからリアルタイムを受信したものでは本当にありません。だから、質問を削除する。

頑張ってください。ウラジスラフさん、よろしくお願いします。
 
VladislavVG:
レナート
整数
ああ...これは飛びつきましたね...。始値が直前の終値と等しいバーがあることがわかった。MTがどのようなシステムでバーを描画しているかは知らない。開発者にしか説明できないと思います。

オフクォータ期間があった場合、クォートの出現時にブローカーは同じ価格のティックを与える可能性があります。しかし、これはあくまで推測に過ぎない。

セッション間のギャップやサーバーの再起動がなく、rltime データのみが使用される場合、あるバーの終値と次のバーの始値を等しくすることはできません。インポートデータを使用する場合、可能です。
これは、どの分単位のデータでも起こることで、ご自身でも、また私がアルパリからダウンロードしたこれらの相場でも確認できます。

その一例として、リアルタイムクォーツ、デモサーバーをご紹介します。ハイライトされたバーとその上の2つのバーを見てください。ハイライトされたバーでは、ティックボリューム値が0になるはずです。このレベルまでの価格変動は、直前のバーのティックボリュームで説明されるためです。
1より2つ上のバーが正解です。

そして、これは孤立したケースではなく、常に存在するのです。つまり、より正確に言うと、選択したケースでゼロを含むようなバーは一つも見つかっていないのです。歴史を見よ。リクオートのことではないと思います。

という疑問が湧いたわけです。

頑張ってください。敬具、ウラジスラフ。


そして、この例で何を示したかったのでしょうか?1つの気配値(OHLC=1つの価格)からバーがかわされる?
だから、絶対に正常な状態なのです。エラーや不一致はありません。
 
Renat:
VladislavVG:
レナート
整数
ああ...これは飛びつきましたね...。始値が直前の終値と等しいバーがあることがわかった。MTがどのようなシステムでバーを描画しているかは知らない。開発者にしか説明できないと思います。

オフクォータ期間があった場合、クォートの出現時にブローカーは同じ価格のティックを与える可能性があります。しかし、これはあくまで推測に過ぎない。

セッション間のギャップやサーバーの再起動がなく、rltime データのみが使用される場合、あるバーの終値と次のバーの始値を等しくすることはできません。インポートデータを使用する場合、可能です。
そのような良いアイデアがない場合は、右手で問題を解決することができます。

例えば、デモサーバーにリアルタイムの相場が表示されます。ハイライトされたバーとその上の2つのバーを見てください。ハイライトされたバーでは、ティックボリューム値が0になるはずです。このレベルまでの価格変動は、直前のバーのティックボリュームで説明されるためです。
1より2つ上のバーが正解です。

そして、これは孤立したケースではなく、常に存在するのです。つまり、より正確に言うと、選択したケースでゼロを含むようなバーは一つも見つかっていないのです。歴史を見よ。リクオートのことではないと思います。

という疑問が湧いたわけです。

頑張ってください。敬具、ウラジスラフ。


この例で何を示したかったのでしょうか?1つの気配値(OHLC=1つの価格)からバーがかわされる?
だから、これは絶対に正常な状態なんです。エラーや不一致はありません。
はい、すでに前回の投稿を拝見し、訂正させていただきました。

頑張ってください。ウラジスラフさん、よろしくお願いします。
 
VladislavVG:

すみません-この例は間違っています-間違った場所を見たのです。他を探します。 ZZZYはあなたのスクリプトデータを実行した - 目は再び間違いを犯すことを恐れていた - 私はあなたのサーバーからリアルタイムを受信したものでは本当にそのようなことはない。だから、質問を削除する。



はい、私も if(Close[previous]==Open[current]) という条件をチェックするスクリプトを書き、インポートデータにのみ これを発見しました。当社のリレンタルデータには、そのようなものはありません。
 
Renat:
VladislavVG:

すみません-この例は間違っています-間違った場所を見たのです。他を探します。
ZZZYは、スクリプトあなたのデータを走った - 目は再び間違いを犯すことを恐れていた - 私はあなたのサーバーからリアルタイムを受信したものでは本当にそのようなことはありません。そこで取り除かれた疑問。


はい、私もif(Close[previous]==Open[current])の条件をチェックするスクリプトを書きましたが、インポートデータにのみ見つかりました。当社のリレンタルデータには、そのようなものはありません。
このような場合、テスターはテストをひどく歪めるべきだという理解でいいのでしょうか?標準のスクリプトにそのようなチェックを加えるべきかもしれませんね。検証済みのデータを使ってテストした方が良いことは明らかです。しかし、多くのトレーダーはブローカーのデータでシステムをテストするため、誤解が生じる可能性があります。

頑張ってください。ウラジスラフさん、よろしくお願いします。
 
VladislavVG:

はい、私も if(Close[previous]==Open[current]) という条件をチェックするスクリプトを書き、インポートデータにのみこれを発見しました。当社の中継データには、そのようなものはありません。
このような場合、テスターはテストを大きく歪ませなければならないという理解で合っていますか?標準のスクリプトにそのようなチェックを加えるべきかもしれませんね。検証済みのデータを使ってテストした方が良いことは明らかです。しかし、多くのトレーダーはブローカーのデータでシステムをテストするため、誤解が生じる可能性があります。

頑張ってください。敬具 ウラジスラフ
絶対に間違っている。トレーダーの頭の中にある1ピップに対する誤った考えを除いては、歪みはないのです。

テストでは決してダニに頼ってはいけないことを理解してください。逆に、ハーフスプレッド内のノイズの動きは無視した方がいい。ほとんどすべてのトレーダーが、1ピップでも多くと願いながら、些細なピップを重ねています。そして、ほとんどのトレーダーは、「いや、私はピップトレーダーではなく、正確な執行をしたいのだ」と自分を正当化するのです:)。

人々は、絶対に正確で保証された執行を期待して自分を欺き、そして現実にはリクオート され、速いマーケットで取引を行うことが不可能であることに驚きます。それだけでなく、リクオートなどの取引サーバーの応答に全く対応していないものも多くあります。
 
Renat:
VladislavVG:

はい、私も if(Close[previous]==Open[current]) という条件をチェックするスクリプトを書き、インポートデータにのみこれを発見しました。当社の中継データには、そのようなものはありません。
このような場合、テスターはテストを大きく歪ませなければならないという理解で合っていますか?標準のスクリプトにそのようなチェックを加えるべきかもしれませんね。検証済みのデータを使ってテストした方が良いのは明らかです。しかし、多くのトレーダーはブローカーのデータでシステムをテストするため、誤解が生じる可能性があります。

頑張ってください。ウラジスラフさん、よろしくお願いします。
絶対に間違っている。トレーダーの頭の中には、1ピップに対する思い違い以外の歪みはない。

テストでは決してダニに頼ってはいけないことを理解してください。逆に、ハーフスプレッド内のノイズの動きは無視した方がいい。ほとんどすべてのトレーダーが、1ピップでも多くと願いながら、些細なピップを重ねています。そして、ほとんどのトレーダーは、「いや、私はピップトレーダーではなく、正確な執行をしたいのだ」と自分を正当化するのです:)。

人々は、絶対に正確で保証された執行を期待して自分を欺き、そして現実にはリクオートされ、速いマーケットで取引を行うことが不可能であることに驚きます。それだけでなく、リクオートなどの取引サーバーの応答に全く対応していないものも多くあります。
正確な実行を望んだことはありません。そして、ダニについては、よく理解しています。一般的に、私のストップは統計的に有意な反転ゾーンの外側にあり、前のバーの極値から2.5ATR以上離れないようにしています。)つまり、「ピプシング」というアルゴリズムは微塵も存在しないのです。ハーフスプレッドについては、APRで表される値の方がより正確な推定値であるとさえ言える(実践で検証済み)。

そのような「干渉」(と呼ぶことにしましょう)が、テスター自体の品質にどの程度影響するのかを知りたかったのです。上で「戦略そのものは考えていない」と書きましたが
あなたの回答から、それは無理だと結論づけられます。よかったね。

頑張ってください。ウラジスラフさん、よろしくお願いします。
 
Renat писал (а):

リレーデータのみを使用し、セッション間のギャップやサーバーの再起動がない場合、あるバーの終値と次のバーの始値が等しくなることはあり得ません。インポートデータを使用する場合、可能です。

インポートデータではなく、DCからMTに "合法的に "アップロードされたデータです。
 
Integer:
Renat wrote:

もし私たちのリレーデータだけが使われ、セッション間のギャップやサーバーの再起動がなければ、あるバーのクローズは次のバーのオープンと等しくなることはありえません。インポートデータを使用している場合、この現象が起こる可能性があります。

インポートデータはありませんが、DCからMTに "合法的に "アップロードしました。
つまり、トレードサーバーにインポート されているわけです。これは、以前の時代のヒストリカルデータではよくあることです。