¿Cuáles son las bibliotecas de álgebra lineal / matemática / matricial lineal de C ++ más utilizadas, y sus compensaciones de costo y beneficio? [cerrado]

Parece que muchos proyectos surgen lentamente de la necesidad de hacer operaciones matemáticas de matriz, y caen en la trampa de construir primero algunas clases de vectores y agregar funcionalidades lentamente hasta que quedan atrapados construyendo una biblioteca de álgebra lineal personalizada a medias y dependiendo de ello.

Me gustaría evitar eso sin construir una dependencia de alguna biblioteca relacionada tangencialmente (por ejemplo, OpenCV, OpenSceneGraph).

¿Cuáles son las bibliotecas de álgebra lineal / matemática matricial comúnmente utilizadas y por qué decidir usar una sobre otra? ¿Hay alguna que se desaconseje usar por alguna razón? Estoy usando esto específicamente en un contexto geométrico / temporal * (2,3,4 Dim) * pero puede estar usando datos de dimensiones superiores en el futuro.

Estoy buscando diferencias con respecto a cualquiera de: API, velocidad, uso de memoria, amplitud / integridad, estrechez / especificidad, extensibilidad y / o madurez / estabilidad.

Actualizar

Terminé usando Eigen3 con el que estoy extremadamente feliz.

Hay bastantes proyectos que se han decidido por el Kit de herramientas de gráficos genéricos para esto. El GMTL allí es agradable: es bastante pequeño, muy funcional y se ha utilizado lo suficiente como para ser muy confiable. OpenSG, VRJuggler y otros proyectos han cambiado a usar esto en lugar de sus propias matemáticas de vértor / matriz enrolladas a mano.

Lo encontré bastante agradable: hace todo a través de plantillas, por lo que es muy flexible y muy rápido.

Editar:

Después de la discusión de comentarios y ediciones, pensé en arrojar más información sobre los beneficios y las desventajas de implementaciones específicas, y por qué podría elegir uno sobre el otro, dada su situación.

GMTL -

Beneficios: API simple, diseñada específicamente para motores gráficos. Incluye muchos tipos primitivos orientados a la representación (como planos, AABB, quatenrions con interpolación múltiple, etc.) que no están en ningún otro paquete. Muy poca carga de memoria, bastante rápido, fácil de usar.

Desventajas: API está muy centrada específicamente en renderizado y gráficos. No incluye matrices de propósito general (NxM), descomposición y resolución de matrices, etc., ya que están fuera del ámbito de las aplicaciones tradicionales de gráficos / geometría.

Eigen -

Beneficios: API limpia , bastante fácil de usar. Incluye un módulo de geometría con cuaterniones y transformaciones geométricas. Baja carga de memoria. Resolución completa y de alto rendimiento de grandes matrices NxN y otras rutinas matemáticas de propósito general.

Desventajas: puede ser un alcance un poco mayor de lo que deseas (?). Menos rutinas geométricas / de representación específicas en comparación con GMTL (es decir: definiciones de ángulo de Euler, etc.).

IMSL -

Beneficios: Biblioteca numérica muy completa. Muy, muy rápido (supuestamente el solucionador más rápido). Con mucho, la API matemática más grande y más completa. Comercialmente soportado, maduro y estable.

Desventajas: costo - no es barato. Muy pocos métodos geométricos / renderizados específicos, por lo que necesitará rodar los suyos sobre sus clases de álgebra lineal.

NT2 -

Beneficios: proporciona una sintaxis que es más familiar si está acostumbrado a MATLAB. Proporciona descomposición completa y resolución para matrices grandes, etc.

Desventajas: Matemáticas, no renderizadas. Probablemente no sea tan eficiente como Eigen.

LAPACK -

Beneficios: algoritmos muy estables y probados. He estado por mucho tiempo. Solución matricial completa, etc. Muchas opciones para matemáticas oscuras.

Desventajas: no es tan eficiente en algunos casos. Portado de Fortran, con API impar para su uso.

