Conseils utiles pour les participants au championnat - page 11

Nouveau commentaire
 
VNIK писал (а):

Désolé pour la question indiscrète adressée aux organisateurs du championnat :

Comment sera gérée la taxation du prix (car le montant de chaque prix est très élevé) :

Chaque lauréat devra-t-il payer sa propre taxe ? (et à quel rythme ?) Ou sera-t-elle centralisée ? ( c'est-à-dire que les taxes sont déjà prises en compte ?).

Il serait dommage de renoncer à la moitié du prix pour les impôts !

Je suis d'accord avec vous, moi aussi je serais désolé de donner la moitié de votre prix pour payer mes impôts...
En fait, il vaut mieux ne pas gagner du tout pour ne pas se sentir désolé... .
 
VNIK:

Désolé pour la question indiscrète adressée aux organisateurs du championnat :

Comment sera gérée la taxation du prix (car le montant de chaque prix est très élevé) :

Chaque lauréat devra-t-il payer sa propre taxe ? (et à quel rythme ?) Ou sera-t-elle centralisée ? ( c'est-à-dire que les taxes sont déjà prises en compte ?).

Il serait dommage de renoncer à la moitié du prix pour les impôts !


Oui, les lauréats paient leurs propres impôts - c'est une pratique courante pour les prix dans le monde entier.
 
Il n'y a aucun moyen de tester si cette fermeture des ordres fonctionnera toujours correctement :
while (OrdersTotal()>0)
   {
      OrderSelect(0,SELECT_BY_POS);
      if (OrderType()==OP_BUY)       OrderClose(OrderTicket(),OrderLots(),Bid,3,Green);
      else if (OrderType()==OP_SELL) OrderClose(OrderTicket(),OrderLots(),Ask,3,Red);
      
      err=GetLastError();
      if (err==135 || err==138) RefreshRates();
   }
La question est la suivante : si le code d'erreur n'est pas 135 ou 138, y aura-t-il une boucle ? Si c'est le cas, comment peut-on l'éviter, avec la garantie que les commandes seront fermées ?
 
MAEstro:
Il n'y a aucun moyen de tester si cette fermeture des ordres fonctionnera toujours correctement :
Il y a erreur sur erreur ici. J'ai compté 4 erreurs et elles sont toutes catastrophiques.
Relisez l'article de conseil, s'il vous plaît.
 
Je me souviens de ce conseil par cœur, mais il semble être de peu d'utilité :(

Négligence grossière du contrôle d'erreur avec le bouclage
(J'ai un contrôle d'erreur, les ordres en attente ne sont pas utilisés, ou dois-je faire une condition de sortie de boucle également ? Que faire alors avec la garantie de fermeture de l'ordre ? Ou peut-être n'ai-je pas trouvé tous les codes d'erreur ?

Manque de contrôle de OrderSelect - les processus asynchrones en action
(oui, je ne vérifie pas ce que retourne Order_Select ! Disons que si, dans ce cas particulier, elle renvoie false, qu'est-ce qui va changer dans la boucle, ou qu'est-ce qui sera incorrect ? Je ne modifie pas l'ordre, je le ferme).

Sauter la fonction de rafraîchissement de l'environnement de marché par RefreshRates()
(Je pense l'avoir rafraîchi, tout devrait être ok ici)

Peut-être existe-t-il un code prêt à l'emploi pour la fermeture de TOUS les ordres ? J'apprécierais si vous pouviez le poster !

P.S. Ce que Rosh a suggéré http://www.alpari-idc.ru/ru/experts/articles/9.html , ne garantit pas les ordres de fermeture !
 
Il y a même 5 erreurs :
  1. Le résultat de OrderSelect n'est pas vérifié
  2. le résultat de OrderClose() n'est pas vérifié explicitement
  3. GetLastError() peut être appelé sans aucune opération commerciale (par exemple, si vous avez rencontré un ordre en attente).
  4. RefreshRates() n'est pas toujours appelé, mais seulement lorsqu'il y a un échec - c'est une erreur grossière
  5. s'il y a des ordres en attente dans la liste, c'est une boucle à 100%.
Résultat : il y a 5 erreurs en 9 lignes - le code ne peut être que jeté.
 
Renat:
Même 5 erreurs :
  1. Le résultat de OrderSelect n'est pas vérifié
  2. le résultat de OrderClose() n'est pas vérifié explicitement
  3. GetLastError() peut être appelé sans aucune opération commerciale (par exemple, si vous avez rencontré un ordre en attente).
  4. ...
Résultat : il y a 5 erreurs en 9 lignes - le code ne peut être que jeté.
Et pourquoi fourrer tout ça dans un expert pour la compétition ? Pour lire le journal ?
L'OrderSelect doit sélectionner et l'OrderClose doit clôturer les ordres nécessaires.
Et il ne devrait pas y avoir d'erreurs :-)
Ou aux frais du client :-)
 
Renat писал (а):
Il y a même 5 erreurs :
  1. OrderSelect ne vérifie pas
  2. explicitement
    3. le résultat
  3. OrderClose()
  4. GetLastError() peut être appelé sans aucune opération commerciale (par exemple, si un ordre en attente est rencontré)
  5. RefreshRates() n'est pas toujours appelé, mais seulement en cas d'échec - une erreur grossière
  6. si la liste contient des ordres en attente, puis un bouclage à 100%
    7. .
Résultat : il y a 5 erreurs en 9 lignes - le code ne peut être que jeté.

Objectif : clôturer toutes les commandes avec une garantie de 100%.
Restrictions : les ordres en attente ne sont pas utilisés

1. Pourquoi devrions-nous vérifier le résultat si nous devons clôturer un ordre ? S'il renvoie false, il y reviendra lors de la prochaine passe, puisqu'une boucle while est utilisée.
2. Voir le point 1.
3. Il existe un contrôle des codes d'erreur à cet effet.
4. Si la mise à jour est systématique, il est inutile de vérifier les erreurs :(
5. Aucune commande en cours

Tous les exemples de clôture d'ordre que j'ai trouvés dans ma recherche sont à passage unique et ne fonctionnent que si tout va bien avec le serveur, sans requêtes, etc. Et ils conduisent tous au fait qu'un jour un ordre ne sera pas fermé et que nous obtiendrons un bon bénéfice... Si je me trompe, corrigez-moi, ou donnez-moi un lien où je peux être convaincu que je me trompe.

Bien sûr, je suis conscient que mon code peut conduire à une boucle, mais à mon avis, c'est mieux que le risque de ne pas clôturer un ordre, ce qui pourrait entraîner de graves pertes financières.
Bien que ce serait mieux si tous les ordres étaient fermés avec 100% de garantie et qu'il n'y ait aucune chance qu'un ordre traîne, voici le code que j'aimerais que vous me donniez =)

Voici un code légèrement modifié, qui devrait même prendre en compte les ordres en attente :
while (OrdersTotal()>0)
   {
      OrderSelect(0,SELECT_BY_POS);
      if (OrderType()==OP_BUY)       OrderClose(OrderTicket(),OrderLots(),Bid,3,Green);
      else if (OrderType()==OP_SELL) OrderClose(OrderTicket(),OrderLots(),Ask,3,Red);
      else OrderDelete(OrderTicket());
      
      RefreshRates();
      err=GetLastError();
      if (err!=135 && err!=138 && err!=0) break;
   }

Il n'est pas aussi "imprudent" que le précédent ?
Je ne comprends toujours pas, pourquoi vérifier OrderSelect et OrderClose dans ce cas ?
 
Malheureusement, personne ne peut donner de garanties sur les opérations commerciales. Le code ci-dessus est bien meilleur que le précédent.

OrderSelect doit toujours être coché, cela est explicitement indiqué dans les Conseils utiles:
  • Manque de contrôle de OrderSelect - les processus asynchrones en action


    En général, un trader perçoit son programme comme étant unique. Mais en réalité, il y a beaucoup de changements asynchrones dans le compte de trading pendant le fonctionnement du conseiller expert. Les positions sont modifiées, ajoutées et supprimées. Si le résultat de chaque appel à OrderSelect() n'est pas contrôlé, il se peut qu'à un moment donné, l'expert opère avec des données erronées (zéro) et fasse un mauvais choix.

 
Renat:
Malheureusement, il n'y a aucune garantie sur les opérations commerciales. Le code ci-dessus est bien meilleur que le précédent.

OrderSelect doit toujours être coché, cela est explicitement indiqué dans les Conseils utiles:
  • Pas de contrôle de OrderSelect - les processus asynchrones en action

    ... Les postes sont modifiés, ajoutés et supprimés. ...

Supposons qu'une position soit modifiée. Il y a une demande de sélection d'un ordre par une certaine condition. Une erreur s'est produite. Les conditions initiales peuvent ne pas être disponibles au prochain tick, alors pourquoi devrais-je refaire la même erreur ?
Aucun commentaire sur "ajouté et supprimé" :-(
Veuillez me donner un exemple fonctionnel de code utilisant OrderSelect pour obtenir OrderCloseTime.
1...45678910111213141516
Nouveau commentaire