Enregistrements du Scripters Club : trucs et astucesVidéo 1 @thickey1 : Gestion des tables de données.
- Modifier les noms des colonnes.
- Méthode alternative de référencement des noms de colonnes.
- Ajoutez/intégrez un script dans le tableau. Un utilisateur peut ensuite l'exécuter quand il le souhaite.
(Fichiers : Trucs et astuces et Sondage)
Vidéo 2 @Georg : Conseils généraux sur la façon d'écrire des scripts et d'utiliser JMP Script Editor
- pliage de code
- gestion des expressions
- JSL dans les formules
- eval (eval expr(un peu de code avec expr(à évaluer en premier)))
- test sur le type de variables
- tableau associatif
(Fichiers : 20241120_Scripters_Club_tipps_and_tricks-inspec)
Vidéo 3 @Mauro_Gerber : Ouvrir l'importation multiple et obtenir le chemin d'un script actuel
(Fichiers : SC-2024_ini et SC-2024_multi-import)
Vidéo 4 @Daniel_Valente : Présentation de JMP Marketplace
https://marketplace.jmp.com/
Je n'ai pas osé mettre Ndoubled à 10 : )
Mon rêve : un :folded_hands: rapide, dynamique et facile à utiliser est dans les spécifications (valeur)
Dans le cadre de l'idée de « rôtir notre code », avez-vous des idées pour améliorer la vitesse ?
Et comment rendre cette approche accessible à d’autres utilisateurs avec moins d’expérience JSL ?


