MT5 et trans2quik.dll - page 9

 
prostotrader:

"Termial" (un groupe de conseillers) en action.

Aujourd'hui, les premiers échanges sur le réel ont été effectués.


Lien synthétique ?

C'est spécialement pour cela que j'ai ouvert EBS à l'ouverture. Fabrication d'un robot en lua dans QuickBooks. Mais en %, cela n'a pas été mieux que d'acheter des obligations. C'est pourquoi j'y ai renoncé.

 

le taux d'intérêt actuel est le suivant (frais et taxes compris)

contango

 
Volokola:

Un lien synthétique ?

C'est spécialement pour cela que j'ai ouvert EBS à l'ouverture. J'ai fait un robot lua dans QuickBooks. Mais en %, il s'est avéré que ce n'était pas mieux que d'acheter simplement des OFZ. C'est pourquoi j'y ai renoncé.

Je suppose que je vais devoir l'abandonner aussi, dommage....

Ajouté par

Mais d'après votre tableau, il est clair que vous ne comptez pas quelque chose correctement (mon pourcentage est beaucoup plus élevé, bien que je compte même le pourcentage lorsque l'argent revient dans 15 jours).

 
Yuriy Asaulenko:

Retards lors de la construction d'une table, chat puis par le DDE.

Insérez quelques print() dans le programme, et sentez la différence).

