对集合更好的支持

Question

使用 Clojure 集合作为组合函数的参数似乎是合理的。然而，在{{(combinations some-set 1)}}的情况下，由于 Clojure 的 distinct 函数（当 {{(= t 1)}} 被调用时使用）不支持集合，因此会引发异常。可以通过在调用 combinations 之前将集合转换为 seq 来解决这个问题。

对于所有其他函数，似乎通过为{{all-different?}}添加一个{{set?}}检查可以使函数稍微更加高效（通过避免线性 {{distinct?}} 扫描）。

Answer 1

由 glchapman 发表评论

我再看了看：看起来{{nth-permutation-distinct}}将会对其{{l}}参数调用{{nth}}。集合不支持{{nth}}，因此更好的集合支持需要修改该函数。

Answer 2

由 markengelberg 发表评论

有关讨论请见此处：https://groups.google.com/forum/#!topic/clojure/XUEqdCSI6c4

我认为集合作为有效输入不一定是有意义的。这些算法返回的结果高度依赖于顺序的元素。由于集合是无序的，这种更改将使得这些不是纯函数，即它们可以对相同的（相等的）输入返回完全不同的输出。这是因为根据比较结果相等的两个集合在应用列表时可能会返回不同的元素顺序。这可能会对人们的函数测试案例造成混乱，这些函数使用集合等调用了这些算法。

我认为最好强迫用户直接应用列表，而不是隐式地发生，这样他/她就可以考虑后果，并且如果需要，可能进行某种排序以确保一致的输出。

Answer 3

评论者：nathan

无论是否修复，至少需要编辑一下文档字符串。

就目前情况来看，组合操作将正常工作，直到遇到大小为1的特殊情况（边角情况）。这种隐藏的地雷需要某种解决方案。
强制对排序问题采取行动可能包括抛出异常、弹出警告或使得函数在集合上持续出错。

Answer 4

由 markengelberg 发表评论

我同意当前行为不太友好。可能的解决方案包括

1) 对所有输入隐式调用 seq（缺点：不再是纯函数）
2) 对集合抛出错误（缺点：增加了运行时检查）
3) 在文档字符串中添加相关信息，说明输入必须是序列（缺点：需要阅读文档字符串来了解约束，每个人都知道“序列”意味着什么，以及集合和映射不满足这一条件？）
4) 在 README 中添加有关此问题的讨论（缺点：是否有人阅读 README？）

我倾向于选择 3 或 4。我愿意做出相应的修改。

Answer 5

评论者：nathan

考虑到#1，除了大小为1的组合之外，对任何其他情况的行为都不会比现在更少纯。它也会与 seq、vec、map 或任何其他保持顺序的功能具有相同的纯度。（map inc some-set）在与顺序隐藏的数据结构和顺序保持（揭示？）函数相关的等价性问题上具有相同的注意事项。这个问题比组合函数要大得多，一个合适的等价性警告应该属于顺序隐藏对象自身。

考虑到邮件列表上的讨论，人们使用集合的一个原因是有意忽略顺序。我想最好的建议是在测试之前将序列转换回集合。（set (map inc some-set)）

我认为如果我们不使 map 在集合上出错，那么在这里修复它是有价值的。

Answer 6

评论者：nathan

我看到了组合的一些问题。数学组合是顺序无关的；但这些都是列表。对于等价性测试，你可以使用：(set (map set (combinations some-set n)))

Answer 7

由 markengelberg 发表评论

目前，我在 README 文件的用法说明最上方添加了一条注释。对于集合而言，真正有问题的是对 distinct 的调用，所以如果 Clojure 修改了 distinct 的代码，使其能够在集合上工作（这似乎是一个微不足道的更改），那么这条注释就可以被移除了。

Answer 8

参考：[https://clojure.atlassian.net/browse/MCOMB-8](https://clojure.atlassian.net/browse/MCOMB-8)（由 glchapman 报告）