Subscribe Bookmark RSS Feed

Should "n items()" be more robust?

msharp

Super User

Joined:

Jul 28, 2015

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?

6 REPLIES
txnelson

Super User

Joined:

Jun 22, 2012

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

Joined:

Jul 28, 2015

That doesn't answer the question.

txnelson

Super User

Joined:

Jun 22, 2012

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

Joined:

Jul 28, 2015

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

Staff

Joined:

Mar 21, 2013

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

Joined:

Jul 28, 2015

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.