18

ここで、1.5 で導入された clojure レデューサーについて読んでいました: https://github.com/clojure/clojure/blob/master/changes.md。私の理解では、それらは既存の map/filter/reduce 関数のパフォーマンス強化です。その場合、なぜそれらが新しい名前空間にあり、既存の map/reduce/filter 実装を単純に置き換えないのか疑問に思っています。別の言い方をすれば、新しいレデューサー機能を使用しないのはなぜでしょうか?

編集：

最初の2つの回答に応じて、ここに明確化があります：

ここでリリースノートを引用します。

レデューサーは、コレクションを操作するための高性能関数のセットを提供します。実際のフォールド/リデュース アルゴリズムは、リデュースされるコレクションを介して指定されます。これにより、各コレクションはその内容を削減する最も効率的な方法を定義できます。

これは、新しい map/filter/reduce 関数が本質的に並列であるようには思えません。たとえば、リリースノートのさらに下には、次のように記載されています。

並列のreduce+combineである新しい関数foldが含まれています

そのため、リリース ノートの記述が不十分でない限り、新しい関数 fold が 1 つあり、これは並列であり、他の関数は、特定のコレクションで可能な限り最高のパフォーマンスを実現することを目的としたコレクション固有の実装であると思われます。ここでリリースノートを読み間違えただけですか?

4

4 に答える 4

8

場合によっては、古い実装を置き換えることができません。たとえば、無限のシーケンスがある場合、または実際にコレクションの順次処理が必要な場合です。

于 2013-04-17T17:37:54.183 に答える
1

レデューサーを使用しないことを決定する正当な理由がいくつかあります。

  • Clojure 1.4 との下位互換性を維持する必要があります。これにより、ライブラリ コードでレデューサーを使用するのが難しくなります。たとえば、使用する Clojure のバージョンが不明な場合などです。
  • 状況によっては、より良いオプションがあります。たとえば、数値配列を扱っている場合は、代わりにcore.matrixなどを使用した方がほぼ確実です。
于 2013-04-18T05:51:21.937 に答える
0

Rich Hickey による次の記事を見つけましたが、まだやや混乱していますが、(いくつかの) ことを解決してくれました: http://clojure.com/blog/2012/05/08/reducers-a-library-and-model for-collect-processing.html

特に要約：

コレクションを seqable ではなく、reducible と見なす別の見方を採用することで、同じ高レベルの関数型プログラミング モデルを維持しながら、遅延性と並列処理をトレードオフする基本的な操作の補完的なセットを得ることができます。2 つのモデルは同じ形状を保持しているため、目の前のタスクに適した方を簡単に選択できます。

于 2013-04-18T04:14:19.487 に答える