Erreurs, bugs, questions - page 589

Nouveau commentaire
 
Ashes:

Vous devez regarder en dehors de la boîte (c)

Je ne vois pas de contre-indications à l'exécution d'un cycle séparé dans le nuage (sauf le prix).

Une exécution autonome dans le nuage sera plus lente dans de nombreux cas que sur le noyau local.
 
joo:
Une exécution individuelle dans le nuage sera plus lente dans de nombreux cas que sur le noyau local.
Au-dessus dehttps://www.mql5.com/ru/forum/1111/page598#comment_125691 se trouve un scénario. Notez le mot CAN. Cette limitation semble farfelue.
 

Un problème s'est posé.

Dans le code de l'indicateur dans OnCalculate() il y a cette ligne (ou plus précisément quelques lignes similaires) :

ArrayInitialize(FractalsBuffer,EMPTY_VALUE);
Le FractalsBuffer n'est pas un tampon de calcul auxiliaire, mais plutôt le tampon principal responsable directement du tracé graphique, il doit donc nécessairement être lié :
SetIndexBuffer(0,FractalsBuffer,INDICATOR_DATA);

qui a été fait. Mais la fonction bind a un certain effet direct, qui agit parfois comme un effet secondaire (dans le mauvais sens du terme). Grâce à CopyBuffer(ind_handle,0,0,amount,FractalsBuffer), le tampon n'est pas rempli pour toute la longueur de l'historique de la trame temporelle, mais seulement partiellement, à partir de son petit segment, par le montant. Mais ArraySize(FractalsBuffer) nous convainc clairement que la taille du tampon (c'est-à-dire la mémoire physique occupée) correspondra au nombre de barres de l'histoire entière, c'est-à-dire qu'au final il sera utilisé au maximum, y compris la partie inefficace. Bien sûr, si vous voulez travailler avec les valeurs de la mémoire tampon plus tard dans la boucle, vous n'avez pas besoin de chercher dans toute la mémoire tampon - vous pouvez simplement spécifier les limites nécessaires et travailler dans ces limites. Mais d'abord, cela n'annule pas l'horrible surallocation de mémoire et, ensuite, l'inévitable fonction dans le code ArrayInitialize ne permet pas d'initialiser le tampon avec la valeur nécessaire partiellementvous devez consacrer du temps et des watts à une réinitialisation complète. Cela rend l'indicateur sensiblement plus lent. Et troisièmement, une citation de la description de la fonction ArrayResize: "Etvous devez garder à l'esprit que . il est impossible de redimensionner les tableaux dynamiques qui sont affectés comme tampons d'indicateurs par la fonction SetIndexBuffer()."Si nous rejetonsSetIndexBuffer auprofit d'une manipulation manuelle de la taille du tampon à l'aide de ArrayResize, le graphique de l'indicateur lui-même s'effondrera.

Veuillez suggérer une recette pour le rétablissement. Ou bien considérez ceci comme une application visant à résoudre ce problème dans la langue elle-même.
 
x100intraday:

C'est un peu le bordel...

1. il est logique d'initialiser le tampon une fois, au départ if(prev_calcul==0)

2. Vous pouvez définir à partir de quelle barre les données seront dessinées, comme ceci : PlotIndexSetInteger(0,PLOT_DRAW_BEGIN,rates_total-amount-1) ;

3. Toutes les valeurs du tampon dans le montant doivent être assignées explicitement, une fois dans tout l'historique, et ensuite seules les nouvelles valeurs seront assignées, alors elles n'ont pas besoin d'être initialisées.

4. Dans les paramètres du terminal, diminuez le nombre de barres dans la fenêtre :)

 
Swan:

C'est un peu le bordel...

1. il est logique d'initialiser le tampon une fois, au départ if(prev_calcul==0)

2. Vous pouvez définir à partir de quelle barre les données seront dessinées, comme ceci : PlotIndexSetInteger(0,PLOT_DRAW_BEGIN,rates_total-amount-1) ;

3. Toutes les valeurs du tampon dans le montant doivent être assignées explicitement, une fois dans tout l'historique, alors seules les nouvelles valeurs seront assignées, et il n'y aura pas besoin d'initialisation.

4. Dans les paramètres du terminal, diminuez le nombre de barres dans la fenêtre :)

1. Vraiment : au niveau de l'idée - il est logique de ne le faire qu'une fois, mais dans la pratique, ce n'est pas si simple, tout est vraiment en cours. Je viens de copier l'indicateur standard : C:\Program Files\MetaTrader 5\MQL5\Indicators\Examples\Fractals.mq5. Comment vider le tampon avant de nouveaux calculs d'une manière différente et plus efficace - je ne sais pas.

