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 :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
timeframe(5minutes)
ifbarindex>bars5then
bars5=barindex
endif
timeframe(15minutes)
ifbarindex>bars15then
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)
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 :
Stratégie inventée pour l'occasion
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
TIMEFRAME(4HOURS)
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(1HOUR)
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 UNDERSM20[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
// 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 :
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
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 !