Personalmente, para mí, todo se reduce a una sola pregunta: ¿cómo planea usar esto? Si su enfoque es solo el renderizado y los gráficos, me gusta Generic Graphics Toolkit , ya que funciona bien y admite muchas operaciones útiles de renderizado sin tener que implementar el suyo. Si necesita una resolución de matriz de propósito general (es decir: SVD o LU descomposición de matrices grandes), iría con Eigen , ya que maneja eso, proporciona algunas operaciones geométricas y es muy eficiente con soluciones de matriz grande. Puede que necesite escribir más de sus propios gráficos / operaciones geométricas (encima de sus matrices / vectores), pero eso no es horrible.

Por lo tanto, soy una persona bastante crítica y creo que si voy a invertir en una biblioteca, será mejor que sepa en qué me estoy metiendo. Me imagino que es mejor criticar las críticas y menospreciar los halagos al escudriñar; lo que tiene de malo tiene muchas más implicaciones para el futuro que lo que está bien. Así que voy a ir un poco por la borda aquí para proporcionar el tipo de respuesta que me habría ayudado y espero que ayude a otros que puedan recorrer este camino. Tenga en cuenta que esto se basa en la poca revisión / prueba que he hecho con estas bibliotecas. Ah, y robé algunas de las descripciones positivas de Reed.

Mencionaré arriba que fui con GMTL a pesar de su idiosincrasia porque la inseguridad de Eigen2 era una desventaja demasiado grande. Pero recientemente he aprendido que la próxima versión de Eigen2 contendrá definiciones que cerrarán el código de alineación y lo harán seguro. Entonces puedo cambiar.

Actualización : me he cambiado a Eigen3. A pesar de su idiosincrasia, su alcance y elegancia son demasiado difíciles de ignorar, y las optimizaciones que lo hacen inseguro se pueden desactivar con una definición.

Eigen2 / Eigen3

Beneficios: LGPL MPL2, API limpia, bien diseñada, bastante fácil de usar. Parece estar bien mantenido con una comunidad vibrante. Baja carga de memoria. Alto rendimiento. Hecho para álgebra lineal general, pero también dispone de buena funcionalidad geométrica. Todo el encabezado lib, no se requiere enlace.

Idiocyncracies / inconvenientes: (Algunos / todos estos pueden evitarse mediante algunas definiciones que están disponibles en la rama de desarrollo actual Eigen3)

• Las optimizaciones de rendimiento inseguras resultan en la necesidad de un seguimiento cuidadoso de las reglas. El incumplimiento de las reglas provoca accidentes.
  • simplemente no puede pasar de manera segura por valor
  • El uso de los tipos Eigen como miembros requiere una personalización especial del asignador (o se bloquea)
  • usar con tipos de contenedores stl y posiblemente otras plantillas requieren personalización de asignación especial (o se bloqueará)
  • ciertos compiladores necesitan cuidados especiales para evitar bloqueos en llamadas a funciones (ventanas GCC)

GMTL

Beneficios: LGPL, API bastante simple, diseñada específicamente para motores gráficos. Incluye muchos tipos primitivos orientados a la representación (como planos, AABB, quatenrions con interpolación múltiple, etc.) que no están en ningún otro paquete. Muy poca carga de memoria, bastante rápido, fácil de usar. Todo basado en encabezado, no es necesario vincular.

Idiocyncracies / inconvenientes:

