我正在阅读1.5中介绍的clojure redurs,这里:https://github.com/clojure/clojure/blob/master/changes.md。我的理解是它们是对现有map / filter / reduce函数的性能增强。因此,如果是这种情况,我想知道他们为什么在新的命名空间中,并且不要简单地替换现有的map / reduce / filter实现。换句话说,为什么我不选择使用新的Reducer功能?
编辑:
对于初步的两个答案,这里有一个澄清:
我将在这里引用发行说明:
Reducers提供了一组用于处理集合的高性能函数。实际的折叠/减少算法通过减少的集合来指定。这允许每个集合定义减少其内容的最有效方法。
这对我来说听起来并不像新的map / filter / reduce函数本质上是并行的。例如,在发行说明中进一步说明:
它包含一个新函数fold,它是一个并行的reduce + combine
因此,除非发行说明写得不好,否则在我看来有一个新功能,fold,它是并行的,其他功能是特定于集合的实现,旨在为特定集合产生最高性能。我只是错误地阅读了这里的发行说明吗?
答案 0 :(得分:7)
前言:你有问题,你将使用并行性,现在问题有两个人。
他们在某种意义上是替代他们并行工作(与普通的旧顺序地图等)。并非所有操作都可以并行化(在许多情况下,操作必须至少为associative,还要考虑延迟序列和迭代器)。此外,并非每个操作都可以有效地并行化(总是存在一些协调开销,有时开销大于并行化增益)。
答案 1 :(得分:6)
在某些情况下,它们无法替换旧的实现。例如,如果您有无限的序列,或者您实际上需要对集合进行顺序处理。
答案 2 :(得分:1)
您可能决定不使用Reducer的几个很好的理由:
答案 3 :(得分:0)
我发现Rich Hickey撰写了以下内容,虽然仍然有点令人困惑,但为我清除了(某些)事情:http://clojure.com/blog/2012/05/08/reducers-a-library-and-model-for-collection-processing.html
特别是摘要:
通过采用另一种集合视图作为可简化而非可选择的东西,我们可以获得一组互补的基本操作,这些操作可以权衡并行性的懒惰,同时保留相同的高级函数式编程模型。由于两个模型保持相同的形状,我们可以轻松选择适合手头任务的任何一个。