Apple de fonction CALL, pour 14 varaibles

Forums ProRealTime forum Français Support plateforme ProRealTime Apple de fonction CALL, pour 14 varaibles

Viewing 9 posts - 1 through 9 (of 9 total)
  • #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 ?

     

    #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

     

    #233341

    En 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…

    #233345

    Au 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)

    #233409

    Bonjour,

    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é:

    et la FONCTION DETECTpivots (je n’ai pas trouvé comment exporté le code dans un fichier, désolé…)

     

     

    #233410

    Ok, 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.

    #233411

    C’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.

    #233414

    Bonjour JC, boujour Druby,

    Merci pour ces informations fort utiles pour la résolution et la compréhension.

     

    #233528

    Bonjour, mon sujet n’est pas encore résolu, mais vos informations sont précieuses, je vous tiens informé.

Viewing 9 posts - 1 through 9 (of 9 total)

Create your free account now and post your request to benefit from the help of the community
Register or Login