Supposons que vous procédiez comme suit, légèrement modifié par rapport à l'index de script :
Names Default To Here( 1 );
dt = Open( "$SAMPLE_DATA/Semiconductor Capability.jmp" );
obj = dt << Process Screening( Grouping( :Site, :lot_id ), Process Variables( Eval( 5 :: 132 ) ), automaticrecalc(1) );
Vous obtiendrez un rapport comme celui-ci avec des lignes pour les différentes combinaisons de valeurs des colonnes Grouping() :
Et ces rangées servent de passerelle vers diverses intrigues.Par exemple, vous pouvez obtenir des cartes de capacité de processus ou de contrôle qui ressemblent à peu près à si vous aviez utilisé ces colonnes grouping() comme By() sur ces plates-formes.Mais vous n'obtiendrez pas de ligne pour un regroupement où l'une des valeurs de la colonne de regroupement était manquante ou, s'il s'agit d'un caractère, d'un espace.Donc, si vous remplacez une valeur lot_id par vide ou un SITE par manquant, vous ne voyez pas cela apparaître sur le rapport, vous ne savez donc pas qu'il y avait des données qui étaient comme ça, nécessitant peut-être une attention particulière.
Lorsque j'en ai discuté avec le support JMP, on m'a dit que cela était cohérent avec d'autres plates-formes JMP, par exemple le fait que les valeurs X vides n'apparaissent pas sur l'axe X d'un Oneway.Mais mon point de vue est que Grouping() ressemble beaucoup plus à By() dans ce cas (ce qui crée des tracés pour les groupes by avec des valeurs manquantes ou vides).La situation avec Grouping() est également similaire à summary/summarize qui reconnaîtrait ces groupes et produirait une ligne.
J'apprécie que Process Screening ait un By() et Grouping() n'est-ce pas, mais je pense qu'il serait utile d'afficher ces groupes et de donner accès aux mêmes tracés que vous verriez à partir d'un by() (c'est-à-dire si vous a exécuté Control Chart() avec un by() sur les mêmes colonnes, vous verriez un rapport pour un SITE manquant) :
Le résultat est que j'ai été encouragé à créer après tout un élément de ma liste de souhaits à ce sujet afin que cette perspective puisse être prise en compte.
Je pense que ce serait au moins une option intéressante.
Pourquoi cette idée est-elle importante ?
Le principal problème/valeur est de savoir comment le fait de partir de Process Screening comme passerelle vers les divers autres rapports vous permet de manquer certaines de vos données ou des problèmes dans vos données.Cela a attiré mon attention alors que je travaillais avec un client avec une grande quantité de données dans de nombreux groupements avec plusieurs niveaux par groupe et avec des données provenant de sources machines.Dans une certaine mesure, le filtrage des processus est censé vous permettre de passer au crible de nombreux processus. Il s'agit donc d'une situation dans laquelle la possibilité que certaines données soient défectueuses - et que cela puisse passer inaperçu - est accrue.Cette plateforme pourrait même aller jusqu’à mettre en avant de tels regroupements, et encore moins les inclure.
Je pense que la plupart des plates-formes de JMP devraient prendre en charge cela d'une manière ou d'une autre (pas seulement le filtrage des processus). Par exemple, Graph Builder le fait déjà, tout comme Neural Network lors de l'utilisation de JMP Pro.
Graph Builder a la possibilité de traiter les éléments manquants comme une catégorie distincte
Et Neural Network peut faire de même (avec JMP Pro)
Si ce paramètre par défaut est trop déroutant, il peut être caché derrière le maj+clic sur le triangle rouge, afin que personne ne le sache (comme afficher les lignes exclues dans le générateur de graphiques).
@hardner , @jthi , :pouces vers le haut:
J'ai le même souci avec la plateforme Process Screening. Je pensais que toutes les données étaient résumées dans notre ensemble complexe de variables BY et j'ai réalisé seulement plus tard que nous n'avions pas examiné et approuvé toutes les cartes de contrôle. J'espère que cela pourra être mis en œuvre. Nous le considérons comme une lacune dans le traitement du groupe BY qui est difficile à retenir et difficile à éviter.
Merci
