Sujet intéressant pour beaucoup : les nouveautés de MetaTrader 4 et MQL4 - de grands changements en perspective - page 66

Nouveau commentaire
 
MetaDriver:

Si le spread est supérieur à la commission du trader (c'est la situation sur les mineurs), il devient rentable pour les traders de pips les limiteurs à l'intérieur du spread (dans le match à venir). Ce qui entraîne automatiquement une baisse des spreads et rend les cross plus attractifs pour le trading..... etc.

En bref - allez apprendre quelques leçons... :)

Eh bien, ça n'arrivera pas.
 
Mischek:
Eh bien, il n'y en aura pas.

Qu'est-ce qui ne se produira pas exactement ? L'appariement, ou ses conséquences automatiques ?

Soyez plus précis... ;)

 
MetaDriver:

Qu'est-ce qui ne se produira pas exactement ? L'appariement, ou ses conséquences automatiques ?

Soyez précis, s'il vous plaît... ;)

Il n'y aura pas de leçons, voilà ce qu'il en est. :)
 
MetaDriver:

Qu'est-ce qui ne se produira pas exactement ? L'appariement, ou ses conséquences automatiques ?

Soyez précis, s'il vous plaît... ;)

Vos conséquences exagérées.
 
MetaDriver:

Qu'est-ce qui ne va pas se passer exactement ?

Il n'y aura rien. Un gros metatrader. Et le silence.)
 
MetaDriver:

Vous n'avez aucune idée de ce que vous avez. L'introduction massive de l'appariement sur les plates-formes MT5 pourrait, dans un certain sens, devenir une "bombe" pour le marché, car elle pourrait théoriquement conduire à une "révolution anti-marché" sur le marché du Forex dans un avenir très proche. Le terme de "révolution" est peut-être exagéré, peut-être pas, car n'importe quel trader sera en mesure de faire du market maker (influencer les prix). Avec la diffusion massive d'agrégateurs natifs couvrant des segments importants du marché mondial..... l'ère du pouvoir (enfin, presque) monopolistique des fournisseurs de liquidités sur la tarification des devises est peut-être (pourrait être) définitivement révolue.

Dans ce contexte, une question "historique" se pose : les traders sont-ils prêts pour la "nouvelle ère" ? De quels outils réguliers dispose la "masse des traders" pour tester, optimiser et déboguer les algorithmes de diffusion ?

Aucun.

Le format de la base de cotation ne permet pas de l'utiliser pour tester et optimiser les stratégies HFT utilisant des ordres limités (ce que sont tous les algorithmes d'étalement).

Je suis d'accord avec cela. Juste un contre-argument : le format actuel des cotations est aussi stupide pour les stratégies de rupture que pour les stratégies inverses, mais vous ne pouvez pas le corriger par une méthode aussi simple que celle-ci. Vous pouvez guérir au moins une classe de stratégies, alors que dans la situation à venir elle prend une "forme dramatique" (voir ci-dessus). Et les autres stratégies ne souffriront pas ! Si vous le voyez, donnez-moi un exemple d'une classe de stratégies pour laquelle la modification du spread de la manière proposée rendra les tests/optimisation moins réalistes.

En fait le testeur est toujours tickwise, donc ce n'est qu'une question de format de l'historique. Et aussi la possibilité d'utiliser des "guillemets non standard" si nécessaire.
MetaDriver:

J'essaie de "regarder autour du coude" un peu plus loin // Tout ce que vous avez écrit est correct.

"La tenue de marché de masse", en raison précisément du déclenchement des scénarios que vous décrivez, peut conduire à terme à la perte de la position d'"échangeur universel" par le dollar. C'est une simple conséquence de l'effondrement des spreads sur les "mineurs". Le marché des changes deviendra plus dynamique et plus efficace. Et ce sont les systèmes d'échange basés sur la prévision (plutôt que sur la manipulation des prix) qui en profiteront. Pour moi, toute régulation non marchande des taux de change est porteuse d'abus majeurs. Peu importe la noblesse des objectifs déclarés - il existe toujours une possibilité de monétisation de l'initié et il est insensé de penser que des mécanismes juridiques peuvent s'y opposer.

En bref, je m'intéresse au "Forex honnête", peut-être que je ne profiterai pas financièrement d'un tel renversement (ou peut-être que si). Mais si je perds, au moins je saurai que j'ai perdu parce que j'ai développé un algorithme stupide, et non parce que j'ai été "trompé".

