"N items ()" dovrebbe essere più robusto?<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />Spesso mi trovo a dover affrontare problemi negli script con "n items ()". E vedo spesso questo errore: "L'argomento N Items () deve essere una lista"
In uno script, a causa della robustezza dei miei dati, ciò che alimento con i nitem a volte può essere una matrice, un numero o un carattere. Aka: variabile = [5], variabile = 5; variabile = "05"; variabile = {5}; Per non andare troppo nei dettagli, sarebbe davvero bello in questo caso se "n items" fosse alimentato con un valore di carattere, ovvero, n elementi ("05"), ne sputerebbe 1, se avesse una matrice sarebbe sputa fuori i netti, ect.
La cosa positiva è che JSL non sarebbe mai riuscito a scovare se un dato di dati inappropriato gli fosse stato dato poiché avrebbe trasformato in modo soft i tuoi dati. Ciò ridurrebbe notevolmente la quantità di codice necessaria per rendere uno script affidabile per molti dati diversi. Il lato negativo è che potrebbe portare a una programmazione pigra che rende difficile trovare errori. Ciò potrebbe portare a problemi: ad esempio, alimentato una matrice e ricercati ncols, non nrows; o la tua stringa era "05, 05" che avresti dovuto analizzare prima, ecc.
Cosa pensa la comunità? Se "n items" fosse più robusto, sarebbe una benedizione o una maledizione?
Ri: dovrebbe "n items ()" essere più robusto?Mi piace la tua idea per la matrice. nrows (matrix) * ncols (matrix) sembra decisamente più utile del semplice ritorno di nrows o ncols.
Direi che restituire 3 per "a, b, c" sarebbe un cattivo rendimento poiché i valori potrebbero essere delimitati da qualsiasi cosa: spazio, underscore, due punti ("" "_" ";") per nominarne alcuni. Questo in realtà dovrebbe essere lasciato al programmatore per analizzare con words () o regex () prima di inviare a un nitem.
Inizialmente pensavo che 1 sarebbe stato il più appropriato dal momento che nel mio caso mi aspettavo un elenco di stringhe, ma se le istruzioni precedenti non restituivano un elenco, restituiva semplicemente la variabile come stringa, nel qual caso volevo 1. Tuttavia, ora che lo menzioni, i nitem potrebbero essere molto utili se restituissero la lunghezza della stringa e avessero diverse applicazioni.
Ri: dovrebbe "n items ()" essere più robusto?Sembra che nItems (matrice) possa essere più utile se restituisce nrows (matrice) * ncols (matrice).
Non sono sicuro di cosa mi aspetterei dai nitemi ("a, b, c") perché potrei creare un caso per 1, 3 o 5.
Ri: dovrebbe "n items ()" essere più robusto?Trovo che il supporto JMP tenda a seguire questi forum, e non ho fretta, in più sono d'accordo sul problema, quindi dubito che sarei il miglior candidato per richiedere questo cambiamento.
So solo che in JavaScript consentono le uguaglianze morbide. Ad esempio 5 == "5" restituirà true, con qualità hard denotate da 5 === "5" sarebbe false. Le morbide uguaglianze possono spesso portare a comportamenti strani e sono disapprovate da molti programmatori. Un sacco di persone hanno pregiudizio a usare sempre le dure uguaglianze, tuttavia, avere le uguaglianze morbide può davvero aiutare a rendere il codice robusto e se il programmatore sa cosa sta facendo può essere un risparmiatore di vita.
JSL è un linguaggio diverso, e mi sembra che la maggior parte degli sceneggiatori non abbia sfondi di programmazione. Quindi, consentire a un nitious robusto potrebbe essere dannoso per la lingua, ma allo stesso tempo, sarei in grado di farne un grande uso.
Ri: dovrebbe "n items ()" essere più robusto?Penso che il tuo suggerimento sia un buon suggerimento. E indipendentemente da ciò che la comunità nel suo insieme ritiene che il suggerimento debba essere inviato al gruppo di supporto di JMP. Solo loro possono influenzare il cambiamento.
E mi scuso per aver letto la tua discussione troppo velocemente e ho perso la tua richiesta di input da parte della community.
Ri: dovrebbe "n items ()" essere più robusto?Questo non risponde alla domanda.
Ri: dovrebbe "n items ()" essere più robusto?È possibile verificare se il valore è un elenco se la funzione "È Elenco". Pertanto, la distribuzione funzionerebbe per ridimensionatori, elenchi e matrici
x = uno scaler, matrice o lista
Se (è una lista (x)
count = 1
)
Ri: "n elementi ()" dovrebbe essere più robusto?Questo thread è piuttosto vecchio, ma ho pensato di affermare cosa è stato infine implementato in JMP 13 e versioni successive:
- NItems (matrice) ora restituisce il numero di elementi nella matrice (righe * colonne) anziché un errore.
- nitems ("cat") restituisce ancora un errore
- nitems ([1 2 3] | / [4 5 6]) == 6
