Est-il possible d'implémenter une comptabilité FIABLE de la structure des positions agrégées dans MT5 ? - page 31
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Combien de...
Les banques de la Fédération de Russie sont les successeurs du système bancaire de l'URSS, le système bancaire de l'URSS est le successeur de la banque de la Russie tsariste, la banque de la CR est le successeur de ...
Faites le calcul...
;)
Peut-être voudraient-ils que ceux qui les entourent le croient. Mais en fait, ce sont des nouveaux riches sans histoire, sans nom, sans réputation.
Le fait est qu'une partie de cette routine, typique du trading multi-expert dans MT4, était automatique et intégrée dans l'architecture, ce qui n'est pas le cas dans MT5. Ce qui, bien sûr, n'est pas une fatalité, mais ne convient pas à tout le monde.
Je dirais même que ce n'est pas pratique ou confortable pour tout le monde.
Moi non plus.
Mais dans la plupart des cas, c'est juste une question d'habitude :
Est-il possible d'implémenter dans MT5 une comptabilité FIABLE de la structure d'une position agrégée ?
peut-être
Enregistrez dans le fichier les informations qui sont perdues lorsque vous passez du système de lot au système de compensation.
Cela ne ralentira pas les performances de vos EAs.
-----
en fait, il serait intéressant d'écouter les développeurs
pourquoi ils s'opposent à la mise en œuvre simultanée des deux systèmes
Je pense que cela augmenterait sérieusement la taille de la distribution.
et aussi ralentir l'ensemble du système.
mais vous devriez leur demander.
Est-il possible d'implémenter une comptabilité FIABLE de la structure des positions agrégées dans MT5 ?
possible
sauvegarder dans un fichier les informations qui sont perdues lorsque vous passez du système de lot au système de compensation.
Cela ne ralentira pas le travail de vos conseillers experts.
Le problème n'est pas la complexité de la mise en œuvre, mais la fiabilité de la solution. Une telle méthode a déjà été discutée et des exemples de son manque de fiabilité ont été donnés.
Il convient de noter que ces exemples, ainsi que le concept de "fiabilité" lui-même, ne convainquent pas grand monde. Vous substituez couramment des concepts, et par "fiabilité" vous entendez autre chose.
bingo - le millième flubber !
La question ne porte pas sur la complexité de la mise en œuvre, mais sur la fiabilité de la solution. Cette méthode a déjà été discutée et des exemples de son manque de fiabilité ont été donnés.
Alors dis-moi, imbécile (désolé d'avance, je n'ai pas lu le sujet en premier, beaucoup de texte)
en quoi la lecture d'un fichier est-elle différente de la lecture de l'historique ou de l'appel d'une fonction µl4 standard ?
vous pouvez mettre ce que vous voulez dans le fichier
Vous pouvez définir l'heure d'ouverture, le prix d'ouverture et le nombre de tickets...
tout ce que vous voulez :)
Alors dis-moi, imbécile (désolé d'avance, je n'ai pas lu le sujet en premier, beaucoup de texte)
en quoi la lecture d'un fichier est-elle différente de la lecture de l'historique ou de l'appel d'une fonction µl4 standard ?
vous pouvez mettre ce que vous voulez dans le fichier
et l'heure d'ouverture, et le prix d'ouverture, et le numéro de ticket...
ce que vous voulez :)
Que se passe-t-il si le fichier a été perdu ? ou si une défaillance s'est produite lors de l'enregistrement dans le fichier, de sorte que le contenu et les commandes ne correspondent pas avec le serveur ? ou si vous devez vous connecter à partir d'une autre entreprise sans le fichier ? Il existe de nombreuses possibilités de perdre ces informations et si cette perte est involontaire sur le plan algorithmique, elle peut entraîner de graves conséquences financières. C'est-à-dire que tout cela ajoute un nouveau lien qui peut réduire la fiabilité du système dans son ensemble.
Alors dis-moi, imbécile (désolé d'avance, je n'ai pas lu le sujet en premier, beaucoup de texte)
en quoi la lecture d'un fichier est-elle différente de la lecture de l'historique ou de l'appel d'une fonction µl4 standard ?
vous pouvez mettre ce que vous voulez dans le fichier
Vous pouvez définir l'heure d'ouverture, le prix d'ouverture et le nombre de tickets...
ce que vous voulez :)
A la question en quoi est-ce différent, ainsi qu'à la question précédente sur "la mise en œuvre de deux systèmes comptables et les complexités".
Il n'y a pas de complications et certainement pas d'augmentation de la distribution...
La question de la comptabilité se situe dans le plan de la plupart qui est de simples requêtes à la base de données du serveur.
Je répète : vers la base de données du serveur, c'est-à-dire où que nous soyons, à partir de n'importe quel terminal,
a tué notre fichier ou pas, le bon fonctionnement est assuré... par opposition à l'auto-construction...
si un "hacker maléfique" enfonçait un marteau dans un disque dur.
et le fichier est dépressurisé et les données qu'il contient sont perdues.
Mais dans ce cas, même MT4 ne vous sauvera pas, car l'EA est mort.
Dans d'autres cas, comme une panne de courant soudaine,
les données sur le disque (et donc dans le fichier) sont sauvegardées
---
il y a cependant la possibilité qu'un vilain programme (par exemple, un autre expert)
va dans le fichier et efface par inadvertance les données
mais ce n'est pas une question de qualité du terminal mais de la qualité du programmeur :)
En pratique, un dossier ne peut être tué sans possibilité de réanimation que dans un seul cas :
si un "hacker maléfique" enfonçait un marteau dans un disque dur.
et que l'un d'entre eux a été dépressurisé avec une perte totale des données stockées sur lui
mais dans ce cas, même MT4 ne vous sauvera pas car le conseiller expert est mort.
Dans d'autres cas, comme une panne de courant soudaine,
>> les données présentes sur le disque (et donc dans le fichier) sont sauvegardées.
---
il y a cependant la possibilité qu'un vilain programme (par exemple, un autre expert)
va dans ce fichier et efface les données par inadvertance.
mais ce n'est pas une question de qualité du terminal, mais de qualité du programmeur :)
Il n'est même pas nécessaire de tuer le fichier, il suffit de ne pas écraser certaines informations en cas de panne, par exemple.
Le maintien des positions est décalé par rapport à l'utilisateur et peut être une source supplémentaire d'erreurs. Même purement logique lors de la mise en œuvre de ce bloc.