2. Je n'ai pas encore étudié cette possibilité, mais il semble qu'il ne faut pas dessiner l'indicateur dans une zone inutile, mais cela ne limite pas la taille du tampon de l'indicateur. En outre, je suis beaucoup plus disposé à travailler avec un tampon qui est rempli de données utiles, sans aucune marge libre, sinon je devrai introduire des limites (dont j'ai parlé dans le post précédent), et cela ne correspond pas à l'algorithme orthodoxe : sur quatre tampons, trois seront analysés dans une boucle avec les mêmes limites, et pour un tampon, je devrai prendre mon temps et faire une boucle de courbe séparée avec des limites différentes, que je peux difficilement caser. Bien que oui, vous pouvez aussi ramper avec des béquilles...

3) Qu'entendez-vous par "explicitement" ? Je ne me porte pas garant de ne pas assigner explicitement du tout. Il se peut que je me sois explicitement approprié. Expliquer ? Quant au fait de ne charger que les nouvelles valeurs, je l'utilise bien sûr, c'est ce qu'on appelle ici un algorithme parcimonieux.

4. Cette idée a été rejetée avant d'écrire le post précédent, car l'indicateur a besoin de plusieurs dernières (nouvelles) barres de l'historique, alors que pour moi personnellement (aspect visuel) j'ai besoin de toutes ou presque toutes les barres. Mon intérêt humain pour les barres d'histoire est plus large que l'intérêt d'un indicateur technique pour celles-ci. Je veux regarder les barres et dessiner l'indicateur dans un seul graphique. Un caprice ? Un besoin ordinaire.

 
x100intraday:

1. En effet, au niveau de l'idée, cela n'a de sens que de le faire une fois, mais dans la pratique, ce n'est pas si simple, tout est vraiment en cours. Je viens de copier l'indicateur standard : C:\Program Files\MetaTrader 5\MQL5\Indicators\Examples\Fractals.mq5. Comment vider le tampon avant de nouveaux calculs d'une manière différente et plus efficace - je ne sais pas.

   if(prev_calculated<7)// if(prev_calculated==0)// if(prev_calculated<1)// вопщем одинаково)
      //Initialize только при первом запуске. нуу или при случае какогнить ахтунга)
      {
      limit=2;//цикл начинается со второго элемента индикаторного массива
      //--- clean up arrays//в принципе здесь не очистка массива, 
                        //а значения EMPTY_VALUE  присваивается 0 и 1 элементу массивов, мм.. и на последних трёх барах)
                        //остальные определяются далее в цикле..
      ArrayInitialize(ExtUpperBuffer,EMPTY_VALUE);
      ArrayInitialize(ExtLowerBuffer,EMPTY_VALUE);
      }
   else limit=rates_total-5;//иначе - в цикле пересчитываются только два последних значения

//зы: при появлении нового бара - новый элемент массива вроде как не определен, насколько мне известно не гарантируется, что он будет  ==EMPTY_VALUE
2. Je n'ai pas encore étudié cette possibilité, mais il semble qu'il ne faut pas dessiner l'indicateur dans une zone inutile, mais cela ne limite pas la taille du tampon de l'indicateur. De plus, je suis beaucoup plus disposé à travailler avec un tampon qui est rempli de données utiles jusqu'aux limites, sans aucune marge libre, sinon je devrais introduire des limites (ce dont j'ai parlé dans le post précédent), et cela ne correspond pas à l'algorithme orthodoxe : sur quatre tampons, trois seront analysés dans une boucle avec les mêmes limites, et pour un tampon, je devrai prendre mon temps et faire une boucle de courbe séparée avec des limites différentes, que je peux difficilement caser. Bien que oui, vous pouvez aussi ramper avec des béquilles...

Eh bien, oui, ça devrait.

La taille du tampon de l'indicateur est définie uniquement par le nombre de barres.

D'une manière ou d'une autre, une certaine taille devra être fixée... Pourquoi faire une boucle incurvée avec des limites différentes quand on peut en faire une droite avec les mêmes limites ?)

En d'autres termes, vous devez spécifier la taille de la boucle, et non la taille du tableau... Sinon, l'indicateur sera basé sur des béquilles


