Besoin d'aide ! Je ne peux pas résoudre le problème, je me heurte à des limitations matérielles. - page 14
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
...
Il existe de nombreuses séquences de transactions similaires et chaque séquence est classée par ordre chronologique.
Une séquence peut-elle tenir dans la mémoire ?
Vous pouvez écrire un conseiller expert. Au départ, l'Expert Advisor charge la séquence # (paramètre dans la fenêtre des propriétés) et trade sur cette séquence. Optimiser №.
La tâche n'est pas tout à fait claire, alors que beaucoup de choses différentes peuvent être mises en œuvre.
Une séquence peut-elle tenir dans la mémoire ?
Vous pouvez écrire un conseiller expert. Le conseiller expert charge la séquence n° au démarrage (paramètre dans la fenêtre des propriétés) et effectue des transactions sur cette séquence. Optimiser №.
La tâche n'est pas tout à fait claire, alors que l'on peut phanatiser beaucoup de choses différentes.
Si nous avons 20 Go (21 474 836 480 octets), avec 1 million de séquences, nous obtenons environ 21 475 octets en moyenne par séquence (~21Kb). Je pense que ça devrait tenir dans la mémoire, même dans le téléphone ;))
О. Au fait, qu'en est-il de l'informatique distribuée ? Nous devrions aussi réfléchir dans cette direction...
Désolé encore pour la pause, j'ai fait des expériences avec le lecteur de RAM (pas très réussies jusqu'à présent). Je réponds à tout le monde dans l'ordre.
Mais les séquences sont indépendantes les unes des autres, non ? Alors pourquoi ne puis-je pas parcourir en boucle les dates d'une séquence à chargement unique en une seule fois ? D'ailleurs, c'est peut-être l'occasion de passer à un algorithme de récurrence efficace, mais c'est le hasard qui veut ça. La taille d'un million sur un million sera conservée, et le fichier sera lu une fois.
Bien sûr, un problème où le nombre d'étapes à l'itération suivante reste le même (c'est-à-dire que la zone de recherche calculée ne devient pas plus étroite) ne semble pas robuste. Mais bien sûr, c'est subjectif.
Indépendant. Et comment entrer dans une boucle sur toutes les séquences à la fois, sans les charger en mémoire ?
Le nombre d'étapes peut être réduit, si vous savez comment lire les séquences à partir du bon endroit (les X dernières transactions à partir de la date analysée actuelle).
La base entière est-elle adaptée aux lignes de 10 ans ou non ? Tous les fichiers sont cumulatifs.
Un fichier par million de séquences (j'écris chacune d'elles en 9 lignes pour plus de commodité).
Bien, ou un million de fichiers, peu importe.
Ai-je bien compris ce qui suit :
1) Un fichier de 20 Go est constitué d'environ un million de séquences classées par ordre chronologique.
2) La taille de chaque séquence peut varier et dépend du nombre de transactions que la séquence contient.
3) La taille moyenne d'une séquence est de 20/10^6 = 20 Mb, donc que pouvons-nous garantir pour télécharger complètement une séquence ?
4) Le coefficient K ne dépend que des échanges au sein de la séquence donnée
5) Pour chaque séquence, nous devons trouver K (soit un total de 10^6 pièces) et sélectionner les 10 premières.
Jusqu'à ce que je dispose de tels volumes, je me contentais de tout télécharger en mémoire et de le faire tourner en boucle, en comptant tout ce dont j'avais besoin.
La meilleure séquence doit être sélectionnée à chaque moment de l'histoire (la meilleure - séquence avec le meilleur critère au moment actuel, le critère est calculé en utilisant la dernière transaction clôturée.
A si nous créons un autre fichier avec les valeurs des distances entre les séquences.
Je n'ai pas compris ça et le suivant.
Au fait, oui, vous pouvez charger des lots de séquences en une seule fois.
Ça ne sauvera pas, vous avez besoin de tous.
Je ne le comprends pas quelque part.
Voici le critère - tout - dans l'intervalle de Date1 à Date2.
C'est-à-dire qu'il se lit comme suit .
Pourquoi ne pas diviser le fichier en plusieurs intervalles de la date 1 à la date 2 ? Il y aura des séquences travaillées qui pourront être fermées, non ?
L'intervalle "Date1 - Date2" couvre actuellement toutes les transactions de toutes les séquences.
Et l'idée de le diviser en plusieurs petits est tout à fait judicieuse. C'est vrai, mais il faudrait alors lire les informations sur le disque à chaque fois que les paramètres sont modifiés... Mais c'est déjà ça.
Apparemment, l'un des résultats du passage d'une date unique est une nouvelle date.
Oui, mais je pense que vous pouvez trouver un point où aucun accord n'aura l'une des séquences et faire une pause.
Puis il y aurait une transition vers l'intervalle suivant. Je vais essayer.
si le problème est le suivant :
donné une rangée 1 2 3 4 5 6 7 8 9
La largeur est donnée, par exemple 4, vous devez vous déplacer avec cette largeur le long de la ligne entière pour trouver une valeur à l'intérieur de la largeur (par exemple le minimum) :
il faut d'abord trouver en 1 2 3 4 puis 2 3 4 5 puis 3 4 5 6 puis 4 5 6 7 puis .... etc.
Si X (nombre de transactions) était fixe (4 dans votre exemple) et qu'il n'y avait pas d'autres paramètres - oui. Et donc - non.
Je réfléchirais à cette tâche
Les conditions sont indiquées ci-dessus, bienvenue dans nos rangs ;)
Puisque le problème est plutôt académique (comme une question pour embaucher un programmeur) et que de nombreuses personnes ont montré de l'intérêt pour celui-ci, pourquoi ne pas le formuler plus strictement en termes de format de description des données d'entrée, et tout le monde pourrait générer 20 Gigs de données de test et soumettre leur solution pratique ?
Pas de problème.
Générer des séquences de trades aléatoires (par ordre chronologique, même sur 1 an) avec tous leurs attributs : date et heure d'ouverture, prix d'ouverture, SL, TP, date et heure de clôture, prix de clôture. Numérotez les séquences de 1 à un million.
La tâche consiste à créer une nouvelle série de transactions consécutives à partir de toutes les transactions de toutes les séquences (ne se chevauchant pas dans le temps), et sélectionnées selon un certain critère.
Le critère est le profit moyen des 20 dernières transactions de la séquence.
Exemple de résultat :
Je suppose donc que nous parlons d'un testeur/optimiseur fait maison ?
Oui, quelque chose comme ça.
nah, il y a quelque chose de différent là.
Je suppose qu'un courtier/prestataire a la base de données des affaires. :)
Si seulement =)
Je vais répéter la tâche en termes plus simples.
Non, ça ne l'est pas. J'ai donné un exemple concret, il peut être considéré comme aussi proche du vrai problème que possible.
Typique de la base de données. Mais il n'y a aucun moyen de le faire sans agrégation de données. Vous pouvez écrire dans un tableau séparé les attributs uniques d'une séquence (c-dates), la valeur moyenne du profit K et de la variance D, puis rechercher les 10 meilleures séquences qui sont proches des critères dont vous avez besoin. Avec des index sur ces champs, la recherche ne sera pas si longue (même dans un million d'enregistrements). Ensuite, lorsque vous aurez trouvé les dix bonnes séquences, vous pourrez fouiller dans les données brutes, mais il n'y aura plus un million de recherches, car nous avons une date limite.
Si le Criterion était statique...
Et si ses paramètres changent ?
C'est encore un mystère - que devrions-nous rechercher ? Quel devrait être le résultat de toutes les opérations ? Si nous parlons de prendre une décision en termes d'ouverture/fermeture d'une commande, tout traitement d'un tel volume prendra un temps assez important.
Oui, alors il y aura un échange. Mais le recalcul ne sera nécessaire que pour les données les plus récentes, nous n'avons pas besoin de recalculer l'ensemble de l'historique.
Il y a un autre point. Puisque nous parlons d'affaires, peut-être y a-t-il lieu de séparer les affaires pour chaque symbole ? Et d'écrire des robots de trading similaires conçus pour l'EURUSD, l'USDJPY, etc.
C'est un instrument...
Il me semble que de cette façon, vous pouvez seulement identifier la stratégie qui a été utilisée pour trader (ou l'ensemble des paramètres du robot) d'une certaine séquence et passer à celle-ci dans une certaine situation de marché.
Exactement.
Une séquence peut-elle tenir dans la mémoire ?
Vous pouvez écrire un conseiller expert. Au départ, l'Expert Advisor charge la séquence n° (paramètre dans la fenêtre des propriétés) et trade sur cette séquence. Optimiser le nombre.
Il le fera.
Mais nous n'avons pas besoin d'un résultat unique (final), mais à chaque instant.
Fondamentalement, nous pourrions utiliser le nuage en donnant le numéro de séquence et la date, jusqu'à laquelle lire, comme un paramètre. Mais c'est à peine plus rapide que le recalcul d'un fichier).
О. Au fait, qu'en est-il de l'informatique distribuée ? Nous devrions aussi réfléchir dans cette direction...
Que devons-nous calculer en parallèle ? Valeur du critère pour différentes séquences ?
Mais pour cela, nous devons les charger en mémoire. Et il importe peu qu'ils soient chargés à partir d'un seul processus (Expert Advisor, terminal) ou de plusieurs processus. Peut-être aurons-nous 8 (ou 12, 16, 20) Go au lieu de 4 Go. Mais il faut ensuite "coller" le résultat.
Que devons-nous considérer comme parallèle ? Quelle est la signification du critère pour les différentes séquences ?
L'idée est de diviser toutes les histoires en 100 groupes, par exemple, et de calculer l'ensemble optimal séparément pour chaque groupe.
Ensuite, pour chaque groupe, nous ne laisserons que les histoires qui se trouvent dans l'ensemble optimal du groupe et nous passerons à l'étape suivante avec un plus petit nombre d'histoires. Alors, théoriquement, il est parallèle 100 fois.
Et de mémoire tout va bien, la taille du groupe peut être ajustée
L'idée est de diviser toutes les histoires en 100 groupes, par exemple, et de calculer l'ensemble optimal séparément pour chaque groupe.
Ensuite, pour chaque groupe, ne laissez que les histoires du groupe optimal et passez à l'étape suivante, avec moins d'histoires. Alors, théoriquement, il est parallèle 100 fois.
Et de mémoire tout va bien, la taille du groupe peut être ajustée
Si vous chargez 100 pièces sur 100 en parallèle, il n'y a pas assez de mémoire =)
Et si vous chargez de manière séquentielle (en mémorisant à chaque fois une meilleure variante), où est le parallélisme ? Et le fichier sera toujours lu à chaque fois que vous vous rendrez sur la machine.
Je pense qu'il est possible d'inventer un mécanisme de chargement partiel astucieux, mais il faut l'inventer.
Par exemple, lors de la première lecture, trouvez pour chaque passe la dernière transaction clôturée avant la date de début, revenez en arrière et lisez X transactions précédentes, retenez le point du fichier où cette transaction se termine.
Après cela, trouvez la première transaction dans les résultats, puis travaillez uniquement avec des données fraîches : lisez le fichier depuis le point souhaité jusqu'à la nouvelle date réelle, et à chaque fois déplacez les transactions dans le tableau (obtenez un tableau de taille fixe - X éléments).
Cela résoudra le problème de la lecture multiple (elle n'est tout simplement pas nécessaire), et de la mémoire (seulement si nous pouvons accueillir X millions de transactions).
Je vais aller dans cette direction.
Le passage à des fichiers binaires, d'ailleurs, n'a pratiquement rien donné en termes de taille.
Le format de texte que j'ai optimisé était très compact : la date était mémorisée une fois (ouverture de la première transaction), et toutes les autres (ouverture et clôture) étaient mémorisées en décalage par rapport à la date précédente ; SL, TP et PriceClose étaient également mémorisés en décalage par rapport au prix d'ouverture.
Lorsque je suis passé au format binaire, cette optimisation n'avait aucun sens - le décalage en secondes (uint) prend autant de place que la date complète (je refuse le long-a, 2030 ans me suffisent), mais le ushort n'est pas suffisant (seulement 18 heures de décalage maximum). De même avec les prix - je pourrais déplacer le décalage vers ushort, mais je devrais alors ajouter des vérifications pour le débordement (si, par exemple, SL = 0), et le gain ne serait que de 6 octets sur les 3 prix. J'ai décidé de ne pas le faire.
Mais j'ai supprimé un peu d'informations inutiles, donc j'en ai 20 %. Taille prévue du fichier original (qui était de 20 Go) - 7-8 Go, quelques heures suffiront pour le convertir.
J'ai également gagné du temps CPU, qui a été utilisé pour convertir les lignes.