FP para simulación y modelado


12

Estoy a punto de comenzar un proyecto de simulación / modelado. Ya sé que OOP se utiliza para este tipo de proyectos. Sin embargo, estudiar Haskell me hizo considerar el uso del paradigma FP para modelar un sistema de componentes. Déjame elaborar:

Digamos que tengo un componente de tipo A, caracterizado por un conjunto de datos (un parámetro como temperatura o presión, un PDE y algunas condiciones límite, etc.) y un componente de tipo B, caracterizado por un conjunto diferente de datos (diferentes o el mismo parámetro, diferentes PDE y condiciones de contorno). Supongamos también que las funciones / métodos que se aplicarán en cada componente son los mismos (un método de Galerkin, por ejemplo). El estado mutable del objeto se usaría para parámetros no constantes.

Si tuviera que usar un enfoque OOP, crearía dos objetos que encapsularían los datos de cada tipo, los métodos para resolver el PDE (la herencia se usaría aquí para la reutilización del código) y la solución al PDE.

Por otro lado, si tuviera que usar un enfoque de FP, cada componente se desglosaría en partes de datos y las funciones que actuarían sobre los datos para obtener la solución para el PDE. Los parámetros no constantes se pasarían como funciones de otra cosa (tiempo, por ejemplo) o se expresarían mediante algún tipo de mutabilidad (emulación de mutabilidad, etc.). Este enfoque me parece más simple suponiendo que las operaciones lineales en los datos serían triviales.

Para concluir, ¿la implementación del enfoque FP sería realmente más simple y fácil de administrar (agregar un tipo diferente de componente o un nuevo método para resolver el pde) en comparación con el de OOP?

Vengo de un entorno de C ++ / Fortran, además no soy un programador profesional, así que corrígeme en cualquier cosa que me haya equivocado.

Respuestas:


7

Buena pregunta, he estado pensando en líneas similares. Históricamente, el paradigma OO surgió de la necesidad de simulación por computadora (vea la historia de Simula ) y, a pesar de que los primeros lenguajes OO, como Smalltalk, fueron creados por personas que sabían lo que estaban haciendo (es decir, Alan Kay), ahora se podría decir que OO está excesivamente usado y trae demasiada complejidad accidental .

En general, los programas de estilo FP serán más cortos, más fáciles de probar y más fáciles de modificar que los programas OO. Como Rob Harrop lo expresó en su discurso, ¿Funciona el futuro? , nunca puede ser más simple que las funciones y los datos; los dos componen infinitamente, para construir cualquier abstracción necesaria. Entonces, una forma de responder a su pregunta (¿o solo la estoy reafirmando? :) es preguntar: ¿Cuál es la función de nivel más alto y los datos de entrada de nivel más alto -> datos de salida? Luego puede comenzar a desglosar esas funciones "alfa" y tipos de datos en la siguiente capa de abstracciones, y repetir según sea necesario.

Otra perspectiva (no del todo respuestas) sobre su pregunta es mirar este hilo (descargo de responsabilidad, lo comencé) en StackOverflow, algunas de las respuestas son muy interesantes: /programming/3431654/how-does- programación-funcional-aplicar-a-simulaciones

Mi propia opinión en este momento es, a menos que esté modelando una situación en la que realmente hay objetos discretos que solo interactúan de manera definida (por ejemplo, un modelo de red informática) y, por lo tanto, se asignan directamente a las capacidades de un mensaje limpio. lenguaje OO de paradigma de paso: es más simple ir FP Tenga en cuenta que incluso en la comunidad de programación de juegos, donde las simulaciones son muy frecuentes y los requisitos de rendimiento son primordiales, los desarrolladores experimentados se están alejando del paradigma OO y / o están utilizando más FP, por ejemplo, vea esta discusión de HN o los comentarios de John Carmack sobre FP


¡Es bueno saber que no soy el único que duda sobre la POO en la simulación y gracias por responder mi pregunta! Había leído los comentarios de John Carmack sobre FP y pensé en implementar algunos aspectos de FP en C ++ (copiar los objetos, o reunir la entrada y pasarla a una función) pero, una vez más, no sé si debería comenzar mi proyecto con C ++ en lugar de un lenguaje FP, como Haskell, ya que los aspectos FP están incorporados y usted expresa mutabilidad solo cuando es necesario. ¿Continuó usando Clojure o FP en general, considerando que tenía un problema / pregunta similar?
heaptobesquare

