“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
)
