[ARCHIVE]Toute question de débutant, afin de ne pas encombrer le forum. Professionnels, ne passez pas à côté. Je ne peux aller nulle part sans toi - 5. - page 386
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
Le MACD montre la vitesse en pips dans le temps. Si par vitesse de changement vous entendez accélération, vous devez prendre la dérivée de la MACD.
Des résultats intéressants sont obtenus. Je suis en train d'écrire un expert sur ce sujet.
C'est absurde ! Il faut donc prendre la dérivée pour connaître l'accélération plutôt que la vitesse, et il faut prendre la macd pour connaître la vitesse, mais pourquoi pas la dérivée de quelque chose ?
Dans ce cas, au lieu de poignées, les expansions elles-mêmes sont définies avec un index, et la file d'attente sera établie en fonction de l'heure de la première exécution.
Oui. Les poignées ne sont pas utilisées.
Le MACD montre la vitesse en pips dans le temps. Si par vitesse de changement vous entendez accélération, vous devez prendre la dérivée de la MACD.
Des résultats assez intéressants en ressortent. Je suis maintenant en train d'écrire un expert sur ce sujet.
Est-ce la bonne façon de procéder ?
Je ne suis pas très doué, donc si ce n'est pas correct, veuillez m'en excuser. Il indique la vitesse en pips par minute et l'accélération en pips par minute. Ou ai-je tort ?
Oh, j'ai oublié d'expliquer. Comme Δt=1, je n'ai pas divisé par un, je pensais que c'était clair.
Celui-là...
Je pense qu'Arles a trouvé la réponse à la question, car je ne suis pas encore capable de saisir l'essentiel de la solution. Mais c'est parce que je suis un débutant et que j'ai besoin de plus de temps pour apprendre la théorie d'abord, puis pour essayer la pratique. Mais je vais essayer de le maîtriser.
Sergey, quelles sont les questions que vous n'avez pas résolues ? Si c'est le cas :
En d'autres termes, pour répondre à la question d'Arles, si un conseiller expert a enregistré des ordres et fait une "sieste" pendant un certain temps, à ce moment-là, l'autre conseiller expert n'a pas dépassé les limites des fonds alloués (supposons 80 % du dépôt - les deux conseillers experts auront cette taille) et va passer un ordre (entrer la transaction sur le marché). Et quand le 1er reprend le travail (et que le terminal de money management a déjà été calculé la veille), il va aussi ouvrir une transaction dépassant les limites fixées par le Conseiller Expert ?
Si ce système (hypothétiquement) est multiplié par plusieurs EE, peut-il y en avoir une où la gestion des risques sera dans un système critique ?
Est-ce que je comprends bien ce multithreading ? - Si c'est le cas, c'est certainement un gâchis d'un point de vue financier. Mais, comme la probabilité que cela se produise est faible pour les petits comptes, il ne s'agit que d'une hypothèse. Et pour les comptes plus importants, ils écriront probablement eux-mêmes quelque chose. Mais, quand même, il s'avère que c'est vrai ?
Et j'ai une question : s'agit-il d'une position officielle ou s'agit-il seulement de spéculations et d'expériences comme les miennes ?.
Ensuite, il y a le code de la page 378. C'est reparti :
Lorsque le délai est un "travail simulé", insérez une référence au dépôt ou à une autre ressource.Vous pouvez transformer ce bloc de synchronisation en fonction et le placer dans une bibliothèque. Il y aura une fonction synchrone d'accès au dépôt à partir de n'importe quel conseiller expert.
C'est vrai, par question non résolue je voulais dire exactement cette liste de questions.
Le fait que vous ayez trouvé une solution - est très bien et je comprends votre position et l'accepte. Mais ! - Comme je l'ai écrit juste dans le post suivant après le post avec les questions - vous avez proposé la solution suivante, quand vous pouvez créer un programme, dans lequel ces questions seront résolues par l'auteur (programmeur) du programme. Et c'est bien. Mais c'est la prochaine étape. Le fait que vous ayez disséqué cette étape en détail dans la discussion est également très bon pour la compréhension et encore plus pour les débutants inexpérimentés comme moi. Et le fait que vous ayez maintenant proposé des exemples pratiques de la manière de le résoudre. - Merveilleux. C'est-à-dire que vous avez ainsi proposé une solution à ce problème (confirmant indirectement son existence et la nécessité d'une solution). MAIS !
Après tout, quand Arles posait la question, il ne parlait pas des robots corrigés qui peuvent être corrigés de cette manière, mais il voulait dire que lorsque lui ou des milliers d'autres traders utilisent des EAs où ces problèmes ne sont pas réduits, mais conçus pour une simple application sur une paire de devises, ils ne tiennent pas compte du fait qu'il y aura beaucoup d'autres EAs (ou même ce même robot) sur d'autres graphiques. Dans ce cas, cela peut conduire à un chaos (avec un énorme flux d'informations, par exemple lors des communiqués de presse, lorsqu'il y a un grand nombre de transactions dans le monde entier) dans la séquence de résolution des tâches. Le parallélisme et le multithreading étant aux antipodes de la cohérence, cette même cohérence sera brisée (sans solution particulière). Mais ! Encore une fois... Une solution ad hoc n'est rien d'autre qu'un retour à la cohérence. Puisque la file d'attente, terme déjà mentionné ici, n'est rien d'autre qu'une séquence.
D'où la question : est-il nécessaire de créer un multithreading pour ensuite le remettre dans la file d'attente ? - Mais c'est un autre sujet. Moi aussi, je suis allé plus loin dans la réflexion sur le problème initial. Vous êtes différent de vous en une chose - vous essayez déjà de proposer des variantes de solution, alors que je ne peux arriver qu'à une formulation de question, car c'est la limitation d'un débutant.
Je vais copier le schéma que vous avez proposé comme solution, et je vais essayer de le démonter et de le maîtriser en détail. Mais je ne suis pas sûr de pouvoir le faire rapidement. Mais jusqu'à présent, franchement, j'essaie de simplifier au maximum les algorithmes de solution. Et de n'utiliser des solutions complexes que là où il n'y a pas d'autre solution au problème (y compris une approche non logicielle - après tout, le problème peut être résolu au-delà du programme informatique).
====================================
C'est-à-dire, en d'autres termes. - Si la solution que vous proposez n'est pas bloquée, la situation décrite dans la question que vous avez posée sur la gestion des risques peut se produire en cas d'utilisation d'un grand nombre de ces EA ?
... Si un EA a compté les ordres et fait une sieste pendant un certain temps, un autre EA n'a pas encore dépassé les limites des fonds alloués (par exemple, 80% du dépôt - cette taille sera dans les deux EA) et passera un ordre (entrée de la transaction sur le marché). Et quand le 1er reprend le travail (et que le terminal de money management a déjà été calculé la veille), il va aussi ouvrir une transaction dépassant les limites fixées par le Conseiller Expert ?
Si ce système (hypothétiquement) est multiplié par plusieurs Expert Advisors, alors peut-il y en avoir un où la gestion du risque sera dans un système critique ?
Laissez-moi vous expliquer un peu plus. Je ne suis pas sûr que ce soit une situation critique. Donc je le considère comme hypothétique pour le moment. Comme la vitesse de résolution des problèmes est élevée et que les solutions dans l'ordinateur vont probablement "voler" à travers le canal à large débit de l'ordinateur. - Mais peut-être que je me trompe, car selon Arles - il ne reçoit que 2 commandes par tour. Il y a donc un problème.
Oh, j'ai oublié de préciser. Comme Δt=1, je n'ai pas divisé par un, je pensais que c'était clair.
Il s'agit d'une unité d'accès atomique et sans synchronisation. Il n'y a pas de raison de n'appeler que le dépôt de cette manière. L'appel de l'une des fonctions de paramètre de dépôt sera atomique par lui-même, sans aucune modification. Si vous le faites de manière atomique, tout le travail du conseiller expert. C'est ainsi que l'on résout les problèmes - on pense avoir fait quelque chose, mais en fait c'est une illusion.
Je pensais que tu comprendrais enfin ce que j'ai dit cette nuit... :-( Malheureusement, ça n'a pas marché.
Il existe deux façons de programmer cette tâche. Une délicate, comme la vôtre, et une simple, comme la mienne. Si vous avez personnellement besoin de mettre des experts en file d'attente avec vos threads, il est plus facile de tout faire dans un seul expert (thread) et de ne pas les synchroniser.
La tâche à accomplir est de synchroniser l'accès à une ressource. Mon code est suffisant. En même temps, les conseillers experts travaillent indépendamment et en parallèle.
C'est absurde ! Donc, vous devez prendre la dérivée pour connaître l'accélération au lieu de la vitesse, et vous devez prendre le mcd pour connaître la vitesse, mais pourquoi pas la dérivée de quelque chose ?
Je pensais que tu comprendrais enfin ce que j'ai dit cette nuit... :-( Malheureusement, ça n'a pas marché.
Il existe deux façons de programmer cette tâche. Une élaborée, comme la vôtre, et une simple, comme la mienne. Si vous avez personnellement besoin de mettre des experts en file d'attente avec vos threads, il est plus facile de tout faire dans un seul expert (thread) et de ne pas les synchroniser.
La tâche à accomplir est de synchroniser l'accès à une ressource. Mon code est suffisant. En même temps, les conseillers experts travaillent indépendamment et en parallèle.
Je ne comprends pas la question.Junko, tu es d-i-B*&%#o^i=d. Comment peux-tu être aussi stupide ? Vous n'avez même pas la cervelle pour comprendre le problème. Ça ne sert à rien de te parler. Tu ne comprends rien du tout. Mais la position que vous prenez... comme si vous saviez et compreniez tout, mais que vous ne saviez et ne compreniez rien, codant au niveau d'un enfant de maternelle nubo-lamer. Et votre compréhension de tout est au même niveau. Mais votre ego...
Junko, ils te l'expliquent même et tu ne comprends pas, même dans ce cas, ça ressemble à une paralysie cérébrale.
Je ne comprends pas la question.
Cela veut tout dire !
Ce delta sera-t-il toujours égal à un ? ou peut-il être variable ? S'il ne s'agit pas d'un paramètre constant, il est préférable de le mettre (le paramètre) dans la formule.
Oui, ce sera toujours un, parce que C'est une autre question, si nous travaillons avec le tic au lieu de M1 TF, alors oui - d'un bac à l'autre Δt sera variable.
Je ne comprends pas la question.Arrêtez de jurer ! - Que toutes les personnes impliquées sauvent la face.
Tous les lecteurs sont tout aussi stupides et peuvent voir et comprendre les choses par eux-mêmes. Il n'est pas toujours possible d'accepter les positions des autres - c'est ce qu'est la tolérance. Et le fait de devenir personnel ne donne pas une bonne image du professionnel et constitue un mauvais exemple pour les nouveaux arrivants. Si vous jurez, que pouvez-vous exiger des pays moins développés ? Nous devrions nous-mêmes donner le bon exemple dans ces domaines également.
(Désolé pour la publicité du travail politique.) Je suggère que les derniers messages des participants (y compris mon message) soient retirés du forum - qui est "en faveur" est prié de "lever la main" - c'est-à-dire de supprimer les messages.