MT4 iMAOnArray et iBandsOnArray : effet du nombre d'éléments sur les calculs - page 3

[Vladimir Karputov]

Alexey Viktorov:

Non, Vladimir. C'est un peu faux.

Dans ce cas, vous devez appliquer ArraySetAsSeries(array, false) ; à un tableau de trois cents éléments parmi lesquels iMAOnArray() est considéré. Mais nous ferions mieux d'utiliser CopyOpen() au lieu de la boucle de remplissage du tableau.

Si je comprends bien, dans cette variante, il sera préférable de

La façon dont la tâche a été définie, c'est ainsi que je l'ai démontrée. C'était très bien. Et en plus vous pouvez le faire vous-même :)

[Sergey Efimenko]

Alexey Viktorov:

Non, Vladimir. C'est un peu faux.

Dans ce cas, vous devez appliquer ArraySetAsSeries(array, false) ; à un tableau de trois cents éléments parmi lesquels iMAOnArray() est considéré. Mais nous ferions mieux d'utiliser CopyOpen() au lieu de la boucle de remplissage du tableau.

Si je comprends bien, dans cette variante, il sera préférable de

Montrez-moi donc la variante "fonctionnelle" du code, le code source de l'original est ici, vous essayez de le réduire à 12 éléments au lieu des trois cents demandés, et cela devrait finalement aboutir à 3 tampons indicateurs avec les données spécifiées pour afficher au moins 300 éléments dans le sous-sol, Et ensuite, quand une nouvelle barre arrive, respectivement, 301 et ensuite la valeur sera dessinée, mais n'oubliez pas que dans ce cas, si vous utilisez 0 comme limite pour le calcul, seule la nouvelle barre sera recalculée, et le type de moyenne (lissage) pour le deuxième tampon n'est pas nécessairement SMA, et peut être n'importe lequel des 4 disponibles.

[Dmitry Fedoseev]

Sergey Efimenko:

Voici la question. Si je n'ai pas besoin de calculer l'ensemble du tableau, mais seulement les N derniers éléments.

Je ne comprends pas bien la logique du calcul de ces fonctions lors de la limitation. J'ai un tableau de timeseries (un des buffers de l'indicateur), si je laisse le nombre d'éléments égal à 0, pas de questions, tout est compté et calculé, mais si je diminue le nombre d'éléments impliqués dans le calcul par les mêmes décalages, je n'obtiens que les primaires. Pour simplifier, il y a un tableau de 5000 éléments (barres sur le graphique), pour gagner du temps je dois calculer seulement les 300 derniers, mais quand j'ai spécifié la valeur 300 dans le deuxième paramètre j'ai obtenu 5000-4700 éléments primaires, mais sur le décalage 300-0, et les autres valeurs à un appel ne changent pas. Quel est l'intérêt d'utiliser ce paramètre ?

L'enfer sait. Oublie ça. Si vous devez accélérer les calculs, réduisez le nombre d'éléments calculés dans votre boucle.

if(prev_calculated==0)limit=300; else ...; 

De deux choses l'une : soit c'est impossible, soit il faut une combinaison secrète de séries temporelles, non temporelles, de directions de calcul.

[Sergey Efimenko]

Dmitry Fedoseev:

Je ne sais pas. Oublie ça. Si vous voulez accélérer les calculs, réduisez le nombre d'éléments à calculer dans votre cycle.

De deux choses l'une : soit c'est impossible, soit il faut une combinaison secrète de séries temporelles, de non séries temporelles, de sens de calcul.

Oui, comme je l'ai déjà écrit un peu plus tôt, il n'y a qu'une seule possibilité - utiliser vos propres analogues des fonctions ci-dessus, qui peuvent être utilisées pour calculer au moins un élément.

Le paradoxe de la situation est que si nous faisons un modèle similaire, en superposant la moyenne ou les barres de bollinger sur n'importe quel indicateur (ligne de prix), il n'y aura pas de tel ralentissement du calcul initial de toutes les barres de l'historique, comme lors de l'utilisation de ces fonctions dans le code, lors du redémarrage du terminal ou du changement de TF, donc il n'est pas clair, ce qui prend si longtemps à être calculé dans ces fonctions.

[forexman77]

Dmitry Fedoseev:

Je ne sais pas. Oublie ça. Si vous voulez accélérer les calculs, réduisez le nombre d'éléments à calculer dans votre cycle.

De deux choses l'une : soit c'est impossible, soit il faut une combinaison secrète de séries temporelles, non temporelles, de directions de calcul.

J'ai également utilisé une telle construction.

if (limit > 300)limit=300;

Au fait,"MovingAverages.mqh" est deux fois plus rapide que"iMAOnArray", même l'ancienne version.

https://www.mql5.com/ru/forum/79988

[Dmitry Fedoseev]

Sergey Efimenko:

Oui, comme je l'ai écrit un peu plus tôt, il n'y a qu'une seule option - utiliser nos propres analogues des fonctions mentionnées où il est possible de calculer au moins un élément.

Le paradoxe de la situation est que si nous faisons un modèle similaire en attachant la MA et les bandes de Bollinger à n'importe quel indicateur (ligne de prix), nous ne verrons pas un tel ralentissement du calcul initial de toutes les barres de l'historique, comme lors de l'utilisation de ces fonctions dans le code, lors du redémarrage du terminal ou du changement de TF, donc il n'est pas clair ce qui prend si longtemps à calculer dans ces fonctions.

