![MQL5 - Langage des stratégies de trading intégré au terminal client MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
1. où se trouve le coefficient ?
2. et p.1 ?
3. Non, c'est plus simple que ça. Ok, j'essaierai de l'accélérer demain.
1. Coefficient (indice composite) dans chaque segment sera sur ses caractéristiques - expérimentalement puis je déterminer la formule, mais conventionnellement, nous pouvons supposer qu'il est.
2) Il s'agit donc de chaque segment séparément, un seul indicateur (sur les trois sur lesquels il est calculé) pouvant être distribué à tous, et les deux autres ne le pouvant pas.
3. Merci, je vais attendre.
Ici. Mais s'il y a 1 000 sections, ça ne sert à rien. Il y a trop de variantes, vous risquez même de ne pas avoir assez de mémoire.
Vous pouvez aussi procéder autrement : à la fin de chaque segment, liez un tableau avec des index pointant vers le segment suivant. De cette façon, vous pouvez passer par toutes les options sans remplir la mémoire. Mais il y aura toujours trop d'options... La recherche prendra beaucoup de temps. Vous pouvez également réfléchir à la manière de donner accès aux variantes par leur numéro, si vous en avez besoin (pour le plaisir).
Mais cela en vaut-il vraiment la peine, alors qu'il existe tant de variantes ? Pourquoi ne pas spécifier la tâche pour la rendre plus réaliste ?
Ici. Mais s'il y a 1 000 sections, ça ne sert à rien. Il y a trop de variantes, vous risquez même de ne pas avoir assez de mémoire.
Vous pouvez aussi procéder autrement : à la fin de chaque segment, liez un tableau avec des index pointant vers le segment suivant. De cette façon, vous pouvez passer par toutes les options sans remplir la mémoire. Mais il y aura toujours trop d'options... La recherche prendra beaucoup de temps. Vous pouvez également réfléchir à la manière de donner accès aux variantes par leur numéro, si vous en avez besoin (pour le plaisir).
Mais cela en vaut-il vraiment la peine, alors qu'il existe tant de variantes ? Pourquoi ne pas spécifier la tâche pour la rendre plus réaliste ?
Il peut y avoir beaucoup de cibles. Les plus petits manques, à partir des segments les plus longs, les plus courts, les plus identiques) même dans les graphes cibles moins de temps et le chemin minimum logiquement sont différemment résolus)
De quoi s'agit-il ?
Les tableaux, avec des pointeurs vers un segment voisin, représentent une quantité dérisoire de mémoire par rapport à un tableau contenant toutes les combinaisons possibles.
Ici. Mais s'il y a 1 000 sections, ça ne sert à rien. Il y a trop d'options, vous pourriez même ne pas avoir assez de mémoire.
Merci !
Mais je ne sais pas vraiment quel est l'intérêt de cette mise à jour - des corrections ont-elles été apportées au code ? La dernière fois, il a récupéré 613 combinaisons, cette fois-ci, il en a récupéré 1507.
La vitesse est devenue plus lente, mais c'est probablement dû au nombre de combinaisons.
Dernière variante :
Variante actuelle :
Nous pourrions procéder autrement : à la fin de chaque segment, nous pourrions attacher un tableau avec des indices pointant vers le segment suivant. Cela permet de passer par toutes les variantes sans remplir la mémoire. Mais il y aura toujours beaucoup de variantes... la recherche prendra beaucoup de temps. Vous pouvez également réfléchir à la manière de donner accès aux variantes par leur numéro, si vous en avez besoin (pour le plaisir).
Si j'ai bien compris, l'idée est de calculer ensuite la combinaison et de l'évaluer, puis de sauvegarder le résultat et de passer à la combinaison suivante. Si le nouveau résultat (ou le top 10) est meilleur que le précédent, nous le remplaçons dans la variable tableau. Et, oui, je voulais juste demander, comment obtenir la chaîne des index du premier niveau du tableau dont la combinaison est constituée ?
Mais cela a-t-il un sens s'il y a tant de variantes ? Pourquoi ne pas spécifier le problème pour le rendre plus réaliste ?
Pourquoi la variante avec un nombre limité de segments à partir du point actuel (étape de combinaison, lorsque n segments ont déjà été prélevés) ne convient-elle pas, car elle réduit considérablement le nombre de combinaisons ?
Merci !
Mais je n'ai pas bien compris l'intérêt de la mise à jour - des corrections ont-elles été apportées au code ? La dernière fois, il y avait 613 combinaisons, cette fois-ci, il y en a 1507.
La vitesse est devenue plus lente, mais c'est probablement dû au nombre de combinaisons.
Dernière variante :
Variante actuelle :
Si j'ai bien compris, il est proposé de calculer consécutivement une combinaison et de l'évaluer immédiatement, de sauvegarder le résultat de l'évaluation et de passer à la combinaison suivante. Si le nouveau résultat (ou le top 10) est meilleur que le précédent, nous le remplaçons dans la variable tableau. Et, oui, je voulais juste demander, comment obtenir une chaîne d'index de premier niveau du tableau dont la combinaison est constituée ?
Pourquoi n'est-il pas bon d'essayer un nombre limité de sections à partir du point actuel (étape de combinaison, quand on a déjà pris n sections), car cela permet de réduire considérablement le nombre de combinaisons ?
Pourquoi ne pas considérer la version originale du problème ?
Pourquoi ne pas examiner la version originale du problème ?
Sans les segments.
Pourquoi ne pas examiner la version originale du problème ?
Sans les segments.
Existe-t-il une telle variante ?
La variante originale consiste à diviser idéalement la série numérique sous forme de tableau en segments (plages). Les critères de scission sont les suivants :
1. Au moins 5 % des nombres se situent dans un intervalle - %R. 2 ;
2) Évaluez la réponse d'un segment à un autre tableau binaire de la même taille (s'il y a un nombre dans la plage - 1, sinon - 0). La réponse du segment doit différer de la valeur moyenne de l'ensemble du tableau binaire d'au moins 5% - dP% ;
3. sur 10 segments identiques par profondeur de réseau, calculer SCO dP%, qui ne doit pas être supérieur à 1,5 - K_SKO.
Maintenant, différentes méthodes définissent des plages, mais différentes méthodes sont capables de sélectionner différentes plages qui répondent aux critères ci-dessus. L'objectif est donc de prendre toutes les ventilations en segments provenant de différentes méthodes et de combiner les meilleures.
Merci !
Mais je n'ai pas bien compris l'intérêt de la mise à jour - des corrections ont-elles été apportées au code ? La dernière fois, il y avait 613 combinaisons, cette fois-ci, il y en a 1507.
La vitesse est devenue plus lente, mais c'est probablement dû au nombre de combinaisons.
Dernière variante :
Variante actuelle :
Si j'ai bien compris, il est proposé de calculer consécutivement une combinaison et de l'évaluer immédiatement, de sauvegarder le résultat de l'évaluation et de passer à la combinaison suivante. Si le nouveau résultat (ou le top 10) est meilleur que le précédent, nous le remplaçons dans le tableau/variable. Et, oui, je voulais juste demander, comment obtenir une chaîne d'index de premier niveau du tableau dont la combinaison est constituée ?
Pourquoi n'est-il pas bon d'essayer un nombre limité de sections à partir du point actuel (étape de la combinaison, lorsque vous avez déjà pris n sections), car cela permet de réduire considérablement le nombre de combinaisons ?
Et je ne sais pas où et dans quoi vous cherchez des combinaisons ? En général, à chaque démarrage, un nouvel ensemble de segments d'entrée est créé et il est toujours différent.
Une chaîne d'indices - vous devez donc créer des combinaisons non pas à partir des segments, mais à partir des indices des segments, ou vous pouvez ajouter un troisième élément dans la deuxième dimension et y stocker l'indice.
Je ne sais pas pourquoi un nombre limité ne convient pas, vous avez écrit sur toutes les combinaisons.
Je ne sais pas où et dans quelles combinaisons vous cherchez ?
Ci-dessus, Alexei Tarabanov a écrit en détail où et dans quoi lorsqu'il a répondu. Mais c'est de la théorie - je n'ai pas encore vraiment terminé ce dont j'ai besoin.
En général, chaque startup crée un nouvel ensemble de segments initiaux et ils sont toujours différents.
Ensuite, je vois - je ne m'en suis pas occupé et j'ai juste exécuté deux scripts - que si l'ensemble est différent, alors il ne sera possible d'évaluer que si les ensembles sont identiques.
Chaîne d'indices - nous devrions donc créer des combinaisons non pas à partir de segments, mais à partir d'indices de segments, ou bien ajouter un troisième élément à la deuxième dimension et y enregistrer l'indice.
Je pense que le troisième élément est une option plus pratique. Pourriez-vous modifier le code afin qu'il fonctionne correctement avec cette implémentation ?
Je ne sais pas pourquoi une sorte d'énumération d'un nombre limité n'est pas bonne, vous avez écrit sur toutes les combinaisons.
C'est vrai, à l'origine j'ai écrit sur toutes les combinaisons, mais dans le processus, grâce à vous, il devient clair que c'est très coûteux et vous avez besoin d'une option, empiriquement capable de ne pas être pire que la force brute. Et puisque l'évaluation du segment résultant est formé de ses chunks, je suppose, qu'en limitant n combinaisons des meilleurs chunks et en ajoutant un nouveau chunk, il sera possible d'approcher la meilleure option de toutes les combinaisons possibles sans limite.