Quelles sont les bibliothèques de mathématiques vectorielles/matricielles/algébriques linéaires C++ les plus utilisées, ainsi que leurs coûts et avantages ?

Question

Il semble que de nombreux projets se heurtent peu à peu à la nécessité de faire des calculs matriciels et tombent dans le piège de construire d'abord quelques classes vectorielles et d'ajouter lentement des fonctionnalités jusqu'à ce qu'ils se retrouvent à construire une bibliothèque d'algèbre linéaire personnalisée et à en dépendre.

J'aimerais éviter cela tout en ne construisant pas une dépendance sur une bibliothèque tangentiellement liée (par exemple OpenCV, OpenSceneGraph).

Quelles sont les bibliothèques de mathématiques matricielles et d'algèbre linéaire les plus couramment utilisées, et pourquoi décider d'en utiliser une plutôt qu'une autre ? Y a-t-il des bibliothèques qu'il serait déconseillé d'utiliser pour une raison quelconque ? Je l'utilise spécifiquement dans un contexte géométrique/temporel*(2,3,4 Dim)* mais il se peut que j'utilise des données de plus grande dimension à l'avenir.

Je cherche des différences par rapport à n'importe lequel de ces éléments : API, vitesse, utilisation de la mémoire, ampleur/complétude, étroitesse/spécificité, extensibilité, et/ou maturité/stabilité.

Mise à jour

J'ai fini par utiliser Eigen3 dont je suis extrêmement satisfait.

Answer 1

Il existe un certain nombre de projets qui se sont installés sur le site de l'Union européenne. Boîte à outils graphique générique pour cela. Le GMTL qu'il contient est agréable - il est assez petit, très fonctionnel, et a été utilisé assez largement pour être très fiable. OpenSG, VRJuggler, et d'autres projets sont tous passés à l'utilisation de cette méthode au lieu de leurs propres calculs de vertor/matrix.

Je l'ai trouvé très agréable - il fait tout via des modèles, il est donc très flexible et très rapide.

---

Edit :

Après la discussion sur les commentaires, et les modifications, j'ai pensé que je pourrais donner plus d'informations sur les avantages et les inconvénients des implémentations spécifiques, et pourquoi vous pourriez choisir l'une plutôt que l'autre, selon votre situation.

GMTL -

Avantages : API simple, spécialement conçue pour les moteurs graphiques. Comprend de nombreux types primitifs orientés vers le rendu (tels que les plans, AABB, quatenrions avec interpolation multiple, etc) qui ne sont pas dans d'autres paquets. Très faible consommation de mémoire, assez rapide, facile à utiliser.

Inconvénients : L'API est très axée spécifiquement sur le rendu et les graphiques. Elle n'inclut pas les matrices d'usage général (NxM), la décomposition et la résolution de matrices, etc., car elles ne font pas partie du domaine des applications graphiques/géométriques traditionnelles.

Eigen -

Avantages : API propre assez facile à utiliser. Comprend un Module de géométrie avec les quaternions et les transformées géométriques. Faible consommation de mémoire. Complet, hautement performant résolution de grandes matrices NxN et autres routines mathématiques d'usage général.

Inconvénients : Le champ d'application peut être un peu plus large que ce que vous souhaitez ( ?). Moins de routines spécifiques à la géométrie et au rendu par rapport à GMTL (par exemple : définitions des angles d'Euler, etc.).

IMSL -

Avantages : Bibliothèque numérique très complète. Très, très rapide (supposé être le solveur le plus rapide). De loin l'API mathématique la plus grande et la plus complète. Supporté commercialement, mature et stable.

Inconvénients : Coût - pas bon marché. Très peu de méthodes spécifiques à la géométrie et au rendu, vous devrez donc vous débrouiller en plus de leurs cours d'algèbre linéaire.

NT2 -

Avantages : Fournit une syntaxe qui est plus familière si vous êtes habitué à MATLAB. Permet la décomposition complète et la résolution de grandes matrices, etc.

Inconvénients : Mathématique, pas axé sur le rendu. Probablement pas aussi performant que Eigen.

LAPACK -

Avantages : Très stable, algorithmes éprouvés. Existent depuis longtemps. Résolution complète de matrices, etc. Nombreuses options pour les mathématiques obscures.

Inconvénients : Pas aussi performant dans certains cas. Porté depuis Fortran, avec une API bizarre pour l'utilisation.

