cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
JMP is taking Discovery online, April 16 and 18. Register today and join us for interactive sessions featuring popular presentation topics, networking, and discussions with the experts.
Choose Language Hide Translation Bar
msharp
Super User (Alumni)

Should "n items()" be more robust?

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?

1 ACCEPTED SOLUTION

Accepted Solutions

Re: Should "n items()" be more robust?

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

 

View solution in original post

7 REPLIES 7
txnelson
Super User

Re: Should "n items()" be more robust?

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

)

Jim
msharp
Super User (Alumni)

Re: Should "n items()" be more robust?

That doesn't answer the question.

txnelson
Super User

Re: Should "n items()" be more robust?

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.

Jim
msharp
Super User (Alumni)

Re: Should "n items()" be more robust?

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.

Craige_Hales
Super User

Re: Should "n items()" be more robust?

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.

Craige
msharp
Super User (Alumni)

Re: Should "n items()" be more robust?

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.

Re: Should "n items()" be more robust?

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