[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 389
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
Des tests datant du 168e siècle avant J.-C. ? :)
1) Problème : chaque script (EA) doit être conscient de la présence de tous les autres.
2) Problème : s'il y a un échec, les globaux de celui qui a échoué resteront inoccupés et la file d'attente sera bloquée.
3) Solution :
Chaque exp organise 1 globalka avec le nom - préfixe commun + poignée de fenêtre + symbole. La valeur du globalka est le temps du dernier tick sur cet instrument. 2 global commun avec sa propre poignée (après avoir travaillé, il écrit sa propre poignée dans celui-ci ou l'efface s'il est le plus ancien)
La file d'attente est classée par ordre croissant (poignées), la plus ancienne met la deuxième globale à zéro.
dans chaque exp, nous créons trois tableaux (par manque de structures) - symbole/manipulateur/dernier temps d'accès/dernier temps de tic.
tous les EXPs gardent la trace de (last access time/last tick time) pour chacun d'entre eux et dès qu'ils sont différents (un des EXPs tombe en panne) les deux globaux de l'EXP en panne sont supprimés et il est considéré comme inactif. ses cellules dans les tableaux sont supprimées (le tableau est reconstruit).
la file d'attente est restaurée
cette opération sera en fait effectuée par l'EA se trouvant sur le graphique le plus actif (ticks fréquents).
lorsqu'elle est désinitialisée normalement, chaque expo nettoie après elle-même.
saut max - une coche.
ZS. et en général, il est préférable de faire une seule multidevise
C'est à peu près ce que j'ai fait pour AIASM complex, de sorte que vous pouvez exécuter plusieurs instances, mais tout est dans une DLL. Cette DLL n'est pas chargeable.
Bien sûr, nous devons créer un seul EA pour le trading afin d'éviter les problèmes de synchronisation.
Est-ce que ce sera correct ?
Je ne suis pas bon en anglais, si quelque chose est faux, veuillez m'excuser. Nous obtenons 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.
Oui, c'est toujours un, parce que l'autre chose est, si vous travaillez non pas avec M1 TF, mais avec des ticks, alors oui - de bin à bin Δt sera variable.Je pense que je comprends. MACD est un delta de deux moyennes, donc la vitesse sera moyenne, pas vraie. On peut y voir une tentative d'introduire le système SI dans l'analyse afin de la systématiser et de la rendre plus compréhensible.
Pourquoi avez-vous mentionné MACD tout de suite ? Il a sauté sans l'expliquer. L'approche doit immédiatement être scientifique. C'est-à-dire que vous ne pouvez pas le faire sans analyse/synthèse. Il est inutile de s'occuper du prix, il est trop complexe. Vous ne pouvez pas l'analyser comme ça. Une analyse spectrale est nécessaire. C'est-à-dire la décomposition en éléments plus simples. La composante la plus simple est une onde sinusoïdale.
Qu'obtiendrons-nous si nous prenons la dérivée du prix (après tout, le prix lui-même est déjà la vitesse temporelle du prix) ? Qu'est-ce qu'on obtient ? Il est à peine utilisable.
Qu'est-ce qu'on obtient si on prend la dérivée du sinus ? Cosinus, bien sûr. C'est-à-dire qu'on obtient l'avance de 90 degrés.
Quoi qu'il en soit, le MACD est l'un des indicateurs intégrés les plus importants. C'est un filtre passe-bande. Il montre le taux du prix moyen d'une petite période par rapport à la tranche spectrale, qui est déterminée par une plus grande période. L'intérêt réside dans l'ensemble de ces tranches continues. C'est-à-dire, le spectre. Bien sûr, alors la synthèse... Si tu as des yeux, tu peux voir beaucoup de choses intéressantes dans l'image.
Je pourrais être un peu déçu. Les méthodes de filtrage incluses sont loin d'être suffisantes. C'est un malentendu total, pas des filtres. Vous avez besoin de filtres appropriés avec des fronts raides.
Junko, tu es une d-i-B*&*%#o^i=d. Comment as-tu pu devenir 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, c'est comme une paralysie du cerveau.
Tu n'as même pas essayé de me parler de ton histoire de fusion de fils. Tout ce que j'ai lu de vous auparavant est un algorithme défectueux. Pas la peine de perdre votre temps avec ça.
Il me semble également que vous ne parvenez pas à trouver des ressources communes et que c'est la raison pour laquelle vous ralentissez les fils de discussion. C'est la mauvaise approche. Les flux ne peuvent pas être ralentis et mis en file d'attente. C'est aussi une règle. Vous devez allouer une ou plusieurs ressources partagées et organiser un accès synchrone à celles-ci avec un temps d'accès minimal. Je vous rappelle que l'organisation de l'accès atomique est la synchronisation. Sinon, vous vous énervez à chaque fois.
C'est toi qui parles. J'ai vu votre code... C'est comme la maternelle... :-((
Zhunko:
Encore des émotions ? Travaillez sur votre psyché. Il vous a dit quels exercices faire. Pratiquez-les.Vous n'avez pas encore essayé de parler de votre bidule de combinaison de fils. Tout ce que j'ai lu de vous auparavant est un algorithme défectueux. Il est inutile de perdre votre temps avec elle.
Il me semble également que vous ne parvenez pas à trouver des ressources communes et que c'est la raison pour laquelle vous ralentissez les fils de discussion. C'est la mauvaise approche. Les flux ne peuvent pas être ralentis et mis en file d'attente. C'est aussi une règle. Vous devez allouer une ou plusieurs ressources communes et organiser un accès synchrone à celles-ci avec un temps d'accès minimal. Je vous rappelle que l'organisation de l'accès atomique est la synchronisation. Sinon, vous vous énervez à chaque fois.
C'est toi qui parles. J'ai vu votre code... C'est comme la maternelle... :-((
Va voir un médecin, fais soigner ta folie des grandeurs.
Si je ne le fais pas, allez-y et faites votre cyclisme amateur.
Je n'ai pas de problème à fusionner les fils de discussion. Essayez de le relire, vous y arriverez peut-être, mais c'est peu probable. Tu t'embrouilles avec les fils parce que tu ne réalises pas que tu n'as toujours pas un accès atomique suffisant. C'est le deuxième jour et vous n'y arrivez toujours pas.
Vous pensez aussi... Vous n'imaginez pas des choses, vous délirez.
Encore une fois, fournir un accès atomique n'est pas fournir une file d'attente. Tu es totalement coincé, alley !
Arrêtez de vous comporter comme un gourou !
Va voir un médecin et fais soigner ta folie des grandeurs, espèce de sous-performant.
Si je ne te le dis pas, retourne à ton cyclisme amateur.
Je n'ai pas de problème à fusionner les fils de discussion. Essayez de le relire, vous comprendrez peut-être, mais c'est peu probable.
Vous pensez aussi... Vous ne vous imaginez pas des choses, mais vous délirez.
Permettez-moi de vous rappeler une fois de plus que fournir un accès atomique n'est pas une file d'attente. Tu es totalement coincé, alley !
Arrêtez de vous comporter comme un gourou !
J'ai compris depuis longtemps que l'accès atomique ne fournit pas votre file d'attente :-)). Mais il fournit une file d'attente, car le système l'utilisera. C'est suffisant pour la synchronisation.
Vous devez écrire de manière à ce que l'ordre de traitement des files d'attente ne soit pas important.
C'est toi qui parles. J'ai vu ton code... C'est le jardin d'enfants... :-((
Encore une fois, un grand bravo ! Félicitations pour un autre pépin. Ce code n'a été publié nulle part.
J'ai compris depuis longtemps que l'accès atomique ne fournit pas votre file d'attente :-)) Mais il fournit une file d'attente, car le système l'affiche. C'est suffisant pour la synchronisation.
Vous devez l'écrire de manière à ce que l'ordre de traitement des files d'attente ne soit pas important.
Vous ne le fournissez pas non plus, mais vous ne le comprenez pas.
J'ai compris depuis longtemps que l'accès atomique ne fournit pas votre file d'attente :-)) Mais il fournit une file d'attente, puisque le système l'affiche. C'est suffisant pour la synchronisation.
Vous devez l'écrire de manière à ce que l'ordre de traitement des files d'attente soit sans importance.
Vous avez vraiment une paralysie du cerveau, ou l'absence d'une partie de celui-ci. Nous avons déjà dit que le système ne sait pas quel thread a été réellement traité et quel thread est resté inactif. Mais vous êtes le seul à ne pas comprendre ce dont vous parlez et à ne pas le faire. ))))))))
En outre, à en juger par vos messages, vous avez un problème de fourniture d'accès partagé à une ressource et de traitement consécutif de plusieurs threads.
Vous ne l'avez pas non plus, seulement vous n'arrivez pas à le comprendre.
Regardez le journal. Tout est traité.
Cherchez vous-même, mais apparemment pas de vue. La cohérence est assurée par pur hasard parce que le processeur a une vitesse élevée et parce qu'il exécute un tas d'autres tâches Windows en parallèle.
C'est en regardant ce journal que j'ai commencé.
Voyez par vous-même, mais apparemment pas de vue. La séquence est assurée par pur hasard, en raison de la vitesse élevée du processeur et du fait qu'il exécute en parallèle un tas d'autres tâches coupables.