Erreurs, bugs, questions - page 616

[Serj]

Question pour les développeurs :

Pourquoi dans le testeur il n'est pas possible d'obtenir le champ de la structure

MqlTradeResultprice;// Prix d'une transaction, confirmé par le courtier ? Il donne 0.

Il fonctionne bien sur la démo.

[Victor Kirillin]

x100intraday:

Existe-t-il une relation entre la structure des listes d'échéances et les indicateurs de visibilité des objets (car même la longueur des listes est différente : 22 vs 23) ? En général, je demande à ce que la visibilité des objets soit attribuée de manière efficace et compacte sur des périodes de temps dans un cycle avec des limites données, plutôt que de lister et résumer les drapeaux manuellement. Quelle logique utiliser si une période arbitraire est prise au hasard, qu'un objet graphique est construit sur celle-ci et qu'il doit être autorisé à être visible sur toutes les périodes qui ne sont pas plus anciennes que la période actuelle (c'est-à-dire celle sur laquelle il a été construit) ? L'algorithme doit être universel, et non destiné à un cas particulier. La corrélation de l'indice est déjà foutue, il n'y a même pas de correspondance d'indice. L'analyse des chaînes de noms et leur comparaison échouent à nouveau en raison de l'impossibilité de traiter les chaînes dans le cas de constantes de visibilité. Jusqu'à présent, on pense à une mise en œuvre compliquée, vague et très tordue.

Bien sûr, il y a une corrélation, mais elle est tellement implicite que la seule façon d'écrire <visibility_flag> = F(<timeframe>) :

int PeriodToTimeframeFlag(ENUM_TIMEFRAMES period)
  {
   flags=0;
   static ENUM_TIMEFRAMES _p_int[]={PERIOD_M1, PERIOD_M2, PERIOD_M3, PERIOD_M4, PERIOD_M5, PERIOD_M6,
                                    PERIOD_M10,PERIOD_M12,PERIOD_M15,PERIOD_M20,PERIOD_M30,
                                    PERIOD_H1, PERIOD_H2, PERIOD_H3, PERIOD_H4, PERIOD_H6, PERIOD_H8,PERIOD_H12,
                                    PERIOD_D1, PERIOD_W1, PERIOD_MN1};
//--- cycle for all timeframes
   for(int i=0;i<ArraySize(_p_int);i++)
      if(period==_p_int[i])
        {
         //--- at the same time generate the flag of the working timeframe
         flags=((int)1)<<i;
         break;
        }
   return(flags);
  }

[Aleksey Lebedev]

x100intraday:

