math - programacion - ¿Matemáticas científicas con lenguajes funcionales?

programacion funcional ventajas y desventajas (7)

¿Existen bibliotecas científicas serias y hechas con lenguajes de programación funcionales? Por la naturaleza misma de los lenguajes funcionales, uno pensaría que son particularmente adecuados para las matemáticas, pero los algoritmos bien conocidos parecen ser de procedimiento.

Por ejemplo, la serie de Recetas Numéricas clásicas está escrita de manera bastante procedimental. LAPACK es un estándar casi de facto en muchos campos, pero está en Fortran y, por lo tanto, es procedimental o quizás OO, pero definitivamente no es funcional.

¿Alguien ha podido transferir este tipo de algoritmos de procedimiento conocidos al estilo funcional?

Actualización : parece ser que los lenguajes funcionales se utilizan en cálculos simbólicos , por ejemplo, en Mathematica. Pero, ¿hay algo inherentemente incompatible con los cálculos numéricos y los algoritmos funcionales? ¿O es solo porque, como los algoritmos imperativos se inventaron primero, nadie se molestó en idear equivalentes funcionales?

Creo que Mathematica utiliza su propio lenguaje funcional.

Definir "serio". Recuerde que los lenguajes funcionales (aparte de LISP) son bastante nuevos: los documentos originales de Backes fueron solo a finales de los 70, y los lenguajes funcionales de ingeniería de producción son bastante nuevos. Los paquetes numéricos bien conocidos y aceptados están basados en algoritmos y códigos que comenzaron a finales de los 60 y principios de los 70; BLAS se publicó por primera vez en 1979. Desde entonces, para uso en producción, las personas tienden a gravitar hacia paquetes bien conocidos y confiables. , hay un gran impulso a los antiguos códigos de FORTRAN.

Pero ciertamente hay personas que hacen procesamiento numérico con lenguajes funcionales. Como se señaló en otra respuesta, Mathematica es cada vez más una función de lenguaje numérico y se implementa cada vez más en sí misma.

En el espíritu de la excelente estructura e interpretación de los programas de computadora , también existe la estructura e interpretación de la mecánica clásica . Este libro utiliza el Esquema para aclarar muchas notaciones matemáticas sueltas utilizadas en el enfoque variacional de la mecánica.

Una piedra angular del libro es el paquete scmutils , que incluye un enfoque funcional para muchas tareas computacionales, como la integración y la minimización.

Excelente pregunta!

He sido uno de los pocos pioneros en este campo durante varios años y recién estamos llegando al punto en el que es posible obtener un rendimiento similar al de Fortran y una brevedad similar al de Python al mismo tiempo para una amplia gama de problemas. Después de haber examinado todos los lenguajes funcionales disponibles y sus implementaciones con gran detalle, decidí centrar mis esfuerzos en los lenguajes funcionales impuros de tipo estático: el lenguaje de programación de código abierto OCaml y el lenguaje de programación F # de Microsoft para .NET.

Mi libro OCaml for Scientists cubre la computación científica con el lenguaje de programación OCaml usando Linux o Mac OS X. Mi libro F # for Scientists cubre la computación científica con el lenguaje de programación F # de Microsoft usando Windows y Visual Studio. Mi compañía también vende F # para Numerics y F # para Visualization las bibliotecas que están escritas completamente en F # y hacen un uso extensivo de la programación funcional tanto internamente para mejorar la brevedad, la claridad y la capacidad de mantenimiento como también externamente para hacer que la biblioteca sea más fácil de usar. Por ejemplo, las funciones de primera clase le permiten trazar gráficos con mucha facilidad, por ejemplo, trazar la función seno:

Plot([Function sin], (-5., 5.))

F # para visualización incluso intentará visualizar cualquier valor de cualquier tipo para que pueda darle una matriz de racionales de precisión arbitraria y mostrará el resultado como matemáticas de tipo .

