Should "n items()" be more robust?

[#1]

I often find myself running into issues in scripts with "n items()".  And I often see this error: "N Items() argument must be a list"

In one script, due to the robustness of my data, what I feed into nitems can sometimes be a matrix, number, or character. Aka: variable = [5], variable = 5; variable = "05"; variable ={5};  Not to go too much into detail, it would be really nice in this case if "n items" was fed a character value, aka, n items("05"), it would spit out 1, if it got a matrix it would spit out nrows, ect.

The positive is that JSL would never bug out if an inappropriate data item was fed to it since it would make a soft transformation to your data.  This would greatly reduce the amount of code needed to make a script robust to lots of different data.  The down side is it could lead to lazy programming making it hard to find mistakes.  This could lead to problems: for example, fed a matrix and wanted ncols, not nrows; or your string was "05, 05" which you should have parsed first, ect.

What does the community think?  If "n items" was more robust, would it be a blessing or a curse?

[#2]

You can check to see if the value is a list if the "Is List" function. Therefore, the folloing would work for scalers, lists and matrices

x= a scaler, matrix or list

If(is list(x)

  count=1

)

[#3]

That doesn't answer the question.

[#4]

I think your suggestion is a good suggestion.  And regardless of what the community as a whole thinks the suggestion should be sent to the support group at JMP.  Only they can affect the change.

And I apologize for reading your discussion too quickly and missing your request for community input.

[#5]

I find that JMP support tends to follow these forums, and I'm not in a hurry, plus I'm on the fence on the issue, so I doubt I'd be the best candidate to request this change.

I just know that in JavaScript they allow soft equalities. For example 5 == "5" will return true, with hard e qualities denoted by 5 === "5" would be false.  Soft equalities can often lead to strange behavior and are frowned upon by a lot of programmers.  Lots of people have prejudice to always use hard equalities, however, having soft equalities can really help make code robust and if the programmer knows what he's doing they can be life savers.

JSL is a different language though, and it seems to me that most scriptwriters don't have programming backgrounds.  So allowing a robust nitems could be detrimental to the language, but at the same time, I'd be able to make great use of it.

[#6]

It does seem like nItems(matrix) could be more useful if it returned nrows(matrix) * ncols(matrix).

I'm not sure what I'd expect of nitems("a,b,c") because I could make a case for 1, 3, or 5.

[#7]

I like your idea for the matrix.  nrows(matrix) * ncols(matrix) definitely seems like it would be more useful than just returning nrows or ncols.

I would argue that returning 3 for "a,b,c" would be a poor return since the values could be delimited by anything: space, underscore, colon (" " "_" ";") to name a few.  This really should be left to the programmer to parse with a words() or regex() before sending to an nitems.

I initially thought 1 would be most appropriate since in my case I was expecting a list of strings, but if previous statements didn't return a list it just returned the variable as a string, in which case I wanted 1.  However, now that you mention it, nitems could be very useful if it returned the length of the string and would have different applications.

[#8 · Accepted solution]

This thread is rather old, but i thought i'd state what was ultimately implemented in JMP 13 and later:

• NItems( matrix ) now returns the number of elements in the matrix ( rows * cols ) rather than an error.
• nitems("cat") still returns an error
• nitems([1 2 3] |/ [4 5 6]) == 6