Suggestion : exporter des Variables ciblées

• 06/24/2019 at 7:42 PM #101342
  RicLg

  Bonjour,
  Je souhaiterai émettre une suggestion.
  Configuration v10.3 , end of day.

  Voici un scenario EXTREME pour la démonstration.
  1- Une procédure principale sous Probuiler (10 000 lignes de codes)
  2- RETURN comporte 66 variables_calculées (de mémoire le max est 66, à confirmer)
  3 – XYZ variables_calculées du RETURN sont requises pour la mise en place d’un Sreenner ou pour une autre procédure.

  Création de la procédure du  Screener
  igonored, ignored, var1PourScreener , ignored, ignored(33)……ignored(54)….ignored,….. var2PourScreener, ignored…….ignored(66)= Call “Proc_Principale”.

  Au mieux on pourrait ecrire ,( en modifiant le return de la procédure principale )
  var1PourScreener, var2PourScreener, var3PourScreener, var4PourScreener, ignored, , ignored, ignored, ….. ignored, ignored……ignored(66)= Call “Proc_Principale”.

  Si j’ai tord sur la syntaxe ou s’il existe un autre manière d’obtenir les variablesPourscreener de manière plus simple, je suis tout ouie ;-).

  La proposition serait qu’il existe une fonction ExportVar ( “Fichier_VarExport”, var1Export, var2Export,var3Export, etc.. )
  Parcequ’avec cette possibilité
  – le Call “Proc_Principale” n’est plus requis (rappel 10 000 lignes de code pour la démonstration)
  – Le Call “Fichier_VarExport” contient seulement les Data que l’on souhaite exploitées, et ce sans aucun calcul.

  Merci de votre attention.

  Bien à Vous

  

  RicLg

  Participant

  Topics: 27

  Replies: 68

  Been thanked: 9 times
  06/25/2019 at 8:02 AM #101365
  Nicolas

  C’est une bonne idée, on en revient cependant toujours au même problème d’impossibilité d’export / import. Si on pouvait débrider ce type de fonctionnalité, il y aurait bien d’autres possibilités 🙂

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20863

  Been thanked: 4773 times
  06/25/2019 at 10:08 AM #101380
  RicLg

  Merci Nicolas pour le retour.

  Quelle serait la solution la “plus éfficace” dans cette situation extrême pour un Screener?

  1° Reprendre la totalité du code “Proc_Principale” dans le Screener?

  2° Faire un CALL “Proc_Principale” dans le Screener?

   

  

  RicLg

  Participant

  Topics: 27

  Replies: 68

  Been thanked: 9 times
  06/25/2019 at 11:51 AM #101383
  Nicolas

  10.000 lignes c’est énorme, mais possible en effet. Je me souviens avoir heurté une barrière sur une quantité de lignes trop importante dans un screener récemment, et j’étais bien en deçà (me souvient plus exactement). Enfin, c’est la conclusion que j’en ai eu, puisque le simple fait de supprimer quelques lignes de l’indicateur CALLé permettait au screener de fonctionner, alors qu’il ne voulait rien entendre si je le laisser tel quel. Bref.

  Dans je ne sais pas au final, c’est un cas extrême qu’il faudrait essayer !

  Pour mémoire, ProScreener est un moteur séparé et le plus ancien actuellement de la plateforme. Il est prévu de le refaire/améliorer, mais ça n’est pas dans la première chose à faire dans l’ordre des priorités 🙂 Il y a en effet encore beaucoup de belles choses à venir dans le courant 2020, quand la v11 sera déployé pour tout le monde.

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20863

  Been thanked: 4773 times
  06/25/2019 at 3:07 PM #101395
  RicLg

  Le choix d’indiquer  10 000 lignes  est de souligner le “poids” de la procédure et l’impact sur un Call. Je n’ai pas codé ces 10000 lignes  🙂

  Je souhaite choisir l’option consommant le moins de ressource possible, ou l’exécution la plus rapide pour ProScreener.

  Selon tes dires , je dois créer/réadapter les codes pour ProScreener , impliquant des calculs en “doublon” avec les codes de  la procédure principale.

  Merci Nicolas

   

  

  RicLg

  Participant

  Topics: 27

  Replies: 68

  Been thanked: 9 times
• Author
  Posts