Sollte "n items()" robuster sein?<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />Ich stoße oft auf Probleme in Skripten mit "n items()".Und ich sehe oft diesen Fehler: "N Items() argument must be a list"
In einem Skript kann das, was ich in Nitems einfüge, aufgrund der Robustheit meiner Daten manchmal eine Matrix, eine Zahl oder ein Zeichen sein. Auch bekannt als: Variable = [5], Variable = 5; Variable = "05"; Variable = {5}; Um nicht zu sehr ins Detail zu gehen, es wäre in diesem Fall wirklich schön, wenn "n items" mit einem Zeichenwert gefüttert würde, aka, n items ("05"), es würde 1 ausspucken, wenn es eine Matrix hätte nrows ausspucken, ect.
Das Positive ist, dass JSL niemals einen Fehler verursachen würde, wenn ihm ein ungeeignetes Datenelement zugeführt würde, da es eine sanfte Transformation Ihrer Daten vornehmen würde.Dies würde die Menge an Code erheblich reduzieren, die erforderlich ist, um ein Skript für viele verschiedene Daten robust zu machen.Der Nachteil ist, dass es zu einer faulen Programmierung führen kann, die es schwierig macht, Fehler zu finden.Dies könnte zu Problemen führen: zum Beispiel eine Matrix gefüttert und Ncols gesucht, nicht Nrows; oder Ihre Zeichenfolge war "05, 05", die Sie zuerst analysiert haben sollten, ect.
Was denkt die Gemeinde?Wenn "n Items" robuster wäre, wäre es ein Segen oder ein Fluch?
Betreff: Sollte "n items()" robuster sein?Dieser Thread ist ziemlich alt, aber ich dachte, ich würde sagen, was letztendlich in JMP 13 und höher implementiert wurde:
- NItems( matrix ) gibt jetzt die Anzahl der Elemente in der Matrix ( rows * cols ) anstelle eines Fehlers zurück.
- nitems("cat") gibt immer noch einen Fehler zurück
- Punkte([1 2 3] |/ [4 5 6]) == 6
Betreff: Sollte "n items()" robuster sein?Deine Idee mit der Matrix gefällt mir.nrows(matrix) * ncols(matrix) scheint definitiv nützlicher zu sein, als nur nrows oder ncols zurückzugeben.
Ich würde argumentieren, dass die Rückgabe von 3 für "a,b,c" eine schlechte Rückgabe wäre, da die Werte durch alles begrenzt werden könnten: Leerzeichen, Unterstrich, Doppelpunkt (" " "_" ";"), um nur einige zu nennen.Dies sollte wirklich dem Programmierer überlassen werden, um es mit words() oder regex() zu parsen, bevor es an ein nitems gesendet wird.
Anfangs dachte ich, 1 wäre am besten geeignet, da ich in meinem Fall eine Liste von Zeichenfolgen erwartete, aber wenn vorherige Anweisungen keine Liste zurückgaben, gab es nur die Variable als Zeichenfolge zurück, in diesem Fall wollte ich 1. Aber jetzt das Sie erwähnen es, Nitems könnte sehr nützlich sein, wenn es die Länge der Zeichenfolge zurückgibt und verschiedene Anwendungen hätte.
Betreff: Sollte "n items()" robuster sein?Es scheint, als könnte nItems(matrix) nützlicher sein, wenn es nrows(matrix) * ncols(matrix) zurückgibt.
Ich bin mir nicht sicher, was ich von nitems("a,b,c") erwarten würde, weil ich für 1, 3 oder 5 plädieren könnte.
Betreff: Sollte "n items()" robuster sein?Ich finde, dass der JMP-Support dazu neigt, diesen Foren zu folgen, und ich habe es nicht eilig, außerdem bin ich in der Angelegenheit unschlüssig, also bezweifle ich, dass ich der beste Kandidat wäre, um diese Änderung zu beantragen.
Ich weiß nur, dass sie in JavaScript weiche Gleichheiten zulassen. Zum Beispiel 5 == "5" wird wahr zurückgeben, mit harten e-Qualitäten, die mit 5 === "5" bezeichnet werden, wäre falsch.Weiche Gleichheiten können oft zu seltsamem Verhalten führen und werden von vielen Programmierern verpönt.Viele Leute haben Vorurteile, immer harte Gleichheiten zu verwenden, aber weiche Gleichheiten können wirklich dazu beitragen, Code robust zu machen, und wenn der Programmierer weiß, was er tut, können sie Lebensretter sein.
JSL ist jedoch eine andere Sprache, und es scheint mir, dass die meisten Drehbuchautoren keinen Programmierhintergrund haben.Das Zulassen eines robusten Nitems könnte sich also nachteilig auf die Sprache auswirken, aber gleichzeitig wäre ich in der Lage, großen Nutzen daraus zu ziehen.
Betreff: Sollte "n items()" robuster sein?Ich finde deinen Vorschlag gut.Und unabhängig davon, was die Community als Ganzes denkt, sollte der Vorschlag an die Support-Gruppe von JMP gesendet werden.Nur sie können die Veränderung beeinflussen.
Und ich entschuldige mich dafür, dass ich Ihre Diskussion zu schnell gelesen und Ihre Bitte um Community-Beitrag verpasst habe.
Betreff: Sollte "n items()" robuster sein?Das beantwortet die Frage nicht.
Betreff: Sollte "n items()" robuster sein?Sie können überprüfen, ob der Wert eine Liste ist, wenn Sie die Funktion „Ist Liste“ verwenden. Daher würde das Folgende für Skalierer, Listen und Matrizen funktionieren
x= ein Scaler, eine Matrix oder eine Liste
Wenn(ist Liste(x)
Anzahl = 1
)
