Quelles sont les bibliothèques de mathématiques vectorielles / matricielles / d'algèbre linéaire C ++ les plus utilisées, et leurs compromis coûts / avantages? [fermé]

Il semble que de nombreux projets rencontrent lentement le besoin de faire des calculs matriciels, et tombent dans le piège de la première construction de certaines classes vectorielles et de l'ajout progressif de fonctionnalités jusqu'à ce qu'ils se retrouvent pris en train de créer une bibliothèque d'algèbre linéaire personnalisée à moitié déterminée, et en fonction de cela.

Je voudrais éviter cela sans créer de dépendance vis-à-vis d'une bibliothèque liée de manière tangentielle (par exemple OpenCV, OpenSceneGraph).

Quelles sont les bibliothèques de mathématiques matricielles / d'algèbre linéaire couramment utilisées, et pourquoi décideriez-vous de les utiliser les unes par rapport aux autres? Y en a-t-il qui 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 j'utiliserai peut-être des données de dimension supérieure à l'avenir.

Je recherche des différences en ce qui concerne: l'API, la vitesse, l'utilisation de la mémoire, l'étendue / l'exhaustivité, l'étroitesse / la spécificité, l'extensibilité et / ou la maturité / la stabilité.

Mettre à jour

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

Il y a pas mal de projets qui se sont installés sur le Generic Graphics Toolkit pour cela. Le GMTL est sympa - il est assez petit, très fonctionnel et utilisé assez largement pour être très fiable. OpenSG, VRJuggler et d'autres projets sont tous passés à l'utilisation de ceci au lieu de leurs propres calculs vertor / matrice roulés à la main.

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

Éditer:

Après la discussion sur les commentaires et les modifications, j'ai pensé jeter plus d'informations sur les avantages et les inconvénients de certaines implémentations, et pourquoi vous pourriez choisir l'une plutôt que l'autre, compte tenu de 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 avions, AABB, quatenrions avec interpolation multiple, etc.) qui ne figurent dans aucun autre package. Très faible surcharge de mémoire, assez rapide, facile à utiliser.

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

Eigen -

Avantages: API propre , assez facile à utiliser. Comprend un module de géométrie avec quaternions et transformations géométriques. Faible surcharge de mémoire. Résolution complète et hautement performante de grandes matrices NxN et d'autres routines mathématiques à usage général.

Inconvénients: la portée peut être un peu plus grande que vous ne le souhaitez (?). Moins de routines spécifiques de géométrie / rendu par rapport à GMTL (ie: définitions d'angle d'Euler, etc.)

IMSL -

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

Inconvénients: coût - pas bon marché. Très peu de méthodes spécifiques géométriques / de rendu, vous devrez donc rouler les vôtres au-dessus de leurs classes d'algèbre linéaire.

NT2 -

Avantages: fournit une syntaxe plus familière si vous êtes habitué à MATLAB. Fournit une décomposition et une résolution complètes pour les grandes matrices, etc.

Inconvénients: mathématique, pas de rendu focalisé. Probablement pas aussi performant qu'Eigen.

LAPACK -

Avantages: algorithmes très stables et éprouvés. Je suis là depuis longtemps. Résolution complète de la matrice, etc. De nombreuses options pour les mathématiques obscures.

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

Personnellement, pour moi, cela se résume à une seule question - comment envisagez-vous d'utiliser cela. Si vous vous concentrez uniquement sur le rendu et les graphiques, j'aime Generic Graphics Toolkit , car il fonctionne bien et prend en charge de nombreuses opérations de rendu utiles sans avoir à implémenter les vôtres. Si vous avez besoin d'une résolution de matrice à usage général (par exemple: décomposition SVD ou LU de grandes matrices), j'irais avec Eigen , car il gère cela, fournit certaines opérations géométriques et est très performant avec des solutions de matrice de grande taille. Vous devrez peut-être écrire davantage de vos propres graphiques / opérations géométriques (au-dessus de leurs matrices / vecteurs), mais ce n'est pas horrible.

Je suis donc une personne assez critique, et je suppose que si j'investis dans une bibliothèque, je ferais mieux de savoir dans quoi je me mets. Je pense qu'il vaut mieux aller lourdement sur la critique et la lumière sur la flatterie lors de l'examen; ce qui ne va pas a beaucoup plus d'implications pour l'avenir que ce qui est bien. Je vais donc aller un peu trop loin ici pour fournir le type de réponse qui m'aurait aidé et j'espère que cela aidera ceux qui pourraient suivre cette voie. Gardez à l'esprit que cela est basé sur le peu de révision / test que j'ai fait avec ces bibliothèques. Oh et j'ai volé une partie de la description positive de Reed.

