Questions d'un "mannequin - page 176

[Yedelkin]

Karlson:

3Б. Fermeture partielle par l'ouverture d'une demi-vente - OUT.

Dommage :/ Il s'avère qu'il peut y avoir plusieurs transactions dans l'historique avec la propriété OUT, alors que la position existera toujours.

[Anatoli Kazharski]

Yedelkin:
Mauvais :/

Pourquoi mauvais ? C'est simple, si je vous comprends bien. Si OUT et qu'il y a une position, il y a eu une réduction du volume. Si OUT et aucune position, alors la position a été complètement fermée.

[Yedelkin]

tol64:
Pourquoi est-ce mauvais ? Tout est simple, si je vous ai bien compris. S'il y a une position et OUT, il y a eu une diminution du volume. Si OUT et qu'il n'y a pas de position, alors la position a été complètement fermée.

La mauvaise chose est la suivante. Votre approche"Si OUT et il y a une position, il y a eu une réduction du volume. S'il n'y a pas de OUT et qu'il n'y a pas de position, alors la position a été complètement fermée" présente une caractéristique que je trouve encombrante, à savoir la nécessité de vérifier en plus à chaque fois si l'information sur la position existe dans la base de données du terminal.

Nous savons tous que l'information dans le terminal de base arrive avec un certain décalage par rapport à la situation réelle. Nous ne pouvons donc pas exclure les situations où le résultat de la vérification est"il y a une position et elle est OUT", mais qu'en fait la position a été fermée. En d'autres termes, il est possible de recevoir des informations inexactes et de s'en servir comme base pour prendre de mauvaises mesures. Ou bien il faudra inventer des contrôles supplémentaires, des retards, ou tout ce qui est pratique.

Mais vous pouvez vous passer de toutes ces astuces. En particulier, sans vérifier la disponibilité des postes. Pour ce faire, il suffit de laisser une correspondance univoque entre la clôture de la position et la propriété DEAL_ENTRY_OUT (correspondance - telle qu'elle est présentée maintenant dans le manuel), et d'attribuer la réduction du volume de la position à une propriété distincte de la transaction. Il suffira alors de trouver dans l'historique (HistorySelectByPosition) une seule transaction avec la propriété DEAL_ENTRY_OUT, et d'être assuré que la position n'est pas réduite, mais exactement fermée, et qu'en aucun cas elle ne peut être inversée.

[Anatoli Kazharski]

Yedelkin:

La mauvaise chose est la suivante. Votre approche"Si OUT et il y a une position, il y a eu une réduction du volume. S'il n'y a pas de OUT et qu'il n'y a pas de position, alors la position a été complètement fermée" présente une caractéristique que je trouve encombrante, à savoir la nécessité de vérifier à chaque fois les informations relatives à la position dans la base de données du terminal.

Nous savons tous que l'information dans le terminal de base arrive avec un certain décalage par rapport à la situation réelle. Par conséquent, nous ne pouvons pas exclure les situations où le résultat de la vérification est"il y a une position et elle est OUT", mais en fait la position a été entièrement fermée. En d'autres termes, il est possible de recevoir des informations inexactes et de s'en servir comme base pour prendre de mauvaises mesures. Ou bien il faudra inventer des contrôles supplémentaires, des retards, ou tout ce qui est pratique.

Mais vous pouvez vous passer de toutes ces astuces. En particulier, sans vérifier la disponibilité des postes. Pour ce faire, il suffit de laisser une correspondance univoque entre la clôture de la position et la propriété DEAL_ENTRY_OUT (correspondance - telle qu'elle est présentée maintenant dans le manuel), et d'attribuer la réduction du volume de la position à une propriété distincte de la transaction. Il suffira alors de trouver dans l'historique (HistorySelectByPosition) une seule transaction avec la propriété DEAL_ENTRY_OUT et de savoir avec certitude que la position n'est pas réduite, mais exactement fermée, et qu'elle ne peut en aucun cas être inversée.

Dans OnTrade(), nous recevons la réponse du serveur. Autrement dit, si nous vérifions l'événement dans OnTrade(), nous saurons déjà avec certitude s'il y a une position ou non. Nous pouvons toutefois fournir des options standard telles que DEAL_ENTRY_FULLOUT (fermeture complète) ouDEAL_ENTRY_PARTOUT (fermeture partielle) pour que tout soit parfaitement élégant.)))

En attendant, vous pouvez créer des fonctions distinctes, afin de ne pas avoir à introduire à chaque fois des "contrôles lourds".

[Yedelkin]

tol64:

Bien que vous puissiez créer des options standard comme DEAL_ENTRY_FULLOUT ouDEAL_ENTRY_PARTOUT pour que tout soit parfaitement élégant.)))

C'est de ça qu'il s'agit. Nous n'aurons même pas besoin d'effectuer des vérifications supplémentaires dans OnTrade qui paraîtront trop lourdes par rapport à la solution proposée (FULLOUT / PARTOUT).

[Anatoli Kazharski]

Yedelkin:
C'est le but... Vous n'auriez même pas besoin d'effectuer des vérifications supplémentaires dans OnTrade, ce qui semblerait encore lourd par rapport à la solution proposée (FULLOUT / PARTOUT).

Essayez de faire une proposition au Service Desk. Peut-être y réfléchiront-ils et la mettront-ils un jour en œuvre.

[Yedelkin]

tol64:
Essayez de faire une proposition au Service Desk. Peut-être y réfléchiront-ils et la mettront-ils un jour en œuvre.

Je l'ai déjà fait :) Comme une erreur de langage ... Wow, ça m'a pris une heure à composer.

[Anatoli Kazharski]

Yedelkin:
Je l'ai déjà fait :) Comme un lapsus... Wow, ça m'a pris une heure à composer.

On ne peut toujours pas appeler ça une erreur. Mais que pouvez-vous faire maintenant que vous avez déjà été envoyé. ))

[Yedelkin]

tol64:
On ne peut toujours pas appeler ça une erreur. Mais que pouvez-vous faire maintenant que vous avez été envoyé. ))

C'est là que les catégories d'évaluation entrent un peu en jeu :) J'ai essayé de justifier la catégorie Erreurs :)

[Валерий]

Yedelkin:

Oui, chaque période correspond à une certaine valeur. Quelqu'un l'a posté sur le forum il y a quelques années. Vous pouvez le découvrir par vous-même en exécutant une ligne comme celle ci-dessous :

Le script imprimera les valeurs ENUM_TIMEFRAMES pour toutes les périodes dans le système décimal :

void OnStart()
  {
//---
   for(int i=(int)PERIOD_CURRENT;i<=(int)PERIOD_MN1;i++)
     {
       ResetLastError();
       string period=EnumToString((ENUM_TIMEFRAMES)i);
       if(GetLastError())
        continue;
       Print(EnumToString((ENUM_TIMEFRAMES)i)+"="+IntegerToString(i));
     }
  }
//+------------------------------------------------------------------+