Hemos tenido un gran éxito al escribir código para computación científica en un estilo funcional en los lenguajes OCaml y F #. En particular, F # facilita la escritura de código paralelo de alto rendimiento que es genérico sin ninguna penalización de rendimiento por abstracción. ¡Así que puede implementar la descomposición QR que funciona para matrices de cualquier tipo (precisión simple, precisión doble, complejo o incluso simbólico) e incluso mejorar el rendimiento de las bibliotecas sintonizadas por los proveedores como Intel MKL !

Finalmente, debo notar que Mathematica fue un camino para abrir este camino mucho antes que yo. Sin embargo, su solución fue combinar una enorme biblioteca estándar de funciones numéricas y simbólicas escritas en C con un estilo imperativo convencional y proporcionar un lenguaje de programación funcional bastante rudimentario para llamar a esas funciones. La principal desventaja de su enfoque es que el código general escrito en Mathematica (es decir, donde el tiempo no se gasta principalmente en su biblioteca estándar) es aproximadamente 1000x más lento que C.

Hay una biblioteca de Haskell para cosas numéricas en hackageDB: hmatrix . Se basa en LAPACK, BLAS y GSL (Biblioteca Científica GNU).

Pero debe tener en cuenta que los algoritmos imperativos se pueden transferir fácilmente a lenguajes puramente funcionales utilizando mónadas (más específicamente, transformadores de estado). De hecho, cualquier implementación eficiente en el lugar generalmente debe usar dicho mecanismo para proporcionar variables mutables en lenguajes puramente funcionales.

En cuanto a seguir un estilo funcional, en muchos casos no es posible. Para muchos problemas, no se conocen enfoques funcionales (eficientes). Por supuesto, puede hacer que tales algoritmos funcionen en Haskell, por ejemplo, pero no se verán muy diferentes a los que se escribieron en Matlab, Fortran o C.

EDITAR:

Es a la vez una aparente incompatibilidad, así como un problema que surgió primero:

Los algoritmos numéricos eficientes generalmente requieren datos mutables. Si bien esto es posible en un entorno puramente funcional, no es tan sencillo como en los lenguajes imperativos. Pero los dos modelos computacionales son perfectamente equivalentes.
La máquina subyacente (por ejemplo, conjunto de instrucciones) siempre ha sido y sigue siendo imperativa, con muy pocas excepciones (!). Los algoritmos codificados de manera imperativa son más fáciles de analizar y optimizar, dada la forma en que se modela la máquina real.
Si bien las matemáticas subyacentes permiten derivaciones relativamente fáciles para soluciones funcionales, no obtendrá un algoritmo eficiente (como en el caso de derivar soluciones imperativas directamente de las matemáticas). Dado que la mayor parte del esfuerzo ha sido y sigue siendo dirigido hacia soluciones imperativas, las contrapartes funcionales son simplemente desconocidas. Por contrapartes funcionales me refiero a código que expresa correctamente la intención funcional y el estilo.
Hay un montón de código imperativo que puede ser reutilizado. Gran parte de esto se puede transcribir a un lenguaje funcional utilizando transformadores de estado, aunque aún se vería imperativo.

De hecho, creo que un lenguaje puramente funcional como Haskell podría ser beneficioso para los algoritmos de codificación: se podría unificar la descripción matemática, el algoritmo en sí y algún tipo de prueba orientada al tipo (es decir, usar el isomorfismo de Curry-Howard ) en el mismo fragmento de código .

Usaría LAPACK como una caja negra de un lenguaje funcional en lugar de intentar reescribirlo. LAPACK ha sido probado, afinado, optimizado, etc. durante décadas por personas extremadamente inteligentes. No lo tocaría.

Varios sistemas de álgebra computacional (por ejemplo, Maxima) utilizan lenguajes basados en LISP internamente para representar cálculos simbólicos / árboles de sintaxis.

Ejemplos de lenguajes matemáticos, funcionales:

http://en.wikipedia.org/wiki/J_(programming_language)

http://en.wikipedia.org/wiki/K_(programming_language)

De todos modos, hay varios problemas matemáticos y algoritmos que no se pueden formular bien o eficientemente en un estilo funcional. Una implementación eficiente siempre será imperativa. Ej: Tamiz de Eratóstenes.