Test des systèmes de prévision en temps réel - page 53

 
grasn писал(а) >>

à Yurixx

Je suggère de jouer aux bons vieux dés à coudre, vous pouvez utiliser n'importe quelle stratégie et chercher n'importe où :o) Prévisions sur EURUSD M15 pour 300 échantillons (du lundi au mercredi inclus) :

Option 1:

Entropie du processus : 13,84

Variante 2:

Entropie du processus : 13,01

Option 3:

Entropie du processus : 14,36

Quel dé à coudre ramassez-vous ? :о)

Je penche pour l'option 1, car la situation évolue depuis longtemps et ne demande qu'à être poursuivie.

 
forte928 >> :

Je penche pour l'option 1, car cette situation se développe depuis longtemps et ne demande qu'à se poursuivre.

Autrement dit, le prix est-il en train de franchir une sorte de zone de retournement ? Par curiosité, si cela ne vous dérange pas trop, pourriez-vous nous en dire plus ?

 
grasn писал(а) >>

Le prix est donc en train de passer une sorte de zone pivot ? Par curiosité, si cela ne vous dérange pas trop, veuillez préciser.

En ce moment, il y a un premier facteur sur la base duquel nous pouvons conclure à une tendance latérale sur la paire EUR-dollar.

La paire a atteint le niveau de la ligne OP de consolidation à 1.4850. Exactement les mêmes fluctuations ont été observées à 1.3437 et 1.3937 avec un retour en arrière ultérieur, ce qui correspond aux niveaux 0.382, 0.618 et 1.00.

la deuxième figure est le même graphique mais avec les 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 les niveaux 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, l'indicateur de saturation a longtemps montré le 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 journalier 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...

 

Grasn, puis-je vous poser une question ? Avez-vous essayé de rechercher des points de basculement dans une série chronologique ?

mise à jour : je pose la question parce que je creuse dans cette direction (et quelque chose s'annonce). Voici un exemple de ce à quoi ressemble ma recherche de points critiques :


Points critiques

Comme vous pouvez le voir, avant que la série ne change de comportement, le caractère des oscillations de l'indicateur change brusquement (il y a des salves de grande amplitude, pour être plus exact, les maxima/minima commencent à s'adapter parfaitement au graphique de la fonction f(x)=a^x). Les pics se produisent un peu plus tôt (généralement :)) que les changements de comportement de la série. Cependant, je ne l'ai pas encore bien maîtrisé. Je dois travailler à la limite de la double précision (les chiffres sont très petits) + il me manque les prédictions directionnelles.

 
grasn писал(а) >>

Supposons qu'il existe une telle construction :

Comme je l'ai compris, il va dynamiquement augmenter le tableau memRow[] lorsque certaines conditions se déclenchent. C'est-à-dire que je ne connais pas la longueur du tableau à l'avance. Est-ce que j'ai bien compris ?

1. Dans MKL4, vous ne pouvez pas opérer avec des tableaux dont la taille n'a pas été définie. Si vous n'avez pas spécifié la taille lors de la déclaration du tableau, vous devrez le faire dans init(). De plus, tout en travaillant, vous pouvez modifier cette taille selon vos besoins.

2. 2. Les conseils de Léa sont très pratiques, ils valent la peine d'être écoutés. En général, pour que les conseils soient adéquats, il vaut mieux expliquer clairement à quoi sert le tableau et pourquoi vous devez en modifier la taille. Il est tout à fait possible que vous vous satisfassiez d'une option permettant de simplement allouer de l'espace et d'avoir une variable avec l'indice du dernier élément. Alors, que vous connaissiez ou non le nombre d'éléments dont vous avez besoin n'aura pas vraiment d'importance.

.

Je ne joue pas aux dés à coudre. Mais je préfère la variante 2. Ou je veux juste que l'EuR se développe ? :-)

Mais les variantes 1 et 3 sont également correctes, bien qu'elles diffèrent très peu l'une de l'autre.

 
Yurixx >> :

1. Dans MKL4, vous ne pouvez pas travailler avec des tableaux dont la taille n'est pas définie. Si vous ne spécifiez pas la taille du tableau, vous devrez le faire dans init().

1 Pas du tout obligatoire.

Déclarer un tableau sans définir sa taille divise le processus de préparation du tableau en trois parties :

1 déclaration en tant que telle - par cette procédure, le programmeur indique au compilateur si le tableau est global ou local.

2. fixer la taille par ArrayResize() - après cette procédure, le tableau est réellement prêt à fonctionner.

3 Initialisation - si elle n'est pas spécifiée, le tableau reste tel qu'il était (et stocke les valeurs des départs passés), lorsque le tableau est créé, il est automatiquement initialisé à 0.

 
grasn >> :

