BESOIN D'UN PROGRAMMEUR - page 2
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
Cela semble être une bonne idée, de créer une interface graphique basée sur les canaux de Barispolz. Une telle machine semi-automatique sous contrôle humain.
Un programme de la classe AutoGraf.
Certaines notions ne sont pas claires dans les TdR, ce qu'il faut considérer comme un extremum, ce qu'est un extremum à sa place, le canal est reconstruit dans certaines limites (+- l'infini ?), approximativement le même (comment compter ?), il atteint un mur (exactement touché ou +-1 point, ou 20 points, et le même pour toutes les échéances ?) Et ce programme doit fonctionner simultanément sur les échelles de temps M1, M5, M15, M30, H1, H4 et sur plusieurs instruments . Un abîme sans fond, des devises, des indices, des futures + tous synchronisés, une telle multidevise. Je voudrais ajouter une autre phrase, à savoir que tout fonctionnerait non seulement sur le réel, mais aussi sur l'historique dans le testeur, afin que nous puissions tout vérifier et nous entraîner.
Bon RPT, un domaine de travail sans fond. Mais je pense que MT devra être écartée et que tout devra être écrit à partir de zéro.
Vous commencez par écrire ce morceau de RPT en 10-30-240 minutes = "il ne devrait pas être approximativement le même".
croyez-moi, ce n'est pas une chose insignifiante !
(ce qui est approximatif est une substance plutôt subjective)
Vous devrez comparer un objet dans certaines limites, au moins sous la forme de 3 points !
Vous devrez utiliser le battage, qui est en fait un triangle selon les règles et couper les objets similaires.
(et pas seulement le couper, mais le faire approuver par l'auteur du RPT).
Eh bien, pour toute substance subjective peut apprendre une définition claire, en discutant TOR avec l'auteur. Et des définitions claires sont faciles à traduire en code.
Je suis d'accord pour dire que tu réagis de manière excessive !
ce n'est pas si facile ! mais si vous parlez à l'auteur des TdR, certaines choses peuvent être arrangées
mais vous ne pouvez pas le faire en 2 heures - même si vous disposez de bibliothèques prêtes à l'emploi.
En fait, qu'est-ce qui est requis dans le cahier des charges en ce qui concerne le code du conseiller expert ?
Sur la base des trois extrema appropriés sur le graphique, le programme construit un canal qui est affiché en bleu.
*La fonction permettant d'identifier un tableau d'extrema ne prendra pas plus de 10 minutes, puisque je l'ai déjà.
*Fonction pour construire un canal basé sur les extrema - 10 minutes, au maximum
Lorsqu'il identifie le quatrième extremum, le programme fixe(verrouille) le canal et le repeint en vert si l'extremum correspond au mur du canal. Si un extremum n'est pas en position, le canal est automatiquement reconstruit dans certaines limites ou supprimé.
*La fonction permettant d'identifier l'emplacement d'un extremum par rapport à la paroi du canal prend au maximum 10 minutes si l'auteur précise ce que signifie "hits ".
3. Un canal verrouillé ne peut être modifié ni par programme ni manuellement, mais il peut être déverrouillé, par exemple, par un double clic ou en sélectionnant l'option correspondante dans le menu contextuel (selon ce qui est le plus facile à mettre en œuvre), puis en le modifiant et en le verrouillant à nouveau.
* Pas de commentaire. Qui sait comment bloquer les kannals des clics dans le terminal et créer des menus contextuels - énorme respect de ma part*.
5) Lorsqu'un canal vert apparaît sur un symbole donné à un moment donné, le programme continue à chercher des extrema et à construire d'autres canaux. Ainsi, plusieurs canaux peuvent être affichés sur le même graphique en même temps, ils ne doivent pas être approximativement les mêmes, mais il est permis d'afficher des canaux les uns dans les autres. Lorsque le prix quitte le canal et y reste pendant un certain temps, le canal est supprimé.
*Ecrire dans un tableau les canaux verts, toutes les informations les concernant (TF par exemple, nécessaire au point 6), faire un contrôle pour deux canaux entre eux - 30 minutes au maximum, encore une fois si l'auteur vous dit quels canaux il définit comme similaires .
6 Lorsque le prix atteint le mur du canal vert, les indicateurs correspondants sont vérifiés, et une position est ouverte. Une seule position peut être ouverte dans un canal à la fois, mais s'il y a des canaux à plus faible échéance dans le canal, des positions supplémentaires peuvent être ouvertes.
*L'intervalle de temps pour vérifier la position du prix par rapport au canal est de 15 minutes au maximum. Ensuite, il suffit de parcourir en boucle tous les canaux inscrits dans le tableau des canaux. Nous devrions également enregistrer quelles positions dans quels canaux sont ouvertes, bloquant ainsi la possibilité d'ouvrir plusieurs positions dans un canal - un total de 6 à 30 minutes*.
Le programme doit fonctionner simultanément sur les horizons M1, M5, M15, M30, H1, H4 et sur plusieurs symboles. Tous les canaux doivent être affichés simultanément sur tous les horizons temporels avec les étiquettes correspondantes (par exemple, "M5" à côté du coin supérieur gauche du canal). Cependant, le code doit être implémenté de manière à désactiver facilement l'affichage des canaux sur des horizons temporels supérieurs ou inférieurs (par exemple, pour éviter d'afficher les canaux M1 sur H1, etc.) ou pour bloquer les opérations sur certains horizons temporels (par exemple, pour négocier uniquement sur H1 et M15).
*Un tableau de ticks - et le programme fonctionnera pour plusieurs instruments, pour n'importe quelle période de temps. Affichage des billets et des blocages et travail sur les petites TF - 30 minutes de plus*.
..
Par exemple, j'ai toujours 3 à 4 fois plus de temps pour travailler que prévu !
Je sais que je peux rencontrer une "souche"... avec un problème auquel je ne m'attendais pas !
Hmmm... Je suppose que je ferai toujours ça à partir de maintenant, merci !
Si vous comprenez tous les résumés du cahier des charges, la partie code est tout à fait réaliste pour 6 heures (120 $).
Je suis d'accord, si vous tapez à 300 caractères par minute.
296, 14 fautes de frappe. Je viens de vérifier.
Fduch, 14 erreurs pour 296 caractères de code prendront au moins 100 fois plus de temps à corriger que ce qu'il vous faut pour taper ces 296 caractères :). Sans compter ceux qui sont logiques, bien sûr.
Le plus difficile ici est de trouver les extrema, un problème flou typique. Je crains que la bibliothèque pour trouver les extrema que vous avez mentionnée ne soit pas tout à fait la bonne. Même pas ça du tout. Identifier les extrema d'une courbe extrêmement brisée (y compris les extrema locaux, notamment à l'intérieur d'un canal) n'est pas du tout une tâche triviale.
Et, bien sûr, une autre tâche floue - l'identification de canaux similaires.
En général, il est extrêmement difficile d'estimer le temps d'exécution des tâches floues.
L'auteur du fil de discussion pense probablement avoir formulé un cahier des charges codifiable, mais j'ai bien peur que ce ne soit pas le cas : il n'a pas défini les concepts flous. Vous ne vous en tirerez pas avec 6 heures, même si vous enlevez le temps passé à affiner les concepts flous jusqu'à leur état codifiable.
2 Fduch.
400 usd, pas moins. Fduch - appréciez votre travail.
20 c.u. = un bâton, = une "heure de travail"))
.
Hmmm... Je suppose que je ferai toujours ça à partir de maintenant, merci !
Si vous comprenez tous les résumés du cahier des charges, la partie code est tout à fait réaliste pour 6 heures (120 $).
Si vous obtenez 6 heures pour la partie principale en moins, alors c'est logique ! (voir la fin du message)
---
Vous n'êtes pas pressé ! Il faut d'abord le mettre en œuvre, et le mettre en œuvre de manière à ce que le client soit satisfait !
Si votre emploi principal vous rapporte plus pour le même temps que le montant convenu --- alors je pense que l'effort que vous fournissez est important.
alors je pense que vous perdez votre temps.
Un homme doit pouvoir se reposer, et vous allez consacrer ces heures à ce projet.
alors que vous feriez mieux de vous reposer !
J'ai aussi des défaillances - je me lance dans un projet puis je ne respecte pas les délais en raison de circonstances imprévues !
Par exemple, la soirée était prévue pour le travail, et puis une fois et invité à visiter !
En conséquence, vous devez expliquer au client que vous n'aviez pas à vous occuper de sa tâche le soir !
Et si vous stipulez un délai adéquat, en tenant compte des temps d'arrêt possibles - c'est-à-dire sans galoper à travers l'Europe, la situation semble meilleure !
---
Au fait, écoutez ce que chacun a à dire !
120 $ pour un projet comme celui-ci - cela ressemble à la célèbre phrase d'humour "J'écris sur C++ pour manger !".
il y avait un membre du forum nommé Piz, et il appelait ça "aide professionnelle nécessaire".
))
Professionnellement pour 20 c.u.s.
Si quelqu'un est prêt à mettre en œuvre ce programme, en précisant le coût des travaux, il faudra bien sûr discuter des TDR dans les moindres détails, car j'ai décrit l'idée, les points clés, et vous avez trouvé beaucoup d'embûches. Tous les éléments dans lesquels apparaissent les termes "approximativement", etc., je suppose qu'ils sont exécutés de manière à ce que le résultat de cette même approximation soit égal à une certaine valeur +-delta, tout en sélectionnant une valeur adéquate de delta pour démontrer le programme.
En ce qui concerne les graphiques et l'interface, je n'ai personnellement jamais été impliqué dans la programmation de graphiques dans ce langage, je propose donc de partir du contraire - quels moments peuvent être implémentés, lesquels ne le peuvent pas, et comment le faire plus facilement. Parce qu'un même canal peut être un canal, ou peut être juste deux bâtons sur le graphique, ou même un tableau de points.
Si quelqu'un est prêt à mettre en œuvre ce programme, en précisant le coût des travaux, il faudra bien sûr discuter des TDR dans les moindres détails, car j'ai décrit l'idée, les points clés, et vous avez trouvé beaucoup d'embûches. Tous les éléments dans lesquels apparaissent les termes "approximativement", etc., je suppose qu'ils sont exécutés de manière à ce que le résultat de cette même approximation soit égal à une certaine valeur +-delta, tout en sélectionnant une valeur adéquate de delta pour démontrer le programme.
En ce qui concerne les graphiques et l'interface, je n'ai personnellement jamais été impliqué dans la programmation de graphiques dans ce langage, je propose donc de partir du contraire - quels moments peuvent être implémentés, lesquels ne le peuvent pas, et comment le faire plus facilement. Parce que le même canal peut être un canal, et peut être juste deux bâtons sur un graphique, ou même un tableau de points.
Veuillez nous envoyer un e-mail.