Ré: Enregistrements du Scripters Club : trucs et astucescelui-ci est plus rapide - mais ne déclenche pas de mise à jour lorsque les spécifications sont ajustées.
Donc pour le moment : aucun bénéfice réel par rapport à
pour chaque (... dt[0,colname] = ...)
ou nouvelle colonne (définir les valeurs())
Names Default To Here( 1 );
Ndoubled = 10;
dynamic = 1;
Try( Close( cdt, NoSave ) );
cdt = Open( "$SAMPLE_DATA/Semiconductor Capability.jmp" );
Wait( 0 );
bigger = Expr(
cdt = cdt << concatenate( cdt, append to first table( 1 ) )
);
For( I = 1, i <= Ndoubled, i++, bigger );
col_lst = cdt << get column group( "Processes" );
Wait( 0 );
cdt << New Table Variable( "trigger update", 1 ); // can this be used to force an update?
cdt << begin data update();
t0 = HP Time();
If( dynamic,
col_lst = cdt << get column group( "Processes" );
For Each( {col}, col_lst,
col_Name = col << get name() || "_inSpecDynamic";
colnew = New Column( col_Name, Nominal );
col_Name = colnew << get name();
Eval(
Substitute(
Expr(
Column( col_Name ) << set Formula(
Local(
{t0 = As Constant(
dt = Current Data Table();
limits = _col_ << get property( "Spec Limits" );
nr = nrows(dt);
usl = limits["USL"];
lsl = limits["LSL"];
myRows = Where( _col_ > lsl & _col_ < usl );
NmyRows = N Items( myRows );
dt[0, _col_Name_] = J( nr, 1, 0 );
If( NmyRows,
dt[myRows, _col_Name_] = J( NmyRows, 1, 1 )
);
1
)},
Stop();
)
)
),
Expr( _col_ ), Name Expr( col ), Expr(_col_name_), col_name
)
);
cdt << move selected columns( {Column( col_name )}, after( col ) );
);
);
cdt << run formulas() << end data update();
Show( (HP Time() - t0) / 1000000 );
Wait( 0 );
Caption( "Process screening - don't dare ..." );
Stop();
// TEST THE RESULT
// check result in table visually
ps = cdt << Process Screening( Process Variables( Eval( col_lst ) ), Spec Limits Dialog( "No (skip columns with no spec limits)" ) );
ps << Color Out Of Spec Values( 1 );
ps << Close Window;
cdt << Clear Select << Clear Column Selection;
Ré: Enregistrements du Scripters Club : trucs et astucesDer @hogi , merci d'avoir examiné le code et l'implémentation supplémentaire. Pour la présentation, je n'ai pas trop étudié la vitesse, etc., mon objectif était de montrer différentes manières et approches. Dans la vie réelle, la meilleure implémentation dépend de vos conditions limites, donc c'est spécifique au cas par cas, comme je le pense.
Si vous regardez le déroulement du programme, il n'est peut-être pas idéal d'extraire les limites de spécification de chaque ligne en utilisant l'approche par formule, mais dans certains cas, cela peut être utile. Cependant, JMP peut améliorer en interne le programme au moment de l'exécution en évitant les calculs inutiles. Il m'est impossible de connaître tous ces détails, mais c'est pourquoi nous devons essayer différentes approches.
En général, lorsque la vitesse entre en jeu, j'utiliserais les options de la plate-forme, par exemple via les couleurs dans le processus de filtrage, car je suppose qu'elles sont optimisées pour les données volumineuses.
Peut-être que nous pourrons y réfléchir à nouveau pendant la série de tests. Et oui, encore une fois, je pense que in_spec serait une fonction intégrée très intéressante. Seule la mise en œuvre peut devenir difficile lorsqu'on prend en compte tous les détails - j'espère que les développeurs trouveront une bonne solution.
Ré: Enregistrements du Scripters Club : trucs et astucesPour comparer les performances avec celles de la plateforme officielle, veuillez supprimer ou commenter le stop().
Ré: Enregistrements du Scripters Club : trucs et astucesUne chose à retenir concernant les limites de spécifications est que les spécifications sont unilatérales. Elles peuvent causer toutes sortes de problèmes amusants
Ré: Enregistrements du Scripters Club : trucs et astucesOui, c'est vrai.
Par souci de simplicité, je pense qu'il est acceptable d'utiliser des spécifications à deux faces.
La comptabilisation des spécifications unilatérales (ou des colonnes sans aucune spécification) est assez simple - mais il ne faut en effet pas l'oublier.
Avez-vous une astuce pour accélérer le calcul - et le rendre dynamique ?
Ré: Enregistrements du Scripters Club : trucs et astucesCela dépend probablement beaucoup du problème à résoudre (la solution dépend donc beaucoup du cas d'utilisation).
Ré: Enregistrements du Scripters Club : trucs et astucescas d'utilisation :
une nouvelle colonne avec une formule pour générer des valeurs 0/1 pour les valeurs hors spécifications/conformes aux spécifications.
S'il y a une faute de frappe dans les spécifications, ou si l'utilisateur souhaite ajuster les spécifications, les valeurs de la colonne doivent être automatiquement mises à jour (elles ne doivent pas rester bloquées avec les anciens paramètres).
peut-être pour 10 à 30 colonnes.
100 000 - 10 millions de lignes.
Une solution qui peut être facilement partagée avec de nouveaux collègues qui souhaitent utiliser JMP pour analyser les informations de réussite/échec.
Ré: Enregistrements du Scripters Club : trucs et astucesCela pourrait être un peu hors sujet :
Il vous manque quelques spécifications (?) (je me considère comme un professionnel de la résolution de problèmes XY et je ne pense pas vraiment que vous souhaitiez en être un) :
- Entrée : juste un tableau de données
- Utiliser TOUTES les colonnes pour lesquelles des limites de spécifications sont définies ?
- Mais gardez à l’esprit que ceux-ci peuvent être mal réglés (un problème beaucoup plus grave à mon avis)
- À quel point est-ce incorrect ? Pouvons-nous avoir des valeurs manquantes sur les deux ? Les mêmes valeurs sur les deux, même si nous avons une mesure continue ? Ou simplement des valeurs « boguées » (vous pouviez avoir des valeurs « non évaluées » comme limites de spécification dans JMP qui s'affichaient toujours comme les valeurs numériques correctes. Je ne sais pas si c'est toujours le cas avec JMP18).
- Un cas distinct est celui où l'utilisateur peut vouloir les ajuster (je considérerais ce cas d'utilisation différent de celui d'une colonne unique avec 0/1)
- Quel est le cas d'utilisation ? Je suis presque sûr que les utilisateurs n'analyseront pas visuellement 30 colonnes et 10 millions de cellules à partir d'un tableau
- Comment utilisent-ils les résultats ? Le calcul pourrait-il être mis en œuvre là-bas ? -> Disposez-vous d'une plateforme personnalisée pour ce type de travail ?
Si je devais « résoudre un problème » dans ce cas, je commencerais d'abord par résoudre les limites de spécification incorrectes, ou peut-être plutôt la situation où elles sont modifiées. Qu'essayez-vous vraiment de voir ? Je doute vraiment que ce soit le cas pour avoir une colonne avec 0/1 basée sur les limites de spécification lorsque vous avez 10 millions de lignes de données.
Vous pourriez (ou je pourrais) créer une fonctionnalité pour créer une telle colonne (je ne sais pas à quelle vitesse vous pourriez le faire) mais est-ce vraiment la solution au problème ? Si vous voulez simplement avoir une colonne 0/1 basée sur les limites de spécifications actuelles pour TOUTES les colonnes, je ne pense pas qu'elle doive être dynamique (mise à jour immédiate). L'utilisateur peut appuyer sur un seul bouton dans le menu pour mettre à jour les résultats (je pense à un module complémentaire qui utilise des noms de colonnes spécifiques ou peut-être des variables de table). Si le but est d'ajuster les spécifications, il n'y a aucune valeur (à mon avis) à voir 0 passer à 1 lorsque vous avez 10 lignes (créez une plate-forme spéciale pour ce cas d'utilisation JUSTE, si rien d'autre et que vous ne vous souciez "que" de la vitesse, ce sera probablement plus rapide).
Ou est-ce juste une question théorique : comment faire cela rapidement ?
Ré: Enregistrements du Scripters Club : trucs et astucesSalut Jarmo, merci pour vos commentaires.
Vous avez raison, avec l'aide d'un simple "cliquez ici pour mettre à jour", tous les problèmes disparaissent.
Mais, pour être honnête, j'adore l'approche « Graph Builder : il suffit de le configurer et JMP s'occupera des détails ».
Il n'est pas nécessaire de discuter/implémenter les détails via la communauté (il est clair comment étendre une formule de telle sorte qu'elle fonctionne également pour les spécifications unilatérales). Ici, je préfère même un code court qui montre le concept.
En plus de cela, il n'y a pas lieu de douter qu'un :folded_hands: rapide, dynamique et convivial soit dans les spécifications (valeur) et sera utilisé pour quelque chose d'utile.
Donc, jusqu'à ce que :folded_hands: soit dans la spécification (valeur) est disponible - Si quelqu'un a une meilleure solution, comment la configurer manuellement, je serai extrêmement heureux et l'utiliserai immédiatement. Ce n'est pas une question théorique:)