Bien sûr, c'est mauvais que ça traîne, mais ce n'est pas un problème (la limite n'est pas exécutée à temps, tant pis, ça marchera la prochaine fois).

Le pire est que trans2quik.dll lui-même est un TROUBLE !

Quand il y a une commande pour vendre des futures, il n'envoie pas de données au DDE, mais attend une réponse de trans2quik.dll.

et une transaction pseudo-marché est exécutée (aucune action ne peut être achetée sur le marché).

Sur l'image, vous pouvez voir que plus de 200 ms plus tard, il y avait un échange de réponse (fonctionne uniquement avec trans2quik.dll)

C'est un compte réel.

 
prostotrader:


Mais votre tableau montre que vous comptez mal (mon pourcentage est beaucoup plus élevé, même si je compte le pourcentage lorsque l'argent est rendu après 15 jours).

J'ai tout compté et recalculé.

Vous pouvez tout voir dans le tableau :

on prend l'offre du contrat à terme + la demande de l'action.

Gazprom : 16753 = 165.78

Écart "sale" = 175 roubles (ou 0,9 % du dépôt = contrats à terme GO + cours de l'action)

commission = 27 roubles

consiste en

brok_comiss_mmvb=0.06 --en % commission du courtier sur le MICEX

brok_comiss_forts=1.00 -- en % de commission du courtier sur FORTS. Roubles par contrat et par tour.

comiss_mmvb=0.009 -- en % commission de la Bourse sur le MICEX

comiss_forts=0.006 -- en % commission de Bourse sur FORTS


le pourcentage peut avoir légèrement changé maintenant.

et moins 13% = 129rub "pure" spread (0.66% de mon dépôt)

50 jours avant l'échéance = 129/50*365 = 940 RUB ou 4,81% de mon dépôt s'élevant à 19537rb.

****

S'il y a une erreur = je vous serais reconnaissant de me la signaler.


 
Volokola:

Tout a été compté et recalculé.

Le tableau montre tout :

nous prenons l'offre à terme + l'action.

gazprom : 16753 = 165.78

spread "sale" = 175 roubles (ou 0,9% du dépôt = contrats à terme GO + cours de l'action)

commission = 27 roubles

consiste en

brok_comiss_mmvb=0.06 --en % commission du courtier sur le MICEX

brok_comiss_forts=1.00 -- en % de commission du courtier sur FORTS. Roubles par contrat et par tour.

comiss_mmvb=0.009 -- en % commission de la Bourse sur le MICEX

comiss_forts=0.006 -- en % commission de Bourse sur FORTS


le pourcentage peut avoir légèrement changé maintenant.

et moins 13% = 129rub "pure" spread (0.66% de mon dépôt)

50 jours avant l'expiration = 129/50*365 = 940 RUB ou 4,81% du dépôt s'élevant à 19537 RUB.


J'ai ces commissions pour Gazprom


Ajouté

A ces commissions (en tenant compte du fait qu'ils garderont mes fonds (13%)) + 1 jour d'expiration (pour négocier le dernier jour)

Voici ce qu'il en ressort

Ajouté

Les commissions d'expiration sont différentes selon les instruments

if (Pos('(SBERP)', aNAme) > 0) then BiExpEdit.Text:= '0,5' else
  if (Pos('(MOEX)', aNAme) > 0) then BiExpEdit.Text:= '1,0' else
  if (Pos('(SBER)', aNAme) > 0) then BiExpEdit.Text:= '1,0' else
  if (Pos('(TATN)', aNAme) > 0) then BiExpEdit.Text:= '1,0' else
  if (Pos('(VTBR)', aNAme) > 0) then BiExpEdit.Text:= '1,0' else
  if (Pos('(HYDR)', aNAme) > 0) then BiExpEdit.Text:= '1,0' else
  if (Pos('(AFLT)', aNAme) > 0) then BiExpEdit.Text:= '1,0' else
  if (Pos('(MGNT)', aNAme) > 0) then BiExpEdit.Text:= '1,6' else
  if (Pos('(TRNF)', aNAme) > 0) then BiExpEdit.Text:= '4,0' else
    BiExpEdit.Text:= '2,0';
 
Envoyez-moi votre formule de calcul et je la comparerai à la mienne.
 
prostotrader:

Bien sûr, c'est dommage que cela ralentisse, mais ce n'est pas un problème (la limite n'est pas exécutée à temps, peu importe, cela fonctionnera la prochaine fois).

Le pire est que trans2quik.dll lui-même est un TROUBLE !

Quand il y a une commande pour vendre des futures, il n'envoie pas de données au DDE, mais attend une réponse de trans2quik.dll.

et une transaction pseudo-marché est exécutée (aucune action ne peut être achetée sur le marché).

Dans l'image, vous pouvez voir qu'il y a eu un accord de réponse après 200 ms (seul trans2quik.dll fonctionne).

Je ne négocie pas selon les limites du marché (seulement les mains, occasionnellement) - il y a jusqu'à une centaine de transactions par seconde, il est clair que le prix va monter, et Dieu seul sait combien de temps il faut attendre.

Les offres d'achat un peu plus élevées que le marché, les ventes un peu plus basses, enfin, + le slippage - seront exécutées par le verre du marché, en général, instantanément. En principe, vous pouvez utiliser les limites, mais faites le prix +/- 5-7 points par rapport au marché sur les futures.

Et à propos de trans2quik.dll. L'utilisez-vous probablement en mode synchrone ? Alors oui, vous devez attendre la réponse. En mode asynchrone, il n'est pas nécessaire d'attendre quoi que ce soit - il suffit de tirer et d'oublier). Résultat par événement ou demande.

 
Yuriy Asaulenko:

Je ne négocie pas en fonction des limites du marché (seulement avec mes mains, occasionnellement) - il y a jusqu'à une centaine de transactions par seconde, il est clair que le prix va monter, et Dieu seul sait combien de temps il faut attendre.

Les offres d'achat un peu plus élevées que le marché, les ventes un peu plus basses, enfin, + le slippage - seront exécutées par le verre du marché, en général, instantanément. En principe, vous pouvez utiliser les limites, mais faites le prix +/- 5-7 points par rapport au marché sur les futures.

Et à propos de trans2quik.dll. L'utilisez-vous probablement en mode synchrone ? Alors oui, vous devez attendre la réponse. En mode asynchrone, il n'est pas nécessaire d'attendre quoi que ce soit - il suffit de tirer et d'oublier). Résultat par événement ou demande.

Les contrats à terme devraient UNIQUEMENT être vendus par un ordre à cours limité - bien, non - bon à rien, attendez la prochaine course.

Non, trans2quik.dll est en mode asynchrone.

Ajouté

Laissez-moi vous expliquer pourquoi c'est la bonne façon de négocier.

La densité des taux au comptant (même pour les instruments à faible liquidité) est très élevée, tandis que la densité des taux au comptant est très faible.

et la densité des futures est faible, donc nous vendons les futures strictement limite (au prix dont nous avons besoin), et les

Le SPOT est un pseudo-marché.

 
prostotrader:

Je suppose que je vais devoir l'abandonner aussi, dommage....

Ajouté

Mais d'après votre tableau, il semble que vous comptiez mal (mon pourcentage est beaucoup plus élevé, bien que je compte même le pourcentage lorsque l'argent est rendu dans 15 jours).

J'ai réalisé un tel EA sur MT5 pur. Je l'ai testé dans le testeur sur la base de ticks réels, toutes les transactions sont sur le marché. Mais si j'utilise l'ordre limite dans une transaction réelle, le résultat devrait être meilleur.

Les commissions ont été considérées, les taxes n'ont pas été prises en compte. Voici ce que j'ai obtenu pour GAZP :

Presque 10% pour un mois.

p.s. si quelqu'un est intéressé, je peux le mettre dans ma kodobase

Raison: