MQL : sécurité ou opportunité - page 5
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
Allez, c'était un chiffre bidon dès le départ. Demandez des fichiers en mémoire, c'est censé être beaucoup plus facile à mettre en œuvre que le mappage et plus efficace.
MQL : Sécurité et possibilités
Renat, 2013.04.25 15:57
On a juste fait des pips, donc on n'a pas besoin d'utiliser des fichiers.
Il n'y a pas de communication efficace dans les deux sens. Les tuyaux ne fonctionnent pas, tout le monde l'a probablement compris maintenant... Des fichiers en mémoire ?
Autre question : dois-je comprendre que vous ne pouvez pas mettre sur le marché un code qui obtient des informations d'une ressource tierce via des pipelines ?
Nous avons juste créé les pips pour que vous n'ayez pas à utiliser de fichiers.
Je comprends parfaitement pourquoi les pips du serveur dans le terminal. Seulement et uniquement (tout le reste n'est que prétexte) pour une seule tâche - combiner les terminaux à des fins d'arbitrage. Mais cela ne fait pas partie de nos tâches.
Qui veut vraiment faire des échanges inter-processeurs, il suffit d'implémenter un pipe-server multi-canaux. Mais vous ne pouvez pas vendre cela sur un marché, et c'est exactement le but que vous poursuivez.
Vous avez tort au sujet de seulement et seulement.
Arbitrage, copieurs, mixeurs (c'est lorsque vous exécutez plusieurs Expert Advisors achetés sur un marché et créez une position de couverture à partir de ceux-ci), ...
Maintenant, Joo en a besoin pour son AG. On ne sait jamais ce que la fantaisie du programmeur va donner.
Je veux dire qu'il est très difficile de prévoir ce que vous pouvez accumuler avec une nouvelle fonctionnalité.
Et en fait vous n'avez pas vraiment besoin d'anticiper (comme pas une priorité), les gens ont un besoin,
Si c'est le cas, pourquoi ne pas leur en donner l'occasion.
Vous savez très bien que toute extension est un plus pour le langage d'application.
SZ
Je comprends qu'il est difficile de comprendre la solution future, mais il y a déjà une solution - les "fichiers".
Ils ne se contentent pas d'une seule chose "bat une vis", tout le reste est vérifié et revérifié.
Il ne s'agit pas de réinventer la roue, mais d'apporter une solution plus organique à ce qui existe déjà.
SZY
Voici encore une autre façon d'utiliser les fichiers virtuels : au lieu d'une interface à boutons, vous créez une interface bitmap, interactive en direct et très élaborée (avec des boutons ronds, par exemple) et vous calculez tout cela en OpenCL à la volée. Vous pourriez au moins diffuser les infos télévisées sur la carte. Vous avez un exemple d'OpenCL, faites-le tourner pendant un mois et voyez par vous-même ce qu'il adviendra du disque.
Nous avons juste créé les pips pour que vous n'ayez pas à utiliser de fichiers.
Je comprends parfaitement pourquoi les pips du serveur dans le terminal. Seulement et uniquement (tout le reste n'est que prétexte) pour une seule tâche - combiner les terminaux à des fins d'arbitrage. Mais cela ne fait pas partie de nos tâches.
Qui veut vraiment faire des échanges inter-processeurs, il suffit d'implémenter un serveur pip-server multi-canaux. Mais vous ne pouvez pas vendre cela sur le marché, et c'est le but.
Mais qu'en est-il dans le bac à sable d'un seul terminal ? Et uniquement dans MQL5, sans dll ?
Je comprends que la difficulté est que le conseiller expert sur le terminal et l'EA dans le testeur sont séparés dans l'espace mémoire en raison du fait que le terminal et le testeur sont des processus différents. Il semble que cette séparation même entre le testeur et le terminal conduise à un tel "gouffre".
Qu'en est-il dans un bac à sable à terminal unique ? Et uniquement dans MQL5, sans dlls ?
Je comprends que la difficulté est que le conseiller expert sur le terminal et l'EA dans le testeur sont séparés dans l'espace mémoire parce que le terminal et le testeur sont des processus différents. Il semble que cette séparation même entre le testeur et le terminal conduise à un tel "gouffre".
Seul l'expert du testeur (même sur un ordinateur physiquement différent ou même dans le nuage) peut transférer des données à l'expert du terminal en utilisant des trames. C'est-à-dire qu'il n'y a en fait aucun écart
Yuk. Uck. (la paupière supérieure gauche est passée en mode vibration superficielle)
Et derrière ? Vous devez obtenir un lot d'informations sur l'agent (qui ne lui est destiné qu'à lui) qui doit être traité au début de l'exécution et renvoyer le résultat à la fin de l'exécution.
Uck. Yuk. (la paupière supérieure gauche passe en mode de vibration superficielle)
Et derrière ? Vous avez besoin d'obtenir un lot d'informations sur l'agent (destiné uniquement à l'agent) à traiter au début de l'exécution et de transmettre le résultat en retour à la fin de l'exécution.
Yuk. Uck. (la paupière supérieure gauche passe en mode de vibration superficielle)
Et derrière ? Il s'agit d'obtenir un lot d'informations sur l'agent (qui lui est destiné uniquement) à traiter au début de l'exécution et à renvoyer le résultat à la fin de l'exécution.
C'est à la fois compliqué et coûteux (surtout dans les cludes). C'est pourtant possible.
Nous ne le ferons pas encore.
Pour faire simple, donnez à l'agent un paramètre d'entrée autre que celui défini par le testeur standard.
C'est à la fois compliqué et coûteux (surtout dans les cludes). C'est pourtant possible.
Nous ne le ferons pas encore.
Pour information - nos serveurs en nuage du MQL5 Cloud Network génèrent normalement environ 5 téraoctets de trafic par jour, parfois jusqu'à 10 Tb.
Si un trafic personnalisé illimité est envoyé à ce réseau avec la garantie que chaque agent peut être atteint, le réseau ne se sentira pas très bien.