"n items()" devrait-il être plus robuste ?Je me retrouve souvent confronté à des problèmes dans les scripts avec "n items()". Et je vois souvent cette erreur : "L'argument N Items() doit être une liste"
Dans un script, en raison de la robustesse de mes données, ce que j'introduis dans les éléments peut parfois être une matrice, un nombre ou un caractère. Autrement dit : variable = [5], variable = 5 ; variable = "05" ; variable ={5} ; Pour ne pas entrer trop dans les détails, ce serait vraiment bien dans ce cas si "n items" recevait une valeur de caractère, c'est-à-dire n items ("05"), il cracherait 1, s'il avait une matrice, ce serait cracher des grains, ect.
Le point positif est que JSL ne se déconnectera jamais si un élément de données inapproprié lui est transmis, car il apporterait une transformation douce à vos données. Cela réduirait considérablement la quantité de code nécessaire pour rendre un script robuste à de nombreuses données différentes. L’inconvénient est que cela pourrait conduire à une programmation paresseuse, rendant difficile la recherche d’erreurs. Cela pourrait entraîner des problèmes : par exemple, nourrir une matrice et rechercher des colonels, pas des nrows ; ou votre chaîne était "05, 05" que vous auriez dû analyser en premier, ect.
Qu’en pense la communauté ? Si « n objets » était plus robuste, serait-ce une bénédiction ou une malédiction ?
Re : « n items() » devrait-il être plus robuste ?Ce fil de discussion est plutôt ancien, mais j'ai pensé indiquer ce qui a finalement été implémenté dans JMP 13 et versions ultérieures :
- NItems( matrice ) renvoie désormais le nombre d'éléments dans la matrice ( rows * cols ) plutôt qu'une erreur.
- nitems("cat") renvoie toujours une erreur
- nitems([1 2 3] |/ [4 5 6]) == 6
Re : « n items() » devrait-il être plus robuste ?J'aime votre idée pour la matrice. nrows(matrix) * ncols(matrix) semble certainement que ce serait plus utile que de simplement renvoyer des nrows ou des ncols.
Je dirais que renvoyer 3 pour "a,b,c" serait un mauvais retour puisque les valeurs pourraient être délimitées par n'importe quoi : espace, trait de soulignement, deux points (" " "_" ";") pour n'en nommer que quelques-uns. Cela devrait vraiment être laissé au programmeur pour analyser avec un mots() ou une regex() avant de l'envoyer à un nitems.
Au départ, je pensais que 1 serait le plus approprié puisque dans mon cas, je m'attendais à une liste de chaînes, mais si les instructions précédentes ne renvoyaient pas de liste, elles renvoyaient simplement la variable sous forme de chaîne, auquel cas je voulais 1. Cependant, maintenant que vous le mentionnez, les nitems pourraient être très utiles s'ils renvoyaient la longueur de la chaîne et auraient des applications différentes.
Re : « n items() » devrait-il être plus robuste ?Il semble que nItems(matrix) pourrait être plus utile s'il renvoyait nrows(matrix) * ncols(matrix).
Je ne suis pas sûr de ce que j'attendrais des nitems("a,b,c") car je pourrais plaider en faveur de 1, 3 ou 5.
Re : « n items() » devrait-il être plus robuste ?Je trouve que le support JMP a tendance à suivre ces forums, et je ne suis pas pressé, et en plus je suis dans le flou sur la question, donc je doute d'être le meilleur candidat pour demander ce changement.
Je sais juste qu'en JavaScript, ils autorisent des égalités douces. Par exemple, 5 == "5" renverra vrai, avec des qualités dures e notées par 5 === "5" serait faux. Les égalités douces peuvent souvent conduire à des comportements étranges et sont mal vues par de nombreux programmeurs. Beaucoup de gens ont préjugé de toujours utiliser des égalités dures, cependant, avoir des égalités douces peut vraiment aider à rendre le code robuste et si le programmeur sait ce qu'il fait, il peut lui sauver la vie.
JSL est cependant un langage différent, et il me semble que la plupart des scénaristes n’ont pas de formation en programmation. Donc autoriser un nitem robuste pourrait être préjudiciable au langage, mais en même temps, je pourrais en faire un grand usage.
Re : « n items() » devrait-il être plus robuste ?Je pense que votre suggestion est une bonne suggestion. Et indépendamment de ce que pense la communauté dans son ensemble, la suggestion doit être envoyée au groupe de soutien de JMP. Eux seuls peuvent influer sur le changement.
Et je m'excuse d'avoir lu votre discussion trop rapidement et d'avoir manqué votre demande de contribution de la communauté.
Re : « n items() » devrait-il être plus robuste ?Cela ne répond pas à la question.
Re : « n items() » devrait-il être plus robuste ?Vous pouvez vérifier si la valeur est une liste si la fonction "Est une liste". Par conséquent, ce qui suit fonctionnerait pour les scalers, les listes et les matrices
x= un scaler, une matrice ou une liste
Si (est une liste (x)
compte = 1
)