Personnellement, pour moi, cela se résume à une seule question : comment comptez-vous l'utiliser ? Si vous vous concentrez uniquement sur le rendu et les graphiques, j'aime bien Boîte à outils graphique générique Il s'agit d'un outil très performant, qui prend en charge de nombreuses opérations de rendu utiles sans avoir à mettre en œuvre les vôtres. Si vous avez besoin de résoudre des matrices de manière générale (par exemple, décomposition SVD ou LU de grandes matrices), j'opterais pour Eigen puisqu'il gère cela, fournit quelques opérations géométriques, et est très performant avec les solutions de grandes matrices. Vous devrez peut-être écrire vos propres opérations graphiques/géométriques (sur leurs matrices/vecteurs), mais ce n'est pas horrible.

Answer 2

Je suis donc assez critique et je me dis que si je dois investir dans une bibliothèque, il vaut mieux que je sache dans quoi je m'engage. Je pense qu'il est préférable d'y aller à fond dans la critique et à fond dans la flatterie lorsque l'on examine un ouvrage ; ce qui est mauvais a beaucoup plus d'implications pour l'avenir que ce qui est bon. Je vais donc m'aventurer un peu trop loin pour fournir le genre de réponse qui m'aurait aidé et qui, je l'espère, aidera d'autres personnes qui pourraient emprunter cette voie. Gardez à l'esprit que ceci est basé sur le peu d'examen/test que j'ai fait avec ces librairies. Oh et j'ai volé une partie de la description positive de Reed.

Je mentionnerai d'emblée que j'ai choisi GMTL malgré ses particularités, car l'insécurité d'Eigen2 était un trop gros inconvénient. Mais j'ai récemment appris que la prochaine version d'Eigen2 contiendra des définitions qui désactiveront le code d'alignement, et le rendront sûr. Il se peut donc que je change de système.

Mise à jour : Je suis passé à Eigen3. Malgré ses idiosyncrasies, sa portée et son élégance sont trop difficiles à ignorer, et les optimisations qui le rendent dangereux peuvent être désactivées avec une définition.

Eigen2/Eigen3

Avantages : LGPL MPL2, API propre, bien conçue, assez facile à utiliser. Semble être bien maintenu avec une communauté dynamique. Faible surcharge mémoire. Haute performance. Conçu pour l'algèbre linéaire générale, mais de bonnes fonctionnalités géométriques sont également disponibles. Toutes les librairies d'en-tête, aucune liaison requise.

Idiocyncraties/downsides : (Certains ou tous ces problèmes peuvent être évités grâce à des définitions disponibles dans la base de données de l'UE. la branche de développement actuelle Eigen3)

• Les optimisations de performances non sûres nécessitent de suivre attentivement les règles. Le non-respect des règles entraîne des plantages.
  • vous ne pouvez tout simplement pas passer par valeur en toute sécurité
  • l'utilisation de types Eigen comme membres nécessite une personnalisation spéciale de l'allocateur (ou vous vous plantez)
  • utilisation avec les types de conteneurs stl et éventuellement d'autres modèles requis personnalisation de l'allocation spéciale (ou vous allez vous planter)
  • certains compilateurs nécessitent une attention particulière pour éviter les plantages sur les appels de fonction (GCC Windows)

GMTL

Avantages : LGPL, API assez simple, spécifiquement conçue pour les moteurs graphiques. Comprend de nombreux types primitifs orientés vers le rendu (comme les les plans, AABB, quatenrions avec interpolation multiple, etc. ) qui ne sont pas dans d'autres paquets. Très faible consommation de mémoire, assez rapide, facile à utiliser. Tout est basé sur les en-têtes, aucune liaison n'est nécessaire.

Idiocyncraties/downsides :

• L'API est excentrique

  • ce qui pourrait être myVec.x() dans une autre librairie est uniquement disponible via myVec[0] (problème de lisibilité)
    • un tableau ou stl::vector de points peut vous amener à faire quelque chose comme pointsList[0][0] pour accéder à la composante x du premier point
  • dans une tentative naïve d'optimisation, a supprimé cross(vec,vec) et remplacé par makeCross(vec,vec,vec) quand le compilateur élimine de toute façon les temps inutiles de toute façon
  • les opérations mathématiques normales ne renvoient pas de types normaux, à moins que vous ne fermiez que vous ne désactiviez certaines fonctions d'optimisation, par exemple vec1 - vec2 ne renvoie pas un vecteur normal, donc length( vecA - vecB ) échoue même si vecC = vecA - vecB œuvres. Vous devez emballer comme : length( Vec( vecA - vecB ) )
  • les opérations sur les vecteurs sont assurées par des fonctions externes plutôt que par des membres. Cela peut vous obliger à utiliser la résolution de portée partout puisque les noms de symboles communs peuvent entrer en collision
  • vous devez faire
    length( makeCross( vecA, vecB ) )
    ou
    gmtl::length( gmtl::makeCross( vecA, vecB ) )
    où sinon vous pourriez essayer
    vecA.cross( vecB ).length()

• pas d'entretien bien fait

  • toujours revendiqué comme "bêta".
  • Il manque à la documentation des informations de base comme les en-têtes nécessaires pour utiliser la fonctionnalité normale
    • Vec.h ne contient pas d'opérations pour les vecteurs, VecOps.h en contient quelques-unes. certaines, d'autres sont dans Generate.h par exemple. cross(vec&,vec&,vec&) in VecOps.h, [make]cross(vec&,vec&) in Generate.h

• API immature/instable ; toujours en évolution.

  • Par exemple, "cross" est passé de "VecOps.h" à "Generate.h", et puis le nom a été changé en "makeCross". Les exemples de documentation échouent car ils font toujours référence à d'anciennes versions de fonctions qui n'existent plus.

NT2

Impossible à dire car ils semblent plus intéressés par l'image fractale de l'en-tête de leur page web que par le contenu. Cela ressemble plus à un projet universitaire qu'à un projet logiciel sérieux.

Dernière version il y a plus de 2 ans.

Apparemment, il n'y a pas de documentation en anglais, mais il y aurait quelque chose en français quelque part.

On ne trouve pas trace d'une communauté autour du projet.

LAPACK & BLAS

Avantages : Vieux et mature.

Inconvénients :

• vieux comme des dinosaures avec des API vraiment merdiques

Answer 3

Pour ce que ça vaut, j'ai essayé Eigen et Armadillo. Vous trouverez ci-dessous une brève évaluation.

Eigen Avantages : 1. Complètement autonome -- aucune dépendance vis-à-vis de BLAS ou LAPACK externes. 2. Documentation décente. 3. Soi-disant rapide, bien que je ne l'aie pas testé.

Inconvénient : L'algorithme QR ne renvoie qu'une seule matrice, avec la matrice R intégrée dans le triangle supérieur. On ne sait pas d'où vient le reste de la matrice, et on ne peut pas accéder à la matrice Q.

Tatouage Avantages : 1. Large gamme de décompositions et autres fonctions (y compris QR). 2. Raisonnablement rapide (utilise des modèles d'expression), mais encore une fois, je ne l'ai pas vraiment poussé à des dimensions élevées.

Inconvénients : 1. Dépend de BLAS et/ou LAPACK externes pour les décompositions de matrices. 2. La documentation est insuffisante à mon avis (y compris les spécificités de LAPACK, autres que la modification d'une déclaration #define).

Ce serait bien s'il existait une bibliothèque open source autonome et simple d'utilisation. Je me heurte à ce même problème depuis 10 ans, et cela devient frustrant. À un moment donné, j'ai utilisé GSL pour le C et j'ai écrit des enveloppes C++ autour de lui, mais avec le C++ moderne - en particulier en utilisant les avantages des modèles d'expression - nous ne devrions pas avoir à nous embêter avec le C au 21e siècle. C'est juste mon avis.

Answer 4

J'ai entendu de bonnes choses sur Eigen y NT2 mais je n'ai personnellement utilisé ni l'un ni l'autre. Il y a aussi Boost.UBLAS qui, à mon avis, commence à avoir de la gueule. Les développeurs de NT2 construisent la prochaine version avec l'intention de l'intégrer à Boost, ce qui peut compter pour quelque chose.

Mes besoins en alg. lin. ne dépassent pas le cas des matrices 4x4, je ne peux donc pas me prononcer sur les fonctionnalités avancées ; je ne fais que signaler quelques options.

Answer 5

Je suis nouveau sur ce sujet, donc je ne peux pas dire grand chose, mais BLAS est à peu près la norme en matière de calcul scientifique. BLAS est en fait un standard API, qui a de nombreuses implémentations. Honnêtement, je ne sais pas quelles implémentations sont les plus populaires ni pourquoi.

Si vous souhaitez également être en mesure d'effectuer des opérations courantes d'algèbre linéaire (résolution de systèmes, régression par les moindres carrés, décomposition, etc. LAPACK .