Aide à la rédaction d'une régression linéaire - page 6

[Sceptic Philozoff]

Dans ce cas, la meilleure chose à faire est probablement de trouver la moyenne arithmétique de tous les X[i], de la soustraire des valeurs elles-mêmes, de calculer les coefficients de régression et de les corriger à nouveau. En principe, rien ne vous empêche de faire de même avec Y[i]. Mais je n'ai pas essayé de trouver la formule, bien que ce ne soit évidemment pas difficile. Il y a évidemment un truc avec les matrices faiblement conditionnées.

P.S. Vous pouvez également normaliser les séries de données pour qu'elles soient à peu près du même ordre.

[Prival]

Mathemat писал (а) >>

Dans ce cas, la meilleure chose à faire est probablement de trouver la moyenne arithmétique de tous les X[i], de la soustraire des valeurs elles-mêmes, de calculer les coefficients de régression et de les corriger à nouveau. En principe, rien ne vous empêche de faire de même avec Y[i]. Mais je n'ai pas essayé de trouver la formule, bien que ce ne soit évidemment pas difficile. Il y a évidemment un truc avec les matrices faiblement conditionnées.

P.S. Vous pouvez également normaliser les séries de données pour qu'elles soient à peu près du même ordre.

Et je l'ai fait et suggéré par le biais du MJ. Formule simple, aucune correction nécessaire.

Maintenant vous pouvez mettre l'ACF dans la base de code aussi. Revérifié, tout coïncide avec une précision de 8 caractères, mais c'est très probablement dû à l'entrée dans le fichier des valeurs d'ACF calculées dans MQL.

[Yurixx]

Sergei, je suis déjà tombé sur ce sujet il y a quelques années lorsque j'écrivais ma LR. La solution est simple : écoutez les recommandations de Candid. La seule chose que je préciserais dans cette recommandation est de soustraire non pas Time[Bars-1], mais le temps de la première valeur X[]. Tout d'abord, elle rend le code de procédure universel puisque le début du X est déplacé à l'intérieur de la procédure. Deuxièmement, s'il y a beaucoup de barres sur le graphique (3 ans correspondent à 1000000 minutes, c'est-à-dire 60000000 sec), soustraire le temps de la première barre du graphique ne changera pas fondamentalement la situation. Troisièmement, vous pourrez revenir à vos formules d'origine sans aucune MO, ce qui signifie que vous pourrez supprimer les répétitions de cycles tout en maintenant la précision.

Une dernière chose. J'ai remarqué que votre X[] est l'heure des minutes. C'est-à-dire que les X sont disposés de manière équidistante. Vous pouvez donc vous affranchir complètement de l'heure et utiliser le numéro de barre. Si vous effectuez cette transition, tout sera compté de manière précise et rapide. Vous pouvez vérifier. C'est également préférable du point de vue du fonctionnement de votre LR sur M1 et D1 (imaginez combien les valeurs X sur D1 seront différentes s'il s'agit de l'heure et non du numéro de barre).

[Prival]

Yurixx писал (а) >>

Sergei...

Merci. J'ai tout essayé.

Je viens d'exposer ma version du calcul, peut-être que quelqu'un la trouvera utile. Je n'ai pas besoin de déplacer quoi que ce soit. Je ne me sens pas à l'aise de déplacer X à 0. J'utilise cette fonction pour calculer l'ACF, elle devrait être limitée dans le temps (il y a quelques dépendances).

[Yurixx]

En général, il n'est pas nécessaire de déplacer X lui-même au point 0. Pour ce faire, il suffit d'utiliser un tableau interne décalé de X[1] dans la fonction LR au lieu de X lui-même. Vous pouvez même vous passer d'un tableau - il suffit de soustraire la valeur de X[1] au moment où les sommes sont calculées.

Au fait, si vous l'avez essayé, cela ne vous a pas aidé ?

[Prival]

Yurixx писал (а) >>

En général, il n'est pas nécessaire de déplacer X lui-même au point 0. Pour ce faire, il suffit d'utiliser un tableau interne décalé de X[1] dans la fonction LR au lieu de X lui-même. Vous pouvez même vous passer d'un tableau - il suffit de soustraire la valeur de X[1] au moment où les sommes sont calculées.

Au fait, si vous l'avez essayé, est-ce que ça a marché ?

