ディスカバリーでのMetaTrader 5の実験 - ページ 12 1...5678910111213141516171819...76 新しいコメント Renat Fatkhullin 2013.03.27 16:42 #111 sanderz:Renatさん、QuickBooksとMTで同じ商品の同じTFの実数量が違うのはなぜか教えてください。日々、小さなズレに気づきます。その理由は何でしょうか。以下は今日の例です - 18:42、MT5 - 3267、QUIK - 3270。日中はさらに偏差が蓄積される。(ブローカー開設、リアル口座)これは、ティックフローを集めて比較することで整理する必要があります。少なくとも3辺に誤りがある可能性があります。 михаил потапыч 2013.03.27 17:42 #112 gdtt:やったー!絵がある!絵は映像から。反省して壁にぶつかったり、私の発言に反論する書き込みを待っています。ナスダックの紙、スプレッドはゼロですね。あとは、とにかくそこに注文を納めることです。アパステナを待ちます。 anonymous 2013.03.27 20:09 #113 sanyooooook:ascがbidに等しいということはありえませんので、取引は行われます。ビッドとアスクの差が1ポイント以上ある、または取引が成立していること一回の賭けの中で、すべてが真実なのです :)NBBO(National Best Bid/Offer)というものがあります。NBBOスプレッドがゼロまたはマイナスになることはよくあることです。 Andrey Egorov 2013.03.27 20:38 #114 sanderz: まあ、トレードフィードは水平方向の出来高を把握するのに便利ではあるんだけどね。 諾う Andrey Egorov 2013.03.27 20:40 #115 C-4: テープに直接手を加える人はいない。もし、現在の日のティックが必要であれば、MT5でプログラム的に簡単に蓄積することができます。ティック情報をExpert Advisorに接続すると、Finamのサーバーで利用できます。考えてみれば、0.001%のトレーダーの善意は、システム全体の重みに見合うものではありません。 QuickとTarnzakは、特に負担はありません。 Andrey Egorov 2013.03.27 20:52 #116 Renat:これは、ティックフローを集めて比較することで整理する必要があります。少なくとも3つの側面でエラーが発生する可能性があります。 見積もりサーバーとMT5サーバーに来るデータの速度が異なるため、速いものと遅いものがある可能性があります。 Andrey Egorov 2013.03.27 21:03 #117 C-4:なぜ、全商品の表が必要なのか、よく理解できないのですが?実際、ほとんどの場合、必要な作業時間枠を組み立てるには、あらゆる取引のテーブルが必要です。MT5では、考えられるすべてのタイムフレームがデフォルトで組み込まれています。では、なぜかという疑問が残る。OIについては、実数値だけでなく、本当に役に立つ情報です。いずれはMT5にも登場すると思います。追伸:全取引の表は非常に特殊なケースで使用され、非常にリソースを消費し、データチャネル容量のために要求されるので、そのブローカーはデフォルトでこの情報の送信を無効にすることです。クライアントからの明示的な要求があって初めて、ブローカーはこのテーブルを接続する。もうひとつ、全業務のテーブルを 支持する議論を加えたいと思います。この表は、ティックと数量を取得する以外に、本来、この特定のティックの背後に2人(買い手と売り手)がいることを公式に確認する文書であり、議論の余地がある場合には、この表を参照することができます。 Andrey Egorov 2013.03.27 21:13 #118 私はOtkritieでMT5をテストしています、本当にメガ便利なプラットフォーム、クイックは恐竜のように隣にあります履歴を ファイルからダウンロード するオプションを有効にしてくれれば、すぐにでも行きたい。とりあえずコンバインを使わなければならない) Valerii Mazurenko 2013.03.27 22:03 #119 pronych:また、オンラインソリューションもあります。普遍的なものではないが(「ぶら下がり」注文には向かない-ただし低流動性商品には関係する)、だいたい合っている。(私自身は「テープ」から何かを絞り出すことはできていませんが、だからといって、みんなができないわけではありません)。 Sergey Andreev 2013.03.28 05:09 #120 Y_e_g_o_r: QuikサーバーとMT5サーバーへの情報の到着速度が異なるためと思われます。どうしてでしょう?たとえデータがゆっくり入ってきても、ポイント・イン・タイムの識別子を持っているので、ある時間枠にヒットしなければならないのです。このように、クライアント・サーバー型のアプリケーションをイメージしています。サーバー間の遅延を補正しなければ、端末から始まるサービスは成り立たない。その理由はもうひとつあると思います。そして、もし遅延があったとしても、このデータはセッションが終わる頃には届いているはずです。しかし、日々の出来高の結果は......やはり食い違いがありますね。レナートティックスレッドを集めて比較することで、これを整理する必要があるのです。エラーは少なくとも3つの側面で発生する可能性があります。 この問題を解決するためにはどうすればいいのか。公式バグとして登録する?ブローカーに要求するのか? このような矛盾が、プラットフォームの普及を妨げているように思えてならないのです。ありがとうございました。 1...5678910111213141516171819...76 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
Renatさん、QuickBooksとMTで同じ商品の同じTFの実数量が違うのはなぜか教えてください。日々、小さなズレに気づきます。その理由は何でしょうか。
以下は今日の例です - 18:42、MT5 - 3267、QUIK - 3270。
日中はさらに偏差が蓄積される。
(ブローカー開設、リアル口座)
これは、ティックフローを集めて比較することで整理する必要があります。
少なくとも3辺に誤りがある可能性があります。
やったー!絵がある!絵は映像から。
反省して壁にぶつかったり、私の発言に反論する書き込みを待っています。
ナスダックの紙、スプレッドはゼロですね。あとは、とにかくそこに注文を納めることです。
アパステナを待ちます。
ascがbidに等しいということはありえませんので、取引は行われます。
ビッドとアスクの差が1ポイント以上ある、または取引が成立していること
一回の賭けの中で、すべてが真実なのです :)
NBBO(National Best Bid/Offer)というものがあります。NBBOスプレッドがゼロまたはマイナスになることはよくあることです。
まあ、トレードフィードは水平方向の出来高を把握するのに便利ではあるんだけどね。
テープに直接手を加える人はいない。もし、現在の日のティックが必要であれば、MT5でプログラム的に簡単に蓄積することができます。ティック情報をExpert Advisorに接続すると、Finamのサーバーで利用できます。考えてみれば、0.001%のトレーダーの善意は、システム全体の重みに見合うものではありません。
これは、ティックフローを集めて比較することで整理する必要があります。
少なくとも3つの側面でエラーが発生する可能性があります。
なぜ、全商品の表が必要なのか、よく理解できないのですが?実際、ほとんどの場合、必要な作業時間枠を組み立てるには、あらゆる取引のテーブルが必要です。MT5では、考えられるすべてのタイムフレームがデフォルトで組み込まれています。では、なぜかという疑問が残る。
OIについては、実数値だけでなく、本当に役に立つ情報です。いずれはMT5にも登場すると思います。
追伸:全取引の表は非常に特殊なケースで使用され、非常にリソースを消費し、データチャネル容量のために要求されるので、そのブローカーはデフォルトでこの情報の送信を無効にすることです。クライアントからの明示的な要求があって初めて、ブローカーはこのテーブルを接続する。
もうひとつ、全業務のテーブルを 支持する議論を加えたいと思います。この表は、ティックと数量を取得する以外に、本来、この特定のティックの背後に2人(買い手と売り手)がいることを公式に確認する文書であり、議論の余地がある場合には、この表を参照することができます。
私はOtkritieでMT5をテストしています、本当にメガ便利なプラットフォーム、クイックは恐竜のように隣にあります
履歴を ファイルからダウンロード するオプションを有効にしてくれれば、すぐにでも行きたい。とりあえずコンバインを使わなければならない)
また、オンラインソリューションもあります。
普遍的なものではないが(「ぶら下がり」注文には向かない-ただし低流動性商品には関係する)、だいたい合っている。
(私自身は「テープ」から何かを絞り出すことはできていませんが、だからといって、みんなができないわけではありません)。
QuikサーバーとMT5サーバーへの情報の到着速度が異なるためと思われます。
どうしてでしょう?たとえデータがゆっくり入ってきても、ポイント・イン・タイムの識別子を持っているので、ある時間枠にヒットしなければならないのです。このように、クライアント・サーバー型のアプリケーションをイメージしています。サーバー間の遅延を補正しなければ、端末から始まるサービスは成り立たない。その理由はもうひとつあると思います。
そして、もし遅延があったとしても、このデータはセッションが終わる頃には届いているはずです。しかし、日々の出来高の結果は......やはり食い違いがありますね。
ティックスレッドを集めて比較することで、これを整理する必要があるのです。
エラーは少なくとも3つの側面で発生する可能性があります。
この問題を解決するためにはどうすればいいのか。公式バグとして登録する?ブローカーに要求するのか?
このような矛盾が、プラットフォームの普及を妨げているように思えてならないのです。
ありがとうございました。