• API es peculiar
  • lo que podría ser myVec.x () en otra biblioteca solo está disponible a través de myVec [0] (problema de legibilidad)
    • una matriz o stl :: vector de puntos puede hacer que haga algo como puntosLista [0] [0] para acceder al componente x del primer punto
  • en un ingenuo intento de optimización, eliminó cross (vec, vec) y reemplazó con makeCross (vec, vec, vec) cuando el compilador elimina las temperaturas innecesarias de todos modos
  • las operaciones matemáticas normales no devuelven tipos normales a menos que apague algunas funciones de optimización, por ejemplo: vec1 - vec2no devuelve un vector normal, por lo que length( vecA - vecB )falla aunque vecC = vecA - vecBfuncione. Debes envolver como:length( Vec( vecA - vecB ) )
  • Las operaciones en vectores son proporcionadas por funciones externas en lugar de miembros. Esto puede requerir que use la resolución del alcance en todas partes ya que los nombres de símbolos comunes pueden colisionar
  • que tienes que hacer
      length( makeCross( vecA, vecB ) )
    o
      gmtl::length( gmtl::makeCross( vecA, vecB ) )
    donde podrías intentar
      vecA.cross( vecB ).length()
    

• mal mantenido
  • todavía reclamado como "beta"
  • documentación que falta información básica como qué encabezados son necesarios para usar la funcionalidad normal
    • Vec.h no contiene operaciones para Vectores, VecOps.h contiene algunas, otras están en Generate.h, por ejemplo. cross (vec &, vec &, vec &) en VecOps.h, [make] cross (vec &, vec &) en Generate.h

• API inmadura / inestable; sigue cambiando
  • Por ejemplo, "cross" se movió de "VecOps.h" a "Generate.h", y luego el nombre se cambió a "makeCross". Los ejemplos de documentación fallan porque todavía se refieren a versiones antiguas de funciones que ya no existen.

NT2

No puedo decirlo porque parecen estar más interesados ​​en el encabezado de la imagen fractal de su página web que en el contenido. Parece más un proyecto académico que un proyecto de software serio.

Último lanzamiento hace más de 2 años.

Aparentemente no hay documentación en inglés, aunque supuestamente hay algo en francés en alguna parte.

No puedo encontrar un rastro de una comunidad alrededor del proyecto.

LAPACK Y BLAS

Beneficios: Viejo y maduro.

Desventajas:

• viejos como dinosaurios con API realmente malas

Por lo que vale, probé Eigen y Armadillo. A continuación se muestra una breve evaluación.

Ventajas de Eigen: 1. Completamente autónomo, sin dependencia de BLAS o LAPACK externos. 2. Documentación decente. 3. Supuestamente rápido, aunque no lo he puesto a prueba.

Desventaja: el algoritmo QR devuelve solo una matriz, con la matriz R incrustada en el triángulo superior. No tengo idea de dónde proviene el resto de la matriz, y no se puede acceder a ninguna matriz Q.

Ventajas del armadillo: 1. Amplia gama de descomposiciones y otras funciones (incluido QR). 2. Razonablemente rápido (usa plantillas de expresión), pero de nuevo, realmente no lo he llevado a grandes dimensiones.