J'ai essayé et cela semble fonctionner. Mais il y a une nuance : si l'algorithme donne une telle erreur pour un tableau de 6 nombres, nous n'avons aucune garantie que l'erreur ne s'accumulera pas même avec un décalage. Le tableau avec lequel je travaille est de 7200 (minutes). C'est pourquoi j'ai trouvé cet algorithme, et il fonctionne correctement. J'ai dû abandonner l'autre, car je ne lui fais plus confiance.

//+------------------------------------------------------------------+
//| Формула предлагаемая мной                                        |
//| Рассчет коэффициентов A и B в уравнении                          |
//| y(x)=A*x+B                                                       |
//| используються формулы https://forum.mql4.com/ru/10780/page5       |
//+------------------------------------------------------------------+

void LinearRegr(double X[], double Y[], int N, double& A, double& B)
{
      double mo_X = 0.0, mo_Y = 0.0, var_0 = 0.0, var_1 = 0.0;
      
    for ( int i = 0; i < N; i ++ )
      {
        mo_X +=X[i];
        mo_Y +=Y[i];
      }
    mo_X /=N;
    mo_Y /=N;
        
    for ( i = 0; i < N; i ++ )
      {
        var_0 +=(X[i]-mo_X)*(Y[i]-mo_Y);
        var_1 +=(X[i]-mo_X)*(X[i]-mo_X);
      }
        A = var_0 / var_1;
        B = mo_Y - A * mo_X;
}

>> Je n'ai pas besoin d'être déplacé.

[Yurixx]

Pas de problème, Sergei, utilise ce que tu veux. Je veux juste attirer votre attention sur un petit détail.

Comme vous le comprenez certainement, le MO se situe entre le maximum et le minimum pour n'importe quel rang. Le code que vous avez donné signifie en fait de déplacer le point de départ à [mo_X, mo_Y]. Et pour ce faire, vous parcourez en boucle toutes vos valeurs 7200. Et puis vous soustrayez, en calculant les sommes, les coordonnées du point zéro des coordonnées de la ligne. On peut tout aussi bien prendre n'importe quel point de la série [Xm, Ym] comme origine et effectuer le calcul du second cycle en remplaçant [mo_X, mo_Y] par [Xm, Ym].

Le paramètre A d'une régression linéaire est invariant par rapport aux transferts d'origine. Le MO n'a rien à voir avec cela.

Vous pouvez vérifier ce fait en 3 minutes sur papier.

C'est pourquoi le cycle de calcul de l'IR est inutile. Nous avons juste besoin d'amener les valeurs de X et Y à des ordres de fermeture.

[Candid]

Prival писал (а) >>

Si l'algorithme donne une telle erreur pour un tableau de 6 nombres, il n'y a aucune garantie que l'erreur ne s'accumulera pas même avec un décalage.

Le problème ici n'est pas le nombre de chiffres, mais le fait que dans chacun de ces 6 chiffres se trouve un additif permanent (inutile) de 1216600000. Il ne contient tout simplement aucune information. Mais c'est 10 chiffres significatifs. Soit 9, le dernier 0 n'est pas informatif car les 6 sont présents aussi. Au carré, ces déchets bloqueront 17 chiffres significatifs de la mantisse. Et il n'y en a que 15. C'est-à-dire qu'il jettera les chiffres les plus bas (dans les toilettes). Or, ce sont ces chiffres écartés qui contiennent l'information nécessaire (ils contiennent une partie de l'information sur la composante variable X).

[Prival]

Donc je n'ai pas inventé cette formule. C'est dans les livres. Et de cette formule, qui utilise des carrés, on dérive celle-ci (sans carrés). Assieds-toi juste avec un crayon. Quand j'aurai le scanner, je posterai une page de Tikhonov V.I. "Statistical Radio Engineering" p.446.

[Yurixx]

Exactement, asseyez-vous avec un crayon et vous verrez que si vous remplacez Xi -> Xi-X0 et Yi -> Yi-Y0 dans votre formule originale pour la pente b, alors cette nouvelle formule est équivalente à la formule originale. Pour toute valeur de X0 et Y0. Par conséquent, les sommes Xi et Yi (qui constituent le calcul de la MO) peuvent être déplacées dans le deuxième cycle, ce qui divise par deux le temps de calcul de la LR. Et pour obtenir la précision, nous devons choisir les bons X0 et Y0. Et il est préférable de le faire de manière à ce que les ordres des séries X et Y soient plus proches les uns des autres.