“n items()”應該更健壯嗎？<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />我經常發現自己在使用“n items()”的腳本中遇到問題。而且我經常看到這個錯誤：“N Items() argument must be a list”
在一個腳本中，由於數據的穩健性，我輸入 nitems 的內容有時可以是矩陣、數字或字符。 又名：變量 = [5]，變量 = 5；變量=“05”；變量={5}；不要太詳細，在這種情況下，如果“n items”被提供一個字符值，也就是 n items（“05”），它會吐出 1，如果它有一個矩陣，它會吐出 nrows 等。
積極的是，如果向它提供不適當的數據項，JSL 永遠不會出錯，因為它會對您的數據進行軟轉換。這將大大減少使腳本對大量不同數據具有魯棒性所需的代碼量。不利的一面是它可能導致懶惰的編程，從而很難發現錯誤。這可能會導致問題：例如，輸入矩陣並想要 ncols，而不是 nrows；或者你的字符串是“05, 05”，你應該先解析它，等等。
社區怎麼看？如果“n items”更強大，這是福還是禍？
回复：“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()”應該更健壯嗎？如果 nItems(matrix) 返回 nrows(matrix) * ncols(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
)
