Mt4 Fin de l'assistance. - page 29
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 principal inconvénient : la POO vous oblige à emprunter la voie de la fragmentation du code en de nombreuses fonctions.
Il est plus facile pour les humains d'accepter un code fragmenté, mais la fragmentation est contre-indiquée pour tout mécanisme.
D'accord, mais quel est l'inconvénient ?
C'est le principal avantage, précisément parce qu'il est plus facile pour une personne de percevoir un code fragmenté !
L'ordinateur doit s'adapter à l'humain, et non l'humain à l'ordinateur.
C'est vrai, mais quel est l'inconvénient ?
C'est le principal avantage ! Justement parce qu'il est plus facile pour une personne de percevoir un code fragmenté !
L'ordinateur doit s'adapter à la personne, et non la personne à l'ordinateur.
Hélas, un développeur doit avant tout penser à l'efficacité de son mécanisme, pas à son confort)).
Sinon, le mécanisme " boitera ".
Le développeur doit s'adapter à l'ordinateur.
Si les cotations proviennent du même serveur, le choix de l'instrument est indifférent. Après tout, les barres sont ouvertes simultanément sur chaque instrument.
Il en va différemment si les sources de citations se trouvent dans différentes parties du monde. Pour les minutes, cela n'a pas d'importance, mais il peut y avoir un problème avec des échéances plus élevées. Peut-être faut-il étudier plus en détail les fonctions temporelles et procéder à une correction précise du temps. Mais c'est la prochaine étape dans le développement de cette solution...
Vous devez faire un étalonnage pour cette fonction...
Au début, je voulais lire tout ce qui était écrit sans moi, au cas où il y aurait déjà une question et une réponse, mais j'ai peur qu'il soit difficile de trouver le post qui doit être cité plus tard.
Pour l'instant, il n'y a qu'une seule question : comme chacun sait, une nouvelle barre n'apparaîtra pas avant le premier tick du nouvel intervalle de temps. Par conséquent, s'il devrait y avoir une barre par millisecondes mais qu'elle est absente, vous pouvez obtenir des lectures de l'indicateur à partir de la mauvaise barre.
J'espère trouver une réponse à la deuxième question, elle a été posée par Artem.
Au début, je voulais lire tout ce qui avait été écrit sans moi, au cas où il y aurait déjà une question et une réponse, mais j'ai peur qu'il soit difficile de trouver le post qui doit être cité.
Jusqu'à présent, une seule question : comme chacun sait, une nouvelle barre n'apparaîtra pas avant le premier tick du nouvel intervalle de temps. Par conséquent, s'il devrait y avoir une barre par millisecondes mais qu'elle est absente, nous pouvons obtenir les valeurs de l'indicateur à partir de la mauvaise barre.
J'espère trouver une réponse à la deuxième question, elle a été posée par Artem.
Oui, nous en avons discuté hier.
J'avais l'habitude de travailler avec une autre plateforme et les barres y étaient formées par le temps indépendamment de l'arrivée des cotations (regardez TWS).
On m'a dit que ce n'était pas le cas avec MT.
Je vais ajouter un contrôle d'arrivée de devis pour confirmer l'événement de l'apparition d'un nouveau bar.
J'ai déjà répondu que les bars ouvrent indépendamment de l'arrivée d'un devis. S'il n'y a pas de cotation, le prix de la nouvelle barre sera le prix de clôture de la barre précédente. Le fait d'une nouvelle barre sera fixé indépendamment de l'arrivée des cotations, par les compteurs eux-mêmes, qui fonctionnent sur une minuterie.
Le cadre temporel spécifique n'a pas d'importance, car il s'agit simplement d'un compteur qui atteint sa valeur et déclenche l'événement de la nouvelle barre de ce cadre temporel. Il s'agit simplement d'une méthode de synchronisation avec l'apparition de nouvelles barres de différentes échéances. LA SYNCHRONISATION.
L'instrument n'a pas d'importance non plus. Si les cotations proviennent d'un seul serveur, cela signifie qu'elles ont la même heure d'apparition des nouvelles barres. Par conséquent, peu importe l'instrument, tant que ces instruments proviennent d'un même point du globe.
Je vais finir ce que j'ai dit et faire d'autres choses. Un peu de bonnes choses).
Et comment expliquer le fait que la clôture de vendredi, la barre précédente de toute période est égale à 1.20333, et l'ouverture de lundi de toute période est égale à 1.20142 ?
Bien sûr, il s'agit du devis d'un courtier, l'autre pourrait être un peu différent, mais il y a une différence dans tous les cas.
Et comment expliquez-vous le fait que la clôture de vendredi, la barre précédente de n'importe quelle période est 1.20333 et que l'ouverture de lundi de n'importe quelle période est également 1.20142 ?
Il s'agit bien sûr des cotations d'un courtier, les autres peuvent être un peu différentes, mais ils ont tous des différences.
Il s'explique par l'écart. Cela se passe à l'ouverture de la session.
Je ne suis pas un expert en trading, donc ne jugez pas mon opinion trop sévèrement).
Et je sais encore moins ce qui se passe sur le marché des changes).
Hélas, le concepteur doit d'abord penser à l'efficacité de son mécanisme, et non à son confort).
Sinon, le mécanisme " boitera ".
Le développeur doit s'adapter à l'ordinateur.
Non.
Laissez l'ordinateur s'adapter à moi. J'ai suffisamment d'autres problèmes. Le développeur ne peut intervenir que là où l'ordinateur n'est pas en mesure d'accomplir la tâche, par exemple dans les goulets d'étranglement où il manque de performance ou de mémoire. Alors, oui, c'est au tour du développeur de s'adapter. Mais jusqu'à présent, je n'ai pas rencontré d'endroits où la POO imposerait une charge supplémentaire tellement importante à l'ordinateur qu'il faudrait la réduire d'une manière ou d'une autre.
Quelque chose comme ça (code pour MQL5) :
Mais je le répète - je suis un partisan d'OOP.
C'est juste un exemple vraiment malheureux pour montrer ce qu'il est impossible de faire en programmation procédurale.
Lorsque j'ai commencé ceci, je n'avais pas l'intention de montrer que tout est possible/impossible à faire, mais juste que ce soit plus pratique à utiliser à l'avenir lorsque j'écrirai mes propres codes.
Mais ça s'est avéré, comme l'a dit V.S., je voulais le meilleur, mais ça s'est avéré comme toujours.
Oh, non.
C'est l'ordinateur qui s'adapte à moi. J'ai suffisamment d'autres problèmes. Le développeur ne peut s'adapter que là où l'ordinateur "ne peut pas gérer", c'est-à-dire dans les "goulets d'étranglement", là où il n'y a pas assez de performance ou de mémoire. Alors, oui, c'est au tour du développeur de s'adapter. Mais jusqu'à présent, je n'ai pas rencontré d'endroits où la POO fournit une charge supplémentaire si importante sur l'ordinateur qu'elle doit être réduite d'une manière ou d'une autre.
La charge sur l'ordinateur est causée par l'attitude négligente du développeur sur la question de la cohérence de son mécanisme. Une volonté d'économiser l'énergie pour améliorer le système. Un gaspillage déraisonnable des ressources informatiques au nom de la facilitation de leur travail.
Tant que l'ordinateur réussit à faire face à un code écrit de manière inefficace, le développeur continuera à "parasiter" la puissance de traitement. C'est une route sans issue.
Tôt ou tard, le mécanisme inefficace cessera de se développer et sera remplacé par un meilleur homologue.
Le temps et les efforts de l'homme seront gaspillés et son invention finira à la poubelle.
Dans le monde de la concurrence, ce risque existe en permanence.
Lorsque nous concevons des machines, nous devrions penser d'abord à leurs performances, et ensuite au confort et à la commodité de passer nos heures de travail).
La charge est placée sur l'ordinateur par l'attitude négligente du développeur à l'égard de la cohérence de son mécanisme. Une volonté d'économiser de l'énergie pour améliorer le système. Consommation déraisonnable des ressources informatiques au nom de la facilitation de leur travail.
Tant que l'ordinateur réussit à faire face à un code écrit de manière inefficace, le développeur continuera à "parasiter" la puissance de traitement. C'est une route sans issue.
Tôt ou tard, le mécanisme inefficace cessera de se développer et sera remplacé par un meilleur homologue.
Le temps et les efforts de l'homme seront gaspillés et son invention finira à la poubelle.
Dans le monde de la concurrence, ce risque existe en permanence.
Lorsque nous concevons des mécanismes, nous devons penser à leur performance en premier lieu, et au confort et à la commodité de nos heures de travail en second lieu).
C'est ce qu'on appelle l'écrire le programme. C'est pourquoi un code qui fonctionne correctement (et qui est lisible par n'importe quel autre développeur) est d'abord écrit et seulement ensuite il est optimisé - si tant est qu'il y ait quelque chose à optimiser.