"n items()" dovrebbe essere più robusto?Spesso mi ritrovo a riscontrare problemi negli script con "n elementi()". E spesso vedo questo errore: "L'argomento N Items() deve essere una lista"
In uno script, a causa della robustezza dei miei dati, ciò che inserisco nei nitem a volte può essere una matrice, un numero o un carattere. Ossia: variabile = [5], variabile = 5; variabile = "05"; variabile ={5}; Per non entrare troppo nei dettagli, sarebbe davvero carino in questo caso se a "n elementi" venisse dato un valore di carattere, ovvero n elementi ("05"), sputerebbe 1, se avesse una matrice lo farebbe sputare righe, ecc.
L'aspetto positivo è che JSL non si bloccherebbe mai se gli venisse fornito un elemento di dati inappropriato poiché effettuerebbe una trasformazione graduale dei tuoi dati. Ciò ridurrebbe notevolmente la quantità di codice necessaria per rendere uno script robusto per molti dati diversi. Lo svantaggio è che potrebbe portare a una programmazione pigra, rendendo difficile trovare errori. Ciò potrebbe portare a problemi: ad esempio, alimentare una matrice e volere ncols, non nrows; oppure la tua stringa era "05, 05" che avresti dovuto analizzare prima, ecc.
Cosa ne pensa la comunità? Se "n elementi" fosse più robusto, sarebbe una benedizione o una maledizione?
Ri: "n items()" dovrebbe essere più robusto?Questo thread è piuttosto vecchio, ma ho pensato di indicare cosa è stato infine implementato in JMP 13 e versioni successive:
- NItems(matrix) ora restituisce il numero di elementi nella matrice (righe * cols) anziché un errore.
- nitems("cat") restituisce ancora un errore
- nitems([1 2 3] |/ [4 5 6]) == 6
Ri: "n items()" dovrebbe essere più robusto?Mi piace la tua idea per la matrice. nrows(matrix) * ncols(matrix) sembra decisamente più utile che restituire semplicemente nrows o ncols.
Direi che restituire 3 per "a,b,c" sarebbe un rendimento scarso poiché i valori potrebbero essere delimitati da qualsiasi cosa: spazio, carattere di sottolineatura, due punti (" " "_" ";") per citarne alcuni. Questo in realtà dovrebbe essere lasciato al programmatore da analizzare con word() o regex() prima di inviarlo a un nitems.
Inizialmente pensavo che 1 sarebbe stato più appropriato poiché nel mio caso mi aspettavo un elenco di stringhe, ma se le istruzioni precedenti non restituivano un elenco restituivano semplicemente la variabile come stringa, nel qual caso volevo 1. Tuttavia, ora che se lo dici, nitems potrebbe essere molto utile se restituisse la lunghezza della stringa e avrebbe diverse applicazioni.
Ri: "n items()" dovrebbe essere più robusto?Sembra che nItems(matrix) potrebbe essere più utile se restituisse nrows(matrix) * ncols(matrix).
Non sono sicuro di cosa mi aspetterei da nitems("a,b,c") perché potrei sostenere il caso 1, 3 o 5.
Ri: "n items()" dovrebbe essere più robusto?Trovo che il supporto di JMP tenda a seguire questi forum e non ho fretta, inoltre sono indeciso sulla questione, quindi dubito che sarei il miglior candidato per richiedere questa modifica.
So solo che in JavaScript consentono uguaglianze morbide. Ad esempio 5 == "5" restituirà vero, con le qualità e dure indicate da 5 === "5" sarebbe falso. Le uguaglianze soft possono spesso portare a comportamenti strani e sono disapprovate da molti programmatori. Molte persone hanno il pregiudizio di utilizzare sempre uguaglianze rigide, tuttavia, avere uguaglianze morbide può davvero aiutare a rendere il codice robusto e se il programmatore sa cosa sta facendo può essere salvavita.
JSL però è un linguaggio diverso e mi sembra che la maggior parte degli sceneggiatori non abbia esperienza di programmazione. Quindi consentire un nitem robusto potrebbe essere dannoso per la lingua, ma allo stesso tempo sarei in grado di farne un grande uso.
Ri: "n items()" dovrebbe essere più robusto?Penso che il tuo suggerimento sia un buon suggerimento. E indipendentemente da ciò che pensa la comunità nel suo complesso, il suggerimento dovrebbe 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 per aver mancato la tua richiesta di contributo alla community.
Ri: "n items()" dovrebbe essere più robusto?Questo non risponde alla domanda.
Ri: "n items()" dovrebbe essere più robusto?Puoi verificare se il valore è un elenco se la funzione "È elenco". Pertanto, quanto segue funzionerebbe per scaler, liste e matrici
x= uno scaler, una matrice o una lista
Se(è lista(x)
contare=1
)
