Test des systèmes de prévision en temps réel - page 54
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
à forte928
В данный момент есть первый фактор на основании которого можно сделать вывод о боковом флете на паре евро доллар -
La paire a atteint le niveau de consolidation de la ligne OP à 1.4850. Exactement les mêmes fluctuations ont été observées aux points de 1.3437 et 1.3937 avec le rollback ultérieur qui correspond aux niveaux de 0.382, 0.618 et 1.00.
dans la deuxième figure le même graphique mais avec des niveaux de croissance calculés par rapport au bas - 1.4162 et le courant 1.4951 et si vous prenez sur la base de ce graphique des niveaux de prix 1.4951 et 1.4851 vous pouvez voir que le prix est juste dans le point d'équilibre au niveau moyen des fluctuations de ces indicateurs les deux derniers jours ... En outre, dans le graphique indicateur vers le bas a montré un niveau de saturation à laquelle le renversement devrait se produire.
mais il y a un certain nombre de choses qui ne permettent pas que cela se produise :
1) le graphique journalier montre un mouvement de croissance négatif (indicateur du bas)
2) Le graphique journalier a atteint le niveau de consolidation de 0.382 à 1.4877 sur le premier indicateur.
3) Le graphique quotidien a atteint le niveau de consolidation du COP à 1.4892 sur le deuxième indicateur
4) Il y a une opposition active à la hausse sur le graphique H4.
5) Présence de deux niveaux de consolidation par rapport au bas de la fin septembre OP et 0,236 (1,4931 et 1,4933), ce qui est une forte indication de la présence d'une correction prolongée.
A suivre...
Merci beaucoup pour ces précisions, je dois dire que j'ai abandonné l'AT il y a quelques années (pour moi-même), mais il est toujours intéressant de lire des analyses compétentes et de les comparer avec mes prédictions. Pourriez-vous clarifier le terme "niveau de consolidation" pour une meilleure compréhension et pour éviter toute confusion dans la terminologie.
pour lea
Avez-vous déjà essayé de rechercher les points critiques d'une série chronologique ?
Non, je ne l'ai pas fait, et jusqu'à présent je n'ai aucune idée de comment les trouver. J'ai utilisé une notion telle que la "mémoire des séries temporelles". Il s'agit d'un terme un peu spécifique, que l'on retrouve dans les réseaux neuronaux, l'analyse fractale, mais vous devez toujours examiner le contexte de son application. Je veux dire l'influence des comptages historiques sur les réalisations futures du processus. En termes simples, ce paramètre répond à la question "combien de temps faut-il prendre les séries historiques".
PS: Au fait, je me souviens que vous aviez promis d'améliorer votre bibliothèque linéaire et de poster une nouvelle version...
à Yurixx
1. Dans MKL4, vous ne pouvez pas utiliser un tableau dont la taille n'est pas définie. Si vous n'avez pas spécifié sa taille lors de la déclaration du tableau, vous le ferez dans init(). De plus, pendant le travail, vous pouvez modifier sa taille selon vos besoins.
Je ne comprends pas bien. Je ne fais pas cela et tout fonctionne, je veux dire sans initialisation dans init().
2. Les conseils de Léa sont très pratiques, ils méritent d'être pris en compte. Il est tout à fait possible que vous souhaitiez simplement allouer de l'espace et avoir une variable avec l'index du dernier élément. Dans ce cas, il importe peu que vous connaissiez le nombre d'éléments dont vous avez besoin ou non.
Je ne pense pas que ce soit très pratique, car il faudra évidemment faireplus de calculs. Des boucles supplémentaires pourraient être ajoutées à ce qui précède. Mais tout de même, il faudrait que je vérifie tout cela, si seulement nous pouvions obtenir quelques recommandations des développeurs.... :о)
En général, pour que le conseil soit adéquat, il vaut mieux expliquer plus précisément à quoi sert le tableau et pourquoi vous devez en modifier la taille.
Par exemple (et c'est l'exemple le plus simple) pour trouver des extrema locaux (pas sur le graphe) par la condition y[n]>y[n+1] et y[n]<y[n-1] et de manière correspondante pour un minimum. Je comprends qu'il est possible de résoudre le problème de plusieurs façons, par exemple comme ceci :
- Créer un tableau de même longueur que la série initiale, y coder 0 et 1 la présence d'un extremum.
- Effectuer la première itération en calculant le nombre d'extrema
- Recalculer le nombre d'extrema
- Initialiser le tableau avec cette valeur
- Ecrire les valeurs dans le nouveau tableau
Vous pouvez le faire de cette façon, vous pouvez le faire de cette façon, j'essaie de trouver la meilleure façon :o)Je ne joue pas aux dés à coudre. Mais je préfère la variante 2 ou peut-être que je veux juste que l'eura grandisse ? :-)
Comme vous l'avez remarqué, je ne suggérais pas les dés à coudre en tant que tels. Tout est clair, j'étais juste curieux de connaître votre opinion (j'ai lu sur un fil voisin votre prédiction).
Mais les options 1 et 3 sont également acceptables, même si elles ne diffèrent pas beaucoup l'une de l'autre.
Déplacement de la valeur moyenne des prix par "vecteur divergent".
à Urain
Selon mon expérience, je recommande de définir et d'utiliser les tableaux directement là où ils doivent être utilisés ; ces tableaux sont principalement locaux et utilisent la mémoire de manière dynamique, ce qui est mieux que d'utiliser des tableaux statiques, car ils fonctionnent plus lentement que depuis la mémoire, surtout si le tableau est petit, cela n'a aucun sens de leur réserver beaucoup d'espace de manière statique. Le compilateur MQL-4 est configuré de telle manière que vous ne sentirez pas de différence entre déclarer un tableau avec la taille explicite et la taille différée.
Il semble qu'il n'y ait pas de "pointeurs" statistiques/dynamiques sur l'endroit où un tableau est stocké dans MQL. Il n'y a qu'un seul opérateur d'initialisation, la seule question est que son utilisation multiple peut ralentir un grand tableau. Ou est-ce le cas ? Ou peut-être que je rate encore quelque chose ?
à marketeer
filtrer les informations du forum
Oh, c'est une qualité précieuse. Je peux vous assurer - j'ai les meilleurs filtres adaptatifs. :о)
Si vous décrivez votre tâche en détail (peut-être dans un message privé), nous (je) trouverons la meilleure façon de la mettre en œuvre.
Je vais y réfléchir, mais maintenant je veux le faire moi-même. Après tout, vous devriez au moins comprendre quelque chose à MQL, afin de pouvoir expliquer le problème d'une manière ou d'une autre :o).
Et il y avait une brindille si calme. (
>> Je pense que ça va rester comme ça. Les collègues sont juste toujours en mode combat :o)
à Yurixx
Je ne comprends pas vraiment. Je ne fais pas cela et tout fonctionne, je veux dire sans initialisation dans init()
Initialiser un tableau est une chose, déclarer une taille en est une autre. Si vous déclarez un tableau comme Arr[], alors un élément est alloué en mémoire. Vous pouvez travailler avec autant que vous voulez, et le système ne vous signalera pas l'erreur lorsque vous adresserez des éléments avec un numéro >0, mais les calculs seront incorrects. Pour que tout aille bien, vous devez définir une taille spécifique en utilisant l'opération ArrayResize(). Lors de l'allocation de la mémoire dans ce cas, tous les éléments seront remplis de zéros, donc si vous n'avez pas besoin de quelque chose de spécial, vous pouvez même ne pas l'initialiser (bien qu'un bon style l'exige).
.
Je ne pense pas que ce soit très pratique, car il est évident qued'autres calculs sont nécessaires. Des boucles supplémentaires peuvent être ajoutées à ce qui précède. Mais de toute façon, nous devrions vérifier tout cela, si seulement nous pouvions obtenir quelques recommandations des développeurs... :о)
Les conseils de Léa ne mènent pas à d'autres calculs. Sortez-le avec précaution. Et si vous faites participer les développeurs à cette question élémentaire, vous serez un héros. :-)
.
Par exemple (et c'est l'exemple le plus simple) pour trouver les extrema locaux (pas sur le graphe) par les conditions y[n]>y[n+1] et y[n]<y[n-1] et de manière correspondante pour le minimum. Je comprends qu'il est possible de résoudre le problème de plusieurs façons, par exemple comme ceci :
C'est ce qu'on appelle la main gauche sur l'oreille droite. Je le fais tout le temps dans mes programmes, mais je travaille en une seule fois pour éviter de gaspiller des ressources de calcul et du temps. La loi est la suivante : si vous gagnez en mémoire, vous perdez en temps et en calcul. Mon opinion personnelle est que la mémoire est moins critique pour le commerce. Par conséquent, vous pouvez facilement créer deux tableaux de même longueur et écrire la valeur extrême dans un tableau et sa coordonnée dans l'autre au fur et à mesure de leur formation.
Sergei, tu ferais mieux de commencer par le scénario le plus compliqué. Sinon, je ne comprendrai pas pourquoi il y a tant d'agitation. :-)))
Je conseille de traiter le conseil d'Urain "de déclarer et d'utiliser les tableaux directement lorsqu'il est nécessaire de les utiliser" avec beaucoup de prudence. L'utilisation des tableaux est déterminée par la nature de la tâche, et non par la façon de se battre avec le fichier d'échange.
Ну например (и это самый простой пример) поиск локальных экстремумов (не на графике) по условию y[n]>y[n+1] и y[n]<y[n-1] и соответственно для минимума. Я понимаю, что можно решить несколькими способами, например таким:
Это называется левой рукой за правое ухо. Я постоянно делаю это в своих программах, но работаю в один проход, чтобы не тратить зря вычислительные ресурсы и время. Закон такой: выигрываешь в памяти - проигрываешь во времени и вычислениях. Лично мне кажется, что память менее критична для трейдинга. Поэтому можешь смело создавать даже два массива такой же длины и писать в один значение экстремума, а во второй его координату, непосредственно по ходу их формирования.
pour lea
Non, je n'ai pas cherché de tels points et je ne sais pas encore comment les trouver. J'ai utilisé une notion telle que la "mémoire des séries temporelles". Il s'agit d'un terme un peu spécifique, que l'on retrouve dans les réseaux neuronaux et l'analyse fractale, mais il faut toujours tenir compte du contexte de son application. Je veux dire l'influence des comptages historiques sur les réalisations futures du processus. En termes simples, ce paramètre répond à la question "combien de temps faut-il prendre les séries historiques".
PS: Au fait, je me souviens que vous aviez promis d'améliorer votre bibliothèque linéaire et de poster une nouvelle version...
Je vois, merci pour la réponse.
Il y a deux mois, j'ai pratiquement achevé le travail sur la bibliothèque (j'ai supprimé les fonctions inutiles et refait celles qui existaient déjà). Bien que je n'aie toujours pas fait le calcul de la conditionnalité de la matrice. Je serai plus libre dans deux semaines environ, et j'essaierai alors de trouver une solution.
J'ai commencé à écrire un article à ce moment-là, mais je n'ai pas eu assez de temps. Actuellement, 50% des descriptions de fonctions sont prêtes (cela représente 6 groupes de fonctions sur 16 ; pour l'instant, je n'écrirai que la documentation sur les fonctions, les exemples d'utilisation suivront).
Comme je ne suis pas très doué pour les prévisions, j'ai décidé d'expérimenter le M1 aujourd'hui, à partir de lundi :
Je n'arrive pas à voir le graphique principal :)
Mais une sur-optimisation à chaque minute et une prévision pour 3 heures à venir.
Comme je ne suis pas très doué pour les prédictions, j'ai décidé d'expérimenter le M1 aujourd'hui, à partir de lundi :
Je n'arrive pas à voir le graphique principal :)
Mais une sur-optimisation à chaque minute et des prévisions pour 3 heures à l'avance.
Comment réoptimiser ? Et d'où tenez-vous vos prévisions, pas du déducteur par hasard ?
Comment ré-optimiser ? Et d'où tenez-vous vos prédictions, pas du déducteur par hasard ?
Pauvre Piboli, ça fait déjà quatre fois qu'on lui pose la question ^_^, oui, il fait ses prédictions à Deductorla prévision est plus ou moins la même (celle avec l'entropie maximale) :o) Un petit raffinement, les trajectoires suivantes demeurent, celle qui est "canalisée" étant la plus probable.
pour lea
Понятно
J'ai fait de mon mieux :o)
En gros, j'ai fini de travailler sur la bibliothèque il y a environ deux mois (j'ai supprimé les fonctions inutiles et refait celles qui existaient déjà). Bien que je n'aie toujours pas fait de calculs de conditionnalité de la matrice.
Mais il est dit que
Le code sera affiché plus tard.
Mais la version n'a pas changé :o(