Est-ce que "n items()" devrait être plus robuste ?<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />Je me retrouve souvent à rencontrer des problèmes dans les scripts avec "n éléments ()".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'alimente en nitems peut parfois être une matrice, un nombre ou un caractère. Aka : variable = [5], variable = 5 ; variable = "05" ; variables={5} ; Pour ne pas entrer trop dans les détails, ce serait vraiment bien dans ce cas si "n éléments" recevait une valeur de caractère, alias, n éléments ("05"), il cracherait 1, s'il avait une matrice, il le ferait cracher nrows, ect.
Le point positif est que JSL ne boguerait jamais si un élément de données inapproprié lui était transmis, car cela entraînerait une transformation douce de 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, ce qui rend difficile la recherche d'erreurs.Cela pourrait conduire à des problèmes : par exemple, alimenter une matrice et vouloir ncols, pas nrows ; ou votre chaîne était "05, 05" que vous auriez dû analyser en premier, etc.
Qu'en pense la communauté ?Si "n éléments" était plus robuste, serait-ce une bénédiction ou une malédiction ?
Re : "n éléments ()" devrait-il être plus robuste ?Ce fil est plutôt ancien, mais j'ai pensé indiquer ce qui a finalement été implémenté dans JMP 13 et versions ultérieures :
- NItems( matrix ) 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 éléments ()" devrait-il être plus robuste ?J'aime votre idée pour la matrice.nrows(matrix) * ncols(matrix) semble définitivement plus utile que de simplement renvoyer nrows ou ncols.
Je dirais que retourner 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 regex() avant de l'envoyer à un nitems.
J'ai d'abord pensé que 1 serait le plus approprié car dans mon cas, j'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, nitems pourrait être très utile s'il renvoyait la longueur de la chaîne et aurait des applications différentes.
Re : "n éléments ()" devrait-il être plus robuste ?Il semble que nItems(matrix) pourrait être plus utile s'il renvoyait nrows(matrix) * ncols(matrix).
Je ne sais pas ce que j'attendrais de nitems("a,b,c") car je pourrais plaider pour 1, 3 ou 5.
Re : "n éléments ()" devrait-il être plus robuste ?Je trouve que le support JMP a tendance à suivre ces forums, et je ne suis pas pressé, en plus je suis sur la clôture sur la question, donc je doute que je sois le meilleur candidat pour demander ce changement.
Je sais juste qu'en JavaScript, ils autorisent les égalités douces. Par exemple 5 == "5" renverra vrai, avec des qualités dures notées par 5 === "5" serait faux.Les égalités douces peuvent souvent conduire à un comportement étrange et sont mal vues par de nombreux programmeurs.Beaucoup de gens ont le 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, cela 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 nitems robuste pourrait être préjudiciable à la langue, mais en même temps, je serais capable d'en faire bon usage.
Re : "n éléments ()" devrait-il être plus robuste ?Je pense que votre suggestion est une bonne suggestion.Et quelle que soit l'opinion de 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 raté votre demande de contribution de la communauté.
Re : "n éléments ()" devrait-il être plus robuste ?Cela ne répond pas à la question.
Re : Est-ce que "n items()" devrait ê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 échelles, les listes et les matrices
x= un scaler, une matrice ou une liste
Si(est une liste(x)
compte=1
)
