Apple de fonction CALL, pour 14 varaibles
Forums › ProRealTime forum Français › Support plateforme ProRealTime › Apple de fonction CALL, pour 14 varaibles
- This topic has 8 replies, 4 voices, and was last updated 5 months ago by InTrouble.
-
-
05/31/2024 at 9:50 AM #233324
Bonjour,
J’ai créé une fonction pivots qui me retourne les pivots hebdos et mensuels, soient 14 variables.
Voici mon appel de fonction :
PPH, Res1H, Sup1H, Res2H, Sup2h, Res3H, Sup3H, PPM, Res1M, Res2M, Res3M, Sup1M, Sup2M, Sup3M = CALL DETECTpivots (Close)
Voici mon retour de fonction :
Return PPH, Res1H, Res2H , Res3H , Sup1H , Sup2H , Sup3H , PPM , Res1M , Res2M , Res3M , Sup1M , Sup2M , Sup3M
Cette fonction DETECTpivots () est un indicateur qui me renvoie bien les pivots souhaités, pour autant, les valeurs des variables obtenues après le CALL depuis un autre indicateur sont toutes nulles !
Un pb de nombre de variable ?
05/31/2024 at 10:08 AM #233326… et si je renvoie 14 valeurs décimales ‘en dur’ (dans la fonction RETURN) , ces valeurs sont bien prisent en compte : ce n’est donc pas un pb de nombre de variables !
Return 130.1,130.12334,130,130,130,130,130,130.123456,130,130,130,130,130,130
05/31/2024 at 1:09 PM #233341En principe, cela ne devrait pas arriver. Je viens de faire un test, même en déclarant les mêmes variables dans 2 indicateurs puis en utilisant CALL fonctionne correctement. Sans le code de vos clignotants je ne peux pas vous en dire plus…
05/31/2024 at 1:36 PM #233345Au cas où ce ne soit pas directement que les valeurs soient nulles, mais que ce soit obtenu après des calculs se servant de ce qui vient du call, il semble y avoir un ordre différent entre ce que donne le return et ce qui a été callé (juste après le PPH et avant le PPM), ce qui éventuellement pourrait fausser les calculs post-call (juste une hypothèse, ne les voyant pas):
Res1H, Sup1H, Res2H, Sup2h, Res3H, Sup3H (alternance des res,sup en 1 puis 2 puis 3)
vs
Res1H, Res2H , Res3H , Sup1H , Sup2H , Sup3H (alternance des 1,2,3 en res d’abord et en sup après)
06/02/2024 at 6:54 PM #233409Bonjour,
Tout d’abord merci de vos retours.
1er point : en effet, les variables sont appelées dans le désordre, je ne l’avais pas remarqué. Celà étant, le problème persiste.
Voici l’appel de fonction modifié:
1PPH, Res1H, Res2H , Res3H , Sup1H , Sup2H , Sup3H , PPM , Res1M , Res2M , Res3M , Sup1M , Sup2M , Sup3M = CALL DETECTpivots (Close)et la FONCTION DETECTpivots (je n’ai pas trouvé comment exporté le code dans un fichier, désolé…)
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091//////////////////////////// Pivots Hebdo et mensuel//////////////////////////Once mode = 0Once lastWeekBarIndex = 0Once weeklyHigh = undefinedOnce weeklyLow = undefinedOnce weeklyPivot = undefinedOnce weeklyR1 = undefinedOnce weeklyS1 = undefinedOnce weeklyR2 = undefinedOnce weeklyS2 = undefinedOnce weeklyR3 = undefinedOnce weeklyS3 = undefinedOnce lastMonthBarIndex = 0Once monthlyHigh = undefinedOnce monthlyLow = undefinedOnce monthlyPivot = undefinedOnce monthlyR1 = undefinedOnce monthlyS1 = undefinedOnce monthlyR2 = undefinedOnce monthlyS2 = undefinedOnce monthlyR3 = undefinedOnce monthlyS3 = undefined//// Pivot Hebdo //IF DayOfWeek < DayOfWeek[1] THENHveille = myHBveille = myBCveille = Close[1]myH = HighmyB = LowELSEmyH = Max(High, myH)myB = Min(Low, myB)ENDIFPPH = (Hveille + Bveille + Cveille) / 3Res1H = 2 * PPH - BveilleRes2H = PPH + (Hveille - Bveille)Res3H = Hveille + 2 * (PPH - Bveille)Sup1H = 2 * PPH - HveilleSup2H = PPH - (Hveille - Bveille)Sup3H = Bveille - 2 * (Hveille - PPH)// Pivot Hebdo //// Pivot Mensuel //IF OpenMonth <> OpenMonth[1] THENmyLastHigh = myHighmyLastLow = myLowmyLastClose = Close[1]myHigh = HighmyLow = LowELSEmyHigh = Max(myHigh, High)myLow = Min(myLow, Low)ENDIFPPM = (myLastHigh + myLastLow + myLastClose) / 3Res1M = (2 * PPM) - myLastLowRes2M = PPM + (myLastHigh - myLastLow)Res3M = myLastHigh + 2 * (PPM - myLastLow)Sup1M = (2 * PPM) - myLastHighSup2M = PPM - (myLastHigh - myLastLow)Sup3M = myLastLow - 2 * (myLastHigh - PPM)/////////////////////////if (IsLastBarUpdate ) THENDRAWTEXT(PPH , barindex, PPH)coloured (70,70,70)DRAWTEXT(Res2H , barindex, Res2H )coloured (70,70,70)DRAWTEXT(Res3M, barindex, Res3M )coloured (70,70,70)DRAWTEXT(PPM , barindex, PPM)coloured (70,70,70)DRAWTEXT(Res1H , barindex, Res1H )coloured (70,70,70)DRAWTEXT(Res3H, barindex, Res3H )coloured (70,70,70)DRAWTEXT(Res1M , barindex, Res1M)coloured (70,70,70)DRAWTEXT(Res2M , barindex, Res2M )coloured (70,70,70)DRAWTEXT(Sup1M, barindex, Sup1M )coloured (70,70,70)DRAWTEXT(Sup2M , barindex, Sup2M)coloured (70,70,70)DRAWTEXT(Sup3M , barindex, Sup3M )coloured (70,70,70)DRAWTEXT(Sup1H , barindex, Sup1H )coloured (70,70,70)DRAWTEXT(Sup2H , barindex, Sup2H )coloured (70,70,70)DRAWTEXT(Sup3H , barindex, Sup3H )coloured (70,70,70)ENDIFReturn PPH, Res1H, Res2H , Res3H , Sup1H , Sup2H , Sup3H , PPM , Res1M , Res2M , Res3M , Sup1M , Sup2M , Sup3M//Return 130.1,130.12334,130,130,130,130,130,130.123456,130,130,130,130,130,130//Return 130,130,130,130,130,130,130,130,130,130,130,130,130,130//////////////////////////06/02/2024 at 8:22 PM #233410Ok, je viens de tester , en UT5mn avec 10000 unités, et ça renvoie des valeurs différentes de 0. Si je réduis à 100 unités (histoire de vérifier un comportement probable par manque d’unités pour la lecture de l’hebdo et du mensuel, là j’ai 0.
La question qui en découle: les tests dans l’ut où est lancé le code qui call ont-ils été fait avec assez d’historique pour parvenir à lire les données hebdo et mensuelles nécessaires?
Nota1: bien que cela ne soit pas lié au problème, il semble aussi que toutes les valeurs en “once” en début de code ne soient pas utilisées ensuite.
Nota2: Pas de souci d’écrire le code au lieu d’exporter un fichier itf. Même si on met un fichier itf exporté, tant que le listing n’est pas trop long c’est même mieux d’écrire le code aussi, vu que la plupart du temps ceux qui aident le font juste en lisant le code sans forcément télécharger un itf, et si besoin de tester font un copier-coller au moins aussi vite qu’une importation d’itf de toute façon. Je reformate le listing via “insert PRT code” dans le post ci-dessus.
06/02/2024 at 10:28 PM #233411C’est ainsi que je pense que l’instruction ‘CALL’ fonctionne. Lorsqu’un programme ‘MAIN’ exécute le code, il s’exécute séquentiellement de la ligne 1 à la fin. Il s’exécute également sur chaque barre de zéro à la barre actuelle. Lorsque le fichier ‘CALL’ est appelé, il exécute son code de la ligne 1 à la fin, puis renvoie la ou les valeurs présentées sur la ligne ‘RETURN’.
La différence est que le fichier ‘CALL’ ne s’exécute que sur la barre sur laquelle il a été appelé.
Par conséquent, si le code du fichier ‘CALL’ nécessite de s’exécuter sur chaque barre pour effectuer son calcul, cela ne peut être fait que si vous utilisez une technique de retour en arrière et que vous parcourez les valeurs précédentes des constantes PRT comme ‘OHLC’, etc. Ensuite, une fois les données requises collectées, traitez-les pour obtenir le résultat souhaité pour ‘RETURN’.
Maintenant, comme si cela ne suffisait pas, chaque fois que vous « APPELEZ » le fichier, c’est une version différente. Donc, à la barre suivante, il doit recommencer tous les calculs à partir de zéro. Vous pouvez voir pourquoi mettre des valeurs numériques littérales sur la ligne ‘RETURN’ fonctionne. De plus, les variables de PRC ont une valeur de zéro par défaut, et dans votre code, les variables ne changeront que si les conditions ‘IF’ sont vraies.
De plus, les variables PRC ont une valeur de zéro par défaut et dans votre code, les variables ne changeront que si les conditions « IF » sont vraies.
De plus, « TIMEFRAME » et « UNITÉS » peuvent ajouter encore plus de complexité.
Actuellement, c’est comme ça que je le comprends.
06/03/2024 at 7:41 AM #23341406/05/2024 at 12:10 PM #233528 -
AuthorPosts
Find exclusive trading pro-tools on