ダニの話 - ページ 8 123456789101112131415...26 新しいコメント Yury Kulikov 2015.10.16 04:23 #71 Renat Fatkhullin: よし、カットしよう。 カットする必要はない :) が、CopyTicks用に別の拡張構造を作ってください。 削除済み 2015.10.16 06:25 #72 Renat Fatkhullin:取引所または取引日ゲートウェイから報告された最終取引価格。一般的には、ビッドアスクが 入るCOPY_TICKS_INFO モードをリクエストすることをお勧めします。昨日は注意していなかったのですが、COPY_TICKS_INFOモードを使用すると、買値と売値が一緒になってしまうのでしょうか？つまり、本来はFXのためのモードなのでしょうか？これで挙動はCOPY_TICKS_ALLモードと同じです（つまり、<5000（約）ティック、それ以上の場合は両方の価格を要求した後、別々に入札（asc = 0）、別々にasc（入札= 0）来ることができます）。 また、要求されたよりも少ない量のティックが返されます（COPY_TICKS_INFOモード、COPY_TICKS_ALL - 要求された量と同じだけ返されます）。何かがおかしいと思うのですが・・・。 Maxim Dmitrievsky 2015.10.16 07:20 #73 チークグレイルを 4から5に書き換えてみるか) Renat Fatkhullin 2015.10.16 07:35 #74 Tapochun:昨日は注意していなかったのですが、COPY_TICKS_INFOモードを使用すると、買値と売値は必ず一緒になるのでしょうか？つまり、本質的にはFXのためのモードなのでしょうか？ いいえ、フィンがないだけです。 Renat Fatkhullin 2015.10.16 07:36 #75 Yury Kulikov: カットしない :) ことも可能で、CopyTicks 用に別の拡張構造を作ることも可能です。別建てになることは絶対にありません。そこで、最後に新しいフィールドを設けて展開します。 Vasiliy Sokolov 2015.10.16 11:49 #76 Dmitriy Skub:このようにスライスしてください。 OI、現在の売買注文数等の 情報はFORTS取引プラットフォーム固有のものであり、他のプラットフォーム（FX、取引所）には存在しません。したがって、MqlTickの統一インターフェースにこの情報を含めることは疑わしいと思われる。アクションとtime_countフィールドについては、便利だと思います。 Vasiliy Sokolov 2015.10.16 11:53 #77 Renat Fatkhullin:こんなデータもあります。MqlTickの構造を 拡張する権利があるかどうかについては、まだ一生懸命考えているところです。この構造の大きさで操作する人は、苦しむかもしれません。基本的には、将来のために、すっきりとした切り口で、構造を拡張していけばいいのです。来週の金曜日の発売までには、決定する予定です。MqlTickを使ったことがある人はsizeof(MqlTick)を、そうでない人はこの状況を正しいプログラミングのための良いレッスンになると思います。一般的に：「地獄に 堕ちる」。 Dmitriy Skub 2015.10.16 12:02 #78 Vasiliy Sokolov: OI や現在の売買注文数等の 情報は FORTS 取引所固有のものであり、他の取引所（FX、証券取引所）では利用できません。したがって、MqlTickの統一インターフェースにこの情報を含めることは疑わしいと思われる。また、actionとtime_countのフィールドはどうでしょうか、これらがあると実に便利です。どのような構造であっても違いはありません。今後数年間は、おそらく実現しないかもしれませんが、別の仕組みに含めるかもしれません。私はすでに昔のDDEプロトコルを思い出し始めています。QuickBooksを使って、そこからこの情報を取得する必要があります。正確なtime_count(msまで)がないと、tickの必要性が疑われる。 Vasiliy Sokolov 2015.10.16 12:11 #79 Dmitriy Skub:どの構造を含んでいても差はない。別の構造にすることも可能ですが、どうやら今後数年間は実現しないようです。私はすでに昔のDDEプロトコルを思い出し始めています。そこからQuickにこの情報を提供しなければならないでしょう。正確なtime_count(msまで)がないと、tickの必要性が疑われる。実は、この情報はMT5で公開されており、長い間放送されているのです。SymbolInfoGet*関数で利用可能です。ダニを受け取った瞬間にこの情報を要求し、独自のデータ型 にまとめることを誰も禁じてはいない。また、集中管理されたサーバーのストレージは、常に自分のサーバーよりも信頼性が高いという問題もあります。見積書の保管を考える必要もなく、とても便利なものばかりです。しかし、繰り返しになりますが、決定的にかけがえのないものではありません。 Vasiliy Sokolov 2015.10.16 12:13 #80 Dmitriy Skub:正確なtime_count(msecまで)がなければ、tickの必要性は全く疑問である。 これは全くその通りです!ミリ秒が命です。マイクロ秒というのもありますが、下位ビットにゼロが入るのが普通なので、使い勝手はあまりよくありません。 123456789101112131415...26 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
よし、カットしよう。
取引所または取引日ゲートウェイから報告された最終取引価格。
一般的には、ビッドアスクが 入るCOPY_TICKS_INFO モードをリクエストすることをお勧めします。
昨日は注意していなかったのですが、COPY_TICKS_INFOモードを使用すると、買値と売値が一緒になってしまうのでしょうか？つまり、本来はFXのためのモードなのでしょうか？
これで挙動はCOPY_TICKS_ALLモードと同じです（つまり、<5000（約）ティック、それ以上の場合は両方の価格を要求した後、別々に入札（asc = 0）、別々にasc（入札= 0）来ることができます）。
また、要求されたよりも少ない量のティックが返されます（COPY_TICKS_INFOモード、COPY_TICKS_ALL - 要求された量と同じだけ返されます）。
何かがおかしいと思うのですが・・・。
昨日は注意していなかったのですが、COPY_TICKS_INFOモードを使用すると、買値と売値は必ず一緒になるのでしょうか？つまり、本質的にはFXのためのモードなのでしょうか？
カットしない :) ことも可能で、CopyTicks 用に別の拡張構造を作ることも可能です。
別建てになることは絶対にありません。
そこで、最後に新しいフィールドを設けて展開します。
このようにスライスしてください。
こんなデータもあります。
MqlTickの構造を 拡張する権利があるかどうかについては、まだ一生懸命考えているところです。この構造の大きさで操作する人は、苦しむかもしれません。基本的には、将来のために、すっきりとした切り口で、構造を拡張していけばいいのです。
来週の金曜日の発売までには、決定する予定です。
MqlTickを使ったことがある人はsizeof(MqlTick)を、そうでない人はこの状況を正しいプログラミングのための良いレッスンになると思います。
一般的に：「地獄に 堕ちる」。
OI や現在の売買注文数等の 情報は FORTS 取引所固有のものであり、他の取引所（FX、証券取引所）では利用できません。したがって、MqlTickの統一インターフェースにこの情報を含めることは疑わしいと思われる。また、actionとtime_countのフィールドはどうでしょうか、これらがあると実に便利です。
どのような構造であっても違いはありません。今後数年間は、おそらく実現しないかもしれませんが、別の仕組みに含めるかもしれません。
私はすでに昔のDDEプロトコルを思い出し始めています。QuickBooksを使って、そこからこの情報を取得する必要があります。
正確なtime_count(msまで)がないと、tickの必要性が疑われる。
どの構造を含んでいても差はない。別の構造にすることも可能ですが、どうやら今後数年間は実現しないようです。
私はすでに昔のDDEプロトコルを思い出し始めています。そこからQuickにこの情報を提供しなければならないでしょう。
正確なtime_count(msまで)がないと、tickの必要性が疑われる。
実は、この情報はMT5で公開されており、長い間放送されているのです。SymbolInfoGet*関数で利用可能です。ダニを受け取った瞬間にこの情報を要求し、独自のデータ型 にまとめることを誰も禁じてはいない。
また、集中管理されたサーバーのストレージは、常に自分のサーバーよりも信頼性が高いという問題もあります。見積書の保管を考える必要もなく、とても便利なものばかりです。しかし、繰り返しになりますが、決定的にかけがえのないものではありません。
正確なtime_count(msecまで)がなければ、tickの必要性は全く疑問である。