La théorie des flux aléatoires et le FOREX - page 17

 

Voici l'AKF, jetez-y un coup d'oeil. J'ai juste besoin d'être sûr que ça compte correctement. Regardez ça.

Dossiers :
akf_01.mq4  7 kb
 
Prival:

Voici l'AKF, jetez-y un coup d'oeil. J'ai juste besoin d'être sûr que ça compte correctement. Regardez ça.


Le calcul de l'ACF lui-même se fait par définition, ce qui est correct au départ - le code est simple et transparent. Mais il serait intéressant de comparer la vitesse si elle est calculée par FFT. D'ailleurs, ce code se prête également à une accélération notable.
 
lna01:
Privé:

Voici l'AKF, jetez-y un coup d'oeil. J'ai juste besoin d'être sûr que ça compte correctement. Vérifiez.


Le calcul de l'ACF lui-même se fait par définition, ce qui est correct au départ - le code est simple et transparent. Mais il serait intéressant de comparer la vitesse si vous calculez via FFT. D'ailleurs, ce code se prête également à une accélération notable.


La FFT ne sera pas exacte, sur le graphique de la 8ème page ('Random Flow Theory and FOREX'), la ligne rouge est ACF par formule, la ligne bleue est symétrique autour du centre. J'ai peut-être fait quelque chose de mal, cependant (le fichier lui-même est joint sur la même page ci-dessus). lna01 S'il vous plaît, dites-moi en formules, comment utiliser la FFT pour construire correctement l'ACF, je l'ai fait de mémoire, peut-être ai-je fait une erreur.

FFT avant -> module+ ^2 -> FFT inverse -> extraction de la partie réelle Re() -> normalisation

 
Prival:

Voici l'AKF, jetez-y un coup d'oeil. J'ai juste besoin d'être sûr que ça compte correctement. Regardez ça.

Vous ne l'avez pas comparé avec matcad ? J'ai spécialement fait WriteToFile pour vérifier ;)
 
lna01:
Mais il serait intéressant de comparer la vitesse si le comptage se fait par FFT.
Dans la première variante, il y avait aussi la méthode via FFT - elle est vraiment plus rapide de plusieurs ordres de grandeur. Nous l'avons abandonné en raison de son exactitude douteuse.

lna01:
D'ailleurs, ce code se prête également à une accélération notable.
Je suis d'accord, le code peut être optimisé. Mais ce n'est pas encore une question de vitesse, alors je ne veux pas le faire.
 
2 Prival , komposter:

L'ACF via fft était symétrique, probablement en raison de la souscription de zéros. Et la précision est discutable pour une raison quelconque.



Mais il me semble que le calcul de la tête en temps réel devrait être plus rapide que la version fft. Cependant, le montant total estimé des calculs continue à être très confus. En particulier, le caractère arbitraire du choix de la longueur de la régression linéaire est déjà discutable à ce stade. Un problème similaire se pose toujours pour les canaux de régression linéaire. En fait, j'en ai déjà parlé plus tôt dans ce fil.
 

Oui, il y a plus de questions que de réponses. Mais ça devient intéressant.

1. Le coefficient de corrélation n'est pas censé être modulo supérieur à 1, mais il l'est.

2. Pourquoi a*x+b, Prival? C'est ainsi que vous voulez déstabiliser le graphique ? Il y a d'autres moyens qui sont plus précis. Par exemple, la régression linéaire (l'analogue de mach, mais elle a un décalage plus petit). En déduisant du prix la valeur actuelle du LR, nous nous débarrassons parfaitement des tendances, y compris celles qui ne sont pas linéaires.

Nous pouvons simplement prendre la première différence de prix (c'est-à-dire former une série de rendements), mais cela n'élimine que les composantes linéaires des tendances. Si nous prenons la deuxième différence, nous éliminons également les composantes quadratiques, etc.

Si vous voulez vous débarrasser du décalage (mais que vous voulez retracer l'historique), alors vous pouvez faire quelque chose comme la MA de Fourier, c'est-à-dire basée sur la transformée de Fourier et le rejet des hautes fréquences. Klot en a aussi.

 
Mathemat:

1. Le coefficient de corrélation n'est pas censé être modulo supérieur à 1, mais il l'est.

Si nous parlons de l'image avec fft, alors pour une raison quelconque, le premier élément disparaît de la série, et c'est lui qui est utilisé pour la normalisation. Je n'ai pas essayé de comprendre ce que c'est à partir des images données dans le post.
 
Faites attention avec la FFT : tnn (ou nl dans le corps) doit être une puissance de deux, c'est-à-dire 2^n, où n est un entier.
 
rsi:
Il faut être plus prudent avec la FFT : tnn (ou nl dans le corps) doit être un degré de deux, c'est-à-dire 2^n, où n est un nombre entier.
Dans ce sens, tout est OK, mais j'ai perdu des éléments bizarres de densité spectrale :). Il n'y a donc aucun problème avec le fft, je vais remplacer la source dans ce post maintenant.


P.S. J'ai supprimé le mauvais code source, et le place ici.

P.P.S. Pour plus de détails sur la manipulation des données : la taille du tableau d'origine doit être multipliée par 2, puis par 2. Toutes les cellules ajoutées doivent être écrites avec des zéros. Le tableau de densité spectrale pour le fft inverse devrait également avoir une taille étendue ; les carrés d'amplitude devraient être écrits dans les cellules pour les composantes réelles, et (naturellement) les zéros devraient être écrits dans les cellules pour les composantes imaginaires. Par conséquent, nous prenons les éléments du début jusqu'à la taille originale du tableau.
2 Prival: Je ne sais pas comment reproduire cela exactement dans Matkadec, les essais et les erreurs devraient aider à la fin. L'ACF doit correspondre avec une précision raisonnable.
Dossiers :
akf_01_fft.mq4  13 kb
Raison: