mql5言語の特徴、微妙なニュアンスとテクニック - ページ 92 1...858687888990919293949596979899...247 新しいコメント fxsaber 2018.07.31 08:40 #911 スラバ マイクロ秒単位で時間を測定するために使用されるGetMicrosecondsCountの2回の呼び出しの間に、ローカルコンピュータの時間が変化する確率はどのくらいか？ゼロではありません。 Renat Fatkhullin 2018.07.31 08:41 #912 TheXpert です。 とても建設的な議論でした。）あと数人の走り屋が永久に削除されるだけで終わり。 もう、禁じ手に殺到し、WinAPI関数の実態をバグと言い張り、我々を非難しようとする輩は許せない。もっと建設的なものがあるのは明らかでしょう。 Konstantin Nikitin 2018.07.31 08:42 #913 fxsaber: ゼロではありません。クライアントとサーバーの交換時間が失われる確率はミリ秒単位で何％か？おそらく、現地時間の 変更確率よりも高いのではないでしょうか。 Konstantin 2018.07.31 09:36 #914 レナト・ファットフーリンあと数人の走り屋を永久に削除してくれればそれでいい。 現実をバグと言い、我々を非難しようと、禁輸措置に殺到する輩をもう許さない。もっと増えるのは明らかです。トピックのやや右側、OnTimer()の方向へ )) どこで読んだか忘れましたが、そこでMQの担当者が、システムを1msの遅延に切り替えて、EventSetMillisecondTimer(...)を使えば、OnTimer()も1ms程度の誤差で動くが、16msにはならない、ということを書いてました。 私の理解が正しければ、OnTimer()はシステム遅延で動作するのですよね？ ps. 昨日servcie-deskにリクエストを送りましたUnprocessed,Started: 2018.07.30 12:52,#2117844, 処理を手伝ってもらえませんか、昨日からずっと掛かっているんです )) Renat Fatkhullin 2018.07.31 09:59 #915 OnTimerは、WinAPI関数GetTickCountで 制御される、システムのWinAPIタイマーのエラーで動作します。この方法は、測定するプロセスへの影響を最小限に抑え、非常に高速で安価な計時方法です。つまり、最終的な仕上がりに大きな影響を与えないということです。 このタイマーの精度は、オペレーティングシステム全体に対して向上させることができますが、CPU消費の増加と、大量のプログラムが開始することによるランダムで大規模な誘発効果の両方を犠牲にしています。 時間をより正確に計るあしをすべらせる一般的なエラーに有効なタイムアウトが、明らかな不正行為に発展することがある。さらに、クールなグリッチをいくつか紹介します。Windowsのシステムタイマーの問題は、20年以上前のことです。しかし、オールドタイマーの行動や精度を変えてしまうのは危険です。 そのため、より正確な新しいタイミングを計る方法が、長い間導入されてきた。しかし、それらはリソースを必要とし、オールドタイマーの完全な代替品として使うには無理があります。 より高精度のタイマーをGetMicrosecondCountで実装しています。GetTickCountよりもコストがかかることを理解した上で、意識的に使用する必要があります。また、正確な計測を行う場合には、GetMicrosecondCountの呼び出しのコストを明示的に考慮する必要がある。 タイマーの使い方を間違えたり、ベンチマークをきれいに保てなかったりすることで、自分も他人も簡単に騙すことができるのです。 TheXpert 2018.07.31 10:05 #916 Renat Fatkhullin: アンバサダーに駆けつけ、WinAPI機能の実態をバグと称して非難しようとする輩はもう許さない。もっと建設的なものがあるのは明らかでしょう。GetMicrosecondsCountはローカルの コンピュータの時間に依存するため、変更すると動作が不十分になる可能性があることをヘルプに書けばよいのです。GetTickCountはそうではありません。 だから、私たちのレベルとあなたのレベルで解決する必要があるのなら、私たちのレベルでやったほうがいいでしょうね。 なぜ禁止する必要があるのですか？ Konstantin 2018.07.31 10:08 #917 レナト・ファットフーリンOnTimerは、WinAPI関数GetTickCountで 制御されるシステムWinAPIタイマと連動します。この方法は、測定するプロセスへの影響を最小限に抑え、非常に高速で安価な計時方法です。つまり、最終的な仕上がりに大きな影響を与えないということです。 このタイマーの精度は、オペレーティングシステム全体に対して向上させることができますが、CPU消費の増加と、大量のプログラムが開始することによるランダムで大規模な誘発効果の両方を犠牲にしています。 時間をより正確に計るあしをすべらせる正常なタイムアウトが、明白な誤動作に変わるものがあるや、クーラーの不具合もあります。Windowsのシステムタイマーの問題は、20年以上前のことです。しかし、オールドタイマーの行動や精度を変えてしまうのは危険です。 そのため、より正確な新しいタイミングを計る方法が長い間導入されてきた。しかし、それらはリソースを必要とし、オールドタイマーの完全な代替品として使うには無理があります。 より高精度のタイマーをGetMicrosecondsCountで実装しています。GetTickCountよりもコストがかかることを理解した上で、意識的に使用する必要があります。また、正確な計測を行う場合には、GetMicrosecondsCountの呼び出しにかかるコストを明示的に考慮する必要がある。 タイマーの使い方を間違えたり、ベンチマークをきれいに保てなかったりすることで、自分も他人も簡単に騙すことができるのです。おっと、MQ代表がシステムタイマーの時間短縮について書いた後、大体そんな感じでしたね )) だから、この方向で何かを変える必要はない、ということに同意します。 ところで、C#のような、あるいは少なくともboostのようなリフレクションへの 発展があるかどうか知りたいのですが？ たとえば、シリアライズ/デシリアライズを実装するとより便利になるでしょう。 Renat Fatkhullin 2018.07.31 10:15 #918 TheXpert: ヘルプに、GetMicrosecondsCountはローカルのコンピュータの時間に依存するので、変更すると十分に動作しない可能性がある、と書いておけばよいでしょう。また、GetTickCountはこれに依存しない。 ヘルプに「GetMicrosecondCount()関数は、MQL5プログラムの開始からの経過 時間である マイクロ秒数を返します」とあります。 それが、「マイクロ秒の数を計測する」とはっきり言ったことです。 に関するマイクロ秒の計測の問題も、多少厄介ではありますが、解決することができます。 なぜ禁止しなければならないのか？禁止しなければならない。 まず、マイクロ秒タイマーは時間の計測に問題がない。2つ目は、「何か言い訳をしたい」とウズウズしている人がいて、その言い訳を最後まで持ち続けることです。 またしても-ルールが変わってしまった。 これ以上、侮辱や「しなければならない」は認めない。前触れもなく掃討を行います。 TheXpert 2018.07.31 10:46 #919 レナト・ファットフーリン ヘルプにそう書いてあります：GetMicrosecondCount()関数は、MQL5プログラム開始からの経過マイクロ秒数を返します。そして、GetTickCount関数 に対して書かれています。 GetTickCount()関数は、システムが起動してから経過したミリ秒数を返します。 フレーズはほぼ同じですが、一方の機能はローカルタイムに依存し、もう一方は依存しません。 Renat Fatkhullin 2018.07.31 10:59 #920 TheXpert です。そして、GetTickCount関数 に対して書かれています。 フレーズはほとんど同じですが、一方の機能はローカルタイムに依存し、もう一方は依存しません。これがWinAPIです。 明示的・暗黙的に "should "フレーズを使用することについての注意点。ご検討ください」ではなく、「メタクォート必須」の使用は、現在では許されないことです。 1...858687888990919293949596979899...247 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
マイクロ秒単位で時間を測定するために使用されるGetMicrosecondsCountの2回の呼び出しの間に、ローカルコンピュータの時間が変化する確率はどのくらいか？
ゼロではありません。
とても建設的な議論でした。）
あと数人の走り屋が永久に削除されるだけで終わり。
もう、禁じ手に殺到し、WinAPI関数の実態をバグと言い張り、我々を非難しようとする輩は許せない。もっと建設的なものがあるのは明らかでしょう。
ゼロではありません。
クライアントとサーバーの交換時間が失われる確率はミリ秒単位で何％か？おそらく、現地時間の 変更確率よりも高いのではないでしょうか。
あと数人の走り屋を永久に削除してくれればそれでいい。
現実をバグと言い、我々を非難しようと、禁輸措置に殺到する輩をもう許さない。もっと増えるのは明らかです。
トピックのやや右側、OnTimer()の方向へ ))
どこで読んだか忘れましたが、そこでMQの担当者が、システムを1msの遅延に切り替えて、EventSetMillisecondTimer(...)を使えば、OnTimer()も1ms程度の誤差で動くが、16msにはならない、ということを書いてました。
私の理解が正しければ、OnTimer()はシステム遅延で動作するのですよね？
ps. 昨日servcie-deskにリクエストを送りましたUnprocessed,Started: 2018.07.30 12:52,#2117844, 処理を手伝ってもらえませんか、昨日からずっと掛かっているんです ))OnTimerは、WinAPI関数GetTickCountで 制御される、システムのWinAPIタイマーのエラーで動作します。この方法は、測定するプロセスへの影響を最小限に抑え、非常に高速で安価な計時方法です。つまり、最終的な仕上がりに大きな影響を与えないということです。
このタイマーの精度は、オペレーティングシステム全体に対して向上させることができますが、CPU消費の増加と、大量のプログラムが開始することによるランダムで大規模な誘発効果の両方を犠牲にしています。
Windowsのシステムタイマーの問題は、20年以上前のことです。しかし、オールドタイマーの行動や精度を変えてしまうのは危険です。
そのため、より正確な新しいタイミングを計る方法が、長い間導入されてきた。しかし、それらはリソースを必要とし、オールドタイマーの完全な代替品として使うには無理があります。
より高精度のタイマーをGetMicrosecondCountで実装しています。GetTickCountよりもコストがかかることを理解した上で、意識的に使用する必要があります。また、正確な計測を行う場合には、GetMicrosecondCountの呼び出しのコストを明示的に考慮する必要がある。
タイマーの使い方を間違えたり、ベンチマークをきれいに保てなかったりすることで、自分も他人も簡単に騙すことができるのです。
アンバサダーに駆けつけ、WinAPI機能の実態をバグと称して非難しようとする輩はもう許さない。もっと建設的なものがあるのは明らかでしょう。
GetMicrosecondsCountはローカルの コンピュータの時間に依存するため、変更すると動作が不十分になる可能性があることをヘルプに書けばよいのです。GetTickCountはそうではありません。
だから、私たちのレベルとあなたのレベルで解決する必要があるのなら、私たちのレベルでやったほうがいいでしょうね。
なぜ禁止する必要があるのですか？
OnTimerは、WinAPI関数GetTickCountで 制御されるシステムWinAPIタイマと連動します。この方法は、測定するプロセスへの影響を最小限に抑え、非常に高速で安価な計時方法です。つまり、最終的な仕上がりに大きな影響を与えないということです。
このタイマーの精度は、オペレーティングシステム全体に対して向上させることができますが、CPU消費の増加と、大量のプログラムが開始することによるランダムで大規模な誘発効果の両方を犠牲にしています。
Windowsのシステムタイマーの問題は、20年以上前のことです。しかし、オールドタイマーの行動や精度を変えてしまうのは危険です。
そのため、より正確な新しいタイミングを計る方法が長い間導入されてきた。しかし、それらはリソースを必要とし、オールドタイマーの完全な代替品として使うには無理があります。
より高精度のタイマーをGetMicrosecondsCountで実装しています。GetTickCountよりもコストがかかることを理解した上で、意識的に使用する必要があります。また、正確な計測を行う場合には、GetMicrosecondsCountの呼び出しにかかるコストを明示的に考慮する必要がある。
タイマーの使い方を間違えたり、ベンチマークをきれいに保てなかったりすることで、自分も他人も簡単に騙すことができるのです。
おっと、MQ代表がシステムタイマーの時間短縮について書いた後、大体そんな感じでしたね ))
だから、この方向で何かを変える必要はない、ということに同意します。
ところで、C#のような、あるいは少なくともboostのようなリフレクションへの 発展があるかどうか知りたいのですが？ たとえば、シリアライズ/デシリアライズを実装するとより便利になるでしょう。
ヘルプに、GetMicrosecondsCountはローカルのコンピュータの時間に依存するので、変更すると十分に動作しない可能性がある、と書いておけばよいでしょう。また、GetTickCountはこれに依存しない。
ヘルプに「GetMicrosecondCount()関数は、MQL5プログラムの開始からの経過 時間である マイクロ秒数を返します」とあります。
それが、「マイクロ秒の数を計測する」とはっきり言ったことです。
に関するマイクロ秒の計測の問題も、多少厄介ではありますが、解決することができます。
なぜ禁止しなければならないのか？
禁止しなければならない。
まず、マイクロ秒タイマーは時間の計測に問題がない。2つ目は、「何か言い訳をしたい」とウズウズしている人がいて、その言い訳を最後まで持ち続けることです。
またしても-ルールが変わってしまった。
これ以上、侮辱や「しなければならない」は認めない。前触れもなく掃討を行います。
ヘルプにそう書いてあります：GetMicrosecondCount()関数は、MQL5プログラム開始からの経過マイクロ秒数を返します。
そして、GetTickCount関数 に対して書かれています。
GetTickCount()関数は、システムが起動してから経過したミリ秒数を返します。
フレーズはほぼ同じですが、一方の機能はローカルタイムに依存し、もう一方は依存しません。
そして、GetTickCount関数 に対して書かれています。
フレーズはほとんど同じですが、一方の機能はローカルタイムに依存し、もう一方は依存しません。
これがWinAPIです。
明示的・暗黙的に "should "フレーズを使用することについての注意点。ご検討ください」ではなく、「メタクォート必須」の使用は、現在では許されないことです。