エラー、バグ、質問 - ページ 2780 1...277327742775277627772778277927802781278227832784278527862787...3185 新しいコメント fxsaber 2020.06.14 18:36 #27791 Sergey Dzyublik:プレイまでの手順 こんな仕事ならThank youと言わないわけにはいきませんね。他のバグでも、いつか同じようなものが出てくることを期待しています。 Nikolai Semko 2020.06.14 20:40 #27792 Sergey Dzyublik:泣かないで、久しぶりのお返事 です。残念ながら、出力はゼロどころかマイナスになってしまったが......。 さて、なぜネガティブかというと... 1回目はダメで、2回目もダメで、3回目でわかったんです。 厚かましいと いうか、どうしようもないですね。あなたのせいではありません。 だから、気を悪くしないでね、セルゲイさん。 Nikolai Semko 2020.06.14 20:44 #27793 Sergey Dzyublik:非同期と同期という言葉を何か勘違いしているようですね。 ある関数が非同期であると言う場合、その関数は現在の実行スレッドではなく、他のスレッドで実行されることを意味します。メインスレッドから非同期のChartSetInteger関数を呼び出すと、実際の実行は別のスレッドで行われるため高速に実行できます。 一方、ChartGetIntegerの同期関数を呼び出すと、スレッドの同期が必要となり、さらに時間がかかる場合があります。 この遅延は、並列スレッドがチャート構造データを常に更新している場合（例えば、ユーザーがチャートウィンドウを移動したり、履歴をスクロールしたりした場合）に特に顕著になります。 ほとんどの場合、シンプルさと信頼性のために、そのチャートデータ構造には1つの同期オブジェクトが使用されます。 データの細分化」で実行速度を向上させようとすると、今度はデッドロックが発生したり、データが更新されなかったり、もっと重要なところで速度が低下したりすることがあるんです。 一般的に、すでに安定して動いているものには手を出さないほうがいいと言われています。 Alain Verleyen: いいえ、Getメソッドは同期ですが、グループ化して同時に実行することができるので、メソッド1のGetや100の呼び出しはほとんど同じになります。Setメソッドは非同期ですが、効率化のためにグループ化することも可能です。したがって、「Get / set / get / set / get / set」ではなく、「Set calls together」と「Get calls together」を常にグループ化する方がよい。非同期呼び出しは、呼び出し側のスレッドが関数実行中にブロックされなければ、より効率的ですが、GetとSetを混在させると、これらの利点が失われます。翻訳ではありますが、お役に立てれば幸いです。 Aleksey Mavrin： 私の理解では、Getは要求された結果を返すので、同期です。しかし、キューに非同期Setがある場合、それらと同期する必要があります。キューにGetだけがある場合、遅延は発生しません。 皆さん、ありがとうございました。少しずつコツがわかってきました。 これで、こうした遅れの真の姿が明らかになった。 私の理解では（間違っていたら訂正してください）。 メインスレッドからGetメソッドを呼び出すと、メインスレッドと並行して動作しているチャートスレッド自身への要求があります。しかし、メインスレッドからはSetメソッドで直接制御されており、メインスレッドはすでにチャートスレッドの現在の状態を知っているはずですが、チャートスレッドの現在の状態を知らないだけで、最後のコマンドが実行されたかどうかはわかりません。そのため、これまでのコマンドがすべて実行されるようにするために、この要求が起こるのです。Get メソッドは同期式なので、並列チャートスレッドから応答があるまで待ちます。これが遅延の原因です。 間違っていなければ、疑問が生じる。 メインスレッドがコマンドを実行したことをスレッドに報告し、メインスレッドがコマンドを実行したとマークし、内部チャートテーブルを更新できるようにできないのはなぜですか？そうすれば、メインスレッドにテーブルからのデータを要求することなく、メインスレッドがテーブルからデータを取得することになる。さらに、メインスレッドは、まだ実行されていないコマンドがある、またはすべてのコマンドが実行されたというフラグを渡すことで、チャートの現在の状態を把握することができます。このスキームには遅れはありません。 iCanvasクラスでほぼ同様の機構を実装しています。 このメカニズムを示すインジケータは、ピクセル座標をチャート時刻と価格に関連付ける非常に遅い関数ChartXYToTimePriceが あり、そのアナログがXYToTimePrice関数で、CHARTEVENT_CHART_CHANGEイベントが発生すると内部の静的変数を更新して、チャートパラメータの静的チャートからのデータに基づいて要求パラメータを計算するものです。 ファイル: TestSpeedXY.mq5 16 kb Artyom Trishkin 2020.06.14 21:17 #27794 このトピックに関係のないコメントは、「MQL5 MT5 MetaTrader5初心者からの質問」に移動しました。 Alain Verleyen 2020.06.14 22:07 #27795 Nikolai Semko :皆さん、ありがとうございました。少しずつコツがわかってきました。... これは正しい。また、Renatさんがおっしゃるように、キャッシュシステムはmql側で実装する必要があります。プラットフォーム側で実装することも可能かもしれませんが、そうすると、可能な限り高性能なマルチスレッドアーキテクチャの 実現が危ぶまれます。 Nikolai Semko 2020.06.14 22:17 #27796 Alain Verleyen: これは本当です。また、Renatさんがおっしゃるように、キャッシュシステムはmql側で実装する必要があります。もしかしたらプラットフォーム側で実装できるかもしれませんが、そうすると最も生産性の高いマルチスレッドアーキテクチャの 実現が危ぶまれます。 なるほど。 このキャッシュシステムの実装方法を理解している人は万々歳ですが、理解していない人は最悪です。 Sergey Dzyublik 2020.06.14 22:42 #27797 Nikolai Semko: 例え話にしてみる、そううまくいかないならそうなんだろうけど。 大げさで事実と違うことばかりですが、それでも。 絵の具を決めて持ってくるお客さんがいて、持ってきた絵の具を使ってキャンバスに絵を描くアーティストがいる。 絵の具を持ってきた後は、仕事、家庭、学校、......と、自由に行動してください。 また、いつでもペインターを訪問し、仕上がりを点検することができます。 ただし、点検に来られた時にアーティストが絵を描いている場合は、アーティストが作業を終えるまでお待ちいただくことになります。 絵描きに必要な絵の具をすべて持っていき、絵を描くように命じて、あとは自分の仕事に専念してもらうのが一番いいやり方です。 最後に、必要であれば、キャンバスにアクセスするために、何度でも画家を訪れて検査を受けることができます。 最もサブオプティカルな対話の方法は、画家を一度に1つの絵の具を持って来て、すぐに結果を求め、その都度画家の仕事が完了するのを待つことです。 2009年製と比べて2485で何が問題かというと、 アーティストが近くに移動したことで、検査のための移動時間が短くなり、それがプラスに働き始めたのです。 しかし、副業として「アルバイト」に多くの時間を割くようになった。 以前は同じ頻度で「アルバイト」を受けていたが、今は作家が完成するまでに時間がかかりすぎる。 Alain Verleyen 2020.06.15 01:14 #27798 Nikolai Semko :なるほど。 このキャッシュシステムの実装方法を理解している人は万々歳ですが、理解していない人は最悪です。 右 Nikolai Semko 2020.06.15 01:57 #27799 Sergey Dzyublik: 一番いい方法は、必要な絵の具をすべて画家に持っていき、絵を描くように注文して、それから自分の仕事をすることです。 最後に、必要であれば、何度でもペインターを訪ね、キャンバスに自由に立ち入ることができます。 私の考えでは、アーティストが絵を描き終えたらすぐに、自分のサイトに特定の完成作品を表示して閲覧できるようにすることと、現在のステータス（アルバイトかフリーか）を表示することに同意するのがベストだと思います。 そうすれば、作家を訪問しなくても、どの絵が出来上がっていて、どの絵が出来ていないかが分かりますし、その作家が今、忙しかったり、暇だったりすれば、次の仕事を送ることが出来ます。また、検査で無駄な移動をすることもないでしょう。クライアントとアーティストの双方にとって、時間と神経の節約になるはずです。 Sergey Dzyublik 2020.06.15 12:07 #27800 Nikolai Semko:1）私の心の中で、最良の方法は、アーティストに同意することです、 2）彼はいくつかの定期的な絵を終了するとすぐに、 3）その後、彼はすぐに顧客が閲覧可能である彼らのサイトで行われた特定の仕事を指摘し、 4）だけでなく、その現在の状態のサイト上で指定するに同意 - それは忙しい月光または無料です。 5) そうすれば、クライアントは知ることになる・・・。アーティストが現在忙しかったり、暇だったりすると、次の仕事を送ることができます。 6）また、検査で無駄な旅をすることもないだろう。クライアントとアーティストの双方にとって、時間と神経の節約になるはずです。 1）アーティストはあなたの計画を知らないし、あなたも未来を知らない...。 2）絵画は存在しない。一枚のキャンバスの上に、すべての操作と「いじり」が行われる。 3) アナロジーの中に原作と無関係のプロセスを持ち込むことは、アナロジーが何であるか、何のためにあるのかを理解していないことになる。 4) 画家は未来を知らないし、検査に来る必要があれば、旅の途中で彼の状態が100回変わるかもしれない。 5）絵の具の持ち込みはいつでも可能で、作家の地位や雇用に関係なく、常に同じ時間がかかる。 6）またもや、アナロジーとは何か、何のためにあるのか、本質を理解していない...。 1...277327742775277627772778277927802781278227832784278527862787...3185 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
プレイまでの手順
こんな仕事ならThank youと言わないわけにはいきませんね。他のバグでも、いつか同じようなものが出てくることを期待しています。
泣かないで、久しぶりのお返事 です。
残念ながら、出力はゼロどころかマイナスになってしまったが......。
さて、なぜネガティブかというと...
1回目はダメで、2回目もダメで、3回目でわかったんです。
厚かましいと いうか、どうしようもないですね。あなたのせいではありません。
だから、気を悪くしないでね、セルゲイさん。
非同期と同期という言葉を何か勘違いしているようですね。
ある関数が非同期であると言う場合、その関数は現在の実行スレッドではなく、他のスレッドで実行されることを意味します。
メインスレッドから非同期のChartSetInteger関数を呼び出すと、実際の実行は別のスレッドで行われるため高速に実行できます。
一方、ChartGetIntegerの同期関数を呼び出すと、スレッドの同期が必要となり、さらに時間がかかる場合があります。
この遅延は、並列スレッドがチャート構造データを常に更新している場合（例えば、ユーザーがチャートウィンドウを移動したり、履歴をスクロールしたりした場合）に特に顕著になります。
ほとんどの場合、シンプルさと信頼性のために、そのチャートデータ構造には1つの同期オブジェクトが使用されます。
データの細分化」で実行速度を向上させようとすると、今度はデッドロックが発生したり、データが更新されなかったり、もっと重要なところで速度が低下したりすることがあるんです。
一般的に、すでに安定して動いているものには手を出さないほうがいいと言われています。
いいえ、Getメソッドは同期ですが、グループ化して同時に実行することができるので、メソッド1のGetや100の呼び出しはほとんど同じになります。
Setメソッドは非同期ですが、効率化のためにグループ化することも可能です。
したがって、「Get / set / get / set / get / set」ではなく、「Set calls together」と「Get calls together」を常にグループ化する方がよい。
非同期呼び出しは、呼び出し側のスレッドが関数実行中にブロックされなければ、より効率的ですが、GetとSetを混在させると、これらの利点が失われます。
翻訳ではありますが、お役に立てれば幸いです。
私の理解では、Getは要求された結果を返すので、同期です。しかし、キューに非同期Setがある場合、それらと同期する必要があります。
キューにGetだけがある場合、遅延は発生しません。
皆さん、ありがとうございました。少しずつコツがわかってきました。
これで、こうした遅れの真の姿が明らかになった。
私の理解では（間違っていたら訂正してください）。
メインスレッドからGetメソッドを呼び出すと、メインスレッドと並行して動作しているチャートスレッド自身への要求があります。しかし、メインスレッドからはSetメソッドで直接制御されており、メインスレッドはすでにチャートスレッドの現在の状態を知っているはずですが、チャートスレッドの現在の状態を知らないだけで、最後のコマンドが実行されたかどうかはわかりません。そのため、これまでのコマンドがすべて実行されるようにするために、この要求が起こるのです。Get メソッドは同期式なので、並列チャートスレッドから応答があるまで待ちます。これが遅延の原因です。
間違っていなければ、疑問が生じる。
メインスレッドがコマンドを実行したことをスレッドに報告し、メインスレッドがコマンドを実行したとマークし、内部チャートテーブルを更新できるようにできないのはなぜですか？そうすれば、メインスレッドにテーブルからのデータを要求することなく、メインスレッドがテーブルからデータを取得することになる。さらに、メインスレッドは、まだ実行されていないコマンドがある、またはすべてのコマンドが実行されたというフラグを渡すことで、チャートの現在の状態を把握することができます。このスキームには遅れはありません。
iCanvasクラスでほぼ同様の機構を実装しています。
このメカニズムを示すインジケータは、ピクセル座標をチャート時刻と価格に関連付ける非常に遅い関数ChartXYToTimePriceが あり、そのアナログがXYToTimePrice関数で、CHARTEVENT_CHART_CHANGEイベントが発生すると内部の静的変数を更新して、チャートパラメータの静的チャートからのデータに基づいて要求パラメータを計算するものです。
皆さん、ありがとうございました。少しずつコツがわかってきました。
...これは本当です。また、Renatさんがおっしゃるように、キャッシュシステムはmql側で実装する必要があります。もしかしたらプラットフォーム側で実装できるかもしれませんが、そうすると最も生産性の高いマルチスレッドアーキテクチャの 実現が危ぶまれます。
なるほど。
このキャッシュシステムの実装方法を理解している人は万々歳ですが、理解していない人は最悪です。
例え話にしてみる、そううまくいかないならそうなんだろうけど。
大げさで事実と違うことばかりですが、それでも。
絵の具を決めて持ってくるお客さんがいて、持ってきた絵の具を使ってキャンバスに絵を描くアーティストがいる。
絵の具を持ってきた後は、仕事、家庭、学校、......と、自由に行動してください。
また、いつでもペインターを訪問し、仕上がりを点検することができます。
ただし、点検に来られた時にアーティストが絵を描いている場合は、アーティストが作業を終えるまでお待ちいただくことになります。
絵描きに必要な絵の具をすべて持っていき、絵を描くように命じて、あとは自分の仕事に専念してもらうのが一番いいやり方です。
最後に、必要であれば、キャンバスにアクセスするために、何度でも画家を訪れて検査を受けることができます。
最もサブオプティカルな対話の方法は、画家を一度に1つの絵の具を持って来て、すぐに結果を求め、その都度画家の仕事が完了するのを待つことです。
2009年製と比べて2485で何が問題かというと、
アーティストが近くに移動したことで、検査のための移動時間が短くなり、それがプラスに働き始めたのです。
しかし、副業として「アルバイト」に多くの時間を割くようになった。
以前は同じ頻度で「アルバイト」を受けていたが、今は作家が完成するまでに時間がかかりすぎる。
なるほど。
このキャッシュシステムの実装方法を理解している人は万々歳ですが、理解していない人は最悪です。
一番いい方法は、必要な絵の具をすべて画家に持っていき、絵を描くように注文して、それから自分の仕事をすることです。
最後に、必要であれば、何度でもペインターを訪ね、キャンバスに自由に立ち入ることができます。
私の考えでは、アーティストが絵を描き終えたらすぐに、自分のサイトに特定の完成作品を表示して閲覧できるようにすることと、現在のステータス（アルバイトかフリーか）を表示することに同意するのがベストだと思います。
そうすれば、作家を訪問しなくても、どの絵が出来上がっていて、どの絵が出来ていないかが分かりますし、その作家が今、忙しかったり、暇だったりすれば、次の仕事を送ることが出来ます。また、検査で無駄な移動をすることもないでしょう。クライアントとアーティストの双方にとって、時間と神経の節約になるはずです。
1）私の心の中で、最良の方法は、アーティストに同意することです、
2）彼はいくつかの定期的な絵を終了するとすぐに、
3）その後、彼はすぐに顧客が閲覧可能である彼らのサイトで行われた特定の仕事を指摘し、
4）だけでなく、その現在の状態のサイト上で指定するに同意 - それは忙しい月光または無料です。
5) そうすれば、クライアントは知ることになる・・・。アーティストが現在忙しかったり、暇だったりすると、次の仕事を送ることができます。
6）また、検査で無駄な旅をすることもないだろう。クライアントとアーティストの双方にとって、時間と神経の節約になるはずです。
1）アーティストはあなたの計画を知らないし、あなたも未来を知らない...。
2）絵画は存在しない。一枚のキャンバスの上に、すべての操作と「いじり」が行われる。
3) アナロジーの中に原作と無関係のプロセスを持ち込むことは、アナロジーが何であるか、何のためにあるのかを理解していないことになる。
4) 画家は未来を知らないし、検査に来る必要があれば、旅の途中で彼の状態が100回変わるかもしれない。
5）絵の具の持ち込みはいつでも可能で、作家の地位や雇用に関係なく、常に同じ時間がかかる。
6）またもや、アナロジーとは何か、何のためにあるのか、本質を理解していない...。