Pas de commentaire pour le moment. Je vais y réfléchir encore. Je n'ai pas vu une seule stratégie rentable qui négocie un lot constant uniquement en fonction des stops. Pas un seul. Théoriquement, c'est très compréhensible. (Affirmer que de telles stratégies existent revient à affirmer qu'il y a des horizons de trading où la H-volatilité est stablement supérieure à 2.0) Toutes les stratégies de suivi de tendance que j'ai vues sont soit remplies en utilisant des ordres au marché, soit en entrant/sortant sur des pullbacks en utilisant des limiteurs (ou des marques). Pour les marques highAsk/lowBid, l'historique n'a pas plus de valeur que LowAsk/HighBid. Pour elles, l'information importante est plutôt le spread à tous les points de la barre OHLC.

Enfin, il faut comprendre que les demi-mesures comme HighBid+LowAsk ne suffiront pas à rendre un testeur adéquat.

 
Urain:

Enfin, il est clair que les demi-mesures comme HighBid+LowAsk ne suffiront pas à rendre le testeur adéquat.

Si vous tirez une telle conclusion de ce que j'ai écrit... alors vous ne comprenez pas non plus)
 
TheXpert:
Si c'est la conclusion que vous tirez de ce que j'ai écrit... ...alors vous ne comprenez pas non plus).

Qu'est-ce que tu vas faire ? Il entre, dit quelques mots, et c'est tout, quelques nuits blanches sont garanties. )

Le post n'était pas pour moi, mais je ne vais pas dormir non plus.

 
MetaDriver:

(Affirmer qu'ils existent revient à affirmer qu'il existe des horizons de négociation où la volatilité H est systématiquement supérieure à 2,0).

c'est un graal de la tendance tout court. Elle n'est pas non plus systématiquement inférieure à 2x. Il n'existe pas de tels instruments pour lesquels la volatilité H sur l'ensemble de la série est régulièrement inférieure ou supérieure à 2. Sur des segments séparés/à des moments séparés. Sachez quand négocier une tendance, quand négocier un retour. Filtrer le bazar))
 
hrenfx:

J'avais besoin d'améliorer mon testeur pour un nouveau métier. Comprendre le code de l'ancien était plus une perte de temps (j'ai tué plusieurs semaines - approches occasionnelles), que d'en écrire un nouveau.

Il m'a donc fallu 5 heures (avec le débogage) pour écrire un nouveau testeur à partir de zéro. Ses performances (satisfaisantes pour moi en tant que débutant) :

  • Fonctionne avec M1 HighBid + LowAsk (les résultats sont plus précis que dans le testeur MT5).
  • Un symbole.
  • Vitesse (i7 2700K) environ 100.000.000 barres par seconde (277 années FOREX par seconde) sur TS de test - pas vide, beaucoup de choses sont calculées. Constamment sur le marché.
  • Pas de MM - pas de lots.
  • Profit uniquement en pips.
  • Le trader a la possibilité de contrôler le slippage et la commission.
  • Optimiseur avec ses propres critères d'optimisation - pour chacun d'eux, il ouvre son propre fichier (qui peut prendre plusieurs Go) avec des chaînes de transactions triées.
  • Il n'y a pas de contrôle d'erreur dans le testeur - je connais toutes les nuances de mon testeur, donc je ne le permets pas.
  • TS est écrit dans un MQL4 légèrement abrégé - toutes les choses inutiles ont été supprimées. Mais vous pouvez utiliser toute la puissance du C++.
  • Le testeur est écrit sans OOP - je ne sais pas comment le faire de manière compétente. Il s'agit donc pratiquement d'un pur langage C.
  • Code source en C++ libre~ 20Kb.
  • Les arrêts et les marchés ont été jetés (OrderClose a été laissé) - pas nécessaire.
  • Chaque exécution (au choix - spécifier le numéro de l'exécution) peut être visualisée et étudiée dans le paquet mathématique - le fichier des modifications de l'équité et de la balance est écrit simplement.
  • Pas de génétique.
  • Pas d'OpenCL - on ne peut pas le faire.
  • Mono-filière. Chargement stupide de tous les cœurs - exécution manuelle de plusieurs optimiseurs.
  • Application console.
  • Les paramètres d'entrée du TC, les réglages du testeur et les plages d'optimisation sont définis dans le fichier.
  • TC est compilé avec le testeur dans un seul fichier EXE.
  • Avant le démarrage, il n'y a que trois fichiers : EXE, historique, paramètres.
  • L'optimiseur a une interruption de l'exécution, si l'état actuel de l'exécution ne satisfait pas aux conditions (par exemple, la subsidence est trop élevée).
  • Le script MQL4 prépare l'histoire pour le testeur, il a été écrit il y a longtemps.
  • Pas d'allocation dynamique de mémoire pour la table des commandes - une fois la mémoire allouée et oubliée.
  • Pas de journaux - je ne les regarde pas.
  • Pas d'historique des commandes - de la même manière.
  • Il n'y a aucune idée des indicateurs et de tout ce qui s'y rapporte - nous n'en avons pas besoin pour le TS.
  • Les prix sont des nombres entiers (long int).

Si le même non-sens est mis en œuvre dans MQL5, nous pouvons utiliser Cloud en mode d'optimisation matricielle. Seul l'historique doit être envoyé à chaque fois - la compression intégrée de ces informations est nécessaire.

Théoriquement, il est possible d'atteindre une vitesse de ~ 100 Bb/s (au niveau du TS d'essai). Je me demande quelles sont les performances de MT5-tester sur l'ensemble du nuage dans les mêmes perroquets ?

