Sollte „n items()“ robuster sein?In Skripten mit „n items()“ stoße ich häufig auf Probleme. Und ich sehe oft diesen Fehler: „N Items()-Argument muss eine Liste sein“
In einem Skript kann es aufgrund der Robustheit meiner Daten manchmal sein, dass ich in nitems eine Matrix, eine Zahl oder ein Zeichen eingebe. Aka: Variable = [5], Variable = 5; Variable = "05"; Variable ={5}; Um nicht zu sehr ins Detail zu gehen, wäre es in diesem Fall wirklich schön, wenn „n items“ ein Zeichenwert zugeführt würde, d. h. n items („05“), würde 1 ausspucken, wenn es eine Matrix hätte Ausspucken usw.
Das Positive daran ist, dass es bei JSL niemals zu Fehlern kommen 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, die erforderlich ist, um ein Skript für viele verschiedene Daten robust zu machen, erheblich reduzieren. Der Nachteil ist, dass dies zu einer verzögerten Programmierung führen kann, die es schwierig macht, Fehler zu finden. Dies könnte zu Problemen führen: Beispielsweise wurde eine Matrix gefüttert und Ncols gesucht, keine Nrows; oder Ihre Zeichenfolge war „05, 05“, die Sie zuerst hätten analysieren sollen usw.
Was denkt die Community? Wenn „n items“ robuster wäre, wäre das ein Segen oder ein Fluch?
Betreff: Sollte „n items()“ robuster sein?Dieser Thread ist ziemlich alt, aber ich dachte, ich erzähle mal, was letztendlich in JMP 13 und höher implementiert wurde:
- NItems(matrix) gibt jetzt die Anzahl der Elemente in der Matrix (Zeilen * Spalten) statt eines Fehlers zurück.
- nitems("cat") gibt immer noch einen Fehler zurück
- nitems([1 2 3] |/ [4 5 6]) == 6
Betreff: Sollte „n items()“ robuster sein?Mir gefällt deine Idee für die Matrix. 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 Mögliche getrennt 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 analysieren, bevor es an nitems gesendet wird.
Anfangs dachte ich, 1 wäre am besten geeignet, da ich in meinem Fall eine Liste von Zeichenfolgen erwartet hatte. Wenn vorherige Anweisungen jedoch keine Liste zurückgegeben haben, wurde die Variable nur als Zeichenfolge zurückgegeben. In diesem Fall wollte ich 1. Aber jetzt das Sie erwähnen es, Nitems könnten 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, dass nItems(matrix) nützlicher sein könnte, wenn es nrows(matrix) * ncols(matrix) zurückgibt.
Ich bin mir nicht sicher, was ich von nitems("a,b,c") erwarten würde, da ich für 1, 3 oder 5 plädieren könnte.
Betreff: Sollte „n items()“ robuster sein?Ich stelle fest, dass der JMP-Support in der Regel diesen Foren folgt, und ich habe es nicht eilig, außerdem bin ich in dieser Frage noch unschlüssig, sodass ich bezweifle, dass ich der beste Kandidat wäre, um diese Änderung zu beantragen.
Ich weiß nur, dass sie in JavaScript weiche Gleichheiten zulassen. Zum Beispiel gibt 5 == „5“ „true“ zurück, wobei harte Eigenschaften, die mit 5 === „5“ bezeichnet werden, falsch wären. Weiche Gleichheiten können oft zu seltsamem Verhalten führen und werden von vielen Programmierern missbilligt. Viele Leute haben das Vorurteil, immer harte Gleichheiten zu verwenden. Weiche Gleichheiten können jedoch wirklich dazu beitragen, den Code robust zu machen, und wenn der Programmierer weiß, was er tut, können sie lebensrettend sein.
JSL ist jedoch eine andere Sprache und es scheint mir, dass die meisten Drehbuchautoren keinen Programmierhintergrund haben. Das Zulassen robuster Nitems könnte sich also nachteilig auf die Sprache auswirken, aber gleichzeitig könnte ich daraus einen großen Nutzen ziehen.
Betreff: Sollte „n items()“ robuster sein?Ich denke, Ihr Vorschlag ist ein guter Vorschlag. Und unabhängig davon, was die Community als Ganzes denkt, sollte der Vorschlag an die Selbsthilfegruppe bei JMP gesendet werden. Nur sie können die Veränderung beeinflussen.
Und ich entschuldige mich dafür, dass ich Ihre Diskussion zu schnell gelesen habe und Ihre Bitte um Community-Beitrag übersehen habe.
Betreff: Sollte „n items()“ robuster sein?Das beantwortet die Frage nicht.
Betreff: Sollte „n items()“ robuster sein?Mit der Funktion „Ist Liste“ können Sie prüfen, ob es sich bei dem Wert um eine Liste handelt. Daher würde Folgendes für Skalierer, Listen und Matrizen funktionieren
x= ein Skalierer, eine Matrix oder eine Liste
If(is list(x)
Anzahl=1
)
