集合支持更优

Question

使用 clojure 集合作为组合函数的 items 参数似乎是合理的。然而，在 {{(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或类似操作以确保一致输出会更好。

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 报告）