Moment de la rédaction du conseiller - 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
Je peux vous envoyer une commande qu'il a fait la source, vous pouvez regarder qui comprend, qualité ou non il l'a fait, je ne comprends pas, qualité ou non, la chose principale il travaille sur l'algorithme, et comme l'intérieur, je ne sais pas) 0
La plupart du code se trouve dans la bibliothèque Trades.mqh, qu'il vous a envoyée, je suppose. Veuillez le joindre pour une estimation de la qualité.
On ne peut pas juger grand-chose à partir de ce dossier. Il semble qu'il n'y ait pas de vérifications et de normalisations là où elles devraient être, mais elles pourraient également se trouver dans le fichier Trades.mqh inclus.
Et la plupart du code est situé au même endroit.
Cependant, j'ai quelque chose à dire sur le bloc de signaux.
1) comparaison des doubles entre eux sans aucune normalisation.
2) Le croisement des prix MA est mis en œuvre sans tenir compte de la situation où le prix de clôture de la bougie est égal au prix MA. C'est rare, mais toujours possible.
Je ne conteste pas que c'est difficile et oui il y a beaucoup d'erreurs, mais il y a 2 mois on leur a dit que les erreurs sont connues, réparables et tout le plus dur est fait, malheureusement je ne suis pas celui qui le fait, et quelqu'un qui connaît tous les détails de la stratégie, et il a accepté un taux horaire et un simple rapport de travail et je n'ai pas pu lui prouver que c'était mauvais et erroné
Le freelancing est-il payé à l'heure ?
Si vous pouvez résoudre les problèmes par le biais de l'arbitrage, cela existe, ils vont régler le problème.
Permettez-moi de participer à la discussion, si vous en êtes capable ))))
Tout d'abord, bien sûr à 82Dmitry82 et au reste de son équipe, je m'excuse pour le retard dans le développement. Comme j'ai moi-même indiqué à leur représentant que je regrettais de m'être chargé de ce développement, j'admets que c'est pour moi une tâche difficile. La tâche a été divisée en plusieurs parties, mais une forte complication des exigences s'est révélée dans la deuxième étape, et en fait, depuis que je l'ai prise, j'ai décidé de la mener à son terme, mais ce n'était pas si facile.
Maintenant, sans dévoiler la stratégie, je vais essayer d'exposer le fait d'augmenter la complexité du TdR, afin que nos programmeurs apprécient vraiment combien ce fait complique le développement.
La base est la construction graphique des niveaux à partir desquels les ordres doivent être ouverts. Ces niveaux ne peuvent pas être construits immédiatement sur le bord du graphique sans se référer à l'historique, nous devons attendre que l'historique soit construit ou simplement faire en sorte que le conseiller expert se réfère à l'historique lui-même et vienne sur le bord du graphique avec des données. C'est ce que nous avons décidé de faire.
Initialement, nous imaginions que nous allions fonctionner par chandeliers et estimer 4 paramètres (Open, Close, High, Low) et construire en fonction des conditions. Et donc nous avons fait la première partie sur une grande TF (le RdR est divisé en 3 parties, 3 TF pour chacune desquelles il y a différentes constructions et conditions pour ces constructions). Lorsque nous sommes passés à la deuxième TF et que nous avons commencé à tester essentiellement la deuxième partie prête, nous avons identifié des erreurs et la discussion générale a montré qu'une bougie dans l'historique devrait être suivie en ligne (c'est-à-dire comme si elle était nulle sur le bord du graphique) et une re-construction effectuée lorsque la bougie n'est pas encore fermée, ce qui n'est pas réaliste pendant le parcours de l'historique, car il y a en fait 4 paramètres : Open, Close, Low et High.
La discussion générale a décidé d'aller plus loin et de la décomposer en m1 afin de tracer la bougie en ligne autant que possible (comme si elle était à zéro sur le bord du graphique). L'idée de laisser le bâtiment historique tel qu'il est de 4 points et de tracer la logique correcte au bord du graphique (lorsque Close[0] est flottant) a été rejetée. Les clients eux-mêmes ont compris que ce fait, révélé au cours du processus de développement, complique considérablement le cahier des charges. Déjà à ce stade, je voulais abandonner le développement, mais comme la première étape était déjà terminée, et que ce n'est pas vraiment dans mes principes d'abandonner le développement au milieu, j'ai décidé de continuer. En adaptant l'algorithme existant au fait que je devais utiliser M1 et tracer des TF plus élevées, j'ai commencé à me sentir psychotique, parce que j'avais tué beaucoup de temps pour cela, pendant le processus d'échec, j'étais frustré et j'écrivais aux clients que je devais augmenter le coût de développement, mais quand je me suis éloigné de l'ordinateur et que j'ai eu un peu froid, j'ai continué à corriger le problème.
J'ai proposé un paiement échelonné dans le temps simplement parce que je n'étais plus en mesure de réaliser le projet pour le montant négocié. Bien qu'il ait proposé de donner le code source pour éventuellement trouver quelqu'un qui le rappellera.
Si j'avais su dès le début, j'aurais utilisé une autre approche pour suivre М1 à l'intérieur du cadre temporel supérieur.
Si j'avais su dès le début qu'il est nécessaire d'effectuer un suivi au sein de M1 et dans des délais plus élevés, j'aurais agi différemment. Je n'ai pas la possibilité de tout vérifier moi-même, car il y a beaucoup de conditions dans la stratégie dont je ne me souviens même pas. Je les ai déjà tous vérifiés pour qu'ils n'entrent pas en conflit les uns avec les autres, c'est le principal problème. Il a été fait progressivement, et les clients admettent que la stratégie est difficile à comprendre, mais en général, il est maintenant presque tous prescrits, mais comme il fonctionne, je ne peux même pas comprendre à juste titre ou non))).
La dernière chose à laquelle ils se sont arrêtés est le cas qui n'a pas été pris en compte (même selon le représentant des clients) et maintenant nous devons écrire, coller et accepter une douzaine d'autres conditions une fois de plus. Je pense donc que le passage à un taux horaire pour ma part est justifié.
82Dmitry82, si vous voulez, nous pouvons vous parler personnellement du conseiller, vous avez mes contacts. J'ai fait un autre EA pour vous, je pense que vous apprécierez sa réactivité et son support, mais je vais vous demander de la patience avec celui-ci, parfois je le remets à plus tard, juste parce que je ne comprends pas de quel côté aller, pour commencer à corriger une autre construction à mauvais niveau.
Actuellement, il y a plus de 1000 lignes de code dans l'Expert Advisor et il s'agit juste de la construction de niveaux, sans aucune belle maille et même des ordres, qui n'ont pas encore été atteints.
Permettez-moi de participer à la discussion, si vous en êtes capable ))))
Tout d'abord, bien sûr à 82Dmitry82 et au reste de son équipe, je m'excuse pour le retard dans le développement. Comme j'ai moi-même indiqué à leur représentant que je regrettais de m'être chargé de ce développement, j'admets que c'est pour moi une tâche difficile. La tâche a été divisée en plusieurs parties, mais une forte complication des exigences s'est révélée dans la deuxième étape, et en fait, depuis que je l'ai prise, j'ai décidé de la mener à son terme, mais ce n'était pas si facile.
Maintenant, sans dévoiler la stratégie, je vais essayer d'exposer le fait d'augmenter la complexité du TdR, afin que nos programmeurs apprécient vraiment combien ce fait complique le développement.
La base est la construction graphique des niveaux à partir desquels les ordres doivent être ouverts. Ces niveaux ne peuvent pas être construits immédiatement sur le bord du graphique sans se référer à l'historique, nous devons attendre que l'historique soit construit ou simplement faire en sorte que le conseiller expert se réfère à l'historique lui-même et vienne sur le bord du graphique avec des données. C'est ce que nous avons décidé de faire.
Initialement, nous imaginions que nous allions fonctionner par chandeliers et estimer 4 paramètres (Open, Close, High, Low) et construire en fonction des conditions. Et donc nous avons fait la première partie sur une grande TF (le RdR est divisé en 3 parties, 3 TF pour chacune desquelles il y a différentes constructions et conditions pour ces constructions). Lorsque nous sommes passés à la deuxième TF et que nous avons commencé à tester essentiellement la deuxième partie prête, nous avons identifié des erreurs et la discussion générale a montré qu'une bougie dans l'historique devrait être suivie en ligne (c'est-à-dire comme si elle était nulle sur le bord du graphique) et une re-construction effectuée lorsque la bougie n'est pas encore fermée, ce qui n'est pas réaliste pendant le parcours de l'historique, car il y a en fait 4 paramètres : Open, Close, Low et High.
La discussion générale a décidé d'aller plus loin et de la décomposer en m1 afin de tracer la bougie en ligne autant que possible (comme si elle était nulle sur le bord du graphique). L'idée de laisser le bâtiment historique tel qu'il est de 4 points et de tracer la logique correcte au bord du graphique (lorsque Close[0] est flottant) a été rejetée. Les clients eux-mêmes ont compris que ce fait, révélé au cours du processus de développement, complique considérablement le cahier des charges. Je voulais abandonner le développement déjà à ce stade, mais comme la première étape était déjà faite, et que ce n'est pas vraiment dans mes principes d'abandonner le développement au milieu, j'ai décidé de continuer. En adaptant l'algorithme existant au fait que je devais utiliser M1 et tracer des TF plus élevées, j'ai commencé à me sentir psychotique, parce que j'avais tué beaucoup de temps pour cela, pendant le processus d'échec, j'étais frustré et j'écrivais aux clients que je devais augmenter le coût de développement, mais quand je me suis éloigné de l'ordinateur et que j'ai eu un peu froid, j'ai continué à corriger le problème.
J'ai proposé un paiement échelonné dans le temps, simplement parce que je n'étais plus en mesure de réaliser le projet pour le montant négocié. Bien qu'il ait proposé de donner le code source pour éventuellement trouver quelqu'un qui le rappellera.
Si j'avais su dès le début, j'aurais utilisé une autre approche pour suivre М1 à l'intérieur du cadre temporel supérieur.
Si j'avais su dès le début qu'il est nécessaire d'effectuer un suivi au sein de M1 et dans des délais plus élevés, j'aurais agi différemment. Je n'ai pas la possibilité de tout vérifier moi-même, car il y a beaucoup de conditions dans la stratégie dont je ne me souviens même pas. J'ai déjà vérifié qu'ils n'entrent pas en conflit les uns avec les autres, c'est le principal problème. Il a été fait progressivement, et les clients admettent que la stratégie est difficile à comprendre, mais en général, il est maintenant presque tous prescrits, mais comme il fonctionne, je ne peux même pas comprendre à juste titre ou non))).
La dernière chose à laquelle ils se sont arrêtés est le cas qui n'a pas été pris en compte (même selon le représentant des clients) et maintenant nous devons écrire, coller et accepter une douzaine d'autres conditions une fois de plus. Je pense donc que le passage à un taux horaire pour ma part est justifié.
82Dmitry82, si vous voulez, nous pouvons vous parler personnellement du conseiller, vous avez mes contacts. J'ai fait un autre EA pour vous, je pense que vous apprécierez sa réactivité et son support, mais je vais vous demander de la patience avec celui-ci, parfois je le remets à plus tard, juste parce que je ne comprends pas de quel côté aller, pour commencer à corriger une autre construction à mauvais niveau.
Pour l'instant, il y a plus de 1000 lignes de code dans l'Expert Advisor et il ne s'agit que de la construction de niveaux sans aucun maillage ni même d'ordres, ce que nous n'avons pas encore fait.
En somme, c'est devenu encore plus confus que cela ne l'était.
J'ai compris que nous devions vérifier la coïncidence des conditions sur une période plus élevée et si la coïncidence n'est pas trouvée.
Si je comprends bien l'algorithme, ce n'est pas si compliqué, 2-3 jours tout au plus.
Actuellement, il y a plus de 1000 lignes de code dans l'EA, et ce n'est que la construction des niveaux, sans aucune belle maille et même des ordres, qui n'ont pas encore été atteints.
1000 lignes, c'est d'ailleurs la taille moyenne de tout EA, au-delà d'un EA simple. Je pense que le problème est que vous avez pris le mauvais chemin en réfléchissant à la manière de contourner les problèmes qui se sont posés. 90% du succès consiste à formuler le bon problème, et sa mise en œuvre est une dixième affaire
.
.
En fait, si j'avais su dès le début qu'il était nécessaire de suivre m1 à l'intérieur du cadre temporel supérieur, j'aurais construit la logique de l'EA différemment.
.
Actuellement, il y a plus de 1000 lignes de code dans l'EA, et ce n'est que la construction des niveaux, sans aucune belle maille et même des ordres, qui n'ont pas encore été atteints.
Laissez-moi vous soutenir.
Bien sûr, ma stratégie n'est pas exactement comme ça, mais elle est similaire. Il prend en compte les niveaux de support/cop, la tendance, les renversements, les pullbacks et bien d'autres choses, sans utiliser d'indicateurs externes (personnalisés).
Je fais du trading manuel avec cette stratégie depuis 3 ans. Pendant tout ce temps, j'ai réfléchi à la manière de le mettre en œuvre et je l'ai programmé pendant un an. Il y a eu moins de 2000 lignes.
Tous les développeurs qui sont capables de trader à la main, c'est plus facile pour eux quand ils prennent quelques barres comme base d'analyse.
Mais une barre, même si elle est M1, est déjà dans le passé. Il est inutile de construire une stratégie sur des barres (surtout sur les plus hautes).
Il faut le faire en utilisant chaque tique.
Dans mon programme, il n'y a pas un seul tableau (au sens absolu), et je n'analyse pas ce qui était dans le passé. Mais bien sûr, je me souviens des points de contrôle nécessaires en temps réel (pas dans des tableaux).
En bref : ce qui est fait à la main et qui est si facilement et magnifiquement dessiné sur le graphique, il n'est pas toujours possible de le programmer.
Permettez-moi de participer à la discussion, si vous en êtes capable ))))
Tout d'abord, bien sûr à 82Dmitry82 et au reste de son équipe, je m'excuse pour le retard dans le développement. Comme j'ai moi-même indiqué à leur représentant que je regrettais de m'être chargé de ce développement, j'admets que c'est pour moi une tâche difficile. La tâche a été divisée en plusieurs parties, mais une forte complication des exigences s'est révélée dans la deuxième phase, enfin, en fait, depuis que je l'ai prise, j'ai décidé de la mener à terme, mais ce n'était pas si facile.
Maintenant, sans dévoiler la stratégie, je vais essayer d'exposer le fait d'augmenter la complexité du TdR, afin que nos programmeurs apprécient vraiment combien ce fait complique le développement.
La base est la construction graphique des niveaux à partir desquels les ordres doivent être ouverts. Ces niveaux ne peuvent pas être construits immédiatement sur le bord du graphique sans se référer à l'historique, nous devons attendre que l'historique soit construit ou simplement faire en sorte que le conseiller expert se réfère à l'historique lui-même et vienne sur le bord du graphique avec des données. C'est ce que nous avons décidé de faire.
Au départ, nous avions imaginé de fonctionner par chandeliers et d'estimer 4 paramètres (Open, Close, High, Low) et de construire en fonction des conditions. Et donc nous avons fait la première partie sur un grand TF (le ToR est divisé en 3 parties, 3 TF pour chacune desquelles il y a des constructions différentes et des conditions pour ces constructions). Lorsque nous sommes passés à la deuxième TF et avons commencé à tester essentiellement la deuxième partie prête, nous avons identifié des erreurs et la discussion générale a montré qu'une bougie dans l'historique devrait être suivie en ligne (c'est-à-dire comme si elle était nulle sur le bord du graphique) et que les reconstructions devraient être faites pendant que la bougie est encore ouverte, ce qui n'est pas réaliste pendant le parcours de l'historique, car il y a en fait 4 paramètres : Open, Close, Low et High.
La discussion générale a décidé d'aller plus loin et de la décomposer en m1 afin de tracer la bougie en ligne autant que possible (comme si elle était à zéro sur le bord du graphique). L'idée de laisser le bâtiment historique tel qu'il est de 4 points et de tracer la logique correcte au bord du graphique (lorsque Close[0] est flottant) a été rejetée. Les clients eux-mêmes ont compris que ce fait, révélé au cours du processus de développement, complique considérablement le cahier des charges. Déjà à ce stade, je voulais abandonner le développement, mais comme la première étape était déjà terminée, et que ce n'est pas vraiment dans mes principes d'abandonner le développement au milieu, j'ai décidé de continuer. En adaptant l'algorithme existant au fait que je devais utiliser M1 et tracer des TF plus élevées, j'ai commencé à me sentir psychotique, parce que j'avais tué beaucoup de temps pour cela, pendant le processus d'échec, j'étais frustré et j'écrivais aux clients que je devais augmenter le coût de développement, mais quand je me suis éloigné de l'ordinateur et que j'ai eu un peu froid, j'ai continué à corriger le problème.
J'ai proposé un paiement échelonné dans le temps simplement parce que je n'étais plus en mesure de réaliser le projet pour le montant négocié. Bien qu'il ait proposé de donner le code source pour éventuellement trouver quelqu'un qui le rappellera.
Si j'avais su dès le début, j'aurais utilisé une autre approche pour suivre М1 à l'intérieur du cadre temporel supérieur.
Si j'ai fait une erreur de construction, je la corrigerai. Je n'ai pas la possibilité de tout vérifier moi-même, car il y a beaucoup de conditions dans la stratégie dont je ne me souviens même pas. J'ai déjà vérifié qu'ils n'entrent pas en conflit les uns avec les autres, c'est le principal problème. Il a été fait progressivement, et les clients admettent que la stratégie est difficile à comprendre, mais en général, il est maintenant presque tous prescrits, mais comme il fonctionne, je ne peux même pas comprendre à juste titre ou non))).
La dernière chose à laquelle ils se sont arrêtés est le cas qui n'a pas été pris en compte (même selon le représentant des clients) et maintenant nous devons écrire, coller et accepter une douzaine d'autres conditions une fois de plus. Je pense donc que le passage à un taux horaire pour ma part est justifié.
82Dmitry82, si vous voulez, nous pouvons vous parler personnellement du conseiller, vous avez mes contacts. J'ai fait un autre EA pour vous, je pense que vous apprécierez sa réactivité et son support, mais je vais vous demander de la patience avec celui-ci, parfois je le remets à plus tard, juste parce que je ne comprends pas de quel côté aller, pour commencer à corriger une autre construction à mauvais niveau.
Pour l'instant, il y a plus de 1000 lignes de code dans l'EA et il ne s'agit que de la construction des niveaux, sans aucun beau maillage et même des ordres, qui n'ont pas encore été atteints.
D'après la description, il est clair que je n'ai pas eu de RPT et que la tâche ressemble à ceci : faites-moi cette stratégie, et elle devrait fonctionner de cette façon et en même temps pensez à comment mettre en œuvre tout cela, pas d'algorithme.
Dans ce cas, il s'agit d'un travail à forte intensité de main-d'œuvre, comme je l'ai écrit plus haut, le programmeur commence à réfléchir, et le coût de la réflexion est différent pour chacun. Par conséquent, le prix peut être justifié.
La division du travail a été inventée pour une raison. Le client comprend le programmeur comme un magicien capable de transposer n'importe quelle idée en code. En fait, les aptitudes et les compétences d'une personne sont toujours limitées, et dans les grandes entreprises, il existe une division du travail entre une personne qui crée des algorithmes, un architecte et un programmeur - chacun d'entre eux ayant sa propre spécialisation. C'est ainsi que la situation a tourné.
Laissez-moi vous soutenir.
Je n'ai pas exactement la même, mais une stratégie similaire. Il prend en compte les niveaux de support/cop, la tendance, les renversements, les pullbacks et bien d'autres choses, sans utiliser d'indicateurs externes (personnalisés).
Je fais du trading manuel avec cette stratégie depuis 3 ans. Pendant tout ce temps, j'ai réfléchi à la manière de le mettre en œuvre et je l'ai programmé pendant un an. Il y a eu moins de 2000 lignes.
Tous les développeurs qui sont capables de trader à la main, c'est plus facile pour eux quand ils prennent quelques barres comme base d'analyse.
Mais un bar, même s'il est M1, c'est déjà le passé. Il est inutile de construire une stratégie sur des barres (surtout sur les plus hautes).
Il faut le faire en utilisant chaque tique.
Dans mon programme, il n'y a pas un seul tableau (au sens absolu), et je n'analyse pas ce qui était dans le passé. Mais bien sûr, je me souviens des points de contrôle nécessaires en temps réel (pas dans des tableaux).
En bref : ce qui est fait à la main et qui est si facilement et magnifiquement dessiné sur un graphique, ne peut pas toujours être programmé.
Vous pouvez programmer n'importe quoi, mais vous devez d'abord développer un algorithme, et c'est une grande partie du travail. En substance, vous devez d'abord transformer ce que vous voyez en formules et en logique, puis les programmer. Et le premier est très souvent sous-estimé.
Permettez-moi de participer à la discussion tant que nous y sommes )))).
....
En fait, si j'avais su au départ ce qu'était ....., j'aurais construit la logique de l'EA différemment.
....
C'est une situation familière. Avant de commencer à écrire le code, vous planifiez sa structure et la logique de son fonctionnement, mais une fois que l'algorithme est prêt et entièrement fonctionnel, vous commencez à ajouter d'autres conditions et de nouvelles fonctionnalités, et finalement il devient évident qu'il est plus facile de revoir toute la structure et de réécrire complètement toute la logique, que de continuer à essayer d'intégrer un nouveau concept dans l'ancien algorithme. Il s'avère qu'il est plus facile de tout repenser avec de nouvelles fonctions et conditions et de réécrire l'algorithme, mais cela prend beaucoup de temps.
Une bonne illustration du "résultat d'un travail sans projet".
Tout le monde n'est pas heureux les uns des autres, il n'y a pas de rendement...