「n items()」應該更穩健嗎？我經常發現自己在帶有“n items()”的腳本中遇到問題。我經常看到這個錯誤：“N Items() 參數必須是一個列表”
在一個腳本中，由於資料的穩健性，我輸入 nitems 的內容有時可以是矩陣、數字或字元。又稱：變數 = [5]，變數 = 5；變數=“05”；變數={5}；不要太詳細，在這種情況下，如果“n items”被提供一個字符值，又名，n items（“05”），它會吐出1，如果它有一個矩陣，它會吐出1吐出nrows等。
積極的一面是，如果向 JSL 提供了不適當的數據項，JSL 永遠不會出錯，因為它會對您的數據進行軟轉換。這將大大減少使腳本對大量不同資料具有穩健性所需的程式碼量。缺點是它可能會導致懶惰的編程，從而很難發現錯誤。這可能會導致問題：例如，輸入矩陣並需要 ncols，而不是 nrows；或者你的字串是“05, 05”，你應該先解析它，等等。
社區怎麼看？如果「n 項」更強大，這是福還是禍？
回覆：「n items()」應該更穩健嗎？該線程相當舊，但我想我應該說明 JMP 13 及更高版本中最終實現的內容：
- NItems(matrix) 現在傳回矩陣中的元素數 ( rows * cols ) 而不是錯誤。
- nitems("cat") 仍然回傳錯誤
- 尼特姆斯([1 2 3] |/ [4 5 6]) == 6
回覆：「n items()」應該更穩健嗎？我喜歡你對矩陣的想法。 nrows(matrix) * ncols(matrix) 看起來肯定比只回傳 nrows 或 ncols 更有用。
我認為，為“a,b,c”返回 3 的回報會很差，因為這些值可以用任何東西分隔：空格、下劃線、冒號（“”“_”“;”）等等。這確實應該留給程式設計師在發送到 nitems 之前用 Words() 或 regex() 進行解析。
我最初認為1 是最合適的，因為在我的情況下，我期待一個字串列表，但如果前面的語句沒有返回列表，它只是將變數作為字串返回，在這種情況下我想要1 。但是，現在你提到過，如果 nitems 返回字串的長度並且有不同的應用程序，它會非常有用。
回覆：「n items()」應該更穩健嗎？如果回傳 nrows(matrix) * ncols(matrix)，nItems(matrix) 似乎會更有用。
我不確定我對 nitems("a,b,c") 有何期望，因為我可以為 1、3 或 5 提供理由。
回覆：「n items()」應該更穩健嗎？我發現 JMP 支援往往會關注這些論壇，而且我並不著急，而且我在這個問題上持觀望態度，所以我懷疑我是否是請求此更改的最佳人選。
我只知道在 JavaScript 中它們允許軟相等。例如 5 == "5" 將傳回 true，而 5 === "5" 表示的硬 e 品質將傳回 false。軟相等常常會導致奇怪的行為，並且受到許多程式設計師的反對。許多人對始終使用硬相等性存有偏見，但是，擁有軟相等性確實可以幫助使程式碼變得健壯，並且如果程式設計師知道他在做什麼，他們可以成為救星。
不過，JSL 是一種不同的語言，在我看來，大多數編劇都沒有程式設計背景。因此，允許強大的 nitems 可能會對語言產生不利影響，但同時，我能夠充分利用它。
回覆：「n items()」應該更穩健嗎？我認為你的建議是一個很好的建議。無論整個社區如何認為，建議都應該發送給 JMP 的支持小組。只有他們才能影響改變。
對於太快閱讀您的討論並錯過您對社區意見的請求，我深表歉意。
回覆：「n items()」應該更穩健嗎？這並不能回答問題。
回覆：「n items()」應該更穩健嗎？如果使用「Is List」功能，您可以檢查該值是否為清單。因此，以下內容適用於縮放器、列表和矩陣
x= 縮放器、矩陣或列表
如果（是列表（x）
計數=1
)