Merci, je vais essayer, mais je ne peux pas évaluer ce qui serait optimal. D'autre part, pour un petit tableau, je ne connaîtrai pas non plus sa dimensionnalité, et de plus, dans cette implémentation, je devrai doubler le tableau, d'abord le petit puis le grand, dans lequel les valeurs calculées sont accumulées. Mais je vais devoir expérimenter, merci pour le conseil.

Dans mon expérience, je recommande de définir et d'utiliser les tableaux directement où ils ont besoin d'être utilisés, de tels tableaux sont principalement locaux, ils utilisent la mémoire dynamiquement, ce qui est mieux par rapport aux tableaux statiques, qui veulent ou non le vent les déplace vers le fichier d'échange, et donc leur travail devient plusieurs fois plus lent que de la RAM, surtout si le tableau est petit, il n'a aucun sens statiquement de réserver beaucoup d'espace pour eux. Le compilateur MQL-4 est conçu pour que vous ne ressentiez pas la différence entre la déclaration d'un tableau avec indication explicite de la taille et celle d'un tableau retardé.

 
Urain писал(а) >>

Dans mon expérience, je recommande de déclarer et d'utiliser les tableaux directement où ils ont besoin d'utiliser de tels tableaux pour la plupart s'avèrent être locaux ceux dynamiquement utiliser la mémoire qui est meilleure par rapport aux tableaux statiques que vous voulez ou non Windows les met dans le fichier d'échange et donc leur travail deviennent plusieurs fois plus lent que de la RAM, plus si le tableau de petite taille alors il n'y a pas de sens statiquement pour eux de réserver beaucoup d'espace.

Je ne comprends pas... Pourquoi un tableau local ne peut-il pas être préempté dans un fichier d'échange ? En fait, il est préempté à cet endroit lorsqu'il y a un manque de mémoire ; je suis sûr que les tableaux locaux et globaux seront préemptés exactement de la même manière. Quelle est la différence ?

 
lea >> :

Quelque chose que je ne comprends pas... Pourquoi un tableau local ne peut-il pas être préempté dans un fichier d'échange ? En général, il est poussé là lorsqu'il y a un manque de mémoire ; je suis sûr que le local et le global seront poussés exactement de la même manière. Quelle est la différence ?

Les tableaux statiques ont toutes les chances d'être créés à chaque appel du programme et d'être écrasés par les tableaux nouvellement créés lors de la permutation. Cependant, si la RAM est plus que suffisante, cela peut ne pas se produire.

 
Urain >> :

1 Pas du tout nécessaire.

Déclarer un tableau sans définir sa taille divise le processus de préparation du tableau en trois parties :

1 déclaration en tant que telle - par cette procédure, le programmeur indique au compilateur si le tableau est global ou local.

2. fixer la taille par ArrayResize() - après cette procédure, le tableau est réellement prêt à fonctionner.

3 Initialisation - si elle n'est pas spécifiée, le tableau reste tel qu'il était (et stocke les valeurs des départs passés), lorsque vous créez un tableau, il sera automatiquement initialisé à 0.

Si vous définissez la taille dans init() avec ArrayResize(), ce tableau n'aura pas de taille dans start(), vous devez spécifier la taille dans la fonction où le tableau sera utilisé, et il en va de même pour l'utilisation du tableau dans les fonctions utilisateur. Si le tableau est passé en paramètre, sa taille ne doit pas être spécifiée dans la fonction définie par l'utilisateur, mais dans start() (ou dans init() si la fonction est appelée par l'initiateur), puis dans la fonction appelée. L'exception est constituée par les tableaux d'indicateurs, dont la taille est attribuée égale aux barres lorsque l'état de l'indicateur est attribué au nom du tableau dans SetIndexBuffer(), et elle change en fonction de l'évolution des barres.

Ainsi, ma chère, vos explications sont non seulement inutiles mais aussi nuisibles car elles font perdre du temps aux gens pour découvrir la vérité.

Urain, vous induisez les gens en erreur. Les tableaux MQL, y compris les tableaux locaux, ont une persistance - leur taille et leur contenu sont préservés entre les appels de fonction et les ticks. Veuillez lire l'aide. Les tableaux globaux se comportent de la même manière, la seule différence étant qu'ils ont une portée globale. Un tableau distribué dans une fonction init est lisible dans start et ailleurs. Je recommande d'ouvrir un nouveau fil de discussion, si quelqu'un a des questions sur certains aspects de la programmation MQL. J'aimerais voir des conversations plus substantielles sur les prévisions ici. ;-)

Si vous avez des questions, veuillez filtrer les informations de ce forum ;-). Si vous décrivez le problème plus en détail (vous pouvez le faire en personne), nous (je) trouverons une meilleure façon de le mettre en œuvre.