Discussions au sujet de NI LabVIEW
Cluster + dynamic event (je râle profondément !)
Résolu !
Je déclare un évent dynamique, avec comme "data" un cluster "glop" contenant : un string et un U32.
surprise !!!! 
l'event data node me donne accès aux éléments séparés du cluster .... mais pas ... au cluster dans sa totalité (all elements)
Je suis le premier à louer la magie de labVIEW (bien des fois) ... mais là, franchement, c'est à mon sens un "flop" de haut vol.
Comment cela est-il possible ???
alors que ma donnée déclarée est un cluster ... donner accès à son contenu, mais pas au cluster lui-même. (all elements)
Je râle 10E+7 !!!
J'étais en train de faire une manip pour simplifier mon code ... et c'est le cul-de-sac.
Je dois recomposer le cluster au départ de ses éléments ... ce qui au final ne me simplifie rien du tout.
Qu'en pensez-vous ? avez vous déjà rencontré le cas ?
contournement :
"entourer" le cluster "glop" d'un 2eme cluster .... le cluster glop devient alors "un élement interne"
ceci dit :
désolé, mais je persiste et signe ... ce "contournement" est du bricolage pour palier un "comportement-flop" évident.
@ Eric :
quelle virulence ....
oui, j'accepte 
.... hier soir , je l'avais trèèès mauvaise quand je me suis aperçu de "la chose".
tous les éléments ... si, j'ai besoin de tous les éléments ... je rentre mon cluster dans un sous-VIs qui a besoin de quasi tous les éléments (90%)
un "bundle" ce n'est pas si grave ... mon cluster contient 24 éléments, demutiplexer et re-multiplexer 24 éléments, c'est très moche.
c'est absurde de ne pas proposer "all elements".
c'était pour moi d'une telle évidence que j'en suis tombé de ma chaise !
J'ai proposé l'idée sur LVExchange ici ... si vous pensez comme moi, n'hésitez pas à promouvoir cette idée. (merci)
C'est pas plutôt avoir un cluster de 24 éléments qui est moche
et non ....
c'est le "bus" principal du moteur d'échecs, la colonne vertébrale de l'AI.
et de plus ... en mode "double" ... c'est à dire que je fais jouer ensemble deux versions différentes de l'AI
(ce qui me permet de mettre en évidence les modifications qui apportent une supériorité)
pour info ... histoire de comprendre ce "24".
1) les positions des pièces blanches
2) les positions des pièces noires
comme j'ai souvent besoin des positions des deux Rois et Reines,
par soucis de vitesse (pour ne pas devoir les extraires des positions globales à chaque fois)
je les mémorise séparément ... d'où ..
3) la position du Roi blanc
4) la position du Roi Noir
5) la position de la Reine blanche
6) la position de la reine Noire
7) la position du pion "en passant" (si il existe)
😎 la couleur dynamique (c'est à dire la couleur courante dans l'arbre de recherche)
9) la couleur de départ (c'est à dire la couleur qui joue)
10) Unlock
11) P_lock (Unlock et P_lock sont deux paramètres utilisés en cas d'oscillation entre 2 ou 3 positions)
12) Board (l'état courant de l'échiquier, un array 2D de U16)
13) FlipFlop (c'est un paramètre essentiel de l'algo "MinMax", c'est la référence de départ pour les comparaisons Min et Max))
14) StepMate (paramètre essentiel pour la mise en évidence d'un Mat)
15) error (un cluster d'erreur)
16) depth [0>(D-1)]
17) depth [(D-1)>0]
il s'agit de la profondeur dynamique d'analyse à laquelle se trouve le moteur.
Parfois j'ai besoin de la profondeur "montante", et parfois de la profondeur descendante
Je mémorise les deux pour ne pas devoir recalculer .....chaque millisec compte !
avec une profondeur de 5 et avec 5E+6 de noeuds à parcourir ... on voit la différence.
18) |>depth (c'est la profondeur statique, la profondeur d'analyse de départ)
19) DepthChoice (paramètre qui me permet à tout instant de modifier la profondeur ... paramètre de mise au point)
20) CinLight
21) CinDark
22) Cout
Ce sont les coefficients de travail pour les fonctions d'évaluation blanches et noires (comme je joue en double)
"Cout" permet de transmettre des résultats intermédiaires entre les différents niveaux d'analyse.
23) ALMD (un historique du dernier chemin parcourru dans l'arbre ... permet d'évaluer les gains/pertes en bout d'arbre)
24) LockMove (la position, si elle existe, qui provoque une oscillation)
Eric ... 
... ce n'est pas un chenillard que j'implémente, c'est un "vrai" moteur d'échecs ( ces 24 informations sont essentielles)
(je te taquine)
Si je pouvais faire avec "moins" ... je n'hésiterais pas.
De toute façon, qu'un clusteur contienne 3 infos ou 33, c'est la même chose ...
c'est juste un pointeur sur une structure ... et les fonctions Bundle et Unbundle sont rapides !!
Cela fait quasi un an que je bosse sur ce jeu d'échecs et cette approche du "bus global - colonne vertébrale" est celle qui me donne la plus grande vitesse de l'ensemble
voilou.
Je ne suis donc pas tombé en catalepsie hier à 01:45 pour rien ! 
ce n'est pas un bug, non, non .... mais un manquement qui nargue l'évidence élémentaire.
oui, oui .... si les développeurs R&D pouvaient (enfin) se pencher sur ce petit cancrelat ....
il y aurait plus d'un heureux !!!
6 ans que cela est demandé ... une chose comme celle là .... et rien à l'horizon ?
comprends pas !
ouadji a écrit :
Je ne suis donc pas tombé en catalepsie hier à 01:45 pour rien !
ce n'est pas un bug, non, non .... mais un manquement qui nargue l'évidence élémentaire.
oui, oui .... si les développeurs R&D pouvaient (enfin) se pencher sur ce petit cancrelat ....
il y aurait plus d'un heureux !!!
6 ans que cela est demandé ... une chose comme celle là .... et rien à l'horizon ?
comprends pas !
Pour comprendre, il faudrait faire partie des équipes NI qui définissent ce qui est à prendre en compte ou non
Sans doute ont-ils leurs raisons (non valables aux yeux de bien des utilisateurs, je te l'accorde 😉 )
A+
