Erreurs, bugs, questions - page 444

[[Supprimé]]

Interesting:
Les séances de négociation et de cotation n'aideront pas à résoudre le problème ?

Malheureusement, non. Selon les spécifications du contrat, la session de cotation commence à 00:00:00 le lundi.
En fait, le Rosh répond ici que le début d'une session de cotation ne garantit pas la disponibilité des cotations dans celle-ci. Ce qui est, en principe, compréhensible.

Pour l'instant, j'utilise une "béquille" sous la forme du contrôle suivant :

input int TTL = 10; // Время "жизни" котировки
...
void Trade() {
  ...
  if (TimeCurrent() - SymbolInfoInteger(Instrumet, SYMBOL_TIME) > TTL) return;
  ...
  // Далее отправка торгового приказа на сервер.
}

Je serais reconnaissant si quelqu'un pouvait partager une solution plus élégante (tous les utilisateurs de multidevises doivent avoir rencontré ce problème).

P.S.
Konstantin Gruzdev propose une variante élégante dans son article Implementing the multicurrency mode in MetaTrader 5.
Mais cette variante ne répondra pas aux exigences du championnat.

[Vladimir Gomonov]

voix_kas:

Oups... qui a touché une corde sensible. :)) La dernière ligne a été corrigée à la main dans un post de forum, alors pardonnez-moi. =)
Au fait, votre code n'a pas compilé non plus (j'ai oublié de mettre une parenthèse fermante dans la dernière ligne). :-Р
En outre, il est 2-3 fois plus lent (je l'ai vérifié sur le script), mais la qualité de la vérification est la même. :-Р

Quoi qu'il en soit, tant qu'il n'y aura pas de code approprié pour déterminer l'entier significatif, je suivrai le conseil du composteur : normaliser le volume à 8 décimales.
Espérons qu'il n'y aura pas d'embûches.

:)

[Aleksey Lebedev]

voix_kas:

OrderCheck ne vous aide pas ?

[Aleksey Lebedev]

Référence :

Функцию Sleep() нельзя вызывать из пользовательских индикаторов, так как индикаторы выполняются в интерфейсном потоке и не должны его тормозить.

Est-ce vraiment, vraiment impossible, ou si vous le voulez vraiment, vous pouvez, mais avec prudence ? :)

Problème d'accès aux données d'un autre symbole à partir de l'indicateur.

s'il n'y a pas de tics)

[[Supprimé]]

Swan:
OrderCheck ne vous aide pas ?

Non. J'écris une ligne avant l'échange :

if (!OrderCheck(TradeRequest, TradeCheckResult) || (TradeCheckResult.retcode != TRADE_RETCODE_DONE)) return;

Il y a toujours une erreur dans le journal. :(

[Andrey Khatimlianskii]

Et qu'en est-il de la normalisation des lots ?

Les gars, pourquoi faire des théories ?

Une situation où l'augmentation du lot sera supérieure au lot minimum est absurde. Imaginez : min = 0,1, pas = 1,0. Donc, seuls les lots 1.1, 2.1, 3.1, ... sont autorisés ? C'est absurde.

Si vous faites de l'arithmétique et de la programmation, alors vos options seront gagnantes. Mais si nous parlons de programmation appliquée (au sens de trading), alors à lot_step > lot_min nous devons terminer le programme avec une erreur critique et changer de toute urgence de courtier, car il n'a pas assez d'argent même pour le salaire d'une personne qui configurerait normalement le serveur).

Tout doit être modéré. Ma variante fonctionne sur les réels depuis plus de 5 ans, avec différents courtiers, types de comptes, instruments - je n'ai jamais eu d'erreur.

[[Supprimé]]

komposter
Pourquoi est-ce absurde ? Prenons un exemple simple : min_lot = 1,0, min_step = 0,3. Les exigences répondent au principe du "no nonsense" (min_lot >= lot_step). :)
Vous passez le volume de 1,3 lots à la fonction de normalisation. Vous en retirez 1,2 lot.
La version mise à jour renverra à la version 1.3. Ses étapes sont "correctes" : à partir du lot minimum, et non à partir de zéro.

Un autre problème est la présence d'étapes "en vie" autres que"1.0, 0.1, 0.01, etc.".
Ici, il me semble que le coût du problème (perte de performance) est négligeable par rapport à la solution d'une éventuelle erreur hypothétique. IMHO.
Après tout, il est tout simplement plus correct de compter de cette façon : des étapes à partir du lot minimum, et non à partir de zéro.

[Гребенев Вячеслав]

Existe-t-il un code prêt à l'emploi quelque part qui achèterait le nombre maximum possible de lots au symbole et au prix actuels pour une somme d'argent donnée (par exemple, 1234,56 $ est le seul paramètre d'entrée). À l'intérieur, il devrait y avoir toutes sortes de contrôles pour les volumes maximum et minimum, la normalisation, la comptabilité de l'effet de levier, la suffisance des fonds, etc. etc. Le principal est que le code doit effectuer un achat et ne pas m'ennuyer avec le fait que je n'ai pas d'argent (achetez autant que j'en ai), qu'une vérification a échoué (faites-la réussir), qu'un ordre est placé, mais qu'aucun achat n'a eu lieu (mourrez, mais ne revenez pas sans acheter), etc. Je comprends que quelque part dans des classes comme CTrade, c'est le cas. Mais il n'est pas si facile de copier quelque chose de là. Je veux traiter avec mon propre algorithme, pas avec le langage de MQL5.

[Aleksey Lebedev]

voix_kas:

Non. J'écris une ligne avant d'échanger :

Il y a toujours une erreur dans les journaux. :(

En regard, sur les comptes de championnat, tous les instruments sont négociés en même temps. Registre)

TradeCheckResult.retcode != TRADE_RETCODE_DONE

Je ne suis pas si sûr de cette condition...

Je ne sais pas si cette condition est correcte ou non :

si(prix actuel == 0.0) retour ;

[Andrey Khatimlianskii]

voix_kas:

komposter
Pourquoi est-ce absurde ? Prenons un exemple simple : lot minimum = 1,0, pas minimum = 0,3. Les exigences répondent au principe du "no nonsense" (min_lot >= lot_step). :)
Vous passez le volume de 1,3 lots à la fonction de normalisation. Sur ce nombre, 1,2 lot vous est restitué.
La version mise à jour renverra à la version 1.3. Ses étapes sont "correctes" : à partir du lot minimum, et non à partir de zéro.

Un autre problème est la présence d'étapes "en vie" autres que"1.0, 0.1, 0.01, etc.".
Ici, il me semble que le coût du problème (perte de performance) est négligeable par rapport à la solution d'une éventuelle erreur hypothétique. IMHO.
Après tout, il est tout simplement plus correct de compter de cette façon : des étapes à partir du lot minimum, et non à partir de zéro.

"lot minimum = 1,0, échelon minimum = 0,3" est également absurde. Les marches doivent être un multiple du lot minimum.

J'ai déjà exprimé mon opinion - dans un concours de mathématiques et de programmation, la variante de soustraction min_lot gagnera, elle n'est pas nécessaire pour le trading réel.

Je ne vois pas l'intérêt de poursuivre la discussion, chacun a fait son chemin ;)