Questions d'un "mannequin - page 79

 
Rosh:
Oui, par moi-même. En principe, je pourrais afficher le code en MQL5 pour le calcul.
Ce serait apprécié. Ça simplifierait certaines tâches.
 

Veuillez me dire comment comparer correctement des doubles ( == < > ). Faut-il le normaliser ? Par exemple, il existait une telle fonction dans MT4 :

CompareDoubles(double nombre1,double nombre2)
{
if(NormalizeDouble(number1-number2,8)==0) return(true) ;
sinon retour(false) ;
}

Et en général, quel est l'algorithme approximatif de la fonction NormalizeDouble()?

Документация по MQL5: Преобразование данных / NormalizeDouble
Документация по MQL5: Преобразование данных / NormalizeDouble
  • www.mql5.com
Преобразование данных / NormalizeDouble - Документация по MQL5
 
220Volt:

Veuillez me dire comment comparer correctement des doubles ( == < > ). Faut-il le normaliser ? Par exemple, dans MT4, il y avait une telle fonction :

CompareDoubles(double nombre1,double nombre2)
{
if(NormalizeDouble(number1-number2,8)==0) return(true) ;
sinon retour(false) ;
}

Vous pouvez trouver les recommandations dans le Manuel. Jetez un coup d'œil.
 
220Volt:

Veuillez me dire comment comparer correctement des doubles ( == < > ). Faut-il le normaliser ? Par exemple, il existait une telle fonction dans MT4 :

CompareDoubles(double nombre1,double nombre2)
{
if(NormalizeDouble(number1-number2,8)==0) return(true) ;
sinon retour(false) ;
}

Et en général, quel est l'algorithme approximatif de la fonction NormalizeDouble()?

En général, lorsque l'on compare deux nombres de type double, il est recommandé de prendre leur différence et de la comparer à la valeur seuil autorisée. Mais je compare généralement directement - je n'ai jamais eu de problèmes.
 

On sait qu'au début du graphique l'historique est incorrect, la question "pourquoi est-il incorrect" ne se pose pas.

Une autre question se pose : comment déterminer de manière programmatique la limite au-delà de laquelle les données historiques incorrectes suivent ?

La ligne verticale rouge montre la frontière.

 
joo:

On sait qu'au début du graphique l'historique est incorrect, la question "pourquoi est-il incorrect" ne se pose pas.

Une autre question se pose : comment déterminer de manière programmatique la limite au-delà de laquelle les données historiques incorrectes suivent ?

La ligne verticale rouge montre la frontière.


Y a-t-il un moyen d'essayer de le savoir à partir de la fréquence des écarts ? Comptez les écarts sur une certaine période.
 
tol64:
On peut peut-être essayer de le déterminer d'une manière ou d'une autre par la fréquence des lacunes ? Compter les écarts pour une certaine période.

Il y a beaucoup de façons d'être tordu. Mais je n'en vois aucune qui soit vraiment fiable. Parce qu'il n'existe pas de véritable critère pour juger de l'"authenticité" des données de chaque barreau individuel.

Tous les graphiques sont basés sur des barres de minutes. Il pourrait être calculé de manière programmatique jusqu'à la date à laquelle le calendrier approprié peut être construit correctement. Mais il y a un "cependant" ici aussi. Cependant, les minuscules TF ne sont pas non plus correctes pour toute la profondeur de l'histoire :

Je ne sais pas, IMHO, nous avons besoin d'un mécanisme régulier pour l'identification de telles limites, quelque chose comme

int Correct_Boundary_of_Timeframe
(
string symbol_name,       // имя символа
ENUM_TIMEFRAMES timeframe  // период
);

-retourne l'indice de la dernière barre valide du symbole demandé de la TF requise.

 
joo:

Je ne sais pas, IMHO, nous avons besoin d'un mécanisme interne pour définir de telles limites, quelque chose comme

-renvoie l'indice de la dernière barre valide de l'instrument demandé de la TF requise.

Ce serait idéal. A quoi servent ces données brisées fournies de toute façon ?
 
joo:

-renvoie l'indice de la dernière barre valide de l'instrument demandé de la TF requise.

J'en veux un aussi.
 
joo:

Il y a beaucoup de façons d'être tordu. Mais je n'en vois aucune qui soit vraiment fiable. Parce qu'il n'existe pas de véritable critère pour juger de l'"authenticité" des données de chaque barreau individuel.

Tous les graphiques sont basés sur des barres de minutes. Il pourrait être calculé de manière programmatique jusqu'à la date à laquelle la création correcte d'un délai plus ancien est possible. Mais il y a un "cependant" ici aussi. Cependant, les TF minutes ne sont pas non plus correctes dans toute la profondeur de l'histoire :

Je ne sais pas, je pense que nous avons besoin d'un mécanisme spécial pour définir de telles limites, quelque chose comme

-retourne l'indice de la dernière barre correcte du symbole demandé du TF requis.

Donc, si cela ne vous dérange pas de lire toute l'histoire dans le passé, alors je ne vois pas de problème. Trouvez l'heure d'ouverture et de fermeture de chaque barre et regardez le nombre de secondes dans ces plages intra-barre. Si les résultats sont inférieurs aux prévisions, écrivez une "fausse" barre. Ce sera le point de basculement, après lequel toutes les autres barres seront incomplètes. Il est inutile de chercher plus loin.