Язык программирования MQL5 позволяет решать задачи на совершенно новом уровне. Даже те задачи, которые уже вроде имеют решения, благодаря объектно-ориентированному программированию могут подняться на качественно новый уровень. В данной статье специально взят простой пример проверки появления нового бара на графике, который был преобразован в достаточно мощный и универсальный инструмент. Какой? Читайте в статье.
Renatさん、zeroさん - トピックに注目していただき、建設的なご回答をありがとうございました!
次のページ
1.x64について
Renat:
より正しい選択肢は、x64にアップグレードすることです。
...
もちろん、誰かが彼らのアンロードせずに市場スキャンのモードで指標の数百を呼び出す場合は、彼らはまっすぐに64ビット版に行く+追加のメモリをインストールする必要があります。
今、x32に座って大規模なテストをしているのは不思議な感じです。16GBのメモリを搭載したまともなx64コンピュータなら（グラフィックカードやモニターにこだわらず）、15,000ルーブルで購入できます。
x64に変更することは、ぜひとも正しい行動です。でも。一方が他方を排除するものではありません。16ギガでも（持っているので）無駄なデータで浪費したくないんです。他にもMSVSやMatlabなど、並行して作業したいものがあり、その上でもボリュームのある作業を計算したいのです。それを理解した上で、節約する方法を探そうという姿勢がうれしいですね。
2.歴史の始まりが決まっていることについて。
レナート
私たち自身も、資源の消費を抑えたいと考えています。おそらく、このEAで作成されたインジケータにのみ作用 する関数 IndicatorMaxDepth(uint len)で解決できるかもしれません。
しかし、問題は、テスト中に蓄積モードの指標のバッファが履歴と一緒に大きくなり、保存ができなくなることです。
完全に（ほぼ）同意見です。免責事項：多くの場合、最適化は最後のストーリーの小さな塊で行われます。この場合、かなりの節約になる可能性があります。それでも、私はこのオプションが比較的機能していると考えています - あなたが良い仕事または実装の見積もりを持っている場合は特に。 私にとって、例えば、オプションはかなり本格的ではないと思われる - 多くの労働、および結果は根本的ではありません。半分の解決策です。
3.これがヤズだ!:
レナート
設定した深さを維持したまま、rltimeでインジケータの履歴をトリミング することは、美しい不具合を 伴い、 チャートとインジケータバッファのバーの同期を計算/使用して いるプログラマを直接打ち のめすことになります。
No ! チャートバーが同じように同期して 動作するのであれば、問題ないでしょう。言い換えれば、-リングバッファが（たとえサイズが違っても）あれば つねに(強制的に)AsSeriesフラグを使用する -ユーザーに 大規模なトラブルが発生することは想定されていない。
// この場合，ユーザに提示されるヒストリバッファはすべて - インジケータ（すなわち，AsSeries=trueで循環）にすると便利である．
このバリアントでは
(1) インジケータと価格の配列の内部表現がある（あなたの側）：左から右へのインデックス（AsSeries==false）、サイズはユーザーに関係なく、実際に「入力は禁止」されています。
(2)ユーザ側 - すべてのバッファは円形で (実装では。ユーザは仮想的な線形配列を見る)、インデックスは右から左へ (AsSeries==true) で、サイズはユーザが設定する。
ここでユーザーの屋根になるものは？ ありません。範囲外のとき-標準応答 範囲外の配列。
しかし！スキームの普遍性を考慮すると、一度だけ 緊張する必要があります。そして、ベータ版デバッグで「いい感じ」の芽を摘み、その後は、万人幸福で、とても経済的な 建設ができるのです。
インジケータキャッシュの見直しを行い、メモリ節約の原則に対して最大効率の原則を用いるようにします。拒否されたインジケータは、現在のようにしばらくメモリに保持するのではなく、すぐにアンロードされます。これにより、IndicatorReleaseを介した直接的なアンロードで、数百のインジケータを連続して呼び出すことが可能になります。
3.ヤゼル登場!:
No ! チャートバーが同じように動作するのであれば、同期する ことはありません。言い換えれば - リングバッファが（たとえサイズが違っても）あれば つねに(強制的に)AsSeriesフラグを使用する - 大規模なトラブルが発生することは 想定されていません。
// この場合、ユーザに提供されるすべてのヒストリカルバッファをインディカティブ（すなわち、AsSeries=trueで循環的）にすると便利である。
このバリアントでは
(1) インジケータと価格の配列の内部表現がある（あなたの側）：左から右へのインデックス（AsSeries==false）、サイズはユーザーに関係なく、実際に「入力は禁止」されています。
(2)ユーザー側がある - すべてのバッファは円形で (実装では。ユーザーは仮想的な線形配列を見る)、インデックスは右から左へ (AsSeries==true) 、サイズはユーザーによって設定されます。
ここでユーザーの屋根になるものは？ ありません。ユーザーが圏外になった場合-標準反応圏外に配列。
しかし！スキームの普遍性を考慮すると、一度だけ 緊張する必要があります。そして、ベータ版のデバッグで "いいところ "の芽をすべて摘み取る。 そうすれば、みんながハッピーになれるし、建設も非常に経済的に なります。
いいアイデアですね、大賛成です。しかし、それはリングスキームの実装をキャンセルするものではなく、うまく補完するものなのです。テスト条件について説明します。
指標を自動的にアンダーカットした結果、私たちは
テストの条件について説明します。
指標を自動的にアンダーカットする結果、我々は。
1.
はい、許容範囲内です。巨大なMaxBarをインストールしてメモリを浪費することは、誰も禁じていない。
// しかし、インジケータはバーをスキップするためグリッチします。そこが不満の正体です!
// それすらも容認するのか...。:)そうですね...:(
2.
まさにノーとノー！循環型スキームこそが、ヒストリーシフトでのコピーで大きな節約につながるのです。実は、1小節（N本）ずつシフトする場合、正確に1値（N値）コピーする必要があるのです。インデックス仮想化にかかる（ユーザーの）コストはごくわずかです。実際、ストレステストでも検出は難しい（除算の余りは プロセッサが1クロックで計算し、履歴をシフトスルーするごとに仮想バッファの開始位置をシフトさせるため、さらに数クロックかかる）。だから、速度低下はほとんど ない。このスローダウンを検出するのは不可能なほど小さいです。そして、膨大なメモリを節約できる背景には、これらの損失と利得が釣り合わないことがあります。
3.
えーっ、顔って・・・。
なぜか、インジケータが無制限バーで窒息することについては、これだけ踊ったり叫んだりしているのに、グラフィカルオブジェクトのダンスについては一言もないのです。例えばアンリミテッドで超ビッグなアンドリュースのピッチフォークを構築し（例えばMN1で）、ターミナル 設定でバー数を制限し、低いタイムフレームに移動してアンカーポイントまで巻き戻してみてください。その中には、極値からとてつもなくタイムラグがあるものもあるでしょう(これは、3点ともピッチフォークが本物のM1バーの 領域だけにあり、より高い時間枠からの偽物の境界を越えていない間です！)。それはなぜか？どうやら、いくつかの自動結合点の正確なM1値を 計算するために、M1に関する 過去のデータが十分でなかったためと思われます。しかし、過去のデータがどう関係するのか？しかし、ウィンドウに表示されるバーは、そうではありません。つまり、「自分がどこにいるのかよくわからない」点があるのです。
誰か自分で確認してほしい、いや、そんな雑念があるのは僕だけか...。
異変に気づきました!
新しいバーが 形成される瞬間に、以前のバー（例えば10本前のバー）のOpenとCloseの値を読み、5秒後にそれらを再び取得すると、これらの値のいくつかは異なっており、新しいバーが形成されている間にそれらを取得すると、すべてがうまくいきますが、最初の数秒間は何らかの理由でこれらの値が異なっているのです。
わかりやすく説明できたでしょうか。
新しいバーの始まりからOpenとCloseのバーの値を読み込む前に、5秒以上の遅延が必要かどうか教えてください。
ここでは、操作の一例をご紹介します。
上は遅延後に正しくトリガーされたもの、下は新しいバーの直後にエラーでトリガーされたもの、右は6行目のベンチマークです。
おそらく問題は非同期であり、使用中のすべてのツールで新しいバーを 追跡することをお勧めします。
はい、その通りになりました！ありがとうございます。
同様に、オペラも。