Je mentionnerai en haut que je suis allé avec GMTL malgré ses particularités parce que l'insécurité Eigen2 était trop grosse d'un inconvénient. Mais j'ai récemment appris que la prochaine version d'Eigen2 contiendra des définitions qui arrêteront le code d'alignement et le rendront sûr. Je peux donc basculer.

Mise à jour : je suis passé à Eigen3. Malgré ses particularités, 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 et bien conçue, assez facile à utiliser. Semble être bien entretenu avec une communauté dynamique. Faible surcharge de mémoire. Haute performance. Conçu pour l'algèbre linéaire générale, mais une bonne fonctionnalité géométrique est également disponible. Tous les en-têtes lib, aucun lien requis.

Idiocyncracies / inconvénients: (Certains / tous peuvent être évités par certaines définitions disponibles dans la branche de développement actuelle Eigen3)

• Les optimisations de performances dangereuses entraînent la nécessité de suivre attentivement les règles. Le non-respect des règles provoque des plantages.
  • vous ne pouvez tout simplement pas passer la valeur en toute sécurité
  • l'utilisation de types propres en tant que membres nécessite une personnalisation spéciale de l'allocateur (ou vous vous plantez)
  • utiliser avec les types de conteneurs stl et éventuellement d'autres modèles requis personnalisation d'allocation spéciale (ou vous planterez)
  • certains compilateurs ont besoin d'une attention particulière pour éviter les plantages lors d'appels de fonction (fenêtres GCC)

GMTL

Avantages: LGPL, Fairly Simple API, spécialement conçu pour les moteurs graphiques. Comprend de nombreux types primitifs orientés vers le rendu (tels que les avions, AABB, quatenrions avec interpolation multiple, etc.) qui ne figurent dans aucun autre package. Très faible surcharge de mémoire, assez rapide, facile à utiliser. Tous basés sur l'en-tête, aucun lien nécessaire.

Idiocyncracies / inconvénients:

• L'API est originale
  • ce qui pourrait être myVec.x () dans une autre bibliothèque n'est disponible que via myVec [0] (problème de lisibilité)
    • un tableau ou un vecteur stl :: de points peut vous amener à faire quelque chose comme pointsList [0] [0] pour accéder au composant x du premier point
  • dans une tentative naïve d'optimisation, supprimé le cross (vec, vec) et remplacé par makeCross (vec, vec, vec) lorsque le compilateur élimine de toute façon les temps inutiles
  • les opérations mathématiques normales ne renvoient pas de types normaux, sauf si vous désactivez certaines fonctionnalités d'optimisation, par exemple: vec1 - vec2ne renvoie pas de vecteur normal, donc length( vecA - vecB )échoue même si cela vecC = vecA - vecBfonctionne. Vous devez envelopper comme:length( Vec( vecA - vecB ) )
  • les opérations sur les vecteurs sont fournies par des fonctions externes plutôt que par des membres. Cela peut vous obliger à utiliser la résolution de portée partout car 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 bien entretenu
  • toujours revendiqué comme "beta"
  • documentation manquante d'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, d'autres sont dans Generate.h par exemple. cross (vec &, vec &, vec &) dans VecOps.h, [make] cross (vec &, vec &) dans Generate.h

• API immature / instable; toujours en train de changer.
  • Par exemple, "cross" est passé de "VecOps.h" à "Generate.h", puis le nom a été changé en "makeCross". Les exemples de documentation échouent car se réfèrent toujours à d'anciennes versions de fonctions qui n'existent plus.

NT2

Je ne peux pas le dire car ils semblent être plus intéressés par l'en-tête de l'image fractale de leur page Web que par le contenu. Ressemble plus à un projet académique qu'à un projet logiciel sérieux.

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

Apparemment, aucune documentation en anglais, bien qu'il y ait quelque chose en français quelque part.

Impossible de trouver une trace d'une communauté autour du projet.

LAPACK & BLAS

Avantages: vieux et mature.

Inconvénients:

• vieux comme des dinosaures avec des API vraiment merdiques

Pour ce que ça vaut, j'ai essayé Eigen et Armadillo. Voici une brève évaluation.

Avantages propres: 1. Complètement autonome - pas de dépendance vis-à-vis du BLAS externe ou du LAPACK. 2. Documentation décente. 3. prétendument rapide, même si je ne l'ai pas mis à l'épreuve.

Inconvénient: l'algorithme QR ne renvoie qu'une seule matrice, la matrice R étant intégrée dans le triangle supérieur. Aucune idée d'où vient le reste de la matrice, et aucune matrice Q n'est accessible.

