Plus on cherche seul, plus on apprend 🙂
J’essai de répondre rapidement à tout le monde, mais j’ai beaucoup de travail en ce moment.
Pour reprendre l’idée du BARINDEX, qui est pour moi la plus viable, car je ne sais pas si currentTime fonctionnerait dans le cas d’un changement de journée ? (je ne connais pas les UT que tu utilises, sans le code complet 🙂 )
Par exemple :
timeframe(5 minutes)
if barindex > bars5 then
bars5 = barindex
endif
timeframe(15 minutes)
if barindex > bars15 then
bars15 = barindex
endif
timeframe(default)
minutes5 = bars5*5
minutes15 = bars15*15
sequence = minutes5<minutes15 //moins de temps écoulé en UT5 qu'en UT15
On pourrait aussi faire une soustraction (minutes15 – minutes5 > 0)
(non testé).
Merci Nicolas pour l’idée, et aussi pour la rapidité de tes réponses 🙂
J’utilise les TF 4h, 1h, 15min, 5 min et 1min
Je ne vois pas comment me servir de ton idée, peut être en commençant par un exemple le plus simple possible :
TIMEFRAME(4 HOURS)
SM14= average[14](close)
EvenementA = HIGH[1]>SM14[1]
// Je vérifie que l'évenement a eu lieu dans les 3 dernières périodes 4h
EvenementASurvenu = Summation[3](HIGH[1]>SM14[1])>0
//Je ne sais pas comment obtenir le barindex de la PREMIERE APPARITION de l'événementA dans les 3 dernières périodes avec le bon format pour comparaison avec le barindex de B:
BARINDEX1erEvenementA = .....EvenementA .....
TIMEFRAME(1 HOUR)
SM5 = average[5](close)
SM20 = average[20](close)
// Je vérifie que l’événement a eu lieu en clôture:
EvenementB = SM5[1] CROSSES UNDER SM20[1]
// Je ne sais pas comment faire comment obtenir le barindex de l’événement B en clôture et dans le bon format pour comparaison avec le barindex de A :
BARINDEX1erEvenementB = ..... EvenementB ...
// J'obtiens un signal non suffisant car ne comportant pas la séquence temporelle : BARINDEX1erEvenementA < BARINDEX1erEvenementB
Signal = EvenementA AND EvenementB AND BARINDEX1erEvenementA < BARINDEX1erEvenementB
If NOT SHORTONMARKET and Signal then
Sellshort 1 contract at market
Endif
En fait dans ton code je comprends la notion de transformer les BARINDEX d’une UT en BARINDEX de l’UT Default
Mais pas les boucles IF ?
/Je ne sais pas comment obtenir le barindex de la PREMIERE APPARITION de l’événementA dans les 3 dernières périodes
Tu ne pourras pas avec un SUMMATION, il faut faire une boucle FOR/NEXT
// J’obtiens un signal non suffisant car ne comportant pas la séquence temporelle : BARINDEX1erEvenementA < BARINDEX1erEvenementB Signal = EvenementA AND EvenementB AND BARINDEX1erEvenementA < BARINDEX1erEvenementB
EvenementA et B ne sont peut être plus présent puisque selon ta logique ils ont peut être eu lieu il y a 3 barres de cela, donc ces 2 variables peuvent retourner 0 ! et Signal restera à 0..
Bref j’ai compris ce que tu veux faire, je vais essayer de reprendre ton exemple et le tester.
Merci Nicolas, j’essaie d’être clair mais ce n’est pas un problème évident.
Je vais aussi essayer encore de mon côté avec une boucle FOR (déjà tenté mais vraiment sans résultats).
J’ai essayé de clarifier la problématique précise du setup sequentiel MTF pour proorder et j’ai alors créé ce post en anglais, pour ouvrir la discussion à un public plus large :
MTF Sequential Setup
Au plaisir de te lire
J’ai fais un screener, mais je ne trouve aucun résultat, à tester:
TIMEFRAME(4 HOURS)
SM14= average[14](close)
EvenementA = HIGH[1]>SM14[1]
// Je vérifie que l'évenement a eu lieu dans les 3 dernières périodes 4h
EvenementASurvenu = Summation[3](EvenementA)>0
BARINDEX1erEvenementA = 0
if EvenementASurvenu then
for i = 2 downto 0 do
if EvenementA[i] then
BARINDEX1erEvenementA = barindex[i]
break
endif
next
endif
temps4h = BARINDEX1erEvenementA*4 //car 4h dans une bougie
TIMEFRAME(1 HOUR)
SM5 = average[5](close)
SM20 = average[20](close)
// Je vérifie que l’événement a eu lieu en clôture:
EvenementB = SM5[1] CROSSES UNDER SM20[1]
if EvenementB then
temps1h = barindex*1 //car 1h dans une bougie
endif
signal = BARINDEX1erEvenementA>0 and temps1h>temps4h
screener[signal]
Merci beaucoup
je crois que ta boucle FOR tape dans le 1000 ça me semble à lecture effectivement renvoyer le BARINDEX du 1er évenement
Je code ça dans proorder dès que possible pour vérifier
🙂
La méthode pour donner le barindex du premier evenement dans les n periodes est gagnante 🙂 je l’ai graphée
Il est par contre clair lorsque l’on graph temps1h et temps4h que l’on n’aura pas de signal (image jointe)
temps1h en rouge et temps4h en noir
je ne suis pas certain de la conversion barindex en temps, je vais étudier les ressources sur le sujet
En utilisant currenttime j’ai réussi a obtenir la détection séquentielle grâce a ta boucle if/ for/ if.
J’en étais très content jusqu’à ce que je remarque qu’effectivement il y a un probleme en 4h :
lors du passage horaire à 000000 à minuit, le currenttime de l’évenement reste elevé s’il a eu lieu avant minuit alors que les currenttime 1h 15min etc sont recalculé sur une nouvelle base 0 et donc sont plus petits et paraissent plus vieux que l’evenement 4h qui a eu lieu pourtant avant… Résultat la détection n’est pas faite. J’ai cherché une solution, mais travailler avec un barcode efficace serait certainement mieux
Je me doutais de ce problème c’est pour cela que je t’ai orienté vers la quantité de bars.
Sinon tu peux aussi tester une Date et un Time.
Oui peut être qu’une comparaison utilisant le date pourrait fonctionner ? Je cherche mais ne trouve pas
Que penses-tu de la proposition de robertogozzi ?
https://www.prorealcode.com/topic/mtf-sequential-setup/
Enregistre la date et le time de la première condition et teste si la seconde est supérieure à ces valeurs.
Bonjour Nicolas, après avoir bien tâtonné, et utilisant jusqu’à 7 UT différentes parfois dans le même robot, je peux dire qu’utiliser le date et le time est vraiment complexe et beaucoup trop fastidieux à cause des suites d’évenements traversant le 000000. Et qu’utiliser le BARINDEX serait bien plus propre dans l’idée.
Malheureusement, après de nombreux graph, le BARINDEX de chaque UT ne semble pas aussi évident à comparer qu’un simple règle de 3
Je ne comprend pas ce barindex, et j’ai même remarqué en UT 1 min que la fonction n’est pas linéaire, donc forcément cela crée aussi des décalages dans le temps.
Bref je toujours bien paumé pour bien comparer ma séquence de conditions !
Par quel bout prendre le problème ??
Merci encore
Je viens de grapher le rapport BARINDEX5MIN/BARINDEX1MIN … résultat plutôt… sympa !
Avec un zoom, encore plus intéressant !
J’essaie tout de même de contourner le problème en comparant les date et les time, du genre
Signal = ((DateA=DateB AND TimeB>TimeA) OR DateB>DateA) and ((DateB=DateC AND TimeC>TimeB) OR DateC>DateB)
Ce qui en théorie devrait marcher.
Mais comme la détection temporelle est de la forme :
A = close > close [1] // condition d'exemple
ASurvenu = Summation[3](A)>0
DateA=0
TimeA = 0
if ASurvenu then
for ia = 2 downto 0 do
if A[ia] then
DateA = date[ia]
TimeA = CurrentTime[ia]
break
endif
next
endif
Si B existait déjà juste avant A, la première heure de B se retrouve avant A, le temps que summation[3] soit fini
Et la détection temporelle retombe à l’eau.
Quel casse-tête cette détection temporelle !!!
Je rapelle mon simple besoin :
- A est détecté en UT1, alors seulement :
- On lance la détection de B en UT2,
- B est détecté (en UT2), alors seulement :
- On lance la détection de C en UT3
- Le signal est alors renvoyé
C’est quand même bien possible de faire cela sur PRT, d’une manière ou d’une autre
On va y arriver