Quelle logique utiliser si on prend au hasard une période arbitraire, qu'on construit un objet graphique dessus et qu'on a besoin de permettre sa visibilité sur toutes les périodes qui ne sont pas plus anciennes que la période actuelle (c'est-à-dire celle sur laquelle il a été construit) ?

s'il ne s'agit pas d'un vérificateur)

ENUM_TIMEFRAMES TF[21]={PERIOD_M1,PERIOD_M2,PERIOD_M3,PERIOD_M4,PERIOD_M5,PERIOD_M6,PERIOD_M10,
                     PERIOD_M12,PERIOD_M15,PERIOD_M20,PERIOD_M30,PERIOD_H1,PERIOD_H2,PERIOD_H3,
                     PERIOD_H4,PERIOD_H6,PERIOD_H8,PERIOD_H12,PERIOD_D1,PERIOD_W1,PERIOD_MN1};

int Visibility[21]={1,3,7,15,31,63,127,255,511,1023,2047,4095,8191,
            16383,32767,65535,131071,262143,524287,1048575,2097151};

Considérer TF[i], définir Visibilité[i]...

ou visibilité=(int)(MathPow(2,i+1)-1) ;

[x572intraday]

Swan:

Si vous en avez besoin, alors ce n'est pas un damier).

Considérer TF[i], définir Visibilité[i]...

ou visibilité=(int)(MathPow(2,i+1)-1) ;

Merci pour la formule de visibilité - je vais peut-être l'adapter. Il était évident, d'après les valeurs sur les délais, qu'il s'agit d'un degré de quelque chose, mais je n'ai pas essayé de reconstituer la formule moi-même.

Est-ce que -1 est nécessaire ? En général, Visibility[] semble être rempli de valeurs incorrectes, en fait il devrait être partout sans -1, c'est-à-dire : 1, 2, 4, 8, 16....

[x572intraday]

uncleVic:

Bien sûr, il existe une relation, mais elle est tellement implicite que la seule façon d'écrire <visibility_flag>=F(<timeframe>) est de le faire de cette manière :

Merci, élégant. C'est exactement ce que j'essayais de faire, sauf pour le décalage lui-même, qui est exactement ce qui me manquait.

Et enfin, j'ai posé la question du calcul des valeurs des drapeaux à chaque tour de la boucle de régression sur le tableau _p_int timeframe (à la fin, quelque chose devrait être ajouté par les drapeaux), et pas seulement sur celui en cours. Eh bien, en décalant la valeur du drapeau de visibilité à l'horizon temporel actuel, puis à chaque rotation de i-- quelque chose devrait changer quelque part... Soit la formule d'exponentiation doit y être appliquée, soit le même principe de décalage doit être utilisé. Je n'ai pas encore trouvé comment...

... Bien que oui, c'est une fonction avec TF-argument - je vais essayer de la boucler...

Cependant, c'est encore faux. Laissez-moi vous expliquer. Dans l'exemple, il existe un tableau statique ENUM_TIMEFRAMES _p_int[] pour 21 éléments, mais voici ce que je veux : j'ai déjà un tel tableau, mais il peut être de n'importe quelle longueur. Il s'agit d'un tableau contenant les délais, sur lesquels quelque chose sera construit. Mais ils devraient également être visibles sur tous les délais inférieurs et aucun des tableaux n'est rempli avec eux séparément ou en plus de ceux existants. Je mentionne donc ici la nécessité de calculer les drapeaux de la période actuelle et de toutes les périodes inférieures et de les additionner dans la boucle de régression à la volée, en dansant à partir de la période actuelle. Le truc n'est pas de créer un tableau complet de valeurs prédéfinies de quoi que ce soit (même de délais ou de drapeaux de visibilité) et de les manipuler, mais de calculer dans mon esprit, pour chaque tour, uniquement le tableau incomplet de délais prédéfinis.

Je vais y aller pendant un moment et si je suis bloqué, je demanderai.

[x572intraday]

Pourquoi ne suis-je pas pressé d'utiliser (int)(MathPow(2,i+1)-1) ou ((int)1)<<i... Si i est présent, vous pouvez facilement le substituer dans une boucle et exécuter... Mais, tout comme dans le cas de la multiplication et du décalage, est-ce toujours sûr ? Supposons que les développeurs ajoutent un jour de nouvelles échéances, toute la logique ne va-t-elle pas s'effondrer ? D'emblée, dans l'exemple avec un décalage, nous nous attendons à ce que la période actuelle coïncide avec la période prédéfinie :

if(period==_p_int[i])

Ainsi, même si, dans le cas réel, certains délais de la séquence théoriquement complète sont omis ou si cette séquence est étendue par les développeurs, la logique ne devrait pas s'effondrer. Mais si l'on se fie aux mathématiques pures et que l'on se contente d'exécuter le cycle par formule d'une frontière à l'autre, sans tenir compte de l'absence ou de la présence éventuelle de nouvelles échéances, alors tôt ou tard, lors de la prochaine construction, nous aurons des distorsions...

[Victor Kirillin]

x100intraday:

Pourquoi ne suis-je pas pressé d'utiliser (int)(MathPow(2,i+1)-1) ou ((int)1)<<i... Puisque i est là, vous pouvez facilement le substituer dans une boucle et exécuter... Mais, tout comme dans le cas de la multiplication et du décalage, est-ce toujours sûr ? Supposons que les développeurs ajoutent un jour de nouvelles échéances, toute la logique ne va-t-elle pas s'effondrer ? Pour commencer, dans l'exemple avec un décalage, nous nous attendons à ce que la période actuelle soit la même que la période prédéfinie :

Ainsi, même si, dans le cas réel, certains délais de la séquence théoriquement complète sont omis ou si cette séquence est étendue par les développeurs, la logique ne doit pas s'immiscer. Mais si l'on se fie aux mathématiques pures et que l'on se contente d'exécuter le cycle selon la formule d'un bout à l'autre, sans prêter attention à l'absence ou à la présence éventuelle de nouvelles échéances, tôt ou tard, dans la prochaine construction, on obtiendra une distorsion...

Nos préoccupations sont très raisonnables. Le code ci-dessus justifie le fait que le drapeau de visibilité défini est en fait une macro.

Il serait plus correct d'y travailler :

int result=0;
//---
switch(period)
  {
   case PERIOD_M1: result=OBJ_PERIOD_M1; break;
   case PERIOD_M2: result=OBJ_PERIOD_M2; break;
   case PERIOD_M3: result=OBJ_PERIOD_M3; break;
   case PERIOD_M4: result=OBJ_PERIOD_M4; break;
   case PERIOD_M5: result=OBJ_PERIOD_M5; break;

//--- и так далее

   default: print("Что-то новенькое");
  }

[Aleksey Lebedev]

x100intraday:

Merci pour la formule de visibilité - je vais peut-être l'adapter. J'ai pu constater, d'après les valeurs des échéances, qu'il s'agissait d'un degré de quelque chose, mais je n'ai pas essayé de reconstituer la formule moi-même.

Le -1 est-il vraiment nécessaire ? En fait, Visibility[] semble être mal rempli, en fait, il devrait être partout sans -1, c'est-à-dire 1, 2, 4, 8, 16...

1,2,4 etc. - la visibilité de l'objet sur une période donnée. =MathPow(2,i) ;

sur le courant et les plus petits 1, 1+2, 1+2+4, 1+2+4+8 etc., taki =MathPow(2,i+1)-1 ;

C'est plus clair dans le code binaire.

oncleVic:

Les réticences sont très raisonnables. Le code ci-dessus ne fait que justifier le fait que l'ensemble des drapeaux de visibilité est en fait une macro.

La bonne façon de procéder est de s'en sortir :

C'est la même chose en principe. Si vous changez dans la liste des af's, vous devrez modifier le code.

Je ne peux pas imaginer de solution universelle, et je soupçonne qu'il est théoriquement impossible de prévoir les changements possibles.

x100intraday:

Encore faux, cependant. Laissez-moi vous expliquer. Dans l'exemple, le tableau statique ENUM_TIMEFRAMES _p_int[] est créé pour 21 éléments, mais voici ce que je veux : j'ai déjà un tel tableau, mais il peut être de n'importe quelle longueur. Il s'agit d'un tableau contenant les délais, sur lesquels quelque chose sera construit. Mais ils devraient également être visibles sur tous les délais inférieurs et aucun des tableaux n'est rempli avec eux séparément ou en plus de ceux existants. Je mentionne donc ici la nécessité de calculer les drapeaux de l'image actuelle et de toutes les images inférieures et de les additionner dans la boucle de régression à la volée, en dansant à partir de l'image actuelle. L'astuce n'est pas de créer un tableau complet de valeurs prédéfinies de quoi que ce soit (même de délais ou de drapeaux de visibilité) et de les parcourir en boucle, mais de calculer en tête à chaque tour uniquement le tableau incomplet de délais prédéfinis.

Non, vous ne le ferez pas. La correspondance entre le calendrier et la visibilité doit être définie. Ou deux matrices correspondantes, ou un commutateur.

+array avec les TFs dont vous avez besoin, +init calcule la visibilité de l'objet pour chaque TF que vous utilisez. Quelque chose comme ça...)

[Serj]

Je n'arrive pas à comprendre ce qui ne va pas.

double VirtualSL;
MqlTick tick;
//+------------------------------------------------------------------+
//| Expert initialization function                                   |
//+------------------------------------------------------------------+
int OnInit()
  {
   VirtualSL=0.0;
   return(0);
  }
//+------------------------------------------------------------------+
//| Expert tick function                                             |
//+------------------------------------------------------------------+
void OnTick()
  {
   trail();
  }
//+------------------------------------------------------------------+
void trail()
  {
   double stopcal;

   SymbolInfoTick(_Symbol,tick);
   stopcal=tick.bid;

//   if((VirtualSL!=0.0 && stopcal>VirtualSL) || VirtualSL==0.0) // так все работает

   if(VirtualSL==0.0 || (VirtualSL!=0.0 && stopcal>VirtualSL)) // так не хочет работать
     {
      VirtualSL=stopcal;
      Print("use Ok!");
     }
   if(VirtualSL<stopcal) Print("o_O ((((( stopcal = ",stopcal,"   VirtualSL = ",VirtualSL);
  }
//+------------------------------------------------------------------+

2011.12.29 01:16:07 Core 1 2011.09.26 02:54:13 o_O ((((( stopcal = 1.54508 VirtualSL = 1.53378

2011.12.29 01:16:07 Core 1 2011.09.26 02:54:12 o_O ((((( stopcal = 1.54507 VirtualSL = 1.53378

2011.12.29 01:16:07 Core 1 2011.09.26 02:54:12 o_O ((((( stopcal = 1.54508 VirtualSL = 1.53378

[Ilyas]

her.human:

Je me suis creusé la tête, je ne comprends pas ce qui ne va pas ?

C'est une erreur dans l'optimiseur du compilateur. Merci pour votre message, nous allons le corriger.

L'erreur se produit avec la construction suivante

if(VirtualSL==0.0 || (VirtualSL!=0.0 && stopcal>VirtualSL))
if(VirtualSL<stopcal)

VirtualSL!=0.0 peut être supprimé de la deuxième partie de la première condition if,puisque cette expression est toujours vraie après vérification de la première partie. L'erreur de l'optimiseur disparaîtra.


Corrigé, le correctif sera inclus dans la prochaine version.