100 milliards de bars par seconde est une bonne vitesse pour toutes sortes de recherches. Si on la convertit en d'autres unités, cette vitesse signifie qu'une année d'une minute d'histoire du FOREX est exécutée ~300 000 fois par seconde sur un symbole.

La majeure partie du temps a été consacrée à l'apprentissage de la syntaxe de la langue - simplement en googlant. Pas un programmeur.

Je vous le dis tout de suite, c'est une énorme perte de temps que d'écrire un cadre universel pour vos modestes besoins. Mieux vaut explorer. Si un élément doit être pris en compte, il suffit de le terminer.

Ce n'est qu'un noyau, il faut maintenant une boîte à outils astucieuse pour l'optimiseur. Cela prendra beaucoup plus de temps ici - vous devez y réfléchir.

Je suis en train de lire tout cela et il me vient à l'esprit que soit une personne est complètement perdue dans les courants de sa conscience, soit au moins la moitié de ce qu'elle a écrit n 'est qu'un vulgaire mensonge.

Un programmeur autodidacte sans connaissance approfondie du langage a écrit un testeur monofilaire avec une performance de 100 000 000 de barres par seconde pendant plusieurs heures ? En revanche, les personnes du plus haut niveau de professionnalisme passent des années à créer un testeur HFT compétent et performant, à créer des équipes entières pour travailler avec lui et à le remplir de stratégies, et ici une personne a décidé de construire un testeur par elle-même et a immédiatement obtenu une performance supérieure d'un ordre de grandeur des principales plateformes HFT (fermées).

Calculons simplement la quantité de mémoire de la bande passante dont nous avons besoin pour exécuter 100 000 000 de barres par seconde. Chaque barre est constituée de 4 prix + AskLow HighBid, ce qui donne 6 types d'entiers de 64 bits chacun(les prix sont des entiers (long int)). Pour 100.000.000 de bars par seconde il faudrait

64 bits * 6 prix * 100 000 000 de barres = 38 400 000 000 bits = 4 800 000 000 octets = . 4 577 Moctets par seconde..


Cela signifie que cette performance peut, fondamentalement et purement théoriquement, être atteinte sur des modules de mémoire DDR2 533 et plus. Au moins, les performances déclarées sont comparables à la limite physique du matériel moderne.

Mais le coût du temps passé sur les logiciels impose des contraintes encore plus importantes. On ne peut les ignorer. C'est pourquoi j'ai pris un compilateur C 64 bits rapide, Win-Lcc 64, et mesuré les performances d'une recherche directe d'un tableau de barres sans calculs mathématiques lourds. Attention : nous parlons de recherche directe, c'est-à-dire la plus rapide. Sans manipulation de l'environnement et autres frais généraux. Contrairement à dickfix, je fournis le code source complet de mon "testeur de stratégie", afin que chacun puisse le compiler et mesurer les performances dans son compilateur préféré :

#include <time.h>
#include <stdio.h>
#include <stdlib.h>
#include <conio.h>
#include <windows.h>
#define  LAPS 10000              //Количество серий
#define  ELEMENTS 10000          //Количество баров в одной серии
#define  INVOKE                  //Определено, если требуется эмулировать
                                //вызов функции

//Представление бара
struct bar
{
        long long Open;
        long long High;
        long long Low;
        long long Close;
        long long AskLow;
        long long BidHigh;
};

int main(void)
{
        struct bar bar_array[ELEMENTS];
        //Общее время выполнения стратегии
        clock_t eleps_time = 0;
        //Общее время выполения
        clock_t total_time = 0;
        //К сожалению заявленный объем памяти (100 000 000 баров) выделить не удалось,
    //поэтому выделяем память порциями, 1000 раз, по 100 000 баров за раз.
        clock_t ttime = clock();
        for(int lap = 0; lap < LAPS; lap++)
        {
                //Заполняем бары случайными числами
                for(int i = 0; i < ELEMENTS; i++)
                {
                        bar_array[i].Open = (long long)rand();
                        bar_array[i].High = (long long)rand();
                        bar_array[i].Low = (long long)rand();
                        bar_array[i].Close = (long long)rand();
                        bar_array[i].AskLow = (long long)rand();
                        bar_array[i].BidHigh = (long long)rand();
                        //if(i < 5)
                        //      printf("%i\n", bar_array[i].High);
                }
                //Эмулируем работу ТС c массивом котировок
                //Рассчитываем время на выполнение этого блока и суммируем его, получая общее время
                //выполнения
                clock_t btime = clock();
                //Наша стратегия будет проверять простое соответствие проверяемого бара настоящему.
                //Настоящий бар, это бар чей high > open, low, close а low < high, open, close
                int signal = 0;

                for(int i = 0; i < ELEMENTS; i++)
                {
                        #ifndef  INVOKE
                        if( bar_array[i].High > bar_array[i].Low &&
                            bar_array[i].High > bar_array[i].Open &&
                                bar_array[i].High > bar_array[i].Close)
                                signal++;
                        #endif
                        #ifdef  INVOKE
                        signal += TradeSystem(&bar_array[i]);
                        #endif
                }
                eleps_time += clock() - btime;
        }
        printf("Bars was worked: %i\n", LAPS*ELEMENTS);
        //Печатаем общее время выполнения
    double timedif = ((double)clock() / (double)CLOCKS_PER_SEC);
    printf("Bars %f seconds\n", timedif);
        //Печатаем время выполнения торговой системы
        double eleps_diff = (double)eleps_time / (double)CLOCKS_PER_SEC;
        printf("The TradeSystem time is %f seconds\n", eleps_diff);
        printf("The Eleps tik is %i tiks\n", eleps_time);
        return 0;
}
//
// Функция торговой системы. Принимает на вход бар,
// обрабатывает его и возвращает целочисленный результат
int TradeSystem(struct bar &cbar)
{
        if( cbar.High > cbar.Low &&
                cbar.High > cbar.Open &&
                cbar.High > cbar.Close)
                                return 1;
        return 0;
}

Vous pouvez voir que ce code, en fonction de la directive Invoke, parcourt le tableau et effectue une simple comparaison (une opération très rapide) ou appelle une fonction qui effectue la même comparaison.

Voyons combien de temps il faut à ce code pour rechercher et comparer 100 000 000 de barres :

Nous pouvons voir qu'il a fallu 1,28 seconde pour parcourir directement 100 000 000 de barres, ce qui est presque un tiers de moins que la performance annoncée.

On constate que la recherche de 100 000 000 de barres avec appel de la fonction de calcul sur chaque barre a pris 1,79 seconde, ce qui est plus de 1,5 fois pire que la performance déclarée.

Tous les tests ont été effectués sur un matérieli7 870, DDR3 3200 8Gb.

La majeure partie du temps a été consacrée à la préparation effective des données (environ 9 secondes). La moindre non-optimalité dans la conception de l'optimiseur entraînera une énorme surcharge. Mais je n'ai pas tenu compte de ce temps puisque nous ne parlions que de la course à la stratégie.

Vous tirez vos propres conclusions. J'espère avoir démontré par des chiffres que le résultat prétendu, pour ne pas dire plus, ne correspond pas à la réalité. Même la performance théorique du code décrivant l'optimiseur ne correspond pas au résultat annoncé. Et si vous implémentez un vrai testeur qui s'approche de la fonctionnalité de celui qui est revendiqué, les performances chuteront encore plus bas, puisque tout appel de fonction et tout calcul mathématique plus ou moins utile réduira immédiatement le temps de la recherche pure.

1...596061626364656667686970717273...75
Nouveau commentaire
Raison: