Alertes séquentielles
Forums › ProRealTime forum Français › Support ProScreener › Alertes séquentielles
- This topic has 46 replies, 2 voices, and was last updated 5 years ago by Nicolas.
-
-
07/10/2019 at 10:31 AM #102332
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 :
1234567891011121314timeframe(5 minutes)if barindex > bars5 thenbars5 = barindexendiftimeframe(15 minutes)if barindex > bars15 thenbars15 = barindexendiftimeframe(default)minutes5 = bars5*5minutes15 = bars15*15sequence = minutes5<minutes15 //moins de temps écoulé en UT5 qu'en UT15On pourrait aussi faire une soustraction (minutes15 – minutes5 > 0)
(non testé).
07/10/2019 at 11:42 AM #102337Merci 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'occasion12345678910111213141516171819202122TIMEFRAME(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 4hEvenementASurvenu = 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 < BARINDEX1erEvenementBSignal = EvenementA AND EvenementB AND BARINDEX1erEvenementA < BARINDEX1erEvenementBIf NOT SHORTONMARKET and Signal thenSellshort 1 contract at marketEndif07/10/2019 at 12:26 PM #10234307/11/2019 at 7:17 AM #102430/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.
07/11/2019 at 7:23 AM #102432Merci 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 :
https://www.prorealcode.com/topic/mtf-sequential-setup/
Au plaisir de te lire
07/11/2019 at 7:32 AM #102433J’ai fais un screener, mais je ne trouve aucun résultat, à tester:
1234567891011121314151617181920212223242526272829TIMEFRAME(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 4hEvenementASurvenu = Summation[3](EvenementA)>0BARINDEX1erEvenementA = 0if EvenementASurvenu thenfor i = 2 downto 0 doif EvenementA[i] thenBARINDEX1erEvenementA = barindex[i]breakendifnextendiftemps4h = BARINDEX1erEvenementA*4 //car 4h dans une bougieTIMEFRAME(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 thentemps1h = barindex*1 //car 1h dans une bougieendifsignal = BARINDEX1erEvenementA>0 and temps1h>temps4hscreener[signal]07/11/2019 at 7:45 AM #10243507/11/2019 at 8:02 AM #102438La 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
07/12/2019 at 8:42 AM #102489En 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
07/12/2019 at 9:01 AM #10249007/12/2019 at 9:16 AM #102491Oui peut être qu’une comparaison utilisant le date pourrait fonctionner ? Je cherche mais ne trouve pas
Que penses-tu de la proposition de robertogozzi ?
07/12/2019 at 10:03 AM #10249307/18/2019 at 8:07 PM #102858Bonjour 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
07/18/2019 at 8:23 PM #10285907/19/2019 at 10:10 AM #102896J’essaie tout de même de contourner le problème en comparant les date et les time, du genre
1Signal = ((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 :
12345678910111213A = close > close [1] // condition d'exempleASurvenu = Summation[3](A)>0DateA=0TimeA = 0if ASurvenu thenfor ia = 2 downto 0 doif A[ia] thenDateA = date[ia]TimeA = CurrentTime[ia]breakendifnextendifSi 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
-
AuthorPosts