3) Que voulez-vous dire par "explicitement" ? Je ne peux absolument pas garantir que je ne l'attribue pas explicitement. Il se pourrait bien que je le fasse explicitement. Expliquer ? Quant au fait de ne charger que les nouvelles valeurs, je l'utilise bien sûr, c'est ce qu'on appelle ici un algorithme parcimonieux.
      //---- Upper Fractal
      if(High[i]>High[i+1] && High[i]>High[i+2] && High[i]>=High[i-1] && High[i]>=High[i-2])
         ExtUpperBuffer[i]=High[i];//условие выполняется - присваиваем значение
      else ExtUpperBuffer[i]=EMPTY_VALUE;//не выполняется - таки тоже присваиваем значение)
//нет зависимости от Initialize, всем элементам в цикле явно присваивается значение.

À propos de l'algorithme d'économie - je ne suis pas sûr que vous l'utilisiez.

L'indicateur est calculé une fois pour toutes les barres - c'est-à-dire qu'il peut être un peu lent lorsqu'il est lancé sur un historique agromadique.

Ensuite, quelques valeurs sont recalculées - tout devrait fonctionner :)

 
Cmu4:

Quel est le problème avec les indicateurs ? Ils vont et viennent. Et seulement ceux qui sont dans une fenêtre séparée ! !!

Voici une capture d'écran du moment où les indicateurs ont disparu. Ils disparaissent de temps en temps et apparaissent ensuite... de façon arbitraire. Il y a aussi une vidéo...

Attention, les indicateurs de base disparaissent ! !! Cela signifie que le bogue est important. Le même problème se pose avec les indicateurs personnalisés.

Messieurs les développeurs, corrigez ce bug, s'il vous plaît, ce n'est pas beau à voir...

Malheureusement, la capture d'écran ne montre pas.

Quel serveur ? Quel serveur d'accès ? Quelle date/heure ? Est-ce que l'histoire a été mise en page à ce moment-là ?

Cela se reproduit-il maintenant ? Pouvez-vous joindre les journaux du terminal pour cette date ?

 

Chers développeurs, j'ai trouvé une erreur (défaut) désagréable dans le compilateur MQL5.

Si vous utilisez une construction conditionnelle de la forme suivante

si (Condition) ;

{ opérateur_1

......

Opérateur_N }

Aucune erreur ou avertissement n'est généré lors de la compilation du code.

Mais comme il y a un " ; " (avec ou sans espace) juste après la condition, {opérateur_1...opérateur_N} sera exécuté tout le temps.

MQL4 affiche un avertissement. Je veux que MQL5 affiche aussi une erreur ou un avertissement ! (J'ai perdu une demi-journée à essayer de trouver ce qui ne va pas dans mon code)

Merci pour vos commentaires !

 
Fia:

Chers développeurs, j'ai trouvé une erreur (défaut) désagréable dans le compilateur MQL5.

Si vous utilisez une construction conditionnelle de la forme suivante

si (Condition) ;

{ opérateur_1

......

Opérateur_N }

Aucune erreur ou avertissement n'est généré lors de la compilation du code.

Mais comme il y a un " ; " (avec ou sans espace) juste après la condition, {opérateur_1...opérateur_N} sera exécuté tout le temps.

MQL4 affiche un avertissement. Je veux que MQL5 affiche aussi une erreur ou un avertissement ! (J'ai perdu une demi-journée à essayer de trouver ce qui ne va pas dans mon code)

Merci pour vos commentaires !


Tout est valable dans ce cas. ; est un opérateur vide.

Nous allons réfléchir à votre suggestion (publier un vorning), mais ce n'est pas la priorité absolue pour le moment.

Документация по MQL5: Основы языка / Операторы / Оператор-выражение
Документация по MQL5: Основы языка / Операторы / Оператор-выражение
  • www.mql5.com
Основы языка / Операторы / Оператор-выражение - Документация по MQL5
 
alexvd:

Dans ce cas, tout est valable. ; est un opérateur vide.

Nous allons réfléchir à votre suggestion (émission de vorning), mais ce n'est pas la priorité absolue pour le moment.

J'espère que vous n'oublierez pas de le faire dans MQL4, car cela a été fait logiquement dans MQL4.


Pouvez-vous nous conseiller de considérer deux ordres en attente (le prix, le type et le volume de leur exécution sont les mêmes) ?

Lorsque le prix est atteint, les deux événements seront déclenchés, et comment l'événement OnTrade() fonctionnera-t-il dans ce cas ?

En particulier, les ordres en suspens qui ont été exécutés iront dans l'historique en un seul événement OnTrade() ou y aura-t-il deux appels ? (mes journaux montrent un appel pour une raison quelconque)

Merci pour votre réponse !

1...582583584585586587588589590591592593594595596...3184
Nouveau commentaire
Raison: