Дело в том, что алгоритм зигзага, скажем так, не расчленяется. Поясню это. Просчет проводится по всей истории. И если мы в какой-то части исправим ошибки, то в районе нулевого бара процесс обработки остается, скажем так, незавершенным. Затрудняюсь подобрать правильные слова. Так вот эта незавершенность в районе нулевого бара и вытаскивает на свет проблему правильного поиска экстремумов.
一つの選択肢です。他にもあります。
最初の光線があります。わかりやすくするために - ゼロバーから来ること。ゼロバーには最大と最小があります。価格が極値を変えずにバーの内側を移動した場合。極限は変化しないので、最初の光線は動かずに止まっているはずです。でも、そうじゃないんです。最初のレイはジャークする。位置を変更します。これは、不安定さの外見的な現れ方を説明したに過ぎない。アルゴリズムが安定的に動作し、ジグザグ動作が依存する市場パラメータ（最後のバーの最大値と最小値）が変化しなければ、最初のレイはもたつくことはないはずです。私自身、この問題で苦労しました。しかし、検索機能の特殊性に気づき、フォーラムに行くことを余儀なくされました。
=================================
指標計算 中にウィンドウを移動（shift,shift+ExtDepth）した場合、新しい極値が出現するのは、新しい価格か古い極値がウィンドウから出たかのどちらかである可能性があります。- 明示的に指定した方が良いと思います。はっきりさせること。言語の説明で言葉の隠れた可能性を探らないように。
そのために、if(highpos!=shift) val=0.0; という行を用意しました。標準コードではどうなっているのか、理解できない。私のバリアントではdangling extremaが消えてしまうことから判断して、正しく行われていないか、全く行われていないかのどちらかです。- この問題に対する私の解答は、if (High[shift]=val) ZigZagBuffer[shift]=val; と if (Low[shift]=val) ZigZagBuffer[shift]=val;
ですが、感覚的には同じことなのです。しかし、それですべての問題が解決するわけではありません。それは、結果との戦い方であって、原因との戦い方ではない。同じように結果と戦おうとした。しかし、最初のレイではうまくいきません。ジグザグアルゴリズムは、言ってみれば、分解しないということです。これを説明します。計算は全履歴に対して行われます。そして、その一部を修正しても、いわばゼロバー付近で処理が不完全なままなのです。適切な言葉が見つからない。つまり、このゼロバー付近の不完全性は、極値を正しく識別する問題を浮き彫りにしているのです。
少し前にウィンドウのパラメータ（shift,shift+ExtDepth）を調整しようとしたことがあります。先日もウィンドウで実験していました。しかし、今のところ結果は出ていません。
この問題は既知であり、理論的に解決されている（私はずっと前にアルゴリズムを頭に叩き込んでいる）。とにかく、他に解決策が見つからなければ、ジグザグアルゴリズムを最適化するつもりです。 1) 最初の実行は、現在のアルゴリズムと同様に履歴全体にわたって行われます 2) 履歴の深いゼロバーからの
各ティックで、ジグザグの2つの極値が検索され、最後の極値は強制的に殺されます。3) からは、ジグザグ計算の標準的な手順が再び実行されます（現在は最後）。4) もし現在の端（ジグザグの尾）が理論的に極値（最後の安値から最高値、またはその逆）になりうるなら、それも極値になる。5) ポイント2)からもう一度新しいティックで
でも、そうはならなかった。1本目のビームがピクリと動く。位置が変わるのです。
まだ見ていないんです。梁の一端を固定したままにしておくのでしょうか？そして、どれを。もし、ゼロバー上にあるのなら、double型の 変数が比較される条件をよく見てみるべきかもしれませんね。 。
これは、言語というより、アルゴリズムに言及しているように思えます。そこで、我々が議論している関数は、実際には極値ではなく、区間内の最大（最小）価格値を求めていることを、本や一部の解説書で注意喚起することが適切であろう。 。
次のティックでポイント4)はポイント2)を通過したファイルで処理されます。
この問題は既知であり、理論的にも解決されている（長い間、アルゴリズムが考えられていた）。
問題は、ジグザグを使用するインジケータを非常に厳しい条件でテストしていることです。分単位で、2-1-1パラメータで。このようなテストは何のために行うのでしょうか？このようなテストは、隠れた欠点をすべてすぐに明らかにしてしまいます。さらに、すべてのタイムフレームで 例外なく機能するインジケータであってほしいという要望もあります。市場はフラクタルなものです。分単位で取引する人はたくさんいます。なぜ、使い慣れたツールを使って小さな時間軸で仕事をする機会を奪わなければならないのでしょうか。
私は自分のバージョンの方が好きです)。整数を扱うことができます。このような倍数（Low[shift]==val 型）の比較を実行すると、ビートが発生することがあります。
今のところ、ダブルでの 作業で困ったことはありません。これらの数値は、変更されずにメモリーに保存されます。しかし、私の比較対象は1つのメモリセルからの値です。ここで問題が発生するとすれば、それはハードウェア（＝コンピューター）の問題です。ハードをどうにかしないといけない。
これは言語ではなく、アルゴリズムのことを指しているように思います。したがって、私たちが議論している関数は、実際には極値ではなく、区間内の最大（最小）価格値を求めているのだということを、本や何らかのコメントで紹介するのが適切でしょう。
私はそれを極限と呼んだだけです。実際には、選択された区間の最大値と最小値である。長い発音です。しかし、その意味は同じです。
CodeBase.mql4.comに長い間ありました。しかし、その描写は非常にわかりにくい。そして矛盾している。夏の間に、スラバはジグザグのコードを微調整したのだと思います。その後、以前の説明文の一部だけがサイトに残されています。
doubleとの 連携は、今のところ困難は生じていません。これらの数値は、変更されずにメモリーに保存されます。そして、私の比較は、1つのメモリロケーションから値を取ります。ここで問題が起きるとすれば、それはハードウェア、つまりコンピュータの問題である。ハードをどうにかしないといけない。