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