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
Pour faire suite à la stochastique "silencieuse".
Quelques changements :
1. corrigé pas tellement une erreur... ...une incohérence ou autre. Lorsque je modifiais ce paramètre, la sensibilité stochastique "s'emballait", en raison des particularités du calcul du ralentissement (Slowing), et je devais la mettre à l'échelle manuellement. Fixe. Dans la fonction, on a simplement introduit une ligne multipliant la sensibilité par la décélération (voir dans le code).
2. Une vérification de la suffisance des barres pour la recherche des extrema dans un tableau a été ajoutée (dans la fonction). Ce n'était pas un gros problème - il y avait juste un avertissement dans le journal mais c'était bon. Il ne s'agit pas d'un "combat" maintenant.
3. J'ai mentionné dans les commentaires de ce billet que je pourrais faire du seuil de sensibilité une fonction de l'ATR. C'est fait. Ajout de deux champs appropriés :
Volatilité - si elle est supérieure à 0, la période de lissage pour ATR ; si elle est définie sur des valeurs négatives, la sensibilité sera liée à StDev. Je n'aime pas avoir à saisir des champs supplémentaires.
xVolatility - multiplicateur pour la Volatilité.
De haut en bas : (1) stochastique, où ATR(66) x 4 fait office de seuil ; (2) le seuil est fixé de manière rigide à 10p ; (3) purement stochastique.
Mais si c'est vraiment "peut-être pas académique", j'écouterais.
Donc je ne vais pas le cacher.)) À moins, bien sûr, que je ne trouve quelque chose dans ce sens.
Intéressant, intéressant. Même si j'avoue avoir un certain scepticisme au départ.
D'ailleurs, une véritable formalisation implique de pouvoir vérifier l'historique, l'avez-vous fait ?
En fait, mes swindroids utilisant cette approche sont des échanges. Alors...
Voilà le truc. Bien sûr, je ne vais pas poster le robot avec la déclaration. Je serais intéressé de discuter de l'approche elle-même, mais pour cela il faudrait faire des outils qui au moins les fusionnent dans un fichier pour pouvoir analyser les lignes nouvellement créées. Je ne l'ai pas pour l'instant. Je dois me préparer.
J'ai formulé une sorte de théorème pour moi-même : pour tout marché (liquide), pour tout zigzag, le slippage moyen sera d'environ 1/2. On peut difficilement le prouver, mais un seul fait suffirait à le réfuter. Mon intérêt, à juste titre, est donc plutôt académique :) .
En fait, mes swindroids utilisant cette approche sont des échanges. Donc.
Le point ici est le suivant. Bien sûr, je ne vais pas poster le robot avec la déclaration. À cette fin, pour l'analyse des séries nouvellement obtenues, nous devrions créer des outils qui permettraient au moins de les fusionner dans un fichier. Je ne l'ai pas pour l'instant. Je dois me préparer.
Ce qui compte ici, c'est le temps, le nombre total de transactions et le fait que des modifications manuelles aient été apportées aux paramètres. Toutefois, ce n'est pas la question la plus importante. En tout cas, le bot avec la déclaration ne devrait pas être publié - le public se rassemblera en une grande multitude, et il sera absolument impossible de discuter du sujet :) .
Mais si tu n'aimes pas ça, ne t'inquiète pas.
Pastukhov a fait des recherches. C'est vrai, sa méthode est basée sur Renko ou Kaga, mais c'est la même chose avec ZZ aussi. En fait, tout revient à Hurst. Au-dessus de 0,5, nous sommes en tendance et en dessous de 0,5, nous sommes à plat. La température moyenne de l'hôpital est de 0,5 sur les liquides. Sinon, ce serait simple :) Et donc nous avons besoin de contexte, quand nous négocions une tendance et quand nous négocions un plat.
Oui, je connais Pastukhov. Si je me souviens bien, il a justifié la valeur de 1/2 comme une ligne de partage entre le pullback et le breakout pour un zigzag particulier. " Le théorème est équivalent à l'impossibilité de créer un zigzag suffisant pour le commerce, c'est-à-dire qu'il est plus général. Cependant, pour aller vers cette hypothèse plus générale, il ne faut pas tant du génie que du pessimisme :). Néanmoins, je crois qu'il est utile de vérifier chaque nouveau zigzag selon ce critère :)
Notez que c'est la réfutation du "théorème" qui est proposée maintenant. Puisqu'un zigzag avec la définition correcte du contexte intégrée serait autosuffisant pour le commerce :)
Pouvez-vous me dire comment corriger la saisie de données dans iCustom pour utiliser l'indicateur dans Expert Advisor?
ZZ=iCustom(Symbol(), 0, "ChanneliMACD_ATR", ..., ..., ..., 0, 0) ;
Merci.
Pouvez-vous me dire comment corriger la saisie de données dans iCustom pour utiliser l'indicateur dans Expert Advisor ?
ZZ=iCustom(Symbol(), 0, "ChanneliMACD_ATR", ..., ..., ..., 0, 0) ;
Merci.
Tampons (n).
0, 1 - pic, creux du Zig-Zag.
2, 3 - limites supérieures, inférieures du canal brut.
4, 5 - limites supérieure et inférieure du canal lissé.
6 - ligne de tendance.
===
Le nom de l'induke est enregistré de manière incorrecte lorsqu'il est attaché au post pour une raison quelconque. Il s'appelait à l'origine _Channel@MACD_ATR, mais le @ a été remplacé par une connerie. Soyez donc plus prudent lorsque vous le nommez dans iCustom.
Pour faire suite à la stochastique "silencieuse".
Le lien ne fonctionne pas
А... Non. Je mens. C'est parce que j'ai copié le lien à travers "mes scripts". Vous devez les ouvrir et les prendre dans la barre du navigateur. Bon à savoir.
===
Nan, c'est toujours avec _my/. Quoi qu'il en soit, j'ai corrigé le lien manuellement. (C'est bizarre, quand même.)