Renat: Индикаторы на короткой истории нельзя рассчитывать, так как они являются общим разделяющимся между всеми процессами (терминал, окна, эксперты) ресурсом. Причем на индикаторах действуют множество правил обновления, синхронизации и пересчета рыночного окружения.
Если разделить штатные отображаемые индикаторы и короткие расчетные, то легко будет получить расхождение на длинных кумулятивных индикаторах.
Так же это приведет к опасным костылям на нашей стороне.
Хороший способ - устанавливать 100000 баров на чарт или переходить на х64.
そして、窓の棒はいくらですか？
問題は、TFを切り替えても端末内のメモリが解放されないことです。タスクマネージャーを起動し、チャートにインジケータを 放り込んで、メモリが増えるのを見る。その後、別のTFに切り替えると、再びメモリが増え始めるのがわかります。しかし、論理的には、別のTFに切り替えたとき、前のTFのデータはメモリからアンロードされるはずです。前のTFのデータは削除されないので、再起動しエラーが発生するまでメモリは成長する。チャートからインジケータを外すと、一定時間後にメモリがクリアされることが確認できます。しかし、インジケーターの動作中はクリアされない。
私見：この問題を解決するのがServiceDecです。
ありがとうございます！まずはインジケータを削除してからTFを切り替えてみます。さらに、ウィンドウ内の最大バーを2000000から1000000に減らしました。どうやらMetaDriver は私にそれを伝えようとしているようです。
今のところ、うまくいっているようです。
ありがとうございます、まずはTFを切り替える前にインジケータを削除してみます。さらに、ウィンドウ内のバーの最大数を2000000から1000000に減らしたのですが、どうやらMetaDriver がそれを教えてくれたいようです。
今のところ、うまくいっているようです。
なぜ10万も必要なんだ？ 10万もあれば十分だ それが言いたかったんだ
それは、いかなる深さにもテストを制限するものではありません。
(1)ウィンドウでの表示 (2)インジケータバッファの大きさを制限しているに過ぎない。
私は長い間、意図的に「見える歴史」を限定してきました。その結果、メモリには何の問題もない。
なぜ100万も必要なんだ？ 10万で十分だ、それこそ私がほのめかしたとおりだ。
また、テストの深さを制限するものでは決してありません。
(1)ウィンドウへの表示 (2)インジケーターバッファーの 大きさを制限しているだけです。
私は長い間、意図的に「見える歴史」を制限してきました。その結果、メモリに困ることはなくなりました。
はい、ありがとうございます！InstaForexの108ペアをさらに使いこなそうと思いますので、メモリの問題はありません。
なかなかのトピックですね。MT5の初期に、私はすべてのインジケータに新しい標準 パラメータである「計算するバーの数」を設定すべきだと叫んでいました。
そうでなければ、唯一のリミッターであるTERMINAL_MAXBARSを 得ることができます。これは、 インジケータを使用して リアルタイムで多くのシンボルを分析するExpert Advisorでは受け入れられません。ほとんどの場合（99％）、Expert Advisorでは、最新のバーの数およびすべてを厳密に指定する必要があります。それ以外のことは、私には無理なのです。もちろん、私だけでなく...。
無視された。その結果、Expert Advisorのコードにそのような計算を移したのです。
そうそう！自作パッチの数々も登場。次のようなスマートな記事も書かれ、掲載された。
補助表示用メモリの消費量削減
ジグザグとATRの例によるクラスとしての指標の実装
...
通常表示される指標と短時間計算される指標を分けると、長時間の累積指標でダイバージェンスが発生しやすくなります。
また、これではこちら側が危険な松葉杖をつくことになる。
良い方法は、1つのチャートに100000バーを設定するか、x64に変更することです。
Renat:
Индикаторы на короткой истории нельзя рассчитывать, так как они являются общим разделяющимся между всеми процессами (терминал, окна, эксперты) ресурсом. Причем на индикаторах действуют множество правил обновления, синхронизации и пересчета рыночного окружения.
Если разделить штатные отображаемые индикаторы и короткие расчетные, то легко будет получить расхождение на длинных кумулятивных индикаторах.
Так же это приведет к опасным костылям на нашей стороне.
Хороший способ - устанавливать 100000 баров на чарт или переходить на х64.
一般的には、何も変わりません。MQL5でインジケータ・バッファのサイズを制限できるようにする要望は却下され、使用するインジケータ・バッファの数が多いためにプログラムが大量のメモリを消費し始めると、それは「プログラミング・エラー」と呼ばれます。
「Expert Advisorsでは、最後のバーの数、およびすべてを 厳密に指定する必要があることがほとんどです。余計なお世話ばかり。もちろん私だけでなく・・・"(с)
2) インジケータは、すべてのプロセス（ターミナル、ウィンドウズ、エキスパート）で共有される共有リソースであるため、短い履歴でカウントすることはできません。そして、指標上の市場環境の更新、同期、再計算のルールが多く存在します。
3. 通常の表示指標と短い計算指標を分けると、長い累積指標でダイバージェンスが 起きやすくなります。
また、これではこちら側が危険な松葉杖をつくことになる。
1. 良い方法は、1つのチャートに100000バーを設定するか、x64に切り替えることです。
1.それが、私の仕事です。それでも、妥協はできない。理想を言えば、開発の問題から完全に目を離すと（純粋にユーザーとして）、計算の長さを設定する際に選択できるようにしたいです。図表の場合は全長（ただし、常にではなく、重大で大きな例外がある）、専門家の場合は必要な長さだけである。
2.開発者として、 このアプローチの難しさと同時に限界も理解しています。それでも、メモリ消費は私の問題でもあり、頑なにバックグラウンドに落ち込もうとしないのです。具体的な提案としては、計算期間（と呼ぶことにしましょう）を、他と 同等のパラメーターと 見なすことです。そうすると、すべてのパラメータが似ていて、計算期間が異なる2つの指標は、単に2つの異なる指標ということになります。確かに、理論的には、（ユーザーが計算期間を増やせば）追加費用が発生するような愚かなユースケースもありますが、実際にはあり得ません。 これに従おうとする人がいれば、その人は有罪です。 ちょうど今、すべてのユーザーが「多くのインディケータを開きすぎて、TERMINAL_MAXBARSを減らすことに関心がなかった」ことで有罪になっているようにです。
EMAの計算では、時間の最初からのすべてのバーが使用される ことは知って いますが、ストキャスティクス、RSI、および他の膨大な（優勢な）数の指標では、有機的な 長さで計算が実行されることも知っています。そして、この知識によって、計算期間（MaxBar）を柔軟に選択できるようになりました。 選択肢を与えてくれるだけでいいのです。
インジケーターを開きすぎて、TERMINAL_MAXBARSを減らすことに気をつけなかった」のは、今やすべてのユーザーの責任であるのと同じくらいです。
ああ、特にチャンピオンシップの条件では、TERMINAL_MAXBARSのサイズにまったく影響を与えることができないんだ。
1.してきました。それでも、妥協はできない。理想を言えば、開発の問題から完全に目を離せば（純粋にユーザーとして）、計算の長さを設定する際に選択できるようにしたいです。図表の場合は全長（ただし、常にではなく、重大で大きな例外がある）、専門家の場合は必要な長さだけである。
2.開発者として、 このアプローチの難しさと同時に限界も理解しています。それでも、メモリ消費は私の問題でもあり、頑なにバックグラウンドに落ち込もうとしないのです。具体的な提案としては、計算期間（と呼ぶことにしましょう）を、他と 同等のパラメーターと 見なすことです。そうすると、すべてのパラメータが似ていて、計算期間が異なる2つの指標は、単に2つの異なる指標ということになります。確かに、理論的には、（ユーザーが計算期間を増やした場合）追加費用につながる愚かなバリエーションがありますが、実際にはあり得ません。 誰かがこのバンプを超えたいと思ったら、それは彼自身の責任です。 ちょうど今、すべてのユーザーが「多くの指標を開いて、TERMINAL_MAXBARSを減らすことに注意を払っていなかった」という罪を犯しているように。
EMAの計算では、時間の初めからのすべてのバーが使われる ことは知って いますが、ストキャスティクスやRSI、その他膨大な（優勢な）数の指標では、有機的な 長さで計算されていることも知っています。そして、この知識によって、計算期間（MaxBar）を柔軟に選択できるようになりました。 選択肢を与えてくれるだけでいいのです。
メッセージは明確です。
私たち自身も、資源の消費を抑えたいと考えています。おそらく、このEAで作成されたインジケータにのみ作用 する関数 IndicatorMaxDepth(uint len)が解決策になり得ます。
しかし、問題は、テスト中に蓄積モードの指標のバッファが履歴と一緒に増えてしまい、保存ができなくなることです。指定した深さを維持しながら、リアルタイムでインジケータの履歴をトリミングすることは、美しいグリッチに満ちており、チャートとインジケータ・バッファのバーの同期を数える／慣れたプログラマの心を揺さぶります。
x64に移行するのがベターな選択です。
指標のキャッシュを見直し、最大効率の原則と省メモリーの原則を使い分けるようにします。リジェクトされた指標は、現在のようにしばらく記憶しておくのではなく、すぐにアンロードするようにします。これにより、IndicatorReleaseによる直接的なアンロードで、数百のインジケータを連続して呼び出すことが可能になります。
もちろん、誰かがそれらをアンロードすることなく、市場のスキャンのモードで指標の数百を呼び出す場合は、64ビット版+追加メモリのインストールにまっすぐ行く必要があります。
今、x32に座って大規模なテストをしているのは不思議な感じです。16GBのメモリを搭載したまともなx64コンピュータなら（グラフィックカードやモニターにこだわらず）、15,000ルーブルで購入できるのです。