Créer un service de certification pour les programmeurs ... - page 6

[Rustamzhan Salidzhanov]

Ouais les gars....

le classement est déjà disponible :))))

[snowman]

VOLDEMAR:
Si vous n'avez rien de bon à dire, ne dites rien ou au moins parlez-en ...... Si tu savais quelque chose, tu me le montrerais... Ou c'est trop mauvais ? Ou ne savent rien du tout ....

il n'y a aucune raison de se disputer.

Il serait en fait préférable de combiner vos fonctions d'envoi de commande pour vérifier l'exactitude de la commande envoyée au serveur.

Je ne veux pas que l'erreur soit signalée avant le serveur, mais avant...).

[Alexander Bereznyak]

MrGold166:

C'est l'intérêt du overshooting de la fin, il n'y a rien de militaire à traiter un ordre deux fois. Dans le pire des cas, cela ne nous empêche que si on compte les ordres, par exemple le prix moyen, un ordre sera compté 2 fois. Même si cela interfère fortement avec les calculs, au prochain tick tout rentrera dans l'ordre et nous mettrons le take profit là où il doit être. De mémoire, avec plus de 50 ordres et avec le pire des "courtiers" asiatiques (oui, vous savez de qui je parle), cela n'est jamais arrivé après que le compte ait été négocié (vous savez pourquoi). Mais cela aussi peut être évité :

int i,last_ticket;

for(i=OrdersTotal()-1;i>=0;i--) if(OrderSelect(i,SELECT_BY_POS) {

   if(OrderTicket()==last_ticket) continue;

   last_ticket=OrderTicket();

   }

Et comment pouvez-vous garantir que vous n'aurez pas la même situation la prochaine fois que vous cocherez, oui rien.

Et dans le pire des cas, vous calculerez mal la moyenne et ouvrirez mal un ordre, et le prochain tick n'aura aucune importance.

Ce n'est pas le nombre d'ordres qui compte, mais l'environnement de trading, la présence de stops réels, la présence d'autres EAs sur le compte.

[A100]

MrGold166:

Mais cela aussi peut être évité :

int i,last_ticket;

for(i=OrdersTotal()-1;i>=0;i--) if(OrderSelect(i,SELECT_BY_POS) {

   if(OrderTicket()==last_ticket) continue;

   last_ticket=OrderTicket();

   }

Théoriquement, plus d'un ordre pourrait changer d'état

[Alexander Bereznyak]

A100:
Théoriquement, l'état de plus d'un ordre peut changer.

Une bonne idée, je n'ai pas pensé à deux, je me suis accroché à une.

Retour à la case départ, donc comment résoudre les collisions avec cette fonction.

[snowman]

sandex:

Bonne idée, je n'ai pas pensé à deux, je suis resté bloqué sur un.

Retour à la case départ, donc comment résoudre les collisions avec cette fonction.

   int j=OrdersTotal();
   for(int i=j-1;i>=0;i--)
   {
      if(OrderSelect(i,SELECT_BY_POS))
      {
      }
   }
   if(j!=OrdersTotal())return(0);

Le cas échéant, recalculez à nouveau. si le nombre d'ordres d' entrée et de sortie n'est pas égal.

[[Supprimé]]

A100:
Théoriquement, plus d'un ordre pourrait changer

Et alors ? Même si tout le monde change, nous n'analyserons toujours pas les mêmes métiers.

Si nous parlons d'une transaction en haut de la liste qui a changé, alors elle peut changer après que nous ayons effectué la recherche - avant que nous mettions le bénéfice total.

[A100]

snowman:

Le cas échéant, recalculez à nouveau si le nombre d'ordres d' entrée et de sortie n'est pas égal.

En général, même le nombre de commandes peut être égal, mais il peut s'agir de commandes différentes.

[[Supprimé]]

snowman:

Si le nombre d'ordres à l'entrée et à la sortie n'est pas égal, alors recalculez-le à nouveau.

Cela ne nous aidera pas non plus si un ordre en attente est ouvert, le nombre d'ordres sera sauvegardé mais pas les paramètres. D'un autre côté, cela ne nous dérangerait guère, si nous n'avions pas inclus un ordre en attente nouvellement ouvert dans le montant, c'est OK. (Je ne vois vraiment pas de situation dans laquelle cela pourrait provoquer une erreur). Cette situation ne peut se produire que dans un ensemble spécial de circonstances, dont l'une est un grand nombre de ticks, c'est-à-dire que la prochaine itération sera très proche et que l'erreur sera corrigée. Si le rebond de l'ordre se produit entre deux ticks, cela ne nous pose pas de problème.

Nous voyons souvent les codes d'autres programmeurs où l'énumération est faite des dizaines de fois par itération séparément pour calculer un tas de paramètres et c'est un problème.

[A100]

MrGold166:

Et alors ? Même si tout le monde change, nous n'analyserons toujours pas les mêmes métiers.

Si nous parlons d'une transaction en haut de la liste qui a changé, alors elle peut changer après que nous ayons effectué la recherche - avant que nous mettions le bénéfice total.

Je ne faisais pas référence au calcul appliqué à une situation spécifique, mais au cas général. Je pense que le double comptage et/ou le sous comptage sont importants, parfois de manière critique.