Une stratégie de trading efficace basée sur l'analyse multidevises de plusieurs DCs - page 12

 
En effet, il faut faire et essayer :) L'essentiel est d'avoir quelque chose pour commencer :) Merci à tous ceux qui ont contribué au développement de ce sujet, vos opinions et commentaires ont porté l'idée à un niveau que nous n'aurions pas atteint seuls :)
 
xnsnet:
Là, là, Alexey j'aime tes pensées :) Je prendrai une définition maximale de données tick 128 bytes, multiplié par 100 mille ticks, douze mètres, d'un client par jour multiplié par 100 clients, gigabytes, même avec mes ressources je peux garder l'historique pour quelques mois d'une centaine de clients, que dire si je mets le matériel nécessaire, pour des années avec une compaction fiable.

Mieux encore, le serveur ne stockera rien, il ne fera que traiter les demandes et rechercher les données nécessaires auprès des clients qui sont actuellement en ligne ou attendre ceux qui sont en ligne et ont déjà vu ces données auparavant.
C'est une sorte de système de pia tu pia (âne ou kazy) mais pour les citations. Si le serveur trouve les données demandées auprès de plusieurs clients, il distribue le téléchargement des différentes parties de l'historique demandé auprès de différents clients, de manière à ne pas en télécharger une seule. Les parties de l'historique fréquemment demandées peuvent être stockées dans le cache du serveur.
 
Mais qu'en est-il, premièrement, du stockage de l'histoire, et deuxièmement, de la qualité de l'histoire, car il serait alors difficile d'identifier les parasites. Il ne s'agit pas de fichiers très répandus et même ceux qui se trouvent dans un réseau P2P ne sont pas à l'abri d'informations de hashcode peu fiables. Il est possible de stocker l'historique sur le client en tant que sauvegarde, si le serveur lui-même tombe en panne. Combien de clients devraient être connectés pour collecter toutes les données ensemble ? De plus, beaucoup d'entre eux sont sous haute sécurité et tout le monde n'a pas d'adresse IP dédiée, nous ne sommes pas dans une zone locale. De nombreuses personnes n'accepteront tout simplement pas un tel empoisonnement du trafic. On peut aussi envisager plusieurs serveurs, mais dans tous les cas, les serveurs doivent avoir une délégation de données.
 
De nombreux commerçants disposent de l'ADSL ou d'un autre moyen de se connecter à l'internet de manière rapide et permanente. J'ai une connexion ADSL, si c'est pour un changement d'IP dynamique, c'est prévu. En général, au début, il peut y avoir un client toi moi et peut-être un autre enthousiaste tous en train de télécharger, mais s'il télécharge, il doit aussi fournir des données aux autres - cela se fait automatiquement. Je pense qu'il devrait y avoir beaucoup de clients comme vous au fil du temps. C'est une sorte de projet OpenQuotes :)
Oui, il peut y avoir du sabotage si de mauvaises données sont données. Cela pourrait être résolu en comparant les données d'au moins deux clients différents, également de manière programmatique. Mais en général, je pense aussi que le serveur sera plus sûr. Vous pouvez mettre un ordinateur portable comme serveur - il ne fait pas beaucoup de bruit et est relativement bon marché. Mais il faut alors se décharger sur elle et stipuler qui elle supportera :) Bien qu'il se peut que quelqu'un fasse don de son ordinateur. Mais il est alors souhaitable d'avoir au moins deux serveurs à des personnes différentes et un serveur avec des lits de camp peut alors disparaître.
Peut-être que MQ fournira un serveur, vu que le projet est populaire ;).
Les représentants de MQ diront - pourquoi avez-vous besoin de l'historique des sociétés de courtage si nous avons nos cotations duveteuses dans le centre d'historique, allez-y et utilisez-les et développez des EA robustes afin qu'ils ne soient pas sensibles aux cotations. C'est correct, mais comment vérifier rapidement que l'EA fonctionne également de manière acceptable sur les données d'autres sociétés de courtage - il est souhaitable d'avoir un historique important avec ces sociétés, par exemple pendant un an. Si vous ne savez pas comment utiliser cette méthode, nous pouvons essayer de vérifier la différence entre le temps que vous voyez et le temps que vous manquez.
 

