Clojure 2024状态调查!中分享您的想法。

欢迎!请参阅关于页面,了解更多相关信息。

0
math.combinatorics
似乎将 clojure 集合用作组合函数的项参数是很合理的。然而,在{{(combinations some-set 1)}}的情况下,由于 Clojure 的 distinct 函数(在={{(= t 1)}}时调用)不支持集合,因此抛出异常。通过在调用 combinations 之前将集合转换为 seq,可以解决这个问题。

对于所有其他函数,通过在 {{all-different?}} 中添加一个 {{set?}} 检查,可以使函数的效率略有提高(通过避免线性的 {{distinct?}} 扫描)。

8 答案

0

评论者:glchapman

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

0

评论者:markengelberg

请参阅此处的讨论:https://groups.google.com/forum/#!topic/clojure/XUEqdCSI6c4

我认为将集合作为有效输入并不一定合理。这些算法返回的结果高度依赖于序列中元素的顺序。由于集合是无序的,这种更改将使这些函数不再完全是纯函数,即对于相同的(相等的)输入,它们可能返回完全不同的输出。这是因为两个比较为相等的集合在应用序列时可能会返回不同顺序的元素。这可能会破坏人们在调用带有集合的函数等时的测试用例。

我认为强制用户直接应用 seq,而不是隐性发生,更好,这样他/她可以思考后果,也许可以做某种 seq 或其他操作来确保一致的结果。

0

评论者:nathan

无论是否修复,至少需要修改文档字符串。

目前情况下,组合操作将能够正常工作,直到遇到大小为 1 的特殊情况。像这样的隐藏陷阱需要 某种 修复。
强制对排序问题进行干预将涉及抛出异常,弹出警告,或使函数在集合上持续出错。

0

评论者:markengelberg

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

1) 隐式地对所有输入调用 seq(缺点:不再是纯函数)
2) 对集合抛出错误(缺点:增加了运行时检查)
3) 在文档字符串中添加信息,说明输入必须是序列(缺点:需要阅读文档字符串来理解约束,每个人都知道“序列”是什么意思吗,以及集合和映射不符合条件?)
4) 在 README 中添加关于此点的讨论(缺点:是否有人阅读 README?)

我会倾向于 3 或 4。我愿意做出相应的更改。

0

评论者:nathan

考虑到 #1,对于除了大小为 1 的组合之外的所有内容,行为不会比现在更不纯粹。它也会与 seq、vec、map 或任何其他保持顺序的功能具有完全相同的纯粹性。(map inc some-set)对于顺序也有相同的警告。由于顺序隐藏数据结构和顺序保留(揭示?)函数的等价性问题比组合函数要大得多,因此适当的等价性警告应属于顺序隐藏对象本身。

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

我认为如果我们不想在集合上留下 map 的错误,那么修复这里是值得的。

0

评论者:nathan

我看出了一些关于组合的问题。数学组合是无顺序的;但这些是列表。对于等价性测试,您将使用:(set (map set (combinations some-set n)))

0

评论者:markengelberg

目前,我已在README的用法说明顶部添加了备注。对集合破坏性最大的只有对distinct的调用,所以如果Clojure最终更新了distinct代码以支持集合(这似乎应该是一个微不足道的更改),则可以删除此备注。

0
参考:[https://clojure.atlassian.net/browse/MCOMB-8](https://clojure.atlassian.net/browse/MCOMB-8)(由glchapman提交)
...