Erreurs, bugs, questions - page 443

Nouveau commentaire
 
voix_kas:

Résultat :

Soit je fais quelque chose de mal (merci de corriger), soit MetaDriver a fait une erreur théorique (lors de la conception de l'algorithme).

:)

Si l'on considère que la "conception" de l'algorithme a pris environ 3 minutes (et 7 minutes d'implémentation), je m'en suis plutôt bien sorti :) Le but était de montrer une idée fonctionnelle et de clarifier l'énoncé du problème.

Et tout cela s'est avéré utile - les développeurs ont eu une réelle opportunité d'améliorer la fonction MathFloor() - de toute évidence, elle n'est pas tout à fait proprement implémentée.

Au final, ils ont dû le bricoler. C'était amusant. J'ai réussi à obtenir une fonction stable (je veux dire CountSignedDigits(double x)) seulement après presque une heure d'expériences.

Et même maintenant, je ne suis pas sûr qu'il fonctionnera correctement avec toutes les valeurs d'entrée. Je n'ai pas développé un stress-test automatisé, j'en ai fait un manuel. Veuillez le tester.

Je m'attends à un fonctionnement stable jusqu'à 10 décimales après la virgule flottante.

int CountSignedDigits(double x)
{
  for(int i=0; i<1000; i++,x*=10)
  {
    if(x-MathFloor(x+0.000000000005)<double(0.000000000005)) return i;
  }
  return -1;
}
Stress-test joint. // Je n'ai pas supprimé certaines réalisations intermédiaires du code. Je l'ai laissé dans les commentaires pour que vous puissiez essayer/réfléchir. Y compris les développeurs.
Dossiers :
CSDigitTest.mq5  2 kb
 
komposter:
1. il n'est pas nécessaire de définir dig pour un lot, il suffit de le normaliser à la bonne étape :

2. même s'il y a des déchets dans la variable lot lors de l'envoi d'une demande de transaction (dans la décimale), ils devraient être éliminés par le terminal lui-même.

En tout cas, je n'ai pas eu de problèmes pendant plusieurs années d'utilisation d'une telle construction.

4. si vous voulez assurer, vous pouvez le normaliser à 8 décimales (avec une marge) - s'il y a des déchets après la normalisation "correcte", ils seront beaucoup plus loin.

La première idée est correcte, les autres sont suspectes. :)

La mise en œuvre est viable dans la pratique, mais pour les conditions artificielles définies par le "démarreur de problèmes" (c), elle est inexacte. Pour les étapes discrètes, la génération n'est pas relative à lot_min, mais relative à zéro. :)

Cependant, il peut être facilement corrigé si vous le remarquez.

double komposterNormalizeLot(double lot, double lot_step, double lot_min, double lot_max)
{
   lot = NormalizeDouble( lot / lot_step, 0 ) * lot_step;
   if ( lot < lot_min ) lot = lot_min;
   if ( lot > lot_max ) lot = lot_max;
   return lot;
}
double metadriverNormalizeLot(double lot, double lot_step, double lot_min, double lot_max)
{
   lot = NormalizeDouble((lot-lot_min) / lot_step, 0) * lot_step + lot_min;
   if ( lot > lot_max ) lot = lot_max;
   return lot;
}

// Ne prenez pas toutes ces perles trop au sérieux. Les clarifications sont purement théoriques, pour l'entraînement du cerveau, car en pratique je n'ai jamais vu lot_step égal à, disons, 0.0231.....

;)

  
metadriverNormalizeLot

L'option est correcte. Correctement pris en compte par lot_min comme dans mon NL().

 

Ma variante est également disponible. Notez que pour certains instruments, le pas de changement de prix est plus grand que le point.

//---------------------------------------------------------------------
//  Нормализация цены:
//---------------------------------------------------------------------
double
NormalizePrice( string _symbol, double _org_price )
{
  double  norm_price = _org_price;

  double  min_price_step = NormalizeDouble( current_tick_size / current_point, 0 );

  norm_price = NormalizeDouble( NormalizeDouble(( NormalizeDouble( _org_price / current_point, 0 )) / min_price_step, 0 ) * min_price_step * current_point, current_digits );

  return( norm_price );
}

