カスタムインジケータ（機能-iCustom）使用時のEA加速度理論について - ページ 3

新しいコメント
 
-Aleks-:
つまり、必要な指標をごった煮にすることで、指標を個別に使うよりも早く機能する--相場に関する情報の要求頻度が少なくなる、ということでしょうか。

必須ではありません。計算が重複しないようにする。2つの指標の予備計算が同じであれば、1つにまとめるべきである。すべてのインジケータを1つに貼り付けるだけではいけません。

見積もり依頼に問題はない。リクエストしなくても、勝手にやってくる。

 

インジケーターの再計算にタイムディレイを使用してみた。

int OnCalculate(const int rates_total,
                const int prev_calculated,
                const int begin,
                const double &price[])
  {
 static datetime   prevtime;
  datetime per=15; //задержка секунд
   
   if((TimeCurrent()-prevtime)<per) 
   {
   return(rates_total); //прошло мало секунд - поэтому выходим
   }
 
//--- main cycle  
....................

prevtime=TimeCurrent();
return(rates_total);
 }

OHLSnaM1」でのテストではほとんど差がないので、「all ticks」でのテストの方が早いかもしれません。

 

iCustomの動作についての私の印象（この2ヶ月で何も変わっていない場合）。
iCustomからインジケータを呼び出すと
可能な履歴のすべてのバッファとキャッシュに格納された結果が計算され、キャッシュはパラメータとインジケータ名とバインドされます

次に同じインジケータを同じパラメータで2番目のインデックス配列に対して呼び出すと、結果はキャッシュから返されます（＋新しいヒストリデータに対する補正）。
同じインジケータを呼び出すが、1つのパラメータのみを変更する場合 - 可能な履歴と別のキャッシュの保存のためのすべてのバッファの完全な計算が、新しいパラメータへのバインドが実行されます。


インジケータにパラメータを作成すれば、エキスパートアドバイザーからダウンロードする履歴の量を指定できますが、この呼び出しでは、常に同じ数字、つまり履歴のサイズを渡す必要があります。
(iCustomの最初の呼び出しの速度に影響します)。

可能であれば、ヒストリーサイズの例のように、インジケーターとインジケーターパラメーターの両方で、不要なバッファの計算を削除してみてください。
(キャッシュサイズを小さくする-計算速度を上げる）。

 

皆さん、情報をありがとうございました。

もし、5つのグラフバッファを持つインジケータで、グラフィカルバッファではなく、通常の配列を使用する場合、私が提案したように、グラフィカルバッファを介してデータを出力するために、最適化中のインジケータの速度が速くなり、より少ないメモリは、指標のために割り当てられ、したがってそれを使用して作業するために費やす時間が短くなるので、私は明らかにしたいと思います？

最適化を行い、各パスでインジケーターの設定を 変更しない場合、インジケーターは再計算されますか？

 
-Aleks-:

皆さん、情報をありがとうございました。

もし、5つのグラフバッファを持つインジケータで、グラフィカルバッファではなく、通常の配列を使用する場合、私が提案したように、グラフィカルバッファを介してデータを出力するために、最適化中のインジケータの速度が速くなり、より少ないメモリは、指標のために割り当てられ、したがってそれを使用して作業するために費やす時間が短くなるので、私は明らかにしたいと思います？

最適化を行い、各パスでインジケーターの設定を 変更しない場合、インジケーターは再計算されますか？

バッファは配列で、データを表示するのに便利なだけです。

最適化の際、指標は毎回再計算されます。

 
komposter:

バッファは配列で、データを表示するのに便利なだけです。

配列はわかるのですが、指標を計算するための配列はもっと小さくてもよく、しばしば動的です。

例えば、1000本の履歴の中で、カスタムインジケーターは 5/8/10の3つのSMAを描画します。

標準的なケースでは、ほぼ3000-10-8-5のグラフィックバッファを持つことになります。

そして、私のメソッドを使用すると

SMA(5)を計算するには、4本のバーのサイズ(用語はすみません)の配列が必要です。

SMA(8) を計算するために、7本のバーの配列が必要 です。

SMA(10)を計算するために、9本の バーの配列が必要です（専門用語で すみません）。

で、1000本のバーのチャート配列がある場合、配列が単純に上書きされるため、結果的に1000+4+7+9が必要になります。

どこが間違ってるんだろう？

 
-Aleks-:

皆さん、情報をありがとうございました。

もし、5つのグラフバッファを持つインジケータで、グラフィカルバッファではなく、通常の配列を使用する場合、私が提案したように、グラフィカルバッファを介してデータを出力するために、最適化中のインジケータの速度が速くなり、より少ないメモリは、指標のために割り当てられ、したがってそれを使用して作業するために費やす時間が短くなるので、私は明らかにしたいと思います？

最適化を行い、各パスでインジケーターの設定を 変更しない場合、インジケーターは再計算されますか？

それよりも、インジケータを再度呼び出したときに、メモリセグメント（オーバーレイ）に再ロードされないことを理解することが重要です。他のすべては、それに比べれば大したことはない。
 
-Aleks-:

配列はわかるのですが、指標を計算するための配列はもっと小さくてもよく、しばしば動的です。

例えば、1000本の履歴の中で、カスタムインジケーターは 5/8/10の3つのSMAを描画します。

標準的なケースでは、ほぼ3000-10-8-5のグラフィックバッファを持つことになります。

そして、私のメソッドを使用すると

SMA(5)を計算するには、4本のバーのサイズ(用語はすみません)の配列が必要です。

SMA(8) を計算するために、7本のバーの配列が必要 です。

SMA(10)を計算するために、9本の バーの配列が必要です（専門用語で すみません）。

で、1000本のバーのチャート配列がある場合、配列が単純に上書きされるため、結果的に1000+4+7+9が必要になります。

どこが間違ってるんだろう？

1本のバーで値が必要な場合、バッファは本当に必要ありません。どちらもインジケーターではありません ;)

