MT4 iMAOnArray et iBandsOnArray : effet du nombre d'éléments sur les calculs - page 6
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Je n'ai pas suggéré une calculatrice ou Excell pour rien. Ça aide à comprendre comment cette merde fonctionne. Vous ne pouvez utiliser un nombre d'éléments différent de zéro pour calculer que si vous avez déjà un tableau prêt. Supposons que vous ayez un tableau de 1000 éléments et que vous vouliez faire la moyenne des 100 derniers éléments. Nous avons deux choix : convertir ces 100 éléments en un tableau personnalisé et les recalculer, ou utiliser la boucle de 100 à 0 et ne pas convertir le nombre d'éléments en 0, mais en 100.
Mais nous sommes ici confrontés au problème de la modification de la taille du tableau, qui est inévitable dans les indicateurs.
Encore une fois, je parlais d'autres moyens de limiter le nombre d'éléments pour le calcul. Eh bien, vous pouvez définir la condition iMAOnArray() uniquement si(rates_total-i >= rates_total-100) ; et seules les 100 dernières barres seront recalculées et tout ira bien lorsqu'une nouvelle barre arrivera.
Je n'ai pas suggéré une calculatrice ou Excell pour rien. Ça aide à comprendre comment cette merde fonctionne. Vous ne pouvez utiliser un nombre d'éléments différent de zéro pour calculer que si vous avez déjà un tableau prêt. Supposons que vous ayez un tableau de 1000 éléments et que vous vouliez faire la moyenne des 100 derniers éléments. Nous avons deux choix : convertir ces 100 éléments en un tableau personnalisé et les recalculer, ou utiliser la boucle de 100 à 0 et ne pas convertir le nombre d'éléments en 0, mais en 100.
Mais nous sommes ici confrontés au problème de la modification de la taille du tableau, qui est inévitable dans les indicateurs.
Encore une fois, je parlais d'autres moyens de limiter le nombre d'éléments pour le calcul. Eh bien, définissez la condition pour lire iMAOnArray() uniquement si(rates_total-prev_calculated-i >= 100) ; et seules les 100 dernières barres seront recalculées et tout ira bien lorsqu'une nouvelle barre arrivera.
Dites-moi, êtes-vous un programmeur ou faites-vous cela comme un hobby, ou par nécessité ? Je n'ai pas besoin d'un excel ou d'une feuille de papier pour comprendre comment cela fonctionne, et Barabashka a démontré toutes les "difficultés" sur la capture d'écran précédente. Allons-y dans l'ordre.
1. iMAOnArray (ainsi que iBandsOnArray) peut fonctionner en deux versions, il peut lire le tableau entier et le faire correctement (mais il a ralenti pendant le calcul primaire) ou il peut lire une partie du tableau, mais il ne le fera que pour les éléments initiaux, malgré le fait que le décalage est spécifié pour les derniers. C'est pourquoi, même si j'ai essayé de limiter le calcul aux barres, j'ai encore besoin de calculer soit tout le tableau (c'est-à-dire la version initiale du "freinage"), soit de créer une variante similaire à la vôtre en copiant le tampon et en recalculant tous les éléments de ce tampon, ce qui, comme je l'ai décrit dans mes messages précédents, ne donne pas le bon résultat pour les méthodes de lissage complexes et augmente également le temps de traitement des données en général.
2. le problème, décrit par vous dans les indicateurs avec le redimensionnement du tableau, ne se produit que si le tableau n'est pas l'un des tampons de l'indicateur, c'est-à-dire que votre "danse autour" décrite a également un effet négatif, parce que si l'on revient au code source primaire, le problème était seulement dans le calcul lent et seulement à la première étape.
3. La variante que vous proposez, avec le recalcul d'une partie seulement des tableaux sur 100 (N) barres, entraîne à nouveau une perte de productivité générale et des problèmes inutiles de mise en œuvre avec la copie des tableaux ou le recalcul inutile. D'ailleurs sur votre capture d'écran et dans le code ci-dessus tous les calculs sont faits (je soupçonne quelque part dans le tableau interne, c'est très probablement la raison pour laquelle les décalages primaires se produisent), sinon ce genre de lissage aurait rendu les premiers résultats remplis différents, et vous n'avez juste pas rempli le tableau tampon avec eux. Parce que 0 dans le paramètre de taille du tableau pour calculer la fonction lui demande explicitement de lire toutes les données, c'est là que le bât blesse.
La seule façon d'y parvenir est d'utiliser ma propre fonction, qui fonctionnera comme elle le devrait et ne recalculera pas toutes les données (ou une partie d'entre elles) lorsqu'une nouvelle barre arrivera, mais se contentera de les lire, d'autant plus que j'ai et utilise une telle fonction de calcul de la moyenne dans plusieurs de mes produits. La question de ce forum était de savoir comment "battre" les fonctions standard de MT4, sans détériorer la vitesse de traitement et le résultat. Si j'en crois le message ci-dessus, l'"écart type" sur le tableau est calculé sans frein, ou en solution de repli je peux écrire mon propre calcul d'écart, d'autant que les formules de calcul sont à la disposition de tous ici dans la documentation.
Tant de lettres... Et tout cela dans le seul but de ne pas être d'accord avec l'option proposée.
Merci pour l'idée, au moins j'ai compris comment ça marche, sinon je ne suis pas entré dans les subtilités de ces fonctions car je n'en avais pas besoin.
Si vous n'aimez pas ça, utilisez des auto-écritures.
Tant de lettres... Et tout ne vise que le désaccord avec l'option proposée.
Merci pour l'idée, au moins j'ai compris comment ça marche, sinon je ne suis pas entré dans les méandres de ces fonctions car je n'en avais pas besoin.
Si vous n'aimez pas ça, utilisez des auto-écritures.
Eh bien, pourquoi sur le désaccord, sur l'explication, pourquoi il n'est pas nécessaire de le faire, parce que d'écrire le code lié à des fonctions de freinage ou de code créant des boucles supplémentaires de la copie - n'est pas toujours l'option correcte, bien que, parfois, et moins laborieux :)
Et il ne s'agit pas de "j'aime"/"j'aime pas", mais du fait que les fonctions ne fonctionnent pas exactement comme elles le devraient, car en fait, créer des analogues revient à réinventer la roue, mais dans ce cas particulier, nous ne pouvons pas nous en passer.
J'ai fait des conclusions pour moi-même il y a plusieurs pages, mais votre façon, peut-être, aidera quelqu'un à comprendre que cette situation a déjà été résolue ici, et ce que je dois faire pour résoudre ce problème, tant de lettres :)
Il n'y a pas de copie ou de cycles supplémentaires dans cette dernière variante. Et la méthode de calcul MODE_LWMA dont vous et Dimitri parliez auparavant ne peut pas être recalculée correctement.
Regardez le code et la capture d'écran. Dans la capture d'écran, période MA 5 comme dans le code, méthode MODE_LWMA et faites attention au nombre de barres calculées, à la coïncidence des valeurs de la MA et de l'indicateur avec iMAOnArray() dans le sous-sol. Si vous voulez recalculer toutes les barres ou seulement 100. S'il n'y a pas de changement, cela signifie que les autres calculs sont lents.
Dites-moi, êtes-vous un programmeur ou faites-vous cela comme un hobby, ou par nécessité... ?
Il n'y a pas de copie ou de cycles supplémentaires dans cette dernière variante. Et la méthode de calcul MODE_LWMA dont Dimitri et vous parliez avant à propos de l'incapacité à recalculer correctement.
Regardez le code et la capture d'écran. Dans la capture d'écran, période MA 5 comme dans le code, méthode MODE_LWMA et faites attention au nombre de barres calculées, à la coïncidence des valeurs de la MA et de l'indicateur avec iMAOnArray() dans le sous-sol. Si vous voulez recalculer toutes les barres ou seulement 100. S'il n'y a pas de changement, cela signifie que les autres calculs sont lents.
Dans le passé, il a lui-même commencé à bafouiller qu'il n'était pas un programmeur, mais un amateur, et qu'il était donc libre de se mettre à l'abri.
C'était plus une question rhétorique :)
PS Messieurs, soyons tolérants les uns envers les autres. Après tout, nous sommes tous ici pour une seule raison : " arnaquer " le marché. :) Alors allons vers cet objectif sans aucune distraction. Chacun de nous a ses propres difficultés, et des caractéristiques de perception, mais seulement dans une dispute née de la vérité, bien que comme Napoléon avait l'habitude de dire : "Pour argumenter, sachant que vous avez tort - stupide, d'argumenter, sachant que vous avez raison moyen. C'est pourquoi je ne discute jamais."
Cette dernière option n'est essentiellement pas différente de l'originale. Comme je l'ai déjà écrit, lorsque la taille du tableau est de 0, il est toujours compté dans son intégralité. Ma première solution, avant même la création du fil de discussion du forum, a été de limiter le nombre de barres, mais malheureusement, cela n'a pas eu d'effet sur la productivité ; ensuite, j'ai commencé à expérimenter avec la longueur du tableau pour iMAOnArray et c'est là que j'ai vu la complexité de la situation. C'est alors et seulement alors, après avoir essayé presque toutes les variantes faciles, y compris la modification de l'indexation des tableaux pour différentes combinaisons, que j'ai créé ce sujet. Eh bien, après cela, j'ai reçu quelques réponses, certaines confirmant que d'autres avaient également essayé et que tous avaient trouvé leur propre fonction. C'est pourquoi j'ai demandé votre code, sachant au départ que cela marcherait :) Sans vouloir vous offenser :) Peut-être que certains utilisateurs se remettront de ce "râteau" en lisant ce fil. :)
Voulez-vous dire qu'après if(rates_total-i >= rates_total-100) ;, lorsqu'il ne reste plus que 100 barres à calculer, la fonction iMAOnArray() recalcule d'abord le tableau ENTIER ?