更好的集合支持

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

我认为将集合作为有效输入不一定有意义。这些算法返回的结果高度依赖于seq中元素顺序。由于集合是无序的，这种修改将导致这些函数不再是纯函数，即对于相同的（相等）输入，它们可能返回完全不同的输出。这是因为两个视为相等的集合在应用seq时可能会返回不同顺序的元素。这可能会对人们测试用例中的函数造成破坏，这些函数用集合调用这些等。

我认为用户直接强制应用 seq 而不是隐式发生更加合适，这样他们可以思考后果，并在需要的情况下进行某种 sort 或其他操作，以确保一致的输出。

Answer 3

评论者：nathan

无论是否修复，至少需要对文档字符串进行编辑。

现状下，组合操作将正常工作，直到遇到大小为 1 的边缘情况。这种隐藏的陷阱需要一种固定的修复。
强制对排序问题采取行动将涉及抛出异常、显示警告或将函数错误地应用于集合中的一致性。

Answer 4

评论者：markengelberg

我同意当前的行为不够友好。可能的解决方案有

1) 隐式地对所有输入调 used 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报告）