また、すべてのバーでインジケータ値が必要な場合は、すべてを計算し、新しいバーだけを追加で計算する方が経済的な場合が多いです。
また、すべてのアルゴリズムがSMAのように単純なものではなく、単純に「5本分」計算できるわけではありません。せめてジグザグだけでも見てください。

一番戸惑うのは、答えを実践で生かそうとしないことです。実践的な課題はなく、理論的な仕掛けだけがあるようです。
それなら、なぜ参加するのか理解できない。

 

ところで、MT4は履歴の一部だけを計算することに非常によく対応しており、ループが最後の1000本を通過する場合、バッファ全体のメモリを消費しません（たとえ50000本が「ウィンドウ内」にある場合でも）。

しかし、私はMT5でこの問題に遭遇しました - 最後の100本しかカウントされていない場合でも、50000本のバーすべてのためにメモリを割り当てます。

 
komposter:

1本のバーで値が必要な場合、バッファは本当に必要ありません。インジケーターもありません ;)

なぜ1本のバーなのか？私は、ある指標の値を計算するためには、その指標の全時間履歴を知る必要はほとんどないと言っただけです。だから、バッファ（配列）は計算だけに使い、3つのMAの計算結果は1つのグラフィカルバッファに 格納すると書きました。

ジグザグについてですが、これはもう頭の痛い問題で、いくつもの回答が必要なのですが、別スレッドを開きます。

komposter

一番戸惑うのは、答えを実践で生かそうとしないことです。現実的な課題がなく、理論的な思索だけがあるように感じられるのです。

それなら、なぜ参加するのか理解できない。

私自身はプログラマーではないということです。私の調査は、要求仕様書を作成するのに役立ちます。現在、EAのエンジンの構成要素となるインジケータを開発中ですが、バッファが多いので、インジケータをコードに統合するのではなく、他の方法でEAを高速化する方法を考えています。

そして、このようなアルゴリズムを実際に試して、動作の速さを比較してみたいという人がいればいいなと思ったのです．


komposter

ところで、MT4は、ループが最後の1000本のバーを通過する場合、履歴の一部だけを計算することが完全に可能で、バッファ全体のメモリを食うことはありません（「ウィンドウ」内に50000本があってもです）。

しかし、私はMT5でこの問題に遭遇しました - 私は最後の100を数えるだけであっても、それはすべての50000バーのためにメモリを割り当てます。

5の悲しい事実なんだけど、開発者はこれの神聖な意味を説明しないの？

123456789
新しいコメント