dll et du marché. - page 3
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
О. Je suppose qu'il était temps et que l'auteur du sujet avait quelque chose à dire. C'est chauffé.
En bref. Nous avons besoin d'un mécanisme, j'insiste sur le terme bidirectionnel, pour échanger des informations entre owl on agent (local pour l'instant, mais accrochez-vous MQ, plus tard les utilisateurs demanderont aussi des agents distants) et owl on chart.
Les horizons sont comparables à... Les horizons sont comparables à... la combinaison nuage de lancement et OCL et mql5.
Je vais donner aux esprits curieux l'occasion de s'échauffer encore plus. A l'attention des experts un bonjour spécial et bravo au crabe pour avoir essayé d'inventer la possibilité d'utiliser des plugins pour les experts.
Horizons - comparable à... le lancement du cloud et la combinaison d'OCL et de mql5.
Andrei, tout est-il prêt ? À quel stade de la mise en œuvre ?
si la question ne concerne que l'accès aux dll - peut-être pourriez-vous déclarer votre problème dans son intégralité, afin que Renat puisse sentir vos horizons... ...et peut-être que le MC suggérera une solution.
S'il ne s'agit que d'une question d'accès aux dll, vous pourriez peut-être exposer votre problème en entier, afin que Renat puisse sentir vos horizons... et peut-être que MK pourrait suggérer une solution.
Allez, c'est ridicule. Il coulera de la même manière qu'il l'a fait (jusqu'à présent, avec le problème des services OpenCL) avec OpenCL.
On dirait un wow, mais en fait personne n'en a besoin sauf 3,5 personnes.
Il semble être wow, mais en fait personne n'en a besoin sauf 3,5 personnes.
Nous parlons donc d'Horizons.
Si la perspective se présente (Joo essaiera d'apporter le projet au CM en couleurs vives), ils se rencontreront et feront la fonctionnalité nécessaire pour cela.
donc c'est à propos d'Horizons, n'est-ce pas ?
Si la perspective se présente (Joo essaiera de sensibiliser les MCs au projet en couleurs vives), ils les rencontreront et feront la fonctionnalité nécessaire pour cela.
Horizons y est simple (discuté 100 fois), utilisant une sorte de fonctionnalité de communication pour glisser la motte leur AG.
ZZY Mais les horizons de la fonctionnalité de liaison elle-même peuvent être plus larges.
Mais les horizons de la fonctionnalité de liaison elle-même peuvent être plus larges.
C'est de ça que je parle.
Tu le dis très bien. J'ai parlé de l'OCL qui s'est stabilisé en temps voulu (et qui a soudainement augmenté après un certain temps) et de ce qui a été discuté 100 fois - le transfert d'informations aux agents et "l'étroitesse du champ" dans le nombre de paramètres optimisés.
J'ai pensé ajouter la fonctionnalité nécessaire (je souligne - au moyen de MQL5) de МТ5 et ainsi gagner un peu d'argent (pourquoi, personne n'a de crédits ou d'hypothèques), mais non - pas moyen.
Cet article limite le nombre de paramètres optimisés.
2. Monocritérialité de l'optimisation (désolé d'avoir inventé de nouveaux mots).
Incapacité à gérer le processus d'évaporation du sable.
Ce n'est pas du tout un reproche aux développeurs. Au contraire, il s'agit d'une fantaisie pour les développeurs de programmes MQL5 ! Mais là encore, il y a des goulets d'étranglement, comme l'indique le titre du sujet. Si la possibilité d'une transmission bidirectionnelle apparaît, les problèmes sont résolus. Il ne sera pas nécessaire de mettre en œuvre ces trois points - tout se fera tout seul.
Andrei, êtes-vous prêt ? À quel stade de la mise en œuvre ?
S'il n'y a qu'une question d'accès à la dll - peut-être pourriez-vous nous exposer votre problème en détail, afin que Renat puisse sentir vos horizons... ...et peut-être que le MC pourrait proposer une solution.
Il est "prêt" .... Non, il ne l'est pas. Il me faut toujours beaucoup de temps pour fermenter mais il durcit rapidement.
Oui, c'est prêt. C'est prêt à 95%.
Le défi (sans entrer dans les détails) :
1. Nous avons besoin d'un mécanisme établi d'échange bidirectionnel d'informations entre le "serveur" de la carte et le "client" de l'agent (nécessaire avant tout).
2. Besoin d'un mécanisme interne permettant d'exécuter le testeur/optimiseur interne par le "serveur" sur le graphique (nécessaire mais pas critique)
C'est à peu près tout.
Horizons :
1. Il n'est pas nécessaire d'inventer un langage de contrôle de l'optimisation des scripts MQ (les utilisateurs l'ont demandé il y a quelque temps).
2. le nuage commencera à être utilisé pour des tâches qui ne sont pas uniquement liées au commerce (et ce public est beaucoup plus large qu'aujourd'hui).
3. il n'est pas nécessaire de se battre avec l'AG interne pour limiter le nombre de paramètres d'opt-in.
4...
Vous pouvez continuer sans énumérer davantage.
О ! J'ai oublié d'ajouter. L'environnement de marché créé dans un testeur interne est coûteux. Quel que soit le degré de sophistication du testeur maison (calculatrice), il ne pourra jamais se rapprocher du testeur du personnel en termes de capacités et de qualité des tests. Il y a beaucoup de choses à prendre en compte - le spread, le swap, le... Et c'est un travail de singe que de corriger la calculatrice pour chaque tâche. Je veux utiliser le testeur/optimiseur standard.
donc s'il vous plaît ajoutez le mode serveur MQL à pips. est-ce autorisé ? ou la sécurité sera-t-elle compromise aussi ?
Tous les appels dll sont interdits sur le marché.
OK. Et si vous faisiez ce qui suit :
1. Le produit lui-même est mis sur le marché.
2. La partie du code responsable de faire référence à la dll (win api), de la mettre dans une bibliothèque et de la mettre dans le codebase. Le code peut même être en code source.
Le point principal est qu'il est nécessaire d'utiliser le FileMapping dans le produit, il est impossible sans lui.