¿Deberían "n elementos()" ser más robustos?A menudo me encuentro con problemas en scripts con "n elementos()". Y a menudo veo este error: "El argumento N Elementos() debe ser una lista"
En un script, debido a la solidez de mis datos, lo que introduzco en nitems a veces puede ser una matriz, un número o un carácter. También conocido como: variable = [5], variable = 5; variables = "05"; variable={5}; Sin entrar demasiado en detalles, sería muy bueno en este caso si a "n elementos" se les alimentara con un valor de carácter, también conocido como n elementos ("05"), escupiría 1, si obtuviera una matriz, lo haría. escupir nrows, etc.
Lo positivo es que JSL nunca fallaría si se le proporcionara un elemento de datos inapropiado, ya que realizaría una transformación suave en sus datos. Esto reduciría en gran medida la cantidad de código necesario para hacer que un script sea robusto para muchos datos diferentes. La desventaja es que podría generar una programación perezosa, lo que dificultaría la búsqueda de errores. Esto podría generar problemas: por ejemplo, alimentar una matriz y querer ncols, no nrows; o su cadena era "05, 05", que debería haber analizado primero, etc.
¿Qué piensa la comunidad? Si "n elementos" fuera más robusto, ¿sería una bendición o una maldición?
Re: ¿Deberían ser más robustos "n elementos()"?Este hilo es bastante antiguo, pero pensé en indicar lo que finalmente se implementó en JMP 13 y versiones posteriores:
- NItems(matriz) ahora devuelve el número de elementos de la matriz (filas * columnas) en lugar de un error.
- nitems("cat") todavía devuelve un error
- nitems([1 2 3] |/ [4 5 6]) == 6
Re: ¿Deberían ser más robustos "n elementos()"?Me gusta tu idea para la matriz. nrows(matrix) * ncols(matrix) definitivamente parece que sería más útil que simplemente devolver nrows o ncols.
Yo diría que devolver 3 para "a,b,c" sería un resultado pobre ya que los valores podrían delimitarse por cualquier cosa: espacio, guión bajo, dos puntos (" " "_" ";") por nombrar algunos. Esto realmente debería dejarse en manos del programador para que lo analice con palabras() o expresiones regulares() antes de enviarlo a nitems.
Inicialmente pensé que 1 sería lo más apropiado ya que en mi caso esperaba una lista de cadenas, pero si las declaraciones anteriores no devolvían una lista, simplemente devolvía la variable como una cadena, en cuyo caso quería 1. Sin embargo, ahora que Lo mencionas, nitems podría ser muy útil si devolviera la longitud de la cadena y tendría diferentes aplicaciones.
Re: ¿Deberían "n elementos()" ser más robustos?Parece que nItems(matrix) podría ser más útil si devolviera nrows(matrix) * ncols(matrix).
No estoy seguro de qué esperaría de nitems("a,b,c") porque podría defender 1, 3 o 5.
Re: ¿Deberían ser más robustos "n elementos()"?Encuentro que el soporte de JMP tiende a seguir estos foros, y no tengo prisa, además estoy indeciso sobre el tema, por lo que dudo que sea el mejor candidato para solicitar este cambio.
Solo sé que en JavaScript permiten igualdades suaves. Por ejemplo, 5 == "5" devolverá verdadero, y las cualidades duras e indicadas por 5 === "5" serían falsas. Las igualdades suaves a menudo pueden conducir a comportamientos extraños y muchos programadores las desaprueban. Mucha gente tiene el prejuicio de usar siempre igualdades estrictas; sin embargo, tener igualdades suaves realmente puede ayudar a que el código sea robusto y, si el programador sabe lo que está haciendo, puede salvarle la vida.
Sin embargo, JSL es un lenguaje diferente y me parece que la mayoría de los guionistas no tienen experiencia en programación. Por lo tanto, permitir un nitems robusto podría ser perjudicial para el lenguaje, pero al mismo tiempo, podría hacer un gran uso de él.
Re: ¿Deberían ser más robustos "n elementos()"?Creo que tu sugerencia es una buena sugerencia. E independientemente de lo que piense la comunidad en su conjunto, la sugerencia debe enviarse al grupo de apoyo de JMP. Sólo ellos pueden afectar el cambio.
Y me disculpo por leer su discusión demasiado rápido y pasar por alto su solicitud de aportes de la comunidad.
Re: ¿Deberían ser más robustos "n elementos()"?Eso no responde a la pregunta.
Re: ¿Deberían ser más robustos "n elementos()"?Puede verificar si el valor es una lista si la función "Es lista". Por lo tanto, lo siguiente funcionaría para escaladores, listas y matrices.
x= un escalador, matriz o lista
Si(es lista(x)
contar=1
)