@heaptobesquare: Sí, he estado aumentando constantemente mi Clojure-fu con el objetivo de escribir simulaciones en él. Todavía no hay nada listo para mostrar, pero no veo topes para mostrar, y el diseño de Clojure es maravillosamente pragmático, por ejemplo, puede usar transitorios / mutación si es necesario, además sus agentes son adecuados para aspectos asincrónicos. En algún momento (sin promesas cuando) escribiré un artículo sobre el tema ...
limist

He echado un vistazo a Clojure pero no puedo decir que me gusten las expresiones S. Sé que es práctico (el código Lisp es información) pero ¿es fácil acostumbrarse?
heaptobesquare

@heaptobesquare - la sintaxis s-expressions / Lisp es realmente muy fácil de acostumbrar; primero elija un buen editor (Emacs o vim, mi voto es para Emacs, consulte dev.clojure.org/display/doc/Getting+Started+with+Emacs ) que tiene un modo para Clojure, obtenga un buen libro (por ejemplo, Programming Clojure ) y comienza a hackear. Después de unas pocas semanas como máximo, la sintaxis se desvanecerá en el fondo, como debería ser: es tan perfectamente consistente que pensarás en ella exponencialmente con menos frecuencia y liberará ciclos mentales para cosas más importantes. :)
limist

Definitivamente lo intentaré entonces. La homoiconicidad de Lisp es interesante después de todo.
heaptobesquare

2

En mi humilde opinión, para casi todas las tareas de complejidad razonable, la pregunta "es un estilo FP o estilo OOP, la mejor opción" no puede responderse objetivamente. Por lo general, en tal situación, la pregunta no es "FP u OOP", sino cómo combinar las mejores partes de ambos paradigmas para resolver su problema.

El problema que ha esbozado anteriormente parece ser muy matemático, y supongo que necesitará algunas operaciones matriciales. OOP es muy bueno para modelar tipos de datos abstractos, y el cálculo matricial se puede implementar fácilmente como "objetos matriciales" con operaciones en matrices. Implementar esto de una manera en que todas las operaciones matriciales sean parte de una clase matricial le ayuda a mantener las cosas juntas que pertenecen juntas, manteniendo así una buena estructura general.

Por otro lado, las PDE son ecuaciones de funciones, y la solución puede volver a funcionar. Por lo tanto, utilizar un enfoque funcional para ese tipo de "componentes" puede parecer natural aquí. Esas funciones pueden tener parámetros de matriz, que muestran un ejemplo de cómo combinar OOP y FP. Otro ejemplo sería una implementación de clase de matriz, que utiliza herramientas funcionales para asignar una determinada operación a cada elemento de su matriz. Entonces, aquí, tampoco es "OOP versus FP" sino "OOP combinado con FP" lo que le brinda los mejores resultados.


¡Gracias por su respuesta! Entonces, si uso C ++, encapsularía solo los datos (es decir, los parámetros, las condiciones de contorno y el PDE en forma de matriz) del componente a un objeto y definiría las funciones (incluso algunas de orden superior, en el caso un parámetro es una función de otra cosa), fuera del alcance del objeto, que operaría en los datos del objeto, ¿sería eficiente?
heaptobesquare

@heaptobesquare: honestamente, no puedo decirte si será eficiente en tu caso. Pruébalo, piensa en grande, comienza en pequeño. Comience a programar algún "código de seguimiento " ( artima.com/intv/tracer.html ) para averiguar qué funciona mejor y qué no. Y si llega a una situación en la que nota que algo no funciona correctamente, refactorice.
Doc Brown

Haskell tiene la biblioteca Hmatrix, que es enlaces para las bibliotecas BLAS / LAPACK, y una sintaxis muy buena para ella, que elegiría personalmente sobre un enfoque OOP.
Paul

@paul: ¡Gracias, definitivamente lo echaré un vistazo! ¿Las bibliotecas de Haskell son generalmente consistentes y ricas en contenido? Los wikis lo dicen, pero ¿es esto un hecho?
heaptobesquare

@heaptobesquare: La única biblioteca de Haskell que he usado hasta cierto punto es Parsec (la usé para escribir un ensamblador), pero me encantó usarla. Solo he hecho una exploración GHCI de Hmatrix y los enlaces Haskell OpenGL, pero parecen bastante agradables. Hmatrix parece ser casi tan conciso como MATLAB (que he usado bastante), que fue hecho específicamente para ese tipo de cosas. Desde mi experiencia limitada, las bibliotecas son consistentes, esto se debe a que Haskell se basa en una pequeña cantidad de bloques de construcción simples, y también son ricas porque a los Haskellers no les gusta hacer cosas mundanas :)
Paul,
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.