Avantages du tatou: 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 du BLAS externe et / ou du LAPACK pour les décompositions matricielles. 2. La documentation manque à mon humble avis (y compris les détails par rapport à LAPACK, autre que la modification d'une instruction #define).

Ce serait bien si une bibliothèque open source était disponible, autonome et simple à utiliser. Je rencontre ce même problème depuis 10 ans, et ça devient frustrant. À un moment donné, j'ai utilisé GSL pour C et j'ai écrit des wrappers 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 à jouer avec C au 21e siècle. Juste mon tuppencehapenny.

Si vous recherchez une matrice haute performance / algèbre linéaire / optimisation sur les processeurs Intel, je regarderais la bibliothèque MKL d'Intel.

MKL est soigneusement optimisé pour des performances d'exécution rapides - en grande partie sur la base des normes fortran BLAS / LAPACK très matures. Et ses performances évoluent avec le nombre de cœurs disponibles. L'évolutivité mains libres avec les cœurs disponibles est l'avenir de l'informatique et je n'utiliserais aucune bibliothèque mathématique pour un nouveau projet ne prenant pas en charge les processeurs multicœurs.

Très brièvement, il comprend:

1. Opérations vectorielles, vectorielles et matricielles de base
2. Factorisation matricielle (LU decomp, hermitian, sparse)
3. Ajustement des moindres carrés et problèmes de valeurs propres
4. Solveurs de systèmes linéaires clairsemés
5. Solveur des moindres carrés non linéaire (régions de confiance)
6. Plus des routines de traitement du signal telles que la FFT et la convolution
7. Générateurs de nombres aléatoires très rapides (torsion de mersenne)
8. Beaucoup plus .... voir: texte du lien

Un inconvénient est que l'API MKL peut être assez complexe en fonction des routines dont vous avez besoin. Vous pouvez également jeter un coup d'œil à leur bibliothèque IPP (Integrated Performance Primitives) qui est orientée vers des opérations de traitement d'image hautes performances, mais qui est néanmoins assez large.

Paul

Logiciel CenterSpace, bibliothèques mathématiques .NET, Centerspace.net

J'ai entendu de bonnes choses sur Eigen et NT2 , mais je ne les ai pas utilisées personnellement non plus. Il y a aussi Boost.UBLAS , qui, je crois, devient un peu long dans la dent. Les développeurs de NT2 sont en train de construire la prochaine version avec l'intention de l'intégrer dans Boost, donc cela pourrait compter pour quelque chose.

Mon lin. alg. les besoins ne dépassent pas le cas de la matrice 4x4, donc je ne peux pas commenter les fonctionnalités avancées; Je souligne simplement quelques options.

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

Si vous voulez également pouvoir effectuer des opérations d'algèbre linéaire courantes (résolution de systèmes, régression des moindres carrés, décomposition, etc.), examinez LAPACK .

Et GLM ?

Il est basé sur la spécification OpenGL Shading Language (GLSL) et publié sous la licence MIT. Destiné clairement aux programmeurs graphiques

J'ajouterai un vote pour Eigen: j'ai porté beaucoup de code (géométrie 3D, algèbre linéaire et équations différentielles) de différentes bibliothèques à celle-ci - améliorant à la fois les performances et la lisibilité du code dans presque tous les cas.

Un avantage qui n'a pas été mentionné: il est très facile d'utiliser SSE avec Eigen, ce qui améliore considérablement les performances des opérations 2D-3D (où tout peut être complété à 128 bits).

D'accord, je pense que je sais ce que vous cherchez. Il semble que GGT soit une assez bonne solution, comme l'a suggéré Reed Copsey.

Personnellement, nous avons lancé notre propre petite bibliothèque, car nous traitons beaucoup de points rationnels - beaucoup de NURBS et de Béziers rationnels.

Il s'avère que la plupart des bibliothèques graphiques 3D effectuent des calculs avec des points projectifs qui n'ont aucune base en mathématiques projectives, car c'est ce qui vous donne la réponse que vous voulez. Nous avons fini par utiliser les points Grassmann, qui ont une solide base théorique et ont diminué le nombre de types de points. Les points de Grassmann sont essentiellement les mêmes calculs que ceux que nous utilisons actuellement, avec l'avantage d'une théorie robuste. Plus important encore, cela rend les choses plus claires dans nos esprits, nous avons donc moins de bugs. Ron Goldman a écrit un article sur les points Grassmann en infographie appelé "Sur les fondements algébriques et géométriques de l'infographie" .

Pas directement lié à votre question, mais une lecture intéressante.

FLENS

http://flens.sf.net

Il implémente également de nombreuses fonctions LAPACK.

J'ai trouvé cette bibliothèque assez simple et fonctionnelle ( http://kirillsprograms.com/top_Vectors.php ). Ce sont des vecteurs nus mis en œuvre via des modèles C ++. Pas de fantaisie - juste ce que vous devez faire avec les vecteurs (ajouter, soustraire multiplier, dot, etc.).