集合支持改进

Question

似乎使用Clojure集合作为组合函数的items参数是个合理的要求。然而，在case{{(combinations some-set 1)}}的情况下，会抛出异常，因为Clojure的distinct函数（当{{(= t 1)}}时被调用）不支持集合。通过在调用combinations前将集合转换为seq可以绕过这个问题。

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

Answer 1

评论由glchapman发表

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

Answer 2

评论由markengelberg发表

请参阅这里的讨论： https://groups.google.com/forum/#!topic/clojure/XUEqdCSI6c4

我认为将集合作为有效输入并不一定有意义。这些算法返回的值高度依赖于元素在seq中的顺序。由于集合是无序的，此类更改将使得这些不仅仅是纯函数，即它们可能会为相同的（相等的）输入返回完全不同的输出。这是因为两个被比较为相等的集合，在应用seq时可能会返回不同的元素顺序。这可能会在人们调用这些函数并使用集合并等时破坏他们的测试案例。

我认为最好强制用户直接应用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发表

目前，我已将说明的用法说明部分的顶部添加了一条注释。对于集合，唯一真正破裂的是对 distinct 的调用来，所以如果 Clojure 修改了对 distinct 的代码使其可用于集合（这似乎是一个微不足道的修改），则可以删除此注释。

Answer 8

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