//---------------------------------------------------------------------
//  Вычисление лота:
//---------------------------------------------------------------------
double
NormalizeLot( double _required_lot )
{
  double        lot, k;

  if( current_min_lot_step > 0 )
  {
    k = 1.0 / current_min_lot_step;
  }
  else
  {
    k = 1.0 / current_min_permitted_lot;
  }

  lot = MathFloor( _required_lot * k ) / k;

  if( lot < current_min_permitted_lot )
  {
   lot = current_min_permitted_lot;
  }

  if( lot > current_max_permitted_lot )
  {
    lot = current_max_permitted_lot;
  }

  lot = NormalizeDouble( lot, 2 );
  return( lot );
}
 

Si nous prenons comme axiome que les étapes "partent" du lot minimum plutôt que de zéro, l'algorithme correct est le suivant :

double voixkasNormalizeLot(double lot, double lot_step, double lot_min, double lot_max)
{
  if ( lot < lot_min ) lot = lot_min;
  else lot = NormalizeDouble((lot-lot_min) / lot_step, 0) * lot_step + lot_min;

  if ( lot > lot_max ) lot = lot_max;
  return NormalizeDouble(Lot, 8);
}

Dans la version Composter, les étapes "partent" de zéro. Ce qui ne me semble pas correct.
Dans la variante MetaDriver, le code saute une valeur négative. =Р

 
voix_kas:
...

Dans la variante MetaDriver, le code saute une valeur négative. =Р

:)) ..... Oh oui ! Vous ne travaillerez pas du tout ! ;-R ;-b ;-R

double voixkasNormalizeLot(double lot, double lot_step, double lot_min, double lot_max)
{
  if ( lot < lot_min ) lot = lot_min;
  else lot = NormalizeDouble((lot-lot_min) / lot_step, 0) * lot_step + lot_min;

  if ( lot > lot_max ) lot = lot_max;
  return NormalizeDouble(L ot, 8);
}

En fait, la variante la plus courte et en même temps la plus exacte est celle-ci :

double mdNormalizeLot(double lot, double lot_step, double lot_min, double lot_max)
{
  lot = MathMin(lot, lot_min);
  lot = NormalizeDouble((lot-lot_min) / lot_step, 0) * lot_step + lot_min;
  return NormalizeDouble(MathMin(lot, lot_max), MathMax(CountSignedDigits(lot_min),CountSignedDigits(lot_step));
}

Et ce, sans vérifier la nullité et la négativité de lot_step, lot_min et lot_max! !......

:))))

 

Euh... a touché un point sensible. :)) La dernière ligne a été corrigée à la main dans un post de forum, alors pardonnez-moi. =)
Au fait, votre code n'a pas compilé non plus (j'ai oublié de mettre une parenthèse fermante dans la dernière ligne). :-Р
En outre, il est 2-3 fois plus lent (je l'ai vérifié sur le script), mais la qualité de la vérification est la même. :-Р

Quoi qu'il en soit, tant qu'il n'y aura pas de code approprié pour déterminer l'entier significatif, je suivrai le conseil du composteur : normaliser le volume à 8 décimales.
Espérons qu'il n'y aura pas d'embûches.

Merci à tous pour votre aide.

 

Vous êtes drôles, je vois.

dans votre premier message vous avez donné NL() ce que vous n'avez fait que deux pages plus tard ;)

 

Il y a une autre question pour les gourous. Lorsque je teste la multidevise, j'obtiens des erreurs (capture d'écran jointe).
J'essaie d'effectuer une opération commerciale, mais je reçois une réponse : Pas de prix. Selon le testeur, on peut voir que les cotations pour cette paire commencent à arriver en 2011.01.0301:00:00, tandis que l'EURUSD est également cotée à partir de 2011.01.0300:00:00 Y a-t-il un moyen de trouver l'heure du début des cotations pour contourner cette erreur ?

Capture d'écran avec erreur

 
voix_kas:

Il y a une autre question pour les gourous. Lorsque je teste la multidevise, j'obtiens des erreurs (capture d'écran jointe).
J'essaie d'effectuer une opération commerciale, mais je reçois une réponse : Pas de prix. Selon le testeur, on peut voir que les cotations pour cette paire commencent à arriver en 2011.01.0301:00:00, alors que l'EURUSD est également cotée à partir de 2011.01.0300:00:00Y a-t-il un moyen de connaître l'heure du début des cotations pour éviter cette erreur ?

Les séances de négociation et de cotation n'aideront pas à résoudre le problème ?
1...436437438439440441442443444445446447448449450...3184
Nouveau commentaire