Numéro magique automatique - page 3

Nouveau commentaire
 
BarrowBoy:

Si vous ne clôturiez pas partiellement des ordres, vous pourriez utiliser le commentaire pour stocker l'information sur la paire/trame d'origine... ?

S'il y a deux EA sur le même symbole et la même période, comment peuvent-ils savoir de quels ordres historiques ils doivent prendre leurs identifiants respectifs ?


Tout cela dépend en partie des informations dont on suppose qu'elles sont garanties lors du redémarrage. Par exemple, il y a des gens sur ce forum qui stockent des données de ce type dans des objets cachés dans la fenêtre du graphique. Ce n'est pas mal, mais je suis personnellement effrayé par tout mécanisme que l'utilisateur peut casser - sans réaliser comment ou pourquoi.

 
jjc wrote >>

S'il y a deux EA sur le même symbole et la même période, comment savent-ils lesquels des ordres doivent prendre leurs identifiants respectifs ?

Mince - c'était dans le cadre du projet :D

Je suppose que j'ai supposé que l'EA (si elle est de type ou de version différente) aurait un identifiant dans les commentaires également :)

-BB-

 
jjc wrote >>

Je ne vois pas comment cela est possible sans que MT4 ou l'utilisateur n'attribue un ID à chaque EA. Ou, plus précisément, je ne vois rien qui n'implique pas quelque chose de très désagréable comme la génération d'un ID unique et la modification du fichier .chr de l'EA pour stocker l'ID dans les paramètres externes de l'EA.

