Théorie de l'accélération de l'EA lors de l'utilisation d'un indicateur personnalisé (fonction - iCustom) - page 3

Nouveau commentaire
 
-Aleks-:
Ainsi, le fatras d'indicateurs nécessaires fonctionnera plus rapidement que l'utilisation des indicateurs séparément - les informations sur les devis seront demandées moins fréquemment ?

Non essentiel. Veillez à ce que les calculs ne soient pas effectués en double. Si les calculs préliminaires de deux indicateurs sont les mêmes, ils doivent être combinés en un seul. Vous ne devez pas simplement coller tous les indicateurs en un seul.

La demande de devis ne pose aucun problème. Ils n'ont pas besoin d'être demandés, ils viennent d'eux-mêmes.

 

J'ai essayé d'utiliser une temporisation pour recalculer l'indicateur :

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);
 }

En testant sur "OHLSnaM1" il n'y a presque aucune différence, peut-être que tester sur "all ticks" sera plus rapide.

 

mon impression du fonctionnement d'iCustom (si rien n'a été changé au cours des 2 derniers mois)
lorsque vous appelez l'indicateur depuis iCustom
tous les tampons pour un historique possible et les résultats stockés dans le cache seront calculés, et le cache sera lié aux paramètres et au nom de l'indicateur

si vous appelez la prochaine fois le même indicateur et les mêmes paramètres pour le deuxième tableau d'indices - le résultat sera renvoyé du cache (+ correction pour les nouvelles données historiques).
si vous appelez le même indicateur, mais ne changez qu'un seul paramètre - le calcul complet de tous les tampons pour l'historique éventuel et la sauvegarde d'un autre cache, mais avec une liaison aux nouveaux paramètres sera effectué.


Vous pouvez spécifier la quantité d'historique à télécharger depuis le conseiller expert, si vous créez un tel paramètre dans l'indicateur, mais à cet appel vous devez toujours passer le même nombre - la taille de l'historique.
(cela affectera la vitesse du premier appel de iCustom).

Vous pouvez essayer de supprimer le calcul des tampons inutiles, si possible, à la fois dans l'indicateur et via les paramètres de l'indicateur, comme dans l'exemple avec la taille de l'historique
(diminuer la taille du cache - augmenter la vitesse de calcul)

 

Merci à tous pour ces informations.

Je veux clarifier, si dans un indicateur avec 5 tampons graphiques pour utiliser non pas un tampon graphique, mais un tableau ordinaire - pour sortir les données par un tampon graphique, comme je l'ai suggéré, la vitesse de l'indicateur pendant l'optimisation sera plus rapide, parce que moins de mémoire sera allouée pour l'indicateur, et donc moins de temps sera passé à travailler avec lui ?

Si l'optimisation est effectuée et que les paramètres de l'indicateur ne sont pas modifiés à chaque passage, l'indicateur sera-t-il recalculé ?

 
-Aleks-:

Merci à tous pour ces informations.

Je veux clarifier, si dans un indicateur avec 5 tampons graphiques pour utiliser non pas un tampon graphique, mais un tableau ordinaire - pour sortir les données par un tampon graphique, comme je l'ai suggéré, la vitesse de l'indicateur pendant l'optimisation sera plus rapide, parce que moins de mémoire sera allouée pour l'indicateur, et donc moins de temps sera passé à travailler avec lui ?

Si l'optimisation est effectuée et que les paramètres de l'indicateur ne sont pas modifiés à chaque passage, l'indicateur sera-t-il recalculé ?

Le tampon est un tableau, pratique uniquement pour afficher des données.

Pendant l'optimisation, l'indicateur est recalculé à chaque fois.

 
komposter:

Un tampon est un tableau, pratique uniquement pour afficher des données.

Je comprends le tableau, mais le tableau pour calculer un indicateur peut être beaucoup plus petit - souvent dynamique.

Par exemple, dans l'historique de 1000 barres, l'indicateur personnalisé dessine 3 SMAs - 5/8/10.

Dans le cas standard, nous aurons un tampon graphique pour presque 3000-10-8-5

Et si nous utilisons ma méthode

pour calculer la SMA(5) nous avons besoin d'un tableau de taille (désolé pour la terminologie) de 4 barres

Pour calculer la SMA(8), j'ai besoin d'un tableau de (excusez la terminologie) 7 barres de taille.

Pour calculer la SMA(10), nous avons besoin d'un tableau de (désolé pour la terminologie) 9 barres.

et un tableau de 1000 barres, le résultat est que vous avez besoin de 1000+4+7+9 car les tableaux vont simplement les écraser.

Où ai-je tort ?

 
-Aleks-:

Merci à tous pour ces informations.