Desventajas: 1. Depende de BLAS externo y / o LAPACK para descomposiciones de matriz. 2. Falta la documentación en mi humilde opinión (incluidos los detalles wrt LAPACK, aparte de cambiar una declaración #define).

Sería bueno si hubiera una biblioteca de código abierto disponible que sea autónoma y fácil de usar. Me he encontrado con este mismo problema durante 10 años, y se vuelve frustrante. En un momento, usé GSL para C y escribí envoltorios de C ++ a su alrededor, pero con C ++ moderno, especialmente usando las ventajas de las plantillas de expresión, no deberíamos tener que meternos con C en el siglo XXI. Solo mi tuppencehapenny.

Si está buscando una matriz de alto rendimiento / álgebra lineal / optimización en procesadores Intel, miraría la biblioteca MKL de Intel.

MKL está cuidadosamente optimizado para un rendimiento rápido en tiempo de ejecución, en gran parte basado en los muy maduros estándares BLAS / LAPACK fortran. Y su rendimiento aumenta con la cantidad de núcleos disponibles. La escalabilidad de manos libres con núcleos disponibles es el futuro de la informática y no usaría ninguna biblioteca matemática para un nuevo proyecto que no sea compatible con procesadores de múltiples núcleos.

Muy brevemente, incluye:

1. Operaciones básicas de vector-vector, vector-matriz y matriz-matriz
2. Factorización matricial (descomposición LU, hermitiana, dispersa)
3. Problemas de ajuste de mínimos cuadrados y valores propios
4. Solucionadores de sistemas lineales dispersos
5. Solucionador de mínimos cuadrados no lineales (regiones de confianza)
6. Más rutinas de procesamiento de señales como FFT y convolución
7. Generadores de números aleatorios muy rápidos (giro de Mersenne)
8. Mucho más ... ver: texto del enlace

Una desventaja es que la API MKL puede ser bastante compleja dependiendo de las rutinas que necesita. También puede echar un vistazo a su biblioteca IPP (Integrated Performance Primitives) que está orientada a operaciones de procesamiento de imágenes de alto rendimiento, pero que, sin embargo, es bastante amplia.

Pablo

Software CenterSpace, bibliotecas de .NET Math, centerspace.net

He escuchado cosas buenas sobre Eigen y NT2 , pero tampoco las he usado personalmente. También hay Boost.UBLAS , que creo que se está haciendo un poco largo en el diente. Los desarrolladores de NT2 están construyendo la próxima versión con la intención de ponerla en Boost, por lo que eso podría contar para algo.

Mi lin. alg. las necesidades no se extienden más allá del caso de la matriz 4x4, por lo que no puedo comentar sobre la funcionalidad avanzada; Solo estoy señalando algunas opciones.

Soy nuevo en este tema, así que no puedo decir mucho, pero BLAS es prácticamente el estándar en informática científica. BLAS es en realidad un estándar API, que tiene muchas implementaciones. Sinceramente, no estoy seguro de qué implementaciones son más populares o por qué.

Si desea también poder realizar operaciones comunes de álgebra lineal (sistemas de resolución, regresión de mínimos cuadrados, descomposición, etc.), busque en LAPACK .

¿Qué hay de GLM ?

Se basa en la especificación OpenGL Shading Language (GLSL) y se publica bajo la licencia MIT. Claramente dirigido a programadores gráficos

Agregaré voto para Eigen: porté una gran cantidad de código (geometría 3D, álgebra lineal y ecuaciones diferenciales) de diferentes bibliotecas a esta, mejorando tanto el rendimiento como la legibilidad del código en casi todos los casos.

Una ventaja que no se mencionó: es muy fácil de usar SSE con Eigen, que mejora significativamente el rendimiento de las operaciones 2D-3D (donde todo se puede rellenar a 128 bits).

De acuerdo, creo que sé lo que estás buscando. Parece que GGT es una solución bastante buena, como sugirió Reed Copsey.

Personalmente, creamos nuestra propia pequeña biblioteca, porque nos ocupamos mucho de los puntos racionales, muchos NURBS y Béziers racionales.

Resulta que la mayoría de las bibliotecas de gráficos en 3D hacen cálculos con puntos proyectivos que no tienen base en matemáticas proyectivas, porque eso es lo que le da la respuesta que desea. Terminamos usando puntos de Grassmann, que tienen una base teórica sólida y disminuyeron el número de tipos de puntos. Los puntos de Grassmann son básicamente los mismos cálculos que la gente usa ahora, con el beneficio de una teoría sólida. Lo más importante es que aclara las cosas en nuestras mentes, por lo que tenemos menos errores. Ron Goldman escribió un artículo sobre puntos de Grassmann en gráficos por computadora llamado "Sobre los fundamentos algebraicos y geométricos de los gráficos por computadora" .

No directamente relacionado con su pregunta, pero una lectura interesante.

FLENOS

http://flens.sf.net

También implementa muchas funciones de LAPACK.

Encontré esta biblioteca bastante simple y funcional ( http://kirillsprograms.com/top_Vectors.php ). Estos son vectores básicos implementados a través de plantillas C ++. Sin lujos, solo lo que necesita hacer con vectores (sumar, restar, multiplicar, punto, etc.).