Developers.MT5端末の時刻形式について - ページ 4 12345678 新しいコメント hrenfx 2013.03.06 11:31 #31 stringo:GetTickCount?全部？バカにしないでください。お客様の取引ニーズは、GetTickCountの限られた機能を表すものではありません。メタ内のティックレートを測定することの有用性が疑わしいという問題は、GetTickCountの限られた可能性によって完全に解決されます。ここで議論するまでもなく、誰でもすぐに解決できる問題です。一般的なミリ秒と私のニーズに関しては、MT5では役に立たないという私の意見を多かれ少なかれ正当化しました。 Slava 2013.03.06 11:32 #32 Swan:すべての計算は、最後の10（または何）ティックに基づいています...分単位のtick_volumeでは少し違う）周期が一桁長くなる。分単位で進み、6万ミリ秒をtick_volumeのサイズで割ると、調べた分ごとに受信するティックのレートはミリ秒単位で正確になるのでは？現在のローカルコンピュータの時間を ミリ秒で取り（WinAPIツールを使用）、そのミリ秒を現在の累積tick_volumeで割れば、現在のtick arrival rateが得られるのではありませんか？ Slava 2013.03.06 11:33 #33 hrenfx:メタ内のティックレートを測定することの有用性に疑問があったのですが、GetTickCountの限られた機能で完全に解決されました。議論する必要すらない、誰でもすぐに解決できる問題なのです。一般的なミリ秒と私のニーズに関しては、MT5では役に立たないという私の意見を多かれ少なかれ正当化しました。 ミリ秒で現在時刻を取得することは誰も止めない。あとはテクニックの問題ですね。 Aleksey Lebedev 2013.03.06 11:34 #34 hrenfx:しかし、GetTickCountはこの単純な問題を完全に解決してくれます。ミリ秒は関係ない。良いアイデアだと思います。やってみようかな）。でも、ティックタイムのミリ秒なら、もっと簡単でしょう。 Slava 2013.03.06 11:34 #35 現在時刻を ミリ秒単位で取得するfoursのスクリプトも書きました。4のフォーラムで調べてみてください。 Документация по MQL5: Дата и время / TimeCurrent www.mql5.com Дата и время / TimeCurrent - Документация по MQL5 削除済み 2013.03.06 11:37 #36 Swan: 宣伝禁止） デポが消耗しているのに説明がつかないと、人間の心は極端から極端になり、理由を探すが、鏡を見ることを忘れてしまうのである。 hrenfx 2013.03.06 11:39 #37 stringo: ミリ秒で現在時刻を取得することを誰も妨げてはいないのです。あとはテクニックの問題ですね。よく読んで いないのでしょう。P.P.S. 誰もあなたが（GetTickCountを使ったエミュレーションによって）ミリ秒でメタのティックを収集することを止めはしません。それはとてもシンプルなことです。問題は、それが必要なのかどうかということです。GetTickCountの良いところは、MQLでWinAPIを必要としないことです。しかし、ローカルタイムとトレードサーバーの時刻が必ずしも同期していないため、そのメリットはより強くなります。また、ティック到着時刻のデータは、トレードサーバーの時刻に受信する必要があります。そのため、ミリ秒はGetTickCountを使ってエミュレートしています。したがって、常に浮遊している2つの時刻の差を考慮するよりも精度は高くなる。ほら、これは机上の空論ではなく、実践的な取引なのです。 --- 2013.03.06 11:45 #38 hrenfx: そして、ティックの到着時刻のデータは、トレードサーバーの時刻に受信する必要があります。したがって、ミリ秒はGetTickCountによってエミュレートされる。したがって、常に浮動する2回の非同期化を考慮するよりも精度が高くなる。+正解です。端末側で時間を計測するということは、データを送信する際にも遅延が発生するということです。そして、サーバーから保存された時間を持つことは、まさに必要なことなのです。 スタニスラフ でも、すでに注文のシステムには入っているんですよね。トレーダーが取れるように端末に渡せばいい。ティックの場合は、サーバーレベルで問題が解決されていないので、言及することもありません。 削除済み 2013.03.06 11:59 #39 papaklass:ほら、チックが出るということは、次のようなことが起きていることを示している。1.レベル1ビッド(Bid_1)が変更された場合。2.Bid_1に変化はないが、この価格帯の出来高が変化（増加/減少）した場合。Bid_1が変化せず、Bid_2、またはBid_2の価格レベルでの出来高のいずれかが変化した場合。などそして、Bid、Ask、各価格帯の出来高が一緒になっています。 どれだけの種類のデータがあるか、想像がつきますか？そして、そのすべてが1cに凝縮されているのです。1秒間に最大で数十回、このような刻みが発生することがあります。1秒という時間軸は非常に粗い分類であり、ミリ秒という細かい時間軸が必要です。一般論として、それは明確なのでしょうか？は、まあ、だから何...例えばサーバーの遅延とすべてのビットと尋ねるにまだ将来的に来るだろう、彼らはどんなに多くのだった。これが本当にトレードに役立つのか......？ボラティリティを計る以外はまだわからない。ところで、MCがm.s.を追加した場合、ミリ秒単位の刻みが最初のソースからモニター（最終的な視覚ポイント）に到達することは確かなのでしょうか。 Andriy Voitenko 2013.03.06 12:54 #40 記事を読んで、ミリ秒は遊びのためだけに必要なのだと理解しました。100m走の値段をms単位で正確に測れるようになること。sergeev 端末に渡すだけでトレーダーが取れるようになる。それを与えるために、datetime 型は10バイトになり、MqlDateTime構造体はより太く ならなければならない。MQL6を待てば、ミリ秒タイマーやティック履歴など、様々なグッズがそこに登場します。しかし、今更追加する意味があるとは思えません。IMHO 12345678 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
GetTickCount?全部？バカにしないでください。
お客様の取引ニーズは、GetTickCountの限られた機能を表すものではありません。
メタ内のティックレートを測定することの有用性が疑わしいという問題は、GetTickCountの限られた可能性によって完全に解決されます。
ここで議論するまでもなく、誰でもすぐに解決できる問題です。
一般的なミリ秒と私のニーズに関しては、MT5では役に立たないという私の意見を多かれ少なかれ正当化しました。
すべての計算は、最後の10（または何）ティックに基づいています...
分単位のtick_volumeでは少し違う）周期が一桁長くなる。
分単位で進み、6万ミリ秒をtick_volumeのサイズで割ると、調べた分ごとに受信するティックのレートはミリ秒単位で正確になるのでは？
現在のローカルコンピュータの時間を ミリ秒で取り（WinAPIツールを使用）、そのミリ秒を現在の累積tick_volumeで割れば、現在のtick arrival rateが得られるのではありませんか？
メタ内のティックレートを測定することの有用性に疑問があったのですが、GetTickCountの限られた機能で完全に解決されました。
議論する必要すらない、誰でもすぐに解決できる問題なのです。
一般的なミリ秒と私のニーズに関しては、MT5では役に立たないという私の意見を多かれ少なかれ正当化しました。
hrenfx:
しかし、GetTickCountはこの単純な問題を完全に解決してくれます。ミリ秒は関係ない。
良いアイデアだと思います。やってみようかな）。
でも、ティックタイムのミリ秒なら、もっと簡単でしょう。
宣伝禁止）
ミリ秒で現在時刻を取得することを誰も妨げてはいないのです。あとはテクニックの問題ですね。
よく読んで いないのでしょう。
P.P.S. 誰もあなたが（GetTickCountを使ったエミュレーションによって）ミリ秒でメタのティックを収集することを止めはしません。それはとてもシンプルなことです。問題は、それが必要なのかどうかということです。
GetTickCountの良いところは、MQLでWinAPIを必要としないことです。しかし、ローカルタイムとトレードサーバーの時刻が必ずしも同期していないため、そのメリットはより強くなります。また、ティック到着時刻のデータは、トレードサーバーの時刻に受信する必要があります。そのため、ミリ秒はGetTickCountを使ってエミュレートしています。したがって、常に浮遊している2つの時刻の差を考慮するよりも精度は高くなる。
ほら、これは机上の空論ではなく、実践的な取引なのです。
そして、ティックの到着時刻のデータは、トレードサーバーの時刻に受信する必要があります。したがって、ミリ秒はGetTickCountによってエミュレートされる。したがって、常に浮動する2回の非同期化を考慮するよりも精度が高くなる。
+正解です。
端末側で時間を計測するということは、データを送信する際にも遅延が発生するということです。
そして、サーバーから保存された時間を持つことは、まさに必要なことなのです。
スタニスラフ でも、すでに注文のシステムには入っているんですよね。トレーダーが取れるように端末に渡せばいい。
ティックの場合は、サーバーレベルで問題が解決されていないので、言及することもありません。
ほら、チックが出るということは、次のようなことが起きていることを示している。
1.レベル1ビッド(Bid_1)が変更された場合。
2.Bid_1に変化はないが、この価格帯の出来高が変化（増加/減少）した場合。
Bid_1が変化せず、Bid_2、またはBid_2の価格レベルでの出来高のいずれかが変化した場合。
など
そして、Bid、Ask、各価格帯の出来高が一緒になっています。 どれだけの種類のデータがあるか、想像がつきますか？そして、そのすべてが1cに凝縮されているのです。
1秒間に最大で数十回、このような刻みが発生することがあります。1秒という時間軸は非常に粗い分類であり、ミリ秒という細かい時間軸が必要です。一般論として、それは明確なのでしょうか？
は、まあ、だから何...例えばサーバーの遅延とすべてのビットと尋ねるにまだ将来的に来るだろう、彼らはどんなに多くのだった。
これが本当にトレードに役立つのか......？ボラティリティを計る以外はまだわからない。
ところで、MCがm.s.を追加した場合、ミリ秒単位の刻みが最初のソースからモニター（最終的な視覚ポイント）に到達することは確かなのでしょうか。
記事を読んで、ミリ秒は遊びのためだけに必要なのだと理解しました。100m走の値段をms単位で正確に測れるようになること。
sergeev
端末に渡すだけでトレーダーが取れるようになる。
それを与えるために、datetime 型は10バイトになり、MqlDateTime構造体はより太く ならなければならない。
MQL6を待てば、ミリ秒タイマーやティック履歴など、様々なグッズがそこに登場します。しかし、今更追加する意味があるとは思えません。IMHO