Erreurs, bugs, questions - page 2820

Nouveau commentaire
 
Une question de barbu. Mais je ne comprends pas ce résultat. 
void OnStart()
{
  Print(NormalizeDouble(1.79435, 5) == 1.79435); // false  
}
 
fxsaber:
Question sur les barbus. Mais je ne comprends pas ce résultat.

On l'a dit 100 fois : "n'utilisez pas la comparaison dub exacte, utilisez l'epsilon". Y compris dans notre documentation.

Même 0,3 ou 0,7 ne sera pas comparable à vos perceptions. Acceptez-le et passez à autre chose. Ou aller apprendre (à MTI, par exemple).

 
Slava:

On l'a dit 100 fois : "n'utilisez pas la comparaison dub exacte, utilisez l'epsilon". Y compris dans notre documentation.

Je sais comment faire une comparaison de doublage, bien sûr.

Même 0,3 ou 0,7 ne sera pas comparable à vos perceptions. Acceptez-le et passez à autre chose. Ou allez apprendre (à MTI, par exemple).

Print(NormalizeDouble(0.3, 5) == 0.3); // true
Print(NormalizeDouble(0.7, 5) == 0.7); // true

Print(NormalizeDouble(0.12345, 5) == 0.12345); // true

Vous ne comprenez pas la question.

 
décimal rendrait les choses plus faciles, mais c'est lent(
 
fxsaber:

Je peux faire une comparaison de doublage, bien sûr.

Vous ne comprenez pas la question.

Il y a d'autres subtilités.

Un nombre réel multiplié par 0,5 peut ne pas être comparable au même nombre divisé par 2,0.

 
Slava:

Il y a d'autres subtilités.

Un nombre réel multiplié par 0,5 peut ne pas être égal au même nombre divisé par 2,0.

C'est vrai. Mais la question était de savoir pourquoi le nombre 1,79435 n'est pas normalisé à 5 décimales.


ZS Le contexte de cette question.

Le SL du testeur s'est éteint. DEAL_PRICE = 1.79435, ORDER_PRICE_OPEN = 0(comme dans MT5), DEAL_COMMENT = "sl 1.79435".

Je voulais savoir s'il y avait un glissement lorsque j'ai exécuté SL ou non ? J'ai donc simplement comparé DEAL_PRICE et le prix figurant dans le commentaire. Avec mes yeux, je vois que les prix sont les mêmes, mais MQL montre qu'ils ne le sont pas. J'ai enfin trouvé le fond de la comparaison originale.

Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie

Erreurs, bugs, questions

fxsaber, 2020.08.10 09:04

void OnStart()
{
  Print(NormalizeDouble(1.79435, 5) == 1.79435); // false  
}
 
fxsaber:

Tout est vrai. Mais la question était de savoir pourquoi le nombre 1,79435 n'est pas normalisé à la 5e décimale.


ZS Le contexte de la question.

Le SL du Testeur a été déclenché. DEAL_PRICE = 1.79435, ORDER_PRICE_OPEN = 0(comme dans MT5), DEAL_COMMENT = "sl 1.79435".

Je voulais savoir s'il y avait un glissement lorsque j'ai exécuté SL ou non ? J'ai donc simplement comparé DEAL_PRICE et le prix figurant dans le commentaire. Avec mes yeux, je vois que les prix sont les mêmes, mais MQL montre qu'ils ne le sont pas. J'ai fini par arriver à la comparaison originale.

Désolé, mais c'est un peu étrange de vous entendre dire ça.


 
Alexey Viktorov:

Je suis désolé, mais c'est un peu étrange de vous entendre dire ça.

Je répète ma question.

fxsaber:

Pourquoi le nombre 1,79435 n'est-il pas normalisé à la 5e décimale ?

void OnStart()
{
  const double Norm = NormalizeDouble(1.79435, 5);
  
  Print((double)(string)Norm == Norm);    // false
  Print((double)(string)Norm == 1.79435); // true
}
 
fxsaber:

Tout est vrai. Mais la question était de savoir pourquoi le nombre 1,79435 n'est pas normalisé à la 5e décimale.

La normalisation n'est pas un arrondi.

@Slava écrit que la représentation interne du double est différente :

#define  PRINT(EX) Print(#EX," = ",EX)
//+------------------------------------------------------------------+
void OnStart()
{
   union ULONG_DOUBLE
   {
      double d_value;
      ulong ul_value;
   }tmp;
   double NORM_DOUBLE   = NormalizeDouble(1.79435, 5);
   double CONST_DOUBLE  = 1.79435;
   
   PRINT(NORM_DOUBLE);
   tmp.d_value = NORM_DOUBLE;
   PRINT(LongToHex(tmp.ul_value));
   
   tmp.d_value = CONST_DOUBLE;
   PRINT(CONST_DOUBLE);
   PRINT(LongToHex(tmp.ul_value));
}
//+------------------------------------------------------------------+
string LongToHex(const ulong value)
{
   return(StringFormat("%llX", value));
}
//+------------------------------------------------------------------+

2020.08.10 13:33:37.737 tst_normalize (EURUSD,H1) NORM_DOUBLE = 1.79435

2020.08.10 13:33:37.737 tst_normalize (EURUSD,H1) LongToHex(tmp.ul_value) = 3FFCB5A858793DDA

2020.08.10 13:33:37.737 tst_normalize (EURUSD,H1) CONST_DOUBLE = 1.79435

2020.08.10 13:33:37.737 tst_normalize (EURUSD,H1) LongToHex(tmp.ul_value) = 3FFCB5A858793DD9


SZS : Il y avait un bon post@Nikolai Semko quelque part, il a donné une très bonne description de la façon de travailler avec le double, peut-être que je vais trouver le lien.

UPD: https://www.mql5.com/ru/forum/1111/page2623#comment_14473837

 
Igor Makanu:

la normalisation n'est pas un arrondi

J'ai un A+ en théorie, comment travailler en double et ainsi de suite. L'algorithme NormalizeDouble contient une erreur. Le sujet soulevé n'est qu'indirectement lié à la comparaison des doubles.

1...281328142815281628172818281928202821282228232824282528262827...3184
Nouveau commentaire