Et, pour le divertissement général, ce qui suit ne fait pas vraiment avancer la discussion, mais remplace l'entrée du hachage djb2 par une valeur dont l'unicité est garantie (au prix d'appels de DLL). Je ne sais pas à quel point djb2 est censé être bon pour des choses comme les GUIDs, mais je viens d'essayer de générer 1.000.000 d'IDs sans aucune collision. Mais cela ne résout toujours pas le problème du redémarrage.

Je ne vois pas comment cela est possible sans que MT4 ou l'utilisateur n'attribue un ID à chaque EA. Ou, plus précisément, je ne vois rien qui n'implique pas quelque chose de très désagréable, comme la génération d'un ID unique, puis la modification du fichier .chr de l'EA pour stocker l'ID dans les paramètres externes de l'EA.

>>Comment la nième instance de l'EA pourrait-elle créer son fichier chartyy.chr?

.

en supposant qu'une instance puisse réellement mapper son propre fichier .chr :

si la source de l'EA a : extern int myID = <someCompileTimeVal> ;

alors toute instance qui voit <someCompileTimeVal> peut supposer que c'est la 'première fois' -> génère son id -> modifie la ligne myID -> crée des fichiers de récupération en utilisant l'unicité de myID ,...

puis lors de la détection du redémarrage, accéder à son fichier .chr pour p/u myID qui serait la clé maîtresse pour permettre le remappage des fichiers...

.

ex :

chart02.chr

<chart>
symbol=EURUSD
période=15
..

..

<expert>
name=LMT 1.8
flags=343
window_num=0
<inputs>
myID=<someCompileTimeVal>

...

</inputs>
</expert>
EOF


Au secours ! !

.

Et, pour le divertissement général, ce qui suit ne fait pas vraiment avancer la discussion, mais il remplace l'entrée du hachage djb2 par une valeur qui est garantie comme étant unique (au prix de nécessiter des appels de DLL). Je ne sais pas à quel point djb2 est censé être bon pour des choses comme les GUIDs, mais je viens d'essayer de générer 1.000.000 d'IDs sans aucune collision.

J'ai utilisé PsPad ed pour aspirer les 1 000 000 et j'ai fait un tri avec remove dups coché.

>>Mais... Comment as-tu fait cette détection "...sans aucune collision." ?

 

"Et, pour le divertissement général, ce qui suit ne fait pas vraiment avancer la discussion de quelque façon que ce soit, mais il remplace l'entrée du hachage djb2 avec une valeur qui est garantie d'être unique (au prix de nécessiter des appels DLL). Je ne sais pas à quel point djb2 est censé être bon pour des choses comme les GUIDs, mais je viens d'essayer de générer 1.000.000 d'IDs sans aucune collision".

.

Pour info, j'ai trouvé des collisions dans mes 1 million d'appels du code

trié EOF

.

sorted + dups removed EOF

 
fbj:

>>Comment la nième instance d'EA pourrait-elle p/u son fichier chartyy.chr?

.

en supposant qu'une instance puisse réellement mapper son propre fichier .chr :

si la source de l'EA a : extern int myID = <someCompileTimeVal> ;

alors toute instance qui voit <someCompileTimeVal> peut supposer que c'est la 'première fois' -> génère son id -> modifie la ligne myID -> crée des fichiers de récupération en utilisant l'unicité de myID ,...

puis lors de la détection du redémarrage, il accède à son fichier .chr pour p/u myID qui serait la clé maîtresse pour permettre le remappage des fichiers...

Vous avez raison. J'avais oublié qu'il n'y a pas de moyen évident pour un EA d'identifier son fichier .chr s'il y a plusieurs EA pour le même symbole et la même période. Je pensais qu'il pourrait créer un objet d'étiquette caché contenant quelque chose comme un GUID, puis rechercher le fichier .chr qui contient la valeur correcte. Cependant, je suis presque sûr que le fichier .chr n'est pas mis à jour lorsqu'un nouvel objet est ajouté au graphique.


Et il y a un autre problème. Je suis à peu près sûr que MT4 conserve les informations sur le graphique en mémoire, écrit dans le fichier .chr lorsque MT4 est fermé (ou lorsqu'une modification est apportée aux propriétés de l'EA), ce qui écraserait donc toute modification apportée par l'EA lui-même au fichier .chr pendant son exécution. Si vous étiez incroyablement courageux, vous pourriez essayer de définir la propriété externe en simulant des pressions sur les touches - en appelant la fenêtre des propriétés, en vous déplaçant vers le paramètre requis, en le modifiant, en appuyant sur Entrée, etc.

 
fbj:

Pour info, j'ai trouvé des collisions dans mes 1 million d'appels du code

trié EOF

En le réexécutant, j'ai fait de même : 172 collisions en 1 000 000 d'essais.

 
jjc wrote >>

Vous avez raison. J'avais oublié qu'il n'y a pas de moyen évident pour un EA d'identifier son fichier .chr s'il y a plusieurs EA pour le même symbole et la même période. Je pensais qu'il pourrait créer un objet d'étiquette caché contenant quelque chose comme un GUID, puis rechercher le fichier .chr qui contient la valeur correcte. Cependant, je suis presque sûr que le fichier .chr n'est pas mis à jour lorsqu'un nouvel objet est ajouté au graphique.

Et il y a un autre problème. Je suis à peu près sûr que MT4 conserve les informations sur le graphique en mémoire, écrit dans le fichier .chr lorsque MT4 est fermé (ou lorsqu'une modification est apportée aux propriétés de l'EA), ce qui écraserait donc toute modification apportée par l'EA lui-même au fichier .chr pendant son exécution. Si vous étiez incroyablement courageux, vous pourriez essayer de définir la propriété externe en simulant des pressions sur les touches - en appelant la fenêtre des propriétés, en vous déplaçant vers le paramètre requis, en le modifiant, en appuyant sur Entrée, etc.

J'ai lu ce qui précède -> je suis allé faire un peu d'exercice -> et pendant la douche les cellules grises crient OBJECT. Vous tuez la route .chr mais les deux mots "label object" ont provoqué cette explosion cérébrale :)

Alors, qu'en est-il ? J'oublie pour le moment d'obtenir l'identification garantie à 100%. L'autre partie est cette mémoire d'état récupérable contenant l'ID d'un EA.

Et bien...

1. void vArchiveID (int iID), int iRestoreID () [et int iGetNewID () à voir dans un autre post SI celui-ci est correct :]

2. vArchiveID() crée un objet [caché ?] label ? sur le tableau de la mémoire d'état de l'EA.

Le nom de l'objet DOIT être le même pour tous les EA appelants... donc .ex4 lib ou .mqh lib pour (1).

3. Le CT fait faillite ou l'EA fait faillite, etc.

4. au redémarrage, le premier travail de l'EA est d'appeler iRestoreID() qui renvoie -1 si aucun objet sur le graphique ou l'ID archivé de l'exécution précédente.

5. si pas d'ID, appelle iGetNewID() puis vArchiveID() et met en place [pour la première fois] le fichier de vidage.

