Besoin d'aide ! Je ne peux pas résoudre le problème, je me heurte à des limitations matérielles. - page 17
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
Oui, sous cette forme, la tâche est parallèle - chaque fois que le SeekDate change, vous pouvez exécuter une recherche simultanée du meilleur critère sur différentes parties de l'ensemble de séquences. Par exemple, nous les divisons en 20 parties et confions la tâche à 20 conseillers experts. Et ils doivent lire le dossier, trouver l'accord, et ne renvoyer que la meilleure séquence (№№, Critère et position du dossier).
Merci beaucoup à tous !
Si nous exécutons cet algorithme sur plusieurs EA, nous sommes limités par la vitesse de lecture du disque + par parties + à partir de différentes positions, et la vitesse risque d'être insuffisante.
Vous pouvez tout calculer en une seule lecture de données - si vous le souhaitez, l'essentiel est d'en avoir envie.
La lecture du disque est une opération assez coûteuse - l'exécution de cet algorithme sur plusieurs conseillers experts sera limitée par la vitesse de lecture du disque + par parties + à partir de différentes positions et il est peu probable que la vitesse soit atteinte.
Qui a dit que lescalculs distribués devaient être effectués sur un seul poste de travail ? Il n'y a pas de telles restrictions ;)) Le disque RAM est également d'une grande aide, comme il a été dit plus haut.
Pourquoi ne pas réfléchir un peu et changer l'algorithme ?
1. comment télécharger plusieurs séquences en une seule fois et comment savoir où elles commencent et où elles se terminent
2. comment calculer les coefficients pour toutes les affaires dans une séquence et dans quelle structure de données stocker la réponse.
3. comment faire une fusion de deux réponses d'un point précédent en une nouvelle réponse un peu plus complète.
4. comment diviser la réponse finale du point 3 dans les intervalles requis (nous parlons dela SeekingDate = Heure de fermeture du commerce + 1).
Nous pouvons obtenir un algorithme légèrement différent permettant de choisir en combien de parties supplémentaires diviser l'intervalleSeekingDate.
nous pouvons obtenir des erreurs différentes par rapport à l'algorithme de l'auteur initial.
La capacité en chiffres d'un numéro est déterminée par l'unicité du code d'entrée, et non par la capacité en chiffres du système. De toute évidence, il devrait être un multiple de 1 octet.
64 bits me semble être trop. :)
S'il y a 1 000 000 d'enregistrements, 16 bits ne suffiraient pas pour un code d'enregistrement unique (maximum 65536 enregistrements). C'en est une.
Regardez l'architecture des processeurs 32 bits et 64 bits d'Intel (Itanium), d'AMD (je n'ai pas dit système d'exploitation). 32/64 est la résolution du bus d'adresse, mais en même temps 32/64 bits (4/8 octets) sont lus de la mémoire en un cycle machine, même en accédant à un octet de mémoire.
Par conséquent, le fait de lire 2 ou 8 octets de mémoire ne fait absolument aucune différence en termes de performances.
En principe, vous pourriez écrire un service Windows pour ce type de traitement des fichiers.
Mais je suis toujours enclin à utiliser le SGBD.
Pourquoi ne pas réfléchir un peu et changer l'algorithme ?
1. comment télécharger plusieurs séquences en une seule fois et comment savoir où elles commencent et où elles se terminent
2. comment calculer les coefficients pour toutes les affaires dans une séquence et dans quelle structure de données stocker la réponse.
3. comment fusionner deux réponses du point précédent en une nouvelle réponse un peu plus complète.
4. comment diviser la réponse finale du point 3 dans les intervalles requis (nous parlons dela SeekingDate = Heure de fermeture du commerce + 1).
Nous pouvons obtenir un algorithme légèrement différent permettant de choisir en combien de parties supplémentaires diviser l'intervalleSeekingDate.
nous pouvons obtenir des erreurs différentes par rapport à l'algorithme de l'auteur initial.
Pour les 4 points, le traitement des données du côté du SGBD.
En ce qui concerne l'algorithme "légèrement différent", ce que vous voulez dire n'est pas très clair. Mais. Pour calculer l'erreur de cet algorithme "légèrement différent" par rapport à celui de "l'auteur", il faut que les deux algorithmes soient mis en œuvre. Et ce fil de discussion a été créé précisément en raison du problème technique que pose la mise en œuvre de l'algorithme de l'"auteur".
Compte tenu de ce fait, quelle méthodologie allez-vous utiliser pour calculer l'erreur dont vous parlez ?
vous pouvez tout calculer en une seule lecture - l'essentiel est le désir.
La lecture du disque est une opération assez coûteuse - l'exécution de cet algorithme sur plusieurs conseillers experts sera limitée par la vitesse de lecture du disque + par parties + à partir de différentes positions et il est peu probable que cette idée donne une quelconque vitesse.
Disons que le disque dur est le périphérique le plus lent, c'est un fait. Toutefois, il ne s'agit pas d'exécuter plusieurs EA en utilisant tous ces calculs. À mon avis, l'application la plus probable est la génération de signaux. Disons un serveur cloud sur amazon avec les performances nécessaires + MT4 + ce développement = fournisseur de signaux.
Pour les 4 points, le traitement des données se fait du côté du SGBD.
En ce qui concerne l'algorithme "légèrement différent", je ne suis pas sûr de ce que vous voulez dire. Mais. Pour calculer d'une manière ou d'une autre l'erreur de cet algorithme "légèrement différent" par rapport à l'algorithme "de l'auteur", les deux algorithmes doivent être mis en œuvre. Et ce fil de discussion a été créé précisément en raison du problème technique que pose la mise en œuvre de l'algorithme de l'"auteur".
Compte tenu de ce fait, quelle méthodologie allez-vous utiliser pour calculer l'erreur dont vous parlez ?
Si je comprends bien la méthodologie de l'auteur, l'intervalle sera écrêté par un coefficient maximal choisi dans l'intervalle donné. Je suggère de diviser chaque intervalle en N sous-ensembles, où, à la convergence, une seule valeur du coefficient peut convenir. Ainsi, à N = 5, la gamme peut être divisée en proportions de 0,2 0,4 0,6 0,8 1. Et toute valeur comprise entre 0 et 1 est coupée dans la fourchette de l'auteur. Ainsi, une erreur de gamme de 0,2 est le maximum pour N = 5.
Et tout autour de la façon dont les messages de l'auteur ont été correctement interprétés, car il n'y a toujours pas de clarté complète.
D'après ce que j'ai compris de la version de l'auteur (au cas où quelque chose serait à nouveau erroné, car il n'y a pas d'explication claire et complète de ce qui est exactement nécessaire), l'intervalle sera coupé par le coefficient maximal sélectionné dans cet intervalle ; dans la version que j'ai suggérée, chacun de ces intervalles devrait être divisé en N sous-espaces où une seule valeur de coefficient peut s'insérer dans la fusion. Ainsi, à N = 5, la gamme peut être divisée en proportions de 0,2 0,4 0,6 0,8 1. Et toute valeur comprise entre 0 et 1 est coupée dans la fourchette de l'auteur. Ainsi, une erreur de gamme de 0,2 est le maximum pour N = 5.
Et tout autour de la façon dont les messages de l'auteur ont été correctement interprétés, car il n'y a toujours pas de clarté complète.
Oui, apparemment le projet a été commandé par le Ministère des Finances, il n'y a pas assez d'informations spécifiques. Cependant, chacun peut trouver quelque chose d'intéressant pour lui-même dans la discussion. Je vois cela comme un aspect positif de la discussion.
Concernant la discrétisation des plages, votre idée est claire. Et si N=100, 1000... (c'est possible d'un point de vue purement mathématique), ce fractionnement entraînera des répercussions en termes de performances et d'utilisation des ressources du système. Il y a aussi la physique en plus des mathématiques)
Nous disposons d'un fragment de fichier dans notre mémoire, nous le parcourons et formons un échantillon de la longueur nécessaire pour calculer le critère, en ne sélectionnant que les accords qui appartiennent à la même séquence. Ensuite, nous calculons le critère sur cet échantillon. À propos, il est possible d'utiliser la récursion dans la sélection.
Il vous faudrait donc passer par plusieurs millions de transactions d'autres séquences ! C'est exactement ce que je veux dire.
Le problème de l'insertion de nouvelles données - résolvez-le d'une manière ou d'une autre.
Aucun problème jusqu'à présent, les données sont d'un montant fixe.
À propos, si vous connaissez le point de départ de chaque séquence, vous pouvez rechercher les bonnes dates à l'aide d'une recherche binaire, puisque les transactions sont classées par ordre chronologique.
+1, merci pour l'idée.
1. sur la base de ce qui précède"Soit le critère est le profit moyen des 20 dernières transactions de la séquence."Il faut entendre par là un seul critère, celui de l'espérance mobile de profit. Quels sont les autres ?
Dans la base de données, générez une table avec l'identifiant de la séquence et les moyennes mobiles correspondantes. Les séquences qui ne répondent pas aux conditions doivent être supprimées immédiatement. Cette opération doit être effectuée par une procédure en mode simultané au niveau du SGBD, à la demande du robot, l'état du processus étant affiché dans le robot.
Disons, FilterAvgProfit (pProfitValue, pTrades, pDeviation),
où pProfitValue est le bénéfice cible, pTrades est le nombre de transactions pour le bénéfice de la moyenne mobile, pDeviation est l'écart autorisé par rapport à pProfitValue.
Le résultat est un tableau rempli d'identifiants de séquences et de valeurs de bénéfices moyens.
1а. Quels sont les autres critères - cela n'a pas d'importance. L'important est que le calcul soit effectué par une série de transactions de la durée spécifiée.
1б. Comment pouvez-vous écarter une séquence simplement parce qu'elle a une mauvaise valeur de critère au moment de la fermeture du commerce N ? Et si elle devient meilleure plus tard ?
Vous ne pouvez supprimer que les séquences qui ont complètement échoué et dont le critère n'a pas montré de profit. Et il ne devrait pas y en avoir beaucoup.
4. À mon avis, si l'on s'intéresse à la sélection de la stratégie, cette opération ne devrait pas être effectuée trop souvent (disons, sur chaque barre ou immédiatement avant l'ouverture de l'ordre). Cette approche est raisonnable si la stratégie actuelle présente N trades perdants d'affilée - alors nous pouvons en choisir une autre et il faudra du temps pour "prendre une décision", il n'y a rien à éviter. Ou bien, effectuer cette sélection une fois par semaine (le week-end, lorsque le marché est fermé), et, ou bien confirmer la stratégie actuellement choisie, ou passer à une autre. Il est possible de dresser une liste des stratégies optimales recommandées pour un trader, dans des conditions données. Ensuite, à l'ouverture du marché et à tête reposée (le lundi), le trader confirmera son choix (ou plus tôt, avant l'ouverture du marché... alerte par e-mail, etc.)
Eh bien, c'est une question d'idéologie. Pas sur lui maintenant ;)
Vous allouez de la mémoire à un tableau de structures et obtenez :
Pourquoi avez-vous besoin d'un tableau de valeurs de critères et d'un tableau de positions de pointeurs de fichiers ? (un Criterion et la dernière transaction n'avez-vous pas pensé à les stocker ?)
Tableau de valeurs des critères - pouvoir trier et sélectionner quelques meilleures séquences (pour l'avenir).
Positions de l'index du fichier - pour continuer à chercher dans chaque séquence à partir du bon endroit (comment faire autrement ?).
Est-ce que j'ai bien compris :
Premier passage - recherche sur l'intervalle de 0 à SeekDate
puis trouver le meilleur critère etFindDate = heure de clôture de la transaction + 1
rechercher maintenant l'intervalle entre"l'heure de clôture de la transaction" et laSeekingDate ?
et vous devez faire rentrer dans cet intervalle X opérations pour calculer le critère pour chaque séquence ?
1. Oui, de 0 à la première SeekingDate
2. Non. La SeekedDate est décalée, et nous traitons la séquence (ajoutons des transactions au tableau) sur l'intervalle "PreviousTreatedTrade - SeekDate".
Ce sont des résultats étranges.
Voici une image de notre système de serveur en fonctionnement sous charge :
Sans les cadres de disques, il faut beaucoup plus de temps pour assembler les projets.
Je commence à avoir des complexes.
Il faudra probablement créer un script de test et joindre un fichier pour que vous puissiez le vérifier sur une tâche similaire.
J'ai un disque dur normal - wdc wd1002FAEX-00Y9A0, à en juger par les spécifications, la vitesse maximale est de 126 Mo/s :
D'après la critique, c'est à peu près tout ce qu'on peut en tirer. Peut-être que je fais quelque chose de mal ?
Jetons un coup d'oeil au script...
C'est de cela que je parle : il faut lire les gros fichiers par gros morceaux, sinon les petits fichiers peuvent prendre jusqu'à 10 fois plus de temps, voire plus.
Comment lire un gros morceau ?
À mon avis, la solution au problème réside dans le codage des données brutes.
Comment coder l'ensemble des informations de la transaction sans perdre d'informations ?
Résultats étranges.
Voici une image de notre système de serveur de production sous charge :
Sans disques RAM, il faut plusieurs fois plus de temps pour construire des projets.
J'ai oublié d'écrire sur la mémoire.
DDR3, 1333 MHz :
Softperfect RAM Disk 3.4.5, bien que j'ai fait NTFS (une différence ?)
Autre détail : le disque RAM est de 12000 Mo, et il n'y a que 1-2 Go de mémoire libre (pour le travail).