Erreurs, bugs, questions - page 1861
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Alpari
fxopen
Ils n'ont pas de drapeaux.
c'est clair, mais alors qu'est-ce qu'on ajoute pour obtenirCOPY_TICKS_ALL ?
parce qu'ils ontCOPY_TICKS_TRADE=0
et les ticks dans l'histoire avec les drapeaux manquants sont lesCOPY_TICKS_TRADE inconnus?
c'est clair, mais alors qu'est-ce qu'on ajoute pour obtenirCOPY_TICKS_ALL ?
parce qu'ils ontCOPY_TICKS_TRADE=0
et les ticks dans l'historique avec les drapeaux manquants sont inconnusCOPY_TICKS_TRADE ?
Les fonctions HistoryDealGet* et HistoryOrderGet* sont écrites de manière très étrange, en termes de performances.
Lorsque je fais HistorySelect, par exemple, pour 100K enregistrements individuels. La fonction HistoryDealGet doit avoir comme premier argument non pas le nombre d'enregistrements dans la table de l'historique, mais un ticket. Et le tableau est trié par heure, et non par ticket. Par conséquent, la première chose que fait la fonction HistoryDealGet, à chaque fois qu'elle s'exécute, est de parcourir la table et de rechercher un ticket correspondant.
Pourquoi un tel gaspillage de ressources ! Il s'avère que le tout premier ticket et le plus récent seront exécutés à des vitesses différentes. Et pour obtenir toutes les caractéristiques de la dernière transaction, les fonctions HistoryDealGet parcourront à chaque fois l'ensemble de la table.
Pourquoi ne pas le rendre normal ?
Et comment pouvons-nous tester le robot HFT, si pour obtenir le montant de la commission de la position actuelle, nous devons entrer dans l'historique lent par HistorySelect à chaque fois, et en aucun cas par HistorySelectByPosition? Le slippage de l'ordre en attente se transforme en une perte de performance !
ACCOUNT_PROFIT dans le testeur montre un non-sens.
Exécutez le conseiller expert qui ouvre et ferme la position immédiatement.
Le résultat est
ACCOUNT_PROFIT affiche zéro, mais en fait il est de -56.44. Par conséquent, l'équité, le drawdown, etc. sont estimés de manière incorrecte.
PositionGetDouble(POSITION_PROFIT) - même chose.
Et comment tester un robot HFT, si pour connaître la taille de la commission de la position actuelle, vous devez entrer dans l'historique par HistorySelect et non par HistorySelectByPosition à chaque fois ? Voir le glissement d'un ordre en attente se transforme en un déchet de performance !
Est-ce que HistorySelect fonctionne par une recherche binaire de l'intervalle de temps demandé ou non ? C'est-à-dire O(N) ou O(log(N)) ?
Non. La recherche binaire n'est pas applicable dans ce cas.
Ainsi, en interne, les deux histoires (commandes et transactions) sont triées par ordre chronologique.
Je suis désolé, je me suis un peu emporté.
Oui, ils sont triés par heure. L'enregistrement initial est recherché par une recherche binaire.
Oui, trié par heure. L'entrée initiale est recherchée par recherche binaire.
N'est-il pas logique de rechercher le dernier enregistrement de la même manière ?
C'est très stressant d'organiser l'histoire. Le HFT dans le testeur est presque irréaliste. J'ai écrit plusieurs messages sur le forum à ce sujet et fait une demande à la SD.
Et autre chose, si le terminal dispose déjà de l'historique, pourquoi exigez-vous d' utiliser HistorySelect au lieu de SELECT_BY_POS selon le principe de MT4 ? Et ce n'est pas clair du tout, pourquoi HistoryDealGet* est implémenté par le billet avec O(N) approprié, alors qu'il est raisonnable d'utiliser SELECT_BY_POS à nouveau ?
Des dossiers très intéressants