una librerias libreria lenguaje las funciones dev crear contenido como c++ math matrix linear-algebra

librerias - ¿Cuáles son las bibliotecas de álgebra lineal, vectoriales/matrices/álgebra de C++ más utilizadas y sus costos y beneficios en la compensación?



librerias de dev c++ (11)

Parece que muchos proyectos surgen lentamente por la necesidad de hacer matrices matemáticas, y caen en la trampa de construir primero algunas clases de vectores y agregar lentamente la funcionalidad hasta que se los atrapa construyendo una biblioteca de álgebra lineal personalizada a medias y dependiendo de ello.

Me gustaría evitar eso mientras no construyo una dependencia en alguna biblioteca relacionada tangencialmente (por ejemplo, OpenCV, OpenSceneGraph).

¿Cuáles son las bibliotecas de matriz / álgebra lineal comúnmente utilizadas por ahí, y por qué decidiríamos usar una sobre otra? ¿Hay alguna que se desaconseje el uso por alguna razón? Lo estoy usando específicamente en un contexto geométrico / de tiempo * (2,3,4 Dim) * pero es posible que esté usando datos de dimensiones más altas 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.

¿Qué pasa con GLM ?

Se basa en la especificación del lenguaje de sombreado de OpenGL (GLSL) y se publica bajo la licencia MIT. Claramente dirigido a los programadores gráficos.

Agregaré vote por Eigen: porté una gran cantidad de código (geometría 3D, álgebra lineal y ecuaciones diferenciales) desde diferentes bibliotecas a esta, mejorando el rendimiento y 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, lo que mejora significativamente el rendimiento de las operaciones 2D-3D (donde todo se puede rellenar a 128 bits).

Así que soy una persona bastante crítica, y imagino que si voy a invertir en una biblioteca, es mejor que sepa en qué me estoy metiendo. Me imagino que es mejor ir pesados ​​sobre la crítica y ligero sobre la adulación al examinar; lo que tiene de malo tiene muchas más implicaciones para el futuro que lo que es correcto. Así que me voy por la borda aquí un poco para proporcionar el tipo de respuesta que me habría ayudado y espero que ayude a otros que puedan transitar por este camino. Tenga en cuenta que esto se basa en lo poco que he revisado / probado que he hecho con estas librerías. Ah, y robé parte de la descripción positiva de Reed.

Mencionaré que fui con GMTL a pesar de su idiosincrasia porque la falta de seguridad de Eigen2 era 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. Así que puedo cambiarme.

Actualización : 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 pueden desactivarse con una definición.

Eigen2 / Eigen3

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