6. si l'ID est "restauré", il récupère joyeusement le dernier état via les fichiers de vidage...

..

Qu'en pensez-vous ?

 
fbj:

[...]

Qu'en pensez-vous ?

Ce que vous suggérez est - je pense - exactement ce à quoi je faisais allusion dans mon message daté de 14:43. Le seul danger de cette méthode - et la seule raison de manipuler directement le fichier .chr pour définir les propriétés externes - est d'éliminer la possibilité que les utilisateurs suppriment accidentellement des objets du graphique. Mais même cela peut être largement surmonté en s'assurant que l'objet est recréé, si nécessaire, dans deinit().


Mais BB/CB peut considérer que la dépendance au fichier .chr est inacceptable. Ils pourraient vouloir quelque chose qui peut être récupéré uniquement à partir de données détenues hors site (c'est-à-dire la liste des transactions détenue par le courtier).

 

J'ai été absent de ce fil pendant un moment.


On dirait que nous ajoutons un certain degré de complexité afin de permettre la récupération avec des nombres magiques automatisés, non ? Par exemple, pour qu'un stupide morceau de code réincarné puisse trouver qui il était dans une vie antérieure alors qu'il ne sait que ce qu'il est et où il est. Pas nécessairement une mauvaise chose. Mais...


Cela m'a fait penser qu'il serait utile de documenter (de manière très concise) :

- Les critères pour décider de mettre en place des nombres magiques

- Critères pour décider d'utiliser la génération automatique de nombres magiques

- Critères de décision pour l'implémentation d'une couche de persistance

- Critères pour décider de l'accès aux globaux ou aux fichiers pour la persistance.


La raison pour laquelle je suggère ceci est d'éviter que tout le monde pense qu'il faut implémenter l'évier de la cuisine dans son EE.


Opinions ?


CB


- Il ne me reste plus que 8 messages avant de faire une pause pour un petit moment.

 

oui, en fin de compte, l'évier de cuisine est très probablement sur ce site, tout académique. Pour moi, la première préoccupation prioritaire est d'avoir un ID d'expert garanti auto[make|acquire]. Une valeur qui peut être utilisée à de nombreuses fins.

Avoir un moyen unique d'accéder aux fichiers de vidage au redémarrage est au mieux aléatoire et, dans tous les cas, exige que les utilisateurs adhèrent à un ensemble de règles d'utilisation d'EA. Plusieurs instances ccy+période+EA n'est pas une option.

J'avais l'intention que n'importe quelle instance soit capable de déterminer qui était moi avant le redémarrage et il s'avère que c'est inapplicable. Pour ma part, je ne ferais confiance à aucun utilisateur pour suivre les règles les plus élémentaires. Si je ne peux pas être totalement sûr d'une méthode automatique, je n'adopterais pas une solution intermédiaire nécessitant l'intervention de l'utilisateur.

.

En utilisant CoCreateGuid() i/f de jjc, je vais générer suffisamment de nombres non répétitifs. Assez est subjectif mais je vais pour beaucoup... Couplé avec un morceau de code de bibliothèque comme fonction de serveur d'accès aux ressources du fichier contenant les numéros. La quantité de numéros sera telle qu'au moins 2 ans peuvent s'écouler sans jamais réutiliser un numéro. Au moment où EOF est atteint, il passe à BOF et continue à fournir des numéros. Mes calculs sont basés sur 10 demandeurs fonctionnant 5 jours par semaine et 50 semaines par an, où chaque jour un demandeur pourrait avoir besoin de 20 nouveaux identifiants. Ce résultat est ensuite doublé. Une quantité absurde de chiffres - en gros 200 000. Oui, une fonctionnalité de l'âge de pierre, mais étanche, sans aucune nécessité de dépendre du terminal de quelque manière que ce soit, au-delà de la capacité d'exécuter mon code. Bien sûr, on pourrait continuer pendant des siècles à parler des ramifications d'un, 10 ou 100 fichiers, de leurs emplacements physiques et des mécanismes d'accès. En fin de compte, le système est bien meilleur que ma pitoyable fonction make expert id et est étanche en ce qui concerne l'unicité du numéro pour [en réalité] plus de 2 ans.

.

CB, 666 doit être le chiffre porte-bonheur des pilotes d'hélicoptères... :\N

1234
Nouveau commentaire
Raison: