online - clojure tutorial

¿Por qué alguna vez elegiría no usar la función de reductores clojure 1.5?

Question

Estaba leyendo sobre los reductores de clojure introducidos en 1.5, aquí: https://github.com/clojure/clojure/blob/master/changes.md . Tengo entendido que son una mejora del rendimiento en las funciones existentes de mapa / filtro / reducción. Entonces, si ese es el caso, me pregunto por qué están en un nuevo espacio de nombres, y no simplemente reemplazan las implementaciones existentes de map / reduce / filter. Dicho de otra manera, ¿por qué nunca elegiría usar la nueva función de reductores?

EDITAR:

En respuesta a las dos respuestas iniciales, aquí hay una aclaración:

Voy a citar las notas de publicación aquí:

Los reductores proporcionan un conjunto de funciones de alto rendimiento para trabajar con colecciones. Los algoritmos de plegado / reducción reales se especifican a través de la colección que se está reduciendo. Esto permite que cada colección defina la forma más eficiente de reducir sus contenidos.

Esto no me suena como que las nuevas funciones de mapa / filtro / reducción son inherentemente paralelas. Por ejemplo, más abajo en las notas de la versión dice:

Contiene una nueva función, fold, que es una combinación paralela + reduce.

Entonces, a menos que la nota de publicación esté mal escrita, me parece que hay una nueva función, fold, que es paralela, y las otras funciones son implementaciones específicas de la colección que tienen como objetivo producir el mayor rendimiento posible para la colección en particular. ¿Estoy simplemente malinterpretando las notas de publicación aquí?

Answer 1

Encontré el siguiente artículo escrito por Rich Hickey que, si bien todavía es algo confuso, aclaró (algunas) cosas para mí: http://clojure.com/blog/2012/05/08/reducers-a-library-and-model-for-collection-processing.html

En particular el resumen:

Al adoptar una visión alternativa de las colecciones como cosas reducibles, en lugar de cosas que se pueden obtener, podemos obtener un conjunto complementario de operaciones fundamentales que compensan la pereza por el paralelismo, al mismo tiempo que conservamos el mismo modelo de programación funcional de alto nivel. Debido a que los dos modelos conservan la misma forma, podemos elegir fácilmente el que sea apropiado para la tarea en cuestión.

Answer 2

No pueden reemplazar las implementaciones antiguas en algunos casos. Por ejemplo, si tiene secuencias infinitas o si realmente necesita un procesamiento secuencial de la colección.

Answer 3

Un par de buenas razones por las que podría decidir no usar reductores:

• Debe mantener la compatibilidad con Clojure 1.4. Esto dificulta el uso de reductores en el código de la biblioteca, por ejemplo, cuando no sabe qué versión de Clojure utilizarán sus usos.
• En algunas circunstancias, hay mejores opciones : por ejemplo, si se trata de matrices numéricas, es probable que sea mejor usar algo como core.matrix .

Answer 4

Prólogo: tienes un problema y vas a usar el paralelismo, ahora los problemas dos te tienen.

Son sustitutos en un sentido en el que hacen ese trabajo en paralelo (en lugar de un mapa secuencial antiguo y etc.). No todas las operaciones podrían ser paralelas (en muchos casos, la operación debe ser al menos associative , también pensar en secuencias perezosas e iteradores). Además, no todas las operaciones se pueden paralizar de manera eficiente (siempre hay una sobrecarga de coordinación, a veces la sobrecarga es mayor que la ganancia de paralelización).