Idiocyncracies / downsides: (Algunos / todos estos pueden ser evitados por 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 se puede pasar de forma segura
    • el uso de tipos Eigen como miembros requiere una personalización especial del asignador (o usted falla)
    • el uso con los tipos de contenedores stl y posiblemente otras plantillas requieren personalización de asignación especial (o se bloqueará)
    • ciertos compiladores necesitan un cuidado especial para evitar bloqueos en las llamadas de función (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, cuadrantes con interpolación múltiple, etc.) que no están en ningún otro paquete. Muy baja sobrecarga de memoria, bastante rápida, fácil de usar. Todo el encabezado basado, sin vinculación necesaria.

Idiocyncracies / downsides:

  • 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 pointsList [0] [0] para acceder al componente x del primer punto
    • en un intento ingenuo de optimización, se eliminaron las referencias cruzadas (vec, vec) y se reemplazaron por makeCross (vec, vec, vec) cuando el compilador elimina las temperaturas innecesarias de todos modos
    • las operaciones matemáticas normales no devuelven los tipos normales a menos que desactive algunas funciones de optimización, por ejemplo: vec1 - vec2 no devuelve un vector normal, por lo que la length( vecA - vecB ) falla a pesar de que vecC = vecA - vecB funciona. 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 de alcance en todas partes, ya que los nombres de símbolos comunes pueden colisionar
    • tu tienes que hacer
      length( makeCross( vecA, vecB ) )
      o
      gmtl::length( gmtl::makeCross( vecA, vecB ) )
      donde de otra manera podrías intentarlo
      vecA.cross( vecB ).length()
  • no bien mantenido
    • aún se reclama como "beta"
    • documentación que falta información básica, como qué encabezados se necesitan 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 ha movido 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 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 & BLAS

Beneficios: viejo y maduro.

Desventajas:

  • viejos como dinosaurios con APIs realmente malos

Encontré esta biblioteca bastante simple y funcional ( http://kirillsprograms.com/top_Vectors.php ). Estos son vectores de huesos descubiertos implementados a través de plantillas de C ++. No hay cosas extravagantes, solo lo que necesita hacer con los vectores (sumar, restar multiplicar, puntos, etc.).

Está bien, 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 tratamos con muchos puntos racionales, muchas NURBS racionales y Beziers.

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

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

Hay bastantes proyectos que se han basado en el Kit de herramientas de gráficos genéricos para esto. El GMTL allí es bueno: es bastante pequeño, muy funcional y se ha utilizado ampliamente para ser muy confiable. OpenSG, VRJuggler y otros proyectos han cambiado a usar esto en lugar de su propio vertor / matriz matemática.

Me ha parecido bastante agradable: lo 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 los comentarios y las ediciones, pensé que iba a arrojar más información sobre los beneficios y desventajas de implementaciones específicas, y por qué podría elegir una sobre la otra, dada su situación.

GMTL -

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

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

Eigen -

Beneficios: API limpia , bastante fácil de usar. Incluye un módulo de geometría con cuaterniones y transformadas geométricas. Baja sobrecarga 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 más grande de lo que quieres (?). Menos rutinas específicas de representación geométrica / en comparación con GMTL (es decir, definiciones de ángulos de Euler, etc.).

IMSL -

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

Desventajas: Costo - no es barato. Muy pocos métodos específicos de representación geométrica, por lo que deberá rodar los suyos por encima de sus clases de álgebra lineal.

NT2 -

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

Desventajas: Matemática, no enfocado. Probablemente no sea tan performante como Eigen.

LAPACK -

Beneficios: algoritmos muy estables y probados. Ha estado alrededor por mucho tiempo. Completa la resolución de matrices, etc. Muchas opciones para las matemáticas oscuras.

Desventajas: No es tan alto rendimiento en algunos casos. Portado desde Fortran, con API impar para uso.

Personalmente, para mí, todo se reduce a una sola pregunta: ¿cómo planea usar esto? Si se enfoca solo en renderizado y gráficos, me gusta Generic Graphics Toolkit , ya que funciona bien y es compatible con muchas operaciones de renderizado útiles sin tener que implementar el suyo. Si necesita una solución matricial de propósito general (es decir, la descomposición SVD o LU de matrices grandes), Eigen por Eigen , ya que se encarga de eso, proporciona algunas operaciones geométricas y es muy eficaz con soluciones matriciales grandes. Es posible que debas escribir más de tus propios gráficos / operaciones geométricas (además de sus matrices / vectores), pero eso no es horrible.

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

Mi lin alg. las necesidades no superan el caso de la matriz 4x4, por lo que no puedo comentar sobre la funcionalidad avanzada; Solo estoy señalando algunas opciones.

Por lo que vale, he probado tanto Eigen como Armadillo. A continuación se muestra una breve evaluación.

Ventajas de Eigen: 1. Totalmente autónomo: no depende de BLAS o LAPACK externos. 2. Documentación decente. 3. Supuestamente rápido, aunque no lo he probado.

Desventaja: el algoritmo QR devuelve solo una matriz, con la matriz R incrustada en el triángulo superior. No tengo idea de dónde viene 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 (incluyendo QR). 2. Razonablemente rápido (usa plantillas de expresión), pero, una vez más, no lo he llevado a grandes dimensiones.

Desventajas: 1. Depende de BLAS externos y / o LAPACK para descomposiciones matriciales. 2. Falta documentación IMHO (incluidos los detalles específicos de LAPACK, aparte de cambiar una declaración #define).

Estaría bien si hubiera una biblioteca de código abierto disponible que sea independiente y fácil de usar. Me he topado con este mismo problema durante 10 años, y se pone frustrante. En un momento, utilicé 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. Sólo mi tuppencehapenny.

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

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

Muy brevemente, incluye:

  1. Operaciones básicas de vector-vector, vector-matriz y matriz-matriz
  2. Factorización matricial (descomp. LU, hermitiana, escasa)
  3. Ajuste de mínimos cuadrados y problemas de valor propio
  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 mersenne)
  8. Mucho más .... ver: enlace de texto

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

Pablo

CenterSpace Software, bibliotecas .NET Math, centerspace.net

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

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