Quand est-il judicieux de conserver une partie du code du robot dans un indicateur ? - page 20

 
hrenfx:

Grande critique ! Seulement pas à mon métier, mais à la plateforme dans son ensemble. Ce fait a été mentionné à plusieurs reprises aux développeurs. Donc la situation :

  1. Vous n'avez pas allumé votre terminal depuis une semaine et vous décidez de le faire fonctionner, avec votre EA par défaut (cela soulève quelques questions quant à son adéquation, mais soit).
  2. Le terminal est connecté, mais l'ensemble de l'historique est toujours en cours. L'indicateur envoie ses valeurs au conseiller expert et ce dernier commence à négocier sur la base de ces valeurs.
  3. Le terminal a téléchargé tout l'historique et l'indicateur a commencé à montrer des valeurs complètement différentes. Le conseiller expert obtient maintenant des valeurs complètement différentes.

Il s'agit d'un problème bien connu que l'on a demandé aux développeurs de résoudre une centaine de fois, en ajoutant le drapeau que toute l'histoire est pompée. Mais le problème n'a pas été résolu.

Maintenant, tout conseiller expert avec des indicateurs à de tels moments est prêt à faire beaucoup de problèmes dans le trading. Par conséquent, nous ne devons pas réduire le problème des développeurs au code ci-dessus. La variante avec un indicateur ne fournit pas une solution acceptable.

Soyons plus proches de la réalité : vous exécutez le conseiller expert alors que vous vous êtes déjà assuré que l'ensemble de l'historique est pompé. Si après cela la connexion est interrompue pendant une courte période (moins d'un jour), alors mon code fonctionnera tout à fait correctement.


Ne cherchez pas les problèmes dans le monde qui vous entoure, cherchez-les en vous. Jusqu'à présent, le terminal fonctionne comme Victor l'a écrit, et dans ces conditions votre code fonctionnera incorrectement et ce ne sont pas les développeurs du terminal, mais l'auteur de ce code, qui fonctionnera incorrectement dans les conditions décrites ci-dessus, qui sera coupable.

 
hrenfx:
Donc vous dites qu'il n'y a toujours pas de tel code ? Je suis surpris de voir que mon élémentaire va combler ce vide.

Je ne l'ai pas vu jusqu'à présent. Bien que j'aie vu quelques articles, je n'ai pas vu de bon code. Même si cela prend cinq minutes pour l'écrire, mais ......
 
Integer:

Victor, tu vas recevoir une réponse disant que nous sommes cool, que nous ne travaillons pas en dessous de H4 ou quelque chose dans le même style, ou d'une autre manière, mais avec la même signification .... ou utiliser un VPS super-duper puissant, et le compte que nous avons dans le meilleur DC du monde, qui ne fait jamais défaut connexion..... etc. etc.

Je l'ai eu ! Je l'ai toujours. Son code est bon et le terminal est mauvais.
 
Vinin:

Je ne l'ai pas vu jusqu'à maintenant. Bien qu'il y ait eu quelques articles, je n'ai pas vu de bon code. Même si cela prend cinq minutes pour l'écrire, mais .......

Eh bien, pas cinq minutes, environ 15 minutes. Mais pour quoi faire ? Si vous pouviez écrire un bon guide de programmation pour les indicateurs, ce serait une autre affaire.
 
hrenfx:

Peut-être que l'homme qui a les couilles dira quelque chose.

Pas de problème. En fait, pour réaliser votre analogue d'IndicatorCounted, vous avez besoin d'un tableau avec un historique à analyser au cas où vous le manqueriez, c'est-à-dire que dans ce cas particulier, vous avez essentiellement besoin d'un recalcul complet à chaque barre.

Peut-être un autre concours ?

 

Donc les gars, vous n'avez toujours pas cité une situation où mon EA sur REAL produirait des valeurs incorrectes.

REAL signifie que vous faites ce qu'il faut : vous exécutez l'EA sur un historique entièrement gonflé. Après cela, vous n'éteignez pas le terminal. Les interruptions de communication, comme sur tout REAL, sont parfaitement acceptables.

Alors quel est le problème sur le REAL ? Je ne parle même pas du testeur.

 
hrenfx:

Donc les gars, vous n'avez toujours pas cité une situation où mon EA sur REAL produirait des valeurs incorrectes.

REAL signifie que vous faites ce qu'il faut : vous exécutez l'EA sur un historique entièrement gonflé. Après cela, vous n'éteignez pas le terminal. Les interruptions de communication, comme sur tout REAL, sont parfaitement acceptables.

Alors quel est le problème sur le REAL ? Je ne parle même pas du testeur.


Combien de fois dois-je t'expliquer la même chose pour que tu la comprennes, ou du moins que tu la remarques ?
 
TheXpert:

Pas de problème. En fait, pour réaliser votre analogue d'IndicatorCounted, vous avez besoin d'un tableau avec un historique à analyser au cas où vous le manqueriez, c'est-à-dire que dans ce cas particulier, vous avez essentiellement besoin d'un recalcul complet de chaque barre.

Peut-être un autre concours ?


Il n'est pas possible de regarder l'heure des barres, nous ne savons pas si la barre a été manquée par le terminal en raison d'un manque de communication ou si elle n'a pas réellement eu lieu.
 
Integer:
Vous ne savez pas si le terminal a manqué une barre à cause d'un manque de communication ou si cela ne s'est pas produit.
Ainsi, si la barre apparaît ensuite, la comparaison révélera une divergence dans l'historique, et c'est à ce moment-là qu'il faut l'enregistrer.
 
TheXpert:
Donc, si la barre apparaît alors, la comparaison révélera une divergence dans l'historique, c'est alors que vous devez l'enregistrer.

Je l'ai. Si de nouvelles barres apparaissent entre les barres existantes.