Je veux clarifier, si dans un indicateur avec 5 tampons graphiques pour utiliser non pas un tampon graphique, mais un tableau ordinaire - pour sortir les données par un tampon graphique, comme je l'ai suggéré, la vitesse de l'indicateur pendant l'optimisation sera plus rapide, parce que moins de mémoire sera allouée pour l'indicateur, et donc moins de temps sera passé à travailler avec lui ?

Si l'optimisation est effectuée et que les paramètres de l'indicateur ne sont pas modifiés à chaque passage, l'indicateur sera-t-il recalculé ?

Il est plus important de comprendre que lorsque vous appelez à nouveau l'indicateur, il ne sera pas rechargé dans le segment de mémoire (overlay). Tout le reste n'est rien comparé à lui.
 
-Aleks-:

Je comprends le tableau, mais le tableau pour le calcul de l'indicateur peut être beaucoup plus petit - souvent dynamique.

Par exemple, dans l'historique de 1000 barres, l'indicateur personnalisé dessine 3 SMAs - 5/8/10.

Dans le cas standard, nous aurons un tampon graphique pour presque 3000-10-8-5

Et si nous utilisons ma méthode

pour calculer la SMA(5) nous avons besoin d'un tableau de taille (désolé pour la terminologie) de 4 barres

Pour calculer la SMA(8), j'ai besoin d'un tableau de (excusez la terminologie) 7 barres de taille.

Pour calculer la SMA(10), nous avons besoin d'un tableau de (désolé pour la terminologie) 9 barres.

et un tableau de 1000 barres, le résultat est que vous avez besoin de 1000+4+7+9 car les tableaux vont simplement les écraser.

Où ai-je tort ?

Si vous avez besoin d'une valeur sur une barre, vous n'avez pas vraiment besoin d'un tampon. L'indicateur non plus ;)

Et si vous avez besoin d'une valeur d'indicateur sur chaque barre, il est souvent plus économique de tout calculer, puis de ne calculer en plus que la nouvelle barre.
Et tous les algorithmes ne sont pas aussi simples que les SMA, ils ne peuvent tout simplement pas être calculés "pour 5 barres". Regardez au moins le zig-zag.

Ce qui me trouble le plus, c'est que vous n'essayez pas d'appliquer les réponses dans la pratique. Il semble qu'il n'y ait pas de tâche pratique, seulement des astuces théoriques.
Alors je ne comprends pas pourquoi j'y participe.

 

A propos, MT4 se débrouille très bien avec le calcul d'une partie seulement de l'historique et ne consomme pas de mémoire pour l'ensemble du tampon, si la boucle passe par les 1000 dernières barres (même s'il y a 50000 barres "dans la fenêtre").

Cependant, j'ai rencontré ce problème dans MT5 - il alloue de la mémoire pour l'ensemble des 50000 barres même si seules les 100 dernières sont comptées.

 
komposter:

Si vous avez besoin d'une valeur sur une barre, vous n'avez pas vraiment besoin d'un tampon. L'indicateur non plus ;)

Pourquoi un seul bar ? Je disais simplement que pour calculer la valeur d'un indicateur, il est rarement nécessaire de connaître tous ses indicateurs pour l'ensemble de l'historique. C'est pourquoi j'ai écrit que les tampons (tableaux) ne seront utilisés que pour le calcul, tandis que le résultat du calcul de 3 MAs sera stocké dans untampon graphique.

En ce qui concerne Zig-zag - c'est un casse-tête pour moi maintenant - il nécessite un certain nombre de réponses, mais je vais ouvrir un fil séparé.

komposter:

Ce qui me trouble le plus, c'est que vous n'essayez pas d'appliquer les réponses dans la pratique. On a l'impression qu'il n'y a pas de tâche pratique, seulement des spéculations théoriques.

Alors je ne comprends pas pourquoi j'y participe.

Le problème, c'est que je ne suis pas moi-même un programmeur - mes recherches m'aideront à rédiger le cahier des charges. Je suis en train de développer un indicateur, qui sera un composant du moteur de l'EA - il a beaucoup de tampons, donc je réfléchis à la façon d'accélérer l'EA non pas en intégrant l'indicateur dans le code, mais par d'autres méthodes.

J'espérais également que quelqu'un serait intéressé par l'essai d'un tel algorithme dans la pratique - pour comparer la vitesse d'exécution ...


komposter:

A propos, MT4 est parfaitement capable de ne calculer qu'une partie de l'historique et ne consomme pas de mémoire pour l'ensemble du tampon, si la boucle passe par les 1000 dernières barres (même s'il y en a 50000 dans la "fenêtre").

Cependant, j'ai rencontré ce problème dans MT5 - il alloue de la mémoire pour toutes les 50000 barres, même si je ne compte que les 100 dernières.

C'est un triste constat pour 5. Les développeurs n'expliquent-ils pas le sens sacré de ceci ?

123456789
Nouveau commentaire