ちょっとびっくり :)私は、共有し、NOT修辞的な質問をすることを考えました。 - ページ 7 1234567891011121314...25 新しいコメント Dmitry Fedoseev 2011.03.31 06:49 #61 AlexSTAL: ポイントは、やはりテスターの中ではなく、 履歴をダウンロードしたり、接続の失敗が発生するような実状にあります。実際の条件下で、インジケーターのリセットと再計算が発生しても、何ら問題はありません。もうひとつ、疑問が湧いてきました。ほとんどの人はここでやることがないのでは？端末の標準機能をmql5用に書き換えているそうです。おそらく、近いうちに誰かがmql5に関するターミナルを全部書いてくれるでしょう。 Aleksandr Chugunov 2011.03.31 06:51 #62 Integer:実際の条件下で、インジケーターのリセットと再計算が発生しても、何ら問題はありません。もうひとつ、疑問が湧いてきました。ほとんどの人はここでやることがないのでは？端末の標準機能をmql5用に書き換えているそうです。おそらく、近いうちに誰かがmql5に関するターミナルを全部書いてくれるでしょう。もちろん、それほど悪くはないのですが。一つの端末に100個のZUPがある場合（あくまで例です）、大丈夫なのですが・・・。同じ質問が出た。みんな自分の視点だけで話をしたがる、なぜ？ここで使われている指標は1つだけではありません。標準のIndicatorCount関数の影響はまさに殺人的です（個人的に確認済みです）。また、クラスとして実装した場合、通信の不連続性はさらに紫色追伸：あるMAにとっては、もちろん大したことではありません。 Dmitry Fedoseev 2011.03.31 07:05 #63 AlexSTAL:もちろん、大したことではありません。1つの端末に100個のZUPがあると（一例ですが）、たいしたことはないのですが......。同じ疑問が湧いてきた。みんな自分のベル・タワーからだけ主張したがる、なぜ？誰かがいつも、自分の手に余るものを欲しがる。しかし、なぜこんなにたくさん？ インジケータをリセットする問題は、5行のコードで解決できます。最初の小節の時刻を覚えておいてください。もし時刻が変わっていたら、完全な再計算が必要です。最後のバーの番号を格納し、リセットされた場合はこのバーから再計算を続行する、それだけです。自分の鐘楼が正しいということを、論証で何も確認せずに、自分の鐘楼から言うのは憚られる、フルボッコだ。 Aleksandr Chugunov 2011.03.31 07:10 #64 Integer:いつも誰かが自分の手に余るものを欲しがる。でも、なぜそんなに？インジケータがリセットされる問題は、5行のコードで回避することができます。最初の小節の時刻を覚えておいてください。もし時刻が変わっていたら、完全な再計算が必要です。最後のバーの番号を格納し、リセットされた場合はこのバーから再計算を続行する、それだけです。論証で何も確認せず、私の鐘楼から「私の鐘楼は正しい」「それだけだ」と言うのは憚られるのです。独善的なことは言わないでください。聞くだけでなく、人の話を聞くことを学ぶ。途中で話が変わって、アプローチがぼろぼろになることもある。レナートに聞いてみてください。MT4のIndicatorCounted()のエラーは、今になって私のTipsで修正されましたが、正しく書かれたインディケータでも スクラップになってしまいました（特に小さなTFのZigZag）。この件に対するあなたの考え方は言うまでもありませんが...。この状況では完全に間違っているので、反論するつもりもない。 Dmitry Fedoseev 2011.03.31 07:21 #65 AlexSTAL:自分に自信を持つのはやめましょう。聞くだけでなく、人の話を聞くことを学ぶ。途中で話が変わって、アプローチがぼろぼろになることもある。レナートに聞いてみてください。MT4のIndicatorCounted()のエラーは、私のTipsでようやく修正されましたが、正しく書かれたインディケータでも ゴミになります（特に小さなTFでのZigZag）。この状況では完全に間違っているので、反論する気にもならない。リセット時に、バーの数は増えたが、バーの時間は変わっていないか、複数のバーが追加されていないか、などのチェックを追加する。自信過剰というのは、逆で、自信過剰なのは、MQよりカッコイイと思ってる三枚目なんだよ。 Aleksandr Chugunov 2011.03.31 07:29 #66 Integer:リセット時に、バーの数は増えたがバーの時間は変わっていないか、複数のバーが追加されていないか、などのチェックを追加する。自信の有無については、逆に自信過剰なのはお前らだろ、もう3人目はMQよりカッコイイと思ってる奴だ。どのようなチェックですか？シチュエーション古いバーの上に新しいティックが表示されます。バーの総数も、最後のバーのオープン時間も、何も変わって いないのに、同時に過去30本のバーが書き換えられました（開閉値、最大値、最小値もわずかですが変更されています）。アルゴリズムで何をするのか？何もない！このような状況では、単純にうまくいかないでしょう。そして、インジケーターは完全に不正解となるのです前回のビルド以前のMT4では、70%のケースでこの状況に反応しませんでした。しかし、問題を分析した結果、彼らはそれを修正しました。 Stingoはそれについて書きました： https://www.mql5.com/ru/forum/132422自分が人よりかっこいいとは思っていない。それどころか、私はMT4とMT5のすべてのバグを修正することに積極的に協力しています。そして、思い通りにならない仕組みがあることも事実で、万人を満足させることはできない......。 Новая версия MetaTrader 4 Client Terminal 392 - MQL4 форум www.mql5.com Новая версия MetaTrader 4 Client Terminal 392 - MQL4 форум Dmitry Fedoseev 2011.03.31 07:38 #67 履歴の修正前と修正後、どちらが正しいかは興味深い問題です。修正されたバーに戻らなければ、インジケータは履歴が修正されていないものとして動作し続けます。Hrenfxはまさにこの姿勢で、古い歴史を正しいと考え、あなたはその逆をいっているのです。また、バリエーションがなく、通常のprev_calculatedのみを使用するべきだという意見もあります。インジケータが重い場合は、起動時にカウントするバーの本数を制限してください。あとはタンバリンダンス、結果が出るかどうか怪しい。 Aleksandr Chugunov 2011.03.31 07:45 #68 Integer:履歴の修正前と修正後、どちらが正しいかは興味深い問題です。修正されたバーに戻らなければ、インジケータは履歴が修正されていないものとして動作し続けます。Hrenfxはまさにこの姿勢で、古い歴史を正しいと考え、あなたはその逆をいっているのです。また、通常のprev_calculatedだけを、可変に使うべきだという意見もあります。インジケータが重い場合は、起動時にカウントするバーの本数を制限してください。あとは、タンバリンで踊っているようなもので、結果は怪しいものです。 何が正しいか、何が正しくないかは、誰もが自分で決めることです。ZigZagにとって、上記の状況は完全に殺人的です。MAでは、その値に0.0001の偏差が生じますが...。意見はしばしば押し付けられることがある（それが悪いとは言っていない）。一般論として、ここで議論を終わらせることを提案します。机上の空論では埒が明かない。 Renat Fatkhullin 2011.03.31 08:04 #69 ちなみにmt5では、rltimeでヒストリカルベースの整合性を非常に効率的かつ瞬時に制御しているため、prev_countedをゼロにリセットする頻度が高くなります。このカウンターを正しく考慮し、自分なりの最適化で対処しないと、実作業で多くの問題を摘発することになります。分単位の履歴の更新は、サーバー本体から瞬時に端末に配信されます。 テスターでは、インジケータ計算の カスタム最適化は完全に動作しますが、クライアントターミナルでは、履歴の不快なシフトや不正確な計算が発生する可能性があります。 Документация по MQL5: Основы языка / Функции / Функции обработки событий www.mql5.com Основы языка / Функции / Функции обработки событий - Документация по MQL5 Aleksandr Chugunov 2011.03.31 08:06 #70 Renat: ところで、mt5では、rltimeのヒストリカルベースインテグリティを非常に効果的かつ瞬時に制御しており、prev_countedをゼロにリセットする頻度を高めています。このカウンターを正しく考慮し、自分なりの最適化で対処しないと、実作業で多くの問題を摘発することになります。分単位の履歴の更新は、サーバー本体から瞬時に端末に配信されます。 テスターでは、インジケータ計算の カスタム最適化は完全に動作しますが、クライアントターミナルでは、履歴の不快なシフトや不正確な計算が発生する可能性があります。私もそういうことです。prev_countedをゼロにするのではなく、最初の未変化の値にリセットする方法を考えてみてはどうでしょうか？ 1234567891011121314...25 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
ポイントは、やはりテスターの中ではなく、 履歴をダウンロードしたり、接続の失敗が発生するような実状にあります。
実際の条件下で、インジケーターのリセットと再計算が発生しても、何ら問題はありません。
もうひとつ、疑問が湧いてきました。ほとんどの人はここでやることがないのでは？端末の標準機能をmql5用に書き換えているそうです。おそらく、近いうちに誰かがmql5に関するターミナルを全部書いてくれるでしょう。
実際の条件下で、インジケーターのリセットと再計算が発生しても、何ら問題はありません。
もうひとつ、疑問が湧いてきました。ほとんどの人はここでやることがないのでは？端末の標準機能をmql5用に書き換えているそうです。おそらく、近いうちに誰かがmql5に関するターミナルを全部書いてくれるでしょう。
もちろん、それほど悪くはないのですが。一つの端末に100個のZUPがある場合（あくまで例です）、大丈夫なのですが・・・。
同じ質問が出た。みんな自分の視点だけで話をしたがる、なぜ？
ここで使われている指標は1つだけではありません。
標準のIndicatorCount関数の影響はまさに殺人的です（個人的に確認済みです）。また、クラスとして実装した場合、通信の不連続性はさらに紫色
追伸：あるMAにとっては、もちろん大したことではありません。
もちろん、大したことではありません。1つの端末に100個のZUPがあると（一例ですが）、たいしたことはないのですが......。
同じ疑問が湧いてきた。みんな自分のベル・タワーからだけ主張したがる、なぜ？
誰かがいつも、自分の手に余るものを欲しがる。しかし、なぜこんなにたくさん？
インジケータをリセットする問題は、5行のコードで解決できます。最初の小節の時刻を覚えておいてください。もし時刻が変わっていたら、完全な再計算が必要です。最後のバーの番号を格納し、リセットされた場合はこのバーから再計算を続行する、それだけです。
自分の鐘楼が正しいということを、論証で何も確認せずに、自分の鐘楼から言うのは憚られる、フルボッコだ。
いつも誰かが自分の手に余るものを欲しがる。でも、なぜそんなに？
インジケータがリセットされる問題は、5行のコードで回避することができます。最初の小節の時刻を覚えておいてください。もし時刻が変わっていたら、完全な再計算が必要です。最後のバーの番号を格納し、リセットされた場合はこのバーから再計算を続行する、それだけです。
論証で何も確認せず、私の鐘楼から「私の鐘楼は正しい」「それだけだ」と言うのは憚られるのです。
独善的なことは言わないでください。聞くだけでなく、人の話を聞くことを学ぶ。
途中で話が変わって、アプローチがぼろぼろになることもある。レナートに聞いてみてください。
MT4のIndicatorCounted()のエラーは、今になって私のTipsで修正されましたが、正しく書かれたインディケータでも スクラップになってしまいました（特に小さなTFのZigZag）。
この件に対するあなたの考え方は言うまでもありませんが...。
この状況では完全に間違っているので、反論するつもりもない。
自分に自信を持つのはやめましょう。聞くだけでなく、人の話を聞くことを学ぶ。
途中で話が変わって、アプローチがぼろぼろになることもある。レナートに聞いてみてください。
MT4のIndicatorCounted()のエラーは、私のTipsでようやく修正されましたが、正しく書かれたインディケータでも ゴミになります（特に小さなTFでのZigZag）。
この状況では完全に間違っているので、反論する気にもならない。
リセット時に、バーの数は増えたが、バーの時間は変わっていないか、複数のバーが追加されていないか、などのチェックを追加する。
自信過剰というのは、逆で、自信過剰なのは、MQよりカッコイイと思ってる三枚目なんだよ。
リセット時に、バーの数は増えたがバーの時間は変わっていないか、複数のバーが追加されていないか、などのチェックを追加する。
自信の有無については、逆に自信過剰なのはお前らだろ、もう3人目はMQよりカッコイイと思ってる奴だ。
どのようなチェックですか？シチュエーション古いバーの上に新しいティックが表示されます。バーの総数も、最後のバーのオープン時間も、何も変わって いないのに、同時に
過去30本のバーが書き換えられました（開閉値、最大値、最小値もわずかですが変更されています）。
アルゴリズムで何をするのか？何もない！このような状況では、単純にうまくいかないでしょう。そして、インジケーターは完全に不正解となるのです
前回のビルド以前のMT4では、70%のケースでこの状況に反応しませんでした。
しかし、問題を分析した結果、彼らはそれを修正しました。 Stingoはそれについて書きました： https://www.mql5.com/ru/forum/132422
自分が人よりかっこいいとは思っていない。それどころか、私はMT4とMT5のすべてのバグを修正することに積極的に協力しています。
そして、思い通りにならない仕組みがあることも事実で、万人を満足させることはできない......。
履歴の修正前と修正後、どちらが正しいかは興味深い問題です。修正されたバーに戻らなければ、インジケータは履歴が修正されていないものとして動作し続けます。Hrenfxはまさにこの姿勢で、古い歴史を正しいと考え、あなたはその逆をいっているのです。
また、バリエーションがなく、通常のprev_calculatedのみを使用するべきだという意見もあります。インジケータが重い場合は、起動時にカウントするバーの本数を制限してください。あとはタンバリンダンス、結果が出るかどうか怪しい。
履歴の修正前と修正後、どちらが正しいかは興味深い問題です。修正されたバーに戻らなければ、インジケータは履歴が修正されていないものとして動作し続けます。Hrenfxはまさにこの姿勢で、古い歴史を正しいと考え、あなたはその逆をいっているのです。
また、通常のprev_calculatedだけを、可変に使うべきだという意見もあります。インジケータが重い場合は、起動時にカウントするバーの本数を制限してください。あとは、タンバリンで踊っているようなもので、結果は怪しいものです。
何が正しいか、何が正しくないかは、誰もが自分で決めることです。ZigZagにとって、上記の状況は完全に殺人的です。MAでは、その値に0.0001の偏差が生じますが...。
意見はしばしば押し付けられることがある（それが悪いとは言っていない）。
一般論として、ここで議論を終わらせることを提案します。机上の空論では埒が明かない。
テスターでは、インジケータ計算の カスタム最適化は完全に動作しますが、クライアントターミナルでは、履歴の不快なシフトや不正確な計算が発生する可能性があります。
ところで、mt5では、rltimeのヒストリカルベースインテグリティを非常に効果的かつ瞬時に制御しており、prev_countedをゼロにリセットする頻度を高めています。このカウンターを正しく考慮し、自分なりの最適化で対処しないと、実作業で多くの問題を摘発することになります。分単位の履歴の更新は、サーバー本体から瞬時に端末に配信されます。
テスターでは、インジケータ計算の カスタム最適化は完全に動作しますが、クライアントターミナルでは、履歴の不快なシフトや不正確な計算が発生する可能性があります。
私もそういうことです。
prev_countedをゼロにするのではなく、最初の未変化の値にリセットする方法を考えてみてはどうでしょうか？