Utilisation des réseaux neuronaux dans le trading. - page 14
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
C'est bizarre, c'est aléatoire ((
Pourquoi est-ce aléatoire ?
Voici une citation de la thèse de Pastukhov :
Comme vous pouvez le constater, cette valeur peut être considérée comme une constante.
)) Je vais citer une autorité plus forte pour moi.
"FR H-volatilité" parce que vous n'avez jamais trouvé H. Il saute. C'est une valeur aléatoire si vous le faites de la manière dont vous l'avez recherché. Bien que je n'aie peut-être pas tout compris (je n'ai pas vu toutes les études).
Pastukhov aurait dû défendre sa dissertation, ceci en premier lieu. Tu cherchais un modèle = une opportunité de gagner de l'argent. J'ai plus confiance en tes recherches. Mais h est, il est égal à deux fois la valeur du spread, au moins pour la paire GBPUSD, plus précisément en termes de radiolocalisation c'est la valeur du mouvement qui peut être détecté. Cette valeur est liée au seuil du rapport signal/bruit (je l'ai obtenu autour de 1.6-1.8 de l'écart).
Je suis intéressé de savoir comment les organisateurs du championnat sont arrivés à cette valeur.
"FR H-volatilité" parce que vous n'avez jamais trouvé H. Il saute. C'est aléatoire.
Vous avez raison.
J'avais déjà oublié les détails - les neurones du MTS suivent la voie H, laisse son homologue biologique se détendre :-)
Vous soulevez un bon point, mais vous n'avez aucune idée de la facilité avec laquelle cela est mis en œuvre dans MT. Il n'est pas nécessaire de créer un indicateur pour cela, tout peut être mis directement dans le conseiller expert. Tiens, regarde mon dernier message. C'est presque un plan pour le partitionnement Kagi (les sommets sont montrés, mais il n'y a aucun problème pour aller au partitionnement lui-même).
Merci pour l'indie. Je dois maintenant améliorer mes connaissances de mql4 pour aller de l'avant.
Oui - j'ai la même chose.
Je dois demander à Prival comment obtenir la distribution souhaitée (rectangulaire) à partir d'une distribution arbitraire sous forme analytique.
Je l'ai trouvé ici. Je l'ai supprimé à la maison et l'ai laissé au forum.
>> Tics : distributions de l'amplitude et du délai.
Eh bien, toi, Prival, tu es rapide !
Merci. Lisons-le.
Eh bien, toi, Prival, tu es rapide !
Merci. Nous allons le lire.
)))) super-opérationnel...
mais mon point de vue est différent... Dans différentes parties du forum, je rencontre des affirmations, disons que sur l'axe des x, nous avons une variable aléatoire (le temps)... ici, par exemple, Prival écrit :
Il y a tellement de façons d'analyser une variable aléatoire sur l'axe Y (MA, RSI, etc.) mais nous avons oublié l'axe X alors qu'il s'agit d'une variable aléatoire et que nous devons la manipuler avec soin et correctement.
un tick n'est pas une valeur aléatoire ! un tick - l'incrément du prix est en réalité une valeur aléatoire dans le temps, si l'on considère le temps comme le nombre de secondes écoulées depuis 00:00 le 1er janvier 1970... le graphique des incréments de tic dans le temps serait une chaîne de Markov à temps continu, c'est-à-dire que les moments du temps y sont aléatoires - d'ailleurs, c'est pour cela que c'est une perte de temps... Les chaînes de Markov à temps continu sont beaucoup plus difficiles à analyser que les chaînes à temps discret.)
et le prix de la transaction n'est pas une variable aléatoire, il existe à tout moment (théoriquement)... En pratique, bien sûr, nous pouvons rencontrer des choses désagréables comme des délais d'attente ou de simples requêtes... Mais cela ne change pas l'essence de la question - le prix d'une transaction existe à tout moment, c'est-à-dire que la fonction du prix en fonction du temps est une valeur continue (indépendamment des écarts) !
La seule difficulté ici est le week-end. Si de simples trous dans les données peuvent être colmatés, alors les week-ends ne peuvent pas être "colmatés"... Mais en principe, ce n'est pas un problème non plus... Il suffit de numéroter les barres à l'envers - la dernière sera zéro et zéro sera la dernière... ...et vous obtiendrez une valeur non aléatoire le long de l'axe des X ! Voilà, tous vos indices conçus pour étudier une fonction non continue fonctionneront correctement !
...
Voici une recherche spéciale pour vous : http://offline.computerra.ru/2003/512/29647/
Deux conditions préalables
prix - continu
Le temps est continu.
DC numérise une valeur continue. dans toute numérisation il y a des erreurs. le bruit de quantification (erreur de niveau) +- pips et le bruit de discrétisation (erreur de temps). Donc, en prenant les minutes de leur cape, nous convenons a priori qu'il y a eu un tic à ce moment précis. Mais en fait, ce n'est pas le cas. Je dirais que c'est très clair sur les tics minute (qui travaille avec eux). Pour ceux qui travaillent avec l'horloge, cela ne se voit pas tellement.
C'est pourquoi pour les spectres GMT, il peut être considéré comme un bruit "minuscule", et il peut être expliqué par le bruit d'échantillonnage.
prix - continu
temps - continu
les deux déclarations sont incorrectes !
nous sommes en quelque sorte d'accord a priori sur le fait qu'il y avait un tic à ce moment précis dans le temps...
non, nous ne sommes pas d'accord sur le fait qu'il y avait un tic... nous sommes d'accord qu'il y avait un prix... ce sont des choses différentes...
Et le bruit d'échantillonnage est un peu trop... >> en tenant compte du fait que notre "dispositif" (c'est-à-dire le terminal) présente des erreurs de synchronisation - Sergei, c'est exagéré...