Bibliothèque: MT4Orders QuickReport - page 6

Nouveau commentaire
 
Forester #:

L'information sur le max long drawdown est intéressante. Je l'ai fait pour l'ensemble du tableau de chaînes de caractères. Je n'ai pas encore mis à jour le code sur le site.
Mais l'utilité de la date n'est pas tout à fait claire. Si nous faisons un point sur la division en tests back/forward (comme je l'ai suggéré), alors nous devons calculer les statistiques sur eux séparément dans 2 tableaux (les périodes max drawdown seront là aussi).

J'ai effectué un calcul complet des statistiques pour les tests back/forward
.

Le fichier a été mis à jour.
 
Forester #:

Ce qui n'est pas tout à fait clair, c'est l'objet de la date.

Si vous voulez voir la date de 2020, n'hésitez pas. À partir de 2023, pas de problème. C'est juste que parfois, vous ne vous souciez pas de savoir ce qu'il en était en 2010. Et cela montre que la durée la plus longue était en 2010.
 
fxsaber #:
Si vous voulez regarder à partir de 2020, vous êtes les bienvenus. A partir de 2023, pas de problème. C'est juste que parfois, vous ne vous souciez pas de savoir ce qu'il en était en 2010. Et cela montre que la durée la plus longue était en 2010.
Ah - j'ai compris. Pas pour un testeur avec un seul expert/stratégie, mais pour un compte réel où différentes idées ont été testées.

La fixation d'une date butoir permettrait de séparer les statistiques.

 
Forester #:
Ah - j'ai compris. Pas pour un testeur avec un seul expert/stratégie, mais pour un compte réel où différentes idées ont été testées.

Je ne l'utiliserais moi-même que pour un testeur. Les pertes réelles ne sont pas du tout intéressantes.

 
Forester #:
Qu'est-ce qui ne va pas avec ça ?

Un style potentiellement dangereux. Par exemple, un peu plus tard, vous voudrez écrire votre propre fonction de formatage de date personnalisée et son appel sera écrit sur une seule ligne super longue, par habitude :

Print("From " + TimeToString(From[i], TIME_DATE) + " MaxLengthDD = " + (string)(MaxLengthDD(BeginDD, EndDD, From[i]) / (25 * 3600)) + " days: " + Format(BeginDD) + " - " + Format(EndDD));

Mais rien ne garantit que les Format-ids seront appelés après MaxLengthDD, simplement parce qu'ils sont listés à droite parmi les summands.

En principe, un enregistrement super long d'une ligne a des aspects négatifs : il est difficile à lire et à comprendre (en fait, il est difficile de répéter dans son esprit l'analyse d'une expression comme le fait un compilateur, mais un humain n'est pas un compilateur après tout), il est difficile à déboguer. De plus, un enregistrement aussi compact n'apporte aucun gain de performance.

 

Super bibliothèque ! Merci à l'auteur !

Suggestions d'améliorations :
- cacher le graphique interactif (ou ajouter un autre mécanisme pour cela) quand on clique à nouveau sur le graphique,
- sauvegarder le source en UTF-8, pour qu'il puisse être lu normalement par GitHub (c'est un événement ponctuel, qui ne menacera rien, mais qui ajoutera de la commodité)
- vérifier le nom du fichier pour les caractères interdits (\ / / : * ? ? "< > | : :), et les remplacer par quelque chose de neutre (-, par exemple)
- ajouter un paramètre pour enregistrer les rapports dans le dossier commun des terminaux, afin de ne pas avoir à les chercher dans les dossiers des agents.


Merci encore, c'est un outil très pratique !

 
Andrey Khatimlianskii dossier commun des terminaux, afin de ne pas les chercher dans les dossiers des agents


Merci encore, c'est un outil très pratique !

J'ai tout fait.
Ajout de 2 nouveaux paramètres à l'appel
void QuickReport(string file_name, bool is_open_file_in_browser=true, int virtual_number=0, bool hide_account_and_name=false, bool common_path=false, bool fileANSI=true){...}
common_path - enregistrer dans le dossier commun du terminal. Pour éviter que les fichiers ne soient écrasés par un autre agent pendant l'optimisation, j'ai ajouté le numéro de l'agent (3000, 3001,...) aux noms des fichiers. Lors de l'enregistrement dans le dossier du testeur (false), ils sont enregistrés dans le dossier de l'agent qui a effectué les calculs.
fileANSI - enregistrer en encodage ANSI ou en UNICODE. La taille des fichiers UNICODE est deux fois plus importante et leur traitement est plus long. Par conséquent, si vous téléchargez beaucoup de données, par exemple 1 Go, il est plus économique d'utiliser l'encodage ANSI. L'UNICODE est ajouté pour des raisons de compatibilité avec des services tiers si vous en avez besoin.

Un vérificateur de caractères et un bouton de masquage sont également ajoutés, mais je ne les ai pas décrits.
 
Forester #:
Ajout de 2 nouveaux paramètres à l'appel
C'est ainsi que de nouveaux paramètres seront ajoutés. C'est pourquoi il est préférable d'écrire la signature une seule fois, où la structure des conditions est saisie. Ainsi, la signature ne changera pas. C'est ce que j'ai fait dans le rapport.
 
fxsaber #:
C'est ainsi que de nouveaux paramètres seront ajoutés. C'est pourquoi il est préférable d'écrire la signature une seule fois, où la structure des conditions est introduite. Ainsi, la signature ne changera pas. C'est ce que j'ai fait dans le rapport.
C'est peut-être mieux. Mais il est nécessaire de conserver le schéma actuel des appels pour des raisons de compatibilité avec les programmes prêts à l'emploi qui utilisent la bibliothèque, afin que personne n'ait à modifier le code.
 
Forester #:
C'est probablement mieux. Mais il est déjà nécessaire de maintenir le schéma d'appel actuel, pour des raisons de compatibilité avec les programmes prêts à l'emploi qui utilisent la bibliothèque, afin que personne ne doive modifier le code.

La surcharge sera utile.

12345678910
Nouveau commentaire