Est-ce qu'il y a un ralentissement même en utilisant iMAOnArray? Il ne doit pas en être ainsi. Comme vous l'étiez, il y a eu un ralentissement à partir de StdOnArray (ou BandsOnArray, je ne me souviens plus) les développeurs n'ont pas admis l'existence du bug pendant longtemps. Puis, soudainement, il a été réparé et il a fonctionné rapidement. Qui sait, peut-être que le bug est revenu. Si iMAOnArray() provoque également des ralentissements notables, il s'agit d'un bug. Il semble qu'il y ait eu des discussions à ce sujet il y a quelques mois... Mais c'est toujours là, apparemment.

[Sergey Efimenko]

Dmitry Fedoseev:

Le ralentissement provient-il même de l'utilisation de iMAOnArray? Ça ne devrait pas être comme ça. Comme vous l'avez été à une époque, il y avait un ralentissement dû à StdOnArray, les développeurs n'ont pas reconnu le bug pendant longtemps. Puis ils l'ont soudainement réparé et ça a marché rapidement. Qui sait, peut-être que le bug est revenu. Si iMAOnArray() provoque également des ralentissements notables, il s'agit d'un bug. Il semble qu'il y ait eu des discussions à ce sujet il y a quelques mois... Mais c'est toujours là, apparemment.

Il est difficile de juger si cela "ralentit beaucoup" ou si c'est acceptable, car tout dépend de la longueur du graphique (nombre de barres), le piège est que pour l'optimisation, il suffit de calculer un peu, mais limiter la longueur du calcul est en fait impossible.

[forexman77]

Sergey Efimenko:
Il est difficile de juger si c'est trop lent ou non, car tout dépend de la longueur du graphique (nombre de barres), le problème est que pour l'optimisation, il suffit de calculer un petit peu, et on ne peut pas limiter la durée du calcul par le calcul réel.

Faites le calcul surMovingAverages.mqh et c'est très rapide.

[Sergey Efimenko]

forexman77:
Faites le calcul avecMovingAverages.mqh et le calcul sera très rapide.

Et cette bibliothèque calcule correctement, si vous définissez le calcul non pas de tout le tableau, mais seulement de sa dernière partie (valeurs actuelles) ? D'ailleurs, ce n'est que la moitié du problème, mais qu'en est-il de iBandsOnArray ?

[Alexey Viktorov]

Sergey Efimenko:
Montrez-moi donc la variante "fonctionnelle" du code, le code original est ici, que vous essayez de réduire à 12 éléments affichés au lieu des trois cents demandés par moi, et qui devrait se retrouver avec 3 tampons indicateurs avec les données spécifiées, de sorte qu'au moins 300 éléments ont été affichés dans le sous-sol, Et ensuite, quand une nouvelle barre arrive, respectivement, 301 et ensuite la valeur sera dessinée, mais n'oubliez pas que dans ce cas, si vous utilisez 0 comme limite pour le calcul, seule la nouvelle barre sera recalculée, et le type de moyenne (lissage) pour le deuxième tampon n'est pas nécessairement SMA, et peut être n'importe lequel des 4 disponibles.

Voilà.

//+------------------------------------------------------------------+
//|                                         Test300AsSeriesFalse.mq4 |
//|                        Copyright 2015, MetaQuotes Software Corp. |
//|                                             https://www.mql5.com |
//+------------------------------------------------------------------+
#property copyright "Copyright 2015, MetaQuotes Software Corp."
#property link      "https://www.mql5.com"
#property version   "1.00"
#property strict
#property indicator_separate_window
#property indicator_buffers 3
#property  indicator_color1 clrYellow
#property  indicator_color2 clrGreen
#property  indicator_color3 clrRed
double Buffer[];
double BufferMA[];
double BufferBMA[];
bool firstrun=true;

//+------------------------------------------------------------------+
//| Custom indicator initialization function                         |
//+------------------------------------------------------------------+
int OnInit()
  {
//--- indicator buffers mapping
   firstrun=true;
   SetIndexBuffer(0,Buffer,INDICATOR_DATA);
   SetIndexBuffer(1,BufferMA,INDICATOR_DATA);
   SetIndexBuffer(2,BufferBMA,INDICATOR_DATA);
//---
   return(INIT_SUCCEEDED);
  }
//+------------------------------------------------------------------+
//| Custom indicator iteration function                              |
//+------------------------------------------------------------------+
int OnCalculate(const int rates_total,
                const int prev_calculated,
                const datetime &time[],
                const double &open[],
                const double &high[],
                const double &low[],
                const double &close[],
                const long &tick_volume[],
                const long &volume[],
                const int &spread[])
{
   int i, limit;
   limit = rates_total-prev_calculated-1;
   double buffer[];

   for(i = limit; i >= 0; i--)
     {
      Buffer[i]=open[i];
       ArrayCopy(buffer, Buffer, 0, i, 12);
      BufferMA[i] = iMAOnArray(buffer, 300, 12, 0, MODE_SMA, 0);
      BufferBMA[i] = iBandsOnArray(buffer, 300, 12, 2.0, 0, MODE_UPPER, 0);
      int x=0;
     }
   return(rates_total);
}
//+------------------------------------------------------------------+