J'ai un canal dédié de 100 mégabits vers Internet, le trafic est seulement limité, le contournement sortant, pour des expériences suffisantes :) Dans ce cas, vous pouvez acheter un serveur à part entière, et non un seul, et le mettre sur le site, si l'idée fonctionne :) Comme le dit le dicton, si ce n'est que pour le plaisir, tout le reste n'est pas important :) Les investisseurs seront trouvés par eux-mêmes, pour cette entreprise, si les résultats et le sens :)) Je travaille avec les tiques pour une raison, comme on dit, il faut penser globalement, et tout aura un sens :) Pour les minutes, je ne vois pas le sens :) Le tick est un temps et un prix précis, enfin, plus le temps du client, et la barre est quelques valeurs entre les deux qui peuvent être n'importe quoi, je ne peux même pas imaginer comment combiner et comparer les barres, c'est un non-sens, car des erreurs se produiront à chaque étape. Si vous pouvez comparer les ticks puis les barres, c'est comme comparer un éléphant avec une souris, surtout entre les centres de trading.

De quel serveur de citations metaquote s'agit-il ? Si c'est un serveur de démonstration, il filtre aussi les citations sur des broutilles, je ne sais pas pour les autres :) Bien que j'ai comparé une variété de serveurs, quelque chose est filtré partout, ou je ne comprends pas que ce ne sont pas des filtres, mais c'est juste des informations qui n'ont pas eu le temps de passer, mais la question est où il n'y a pas de temps si la différence entre les ticks par seconde et moins, mais encore plus aussi, les filtres sont clairement définis par leurs caractéristiques.

 

Je pense que je vais écrire un programme qui vole les tiques aussi - ça ne prendra pas longtemps. Nous échangerons les tiques s'il y a des problèmes. Je pense que le serveur de devis est une tâche pénible et qui prend du temps. Mais si vous le faites, je vais connecter mon client à votre serveur.

 
elritmo:
Piligrimm:
elritmo:
Piligrimm, dites-moi, comment pouvez-vous utiliser mt pour tracer une clôture d'une paire de devises sur le graphique d'une autre paire de devises ?

Avec la fonction iClose, créez un fichier avec tous les instruments dont vous avez besoin, puis obtenez un ratio de moyenne pour chaque instrument, par exemple en additionnant les 100 dernières barres pour chaque instrument et en divisant par 100. Après cela, toutes les données, pour chaque instrument, sont divisées par son coefficient, ce qui permet d'obtenir des valeurs de tous les instruments fluctuant autour de un (d'ailleurs, il est pratique pour le traitement ultérieur en utilisant des réseaux neuronaux, toutes les données sont normalisées), après quoi vous multipliez les valeurs de l'instrument, que vous voulez afficher sur un autre graphique par le coefficient, qui a été obtenu pour l'instrument sur le graphique que vous allez afficher.

OK, je comprends comment vous prenez les clones des paires sélectionnées via iClose, puis vous écrivez ces valeurs dans un fichier (je me demande quel type de fichier et quel format ?).
Ensuite, je suppose que vous ouvrez ce fichier dans MT4 et qu'il dessine toutes les valeurs sous la forme de lignes reliant les clôtures des différents instruments. Au moins dans votre capture d'écran, où sont tracées les lignes reliant les cloisons GBPUSD, AUDUSD et EURUSD, sans parler des lignes de tendance tracées selon un quelconque algorithme. Je me demandais juste comment vous pouviez dessiner les trois paires sous la forme de lignes de couleurs différentes, reliant les proches.
La ligne de fermeture par instrument dans la fenêtre de laquelle est dessinée est dessinée en vert dans MT. Dans le fichier joint se trouve un exemple, je n'ai pas pu le charger sous forme de code dans la fenêtre. Le fichier lui-même est destiné à d'autres tâches, il a donc quelques particularités, de plus je ne connais pas MQL et j'écris très mal dedans.

Mes données sont chargées sur la barre formée, respectivement les graphiques superposés devraient être décalés d'une barre. (Si quelqu'un a téléchargé dans l'heure qui suit la mise en place du programme, merci de corriger :
ExtMapBuffer1[155-iw+ip] vers ExtMapBuffer1[156-iw+ip], et d'autres tampons de manière similaire).
Dossiers :
multim_1.mq4  11 kb
 
D'ailleurs, je n'ai pas réussi à faire du multidevise, parce que des facteurs secondaires se sont mis en travers du chemin, et comme je fais tout en cours d'exécution, assez rapidement, alors je ne fais que corriger les bugs, donc le serveur n'est pas un travail si long à écrire. Souvent, je fais le travail principal en quelques heures ou disons en une journée, et ensuite je n'y pense plus, parce qu'avant de continuer à faire quelque chose de plus loin, il faut une signification, qui parfois n'existe tout simplement pas. Cela s'appelle l'idéalisme ou le maximalisme, ce qui est presque la même chose :) Si les données sont ma première préoccupation, j'oublie parfois le graphique de sortie, parce que tout se fait progressivement, étape par étape, seulement en cas de besoin, tel ou tel choix. Peut-être que si j'avais d'abord écrit et ensuite pensé, il y aurait déjà un multidevise et un graphique avec des indicateurs numériques, mais comment précis et correct il serait pour la visualisation, je ne peux pas prétendre, si les données sont filtrées :) La filtration est identifiée, tant que ce problème n'est pas résolu, un autre problème n'apparaîtra pas en face de la vue :)

Comme le souligne à juste titre Pilgrim, l'exactitude des données brutes n'est pas sans importance :) A propos de la synchronisation des ticks, tout est résolu dans ce domaine, car le marché réagit de manière séquentielle aux événements, et donc nous réagissons aux ticks de manière séquentielle, chaque tick a une valeur, mais sans les données des autres ticks par paires, ses données ne sont pas exactement reflétées dans la même représentation graphique, les influences - les mouvements, les chevauchements, tout cela fait de la qualité, sans tous les ticks nous sommes en fait aveugles ou pas si sûrs de l'influence exacte qui se produit. Alors que nous n'obtenons pas le temps avec une précision supérieure à la seconde, ceci est compensé par le temps d'absorption du client, plus il y a de clients, plus le timing peut être précis à la nanoseconde près, c'est toute la précision de la synchronisation des tics :) Dix millions de ticks en une seconde ne passeront pas, c'est suffisant dans la structure numérique temporelle à huit octets, d'où leur ordre consécutif. La différence de tick dans notre cas est la condition principale, si un tick n'a pas de différence de prix par rapport au tick précédent, c'est la première chose à laquelle il faut prêter attention, car par définition ce n'est pas un changement de prix, mais en termes simples, une erreur du serveur ou du client.
 
Piligrimm:
La ligne de fermeture de l'outil dans la fenêtre est dessinée en vert dans MT. Les autres sont appliquées après le redimensionnement, il y a un exemple dans le fichier joint, je n'ai pas réussi à le charger comme un code dans la fenêtre. Le fichier lui-même est destiné à d'autres tâches, il a donc quelques particularités, de plus je ne connais pas MQL et l'écrire dedans est très désordonné.
Eh bien maintenant je comprends - c'est la fenêtre de l'indicateur où vous dessinez tout dans le code de l'indicateur.
 
Je pense que vous êtes idiots.

1. Les courtiers ne vous laisseront pas construire un système sur les ticks, ils ont de nombreux moyens de s'en défendre.
2. Les tiques sont contingentes et aléatoires. Ils sont différents pour chacun par définition et il n'y a pas de système.
3. Pour la tique, comme en mécanique quantique, il y a un effet du principe d'incertitude - le processus de mesure affecte le résultat. Pendant que vous êtes observateur (sur la démo), vous n'affectez pas le flux des ticks. Lorsque vous commencez à travailler sur le réel (mesurer - faire des demandes de cotation), vous allez vous-même créer un flux de ticks, qui dépendra des conditions du marché, de l'humeur de votre courtier, des résultats de votre travail ...

En outre, j'ai peut-être manqué beaucoup de choses, je n'ai pas lu tout le fil, mais pourquoi avez-vous besoin de 128 octets par tic ?
À mon avis, deux suffisent pour les yeux. Utilisons le codage delta - le premier octet donne l'incrément de temps (par exemple, en secondes), le second donne l'incrément de prix en pips. Le prix ne variera guère de plus d'un chiffre au cours d'un tick, et il est peu probable qu'il y ait plus de 4 minutes entre deux ticks consécutifs. La série résultante sera principalement constituée de valeurs proches de zéro, et sera bien compressée par n'importe quel algorithme de compression. De plus, il n'y a pas tant de tics dans une journée. Par exemple, l'EURUSD sur Alpari a maintenant environ 5000 ticks par jour.
Raison: