Quais são as bibliotecas de álgebra linear vetorial / matriz matemática / linear C ++ mais usadas, e suas vantagens e desvantagens em custos e benefícios? [fechadas]

Parece que muitos projetos enfrentam lentamente a necessidade de fazer matemática matricial e caem na armadilha de criar primeiro algumas classes de vetores e adicionar funcionalidades lentamente até serem pegos construindo uma biblioteca de álgebra linear personalizada de meia-boca e dependendo dela.

Eu gostaria de evitar isso enquanto não cria uma dependência em alguma biblioteca relacionada tangencialmente (por exemplo, OpenCV, OpenSceneGraph).

Quais são as bibliotecas de matemática / álgebra linear de matriz comumente usadas por aí e por que decidem usar uma sobre a outra? Existe algum que não seja aconselhável usar por algum motivo? Estou usando isso especificamente em um contexto geométrico / temporal * (2,3,4 Dim) *, mas pode estar usando dados dimensionais mais altos no futuro.

Estou procurando diferenças em relação a: API, velocidade, uso de memória, abrangência / abrangência, estreiteza / especificidade, extensibilidade e / ou maturidade / estabilidade.

Atualizar

Acabei usando o Eigen3, com o qual estou extremamente feliz.

Existem alguns projetos que se adaptaram ao Generic Graphics Toolkit para isso. O GMTL é bom - é bem pequeno, muito funcional e foi usado o suficiente para ser muito confiável. O OpenSG, o VRJuggler e outros projetos passaram a usar isso em vez de suas próprias matemáticas de matriz / vertor.

Achei bastante legal - ele faz tudo via modelos, por isso é muito flexível e muito rápido.

Editar:

Após a discussão e as edições dos comentários, pensei em lançar mais algumas informações sobre os benefícios e desvantagens de implementações específicas e por que você pode escolher um sobre o outro, dada a sua situação.

GMTL -

Benefícios: API simples, projetada especificamente para mecanismos gráficos. Inclui muitos tipos primitivos voltados para a renderização (como planos, AABB, quatenrions com interpolação múltipla etc.) que não estão em nenhum outro pacote. Sobrecarga de memória muito baixa, muito rápido, fácil de usar.

Desvantagens: a API é muito focada especificamente em renderização e gráficos. Não inclui matrizes de uso geral (NxM), decomposição e resolução de matrizes, etc., pois estão fora do domínio das aplicações tradicionais de gráficos / geometria.

Eigen -

Benefícios: API limpa , bastante fácil de usar. Inclui um módulo de geometria com quaternions e transformações geométricas. Sobrecarga de memória baixa. Solução completa e de alto desempenho de grandes matrizes NxN e outras rotinas matemáticas de uso geral.

Desvantagens: pode ser um escopo um pouco maior do que você deseja (?). Menos rotinas geométricas / de renderização específicas quando comparadas ao GMTL (por exemplo: definições de ângulo de Euler, etc.).

IMSL -

Benefícios: Biblioteca numérica muito completa. Muito, muito rápido (supostamente o solucionador mais rápido). De longe, a maior e mais completa API matemática. Suporte comercial, maduro e estável.

Desvantagens: Custo - não é barato. Muito poucos métodos geométricos / de renderização específicos, portanto, você precisará rolar por cima das classes de álgebra linear.

NT2 -

Benefícios: fornece uma sintaxe mais familiar se você estiver acostumado ao MATLAB. Fornece decomposição e solução completas para matrizes grandes, etc.

Desvantagens: matemático, sem renderização focada. Provavelmente não é tão eficiente quanto Eigen.

LAPACK -

Benefícios: algoritmos comprovados e muito estáveis. Já existe há muito tempo. Resolução completa de matrizes, etc. Muitas opções para matemática obscura.

Desvantagens: Não é tão altamente eficiente em alguns casos. Portado de Fortran, com API ímpar para uso.

Pessoalmente, para mim, tudo se resume a uma única pergunta - como você planeja usar isso. Se seu foco é apenas renderização e gráficos, eu gosto do Generic Graphics Toolkit , pois ele tem um bom desempenho e suporta muitas operações úteis de renderização prontas para uso, sem a necessidade de implementar suas próprias. Se você precisar de uma solução geral para matrizes (ex .: decomposição SVD ou LU de matrizes grandes), eu usaria o Eigen , pois ele lida com isso, fornece algumas operações geométricas e é muito eficiente em soluções de matrizes grandes. Você pode precisar escrever mais operações gráficas / geométricas (além das matrizes / vetores), mas isso não é horrível.

Portanto, sou uma pessoa bastante crítica e, se vou investir em uma biblioteca, é melhor saber no que estou me metendo. Eu acho que é melhor se opor às críticas e à luz da bajulação ao examinar; o que há de errado com isso tem muito mais implicações para o futuro do que o que é certo. Então, vou exagerar um pouco aqui para fornecer o tipo de resposta que teria me ajudado e espero que ajude outras pessoas que possam seguir esse caminho. Lembre-se de que isso se baseia no pouco teste / revisão que fiz com essas bibliotecas. Ah, e roubei parte da descrição positiva de Reed.

Vou mencionar acima que fui com o GMTL, apesar das idiossincrasias, porque a insegurança do Eigen2 era muito grande como um ponto negativo. Mas eu aprendi recentemente que a próxima versão do Eigen2 conterá definições que desligarão o código de alinhamento e o tornarão seguro. Então eu posso mudar.

Atualização : mudei para o Eigen3. Apesar das idiossincrasias, seu escopo e elegância são muito difíceis de ignorar, e as otimizações que a tornam insegura podem ser desativadas com uma definição.

Eigen2 / Eigen3

Benefícios: LGPL MPL2, API limpa, bem projetada, bastante fácil de usar. Parece ser bem conservado com uma comunidade vibrante. Sobrecarga de memória baixa. Alta performance. Feito para álgebra linear geral, mas também possui boa funcionalidade geométrica. Toda a biblioteca de cabeçalho, sem necessidade de vinculação.

Idiocincracias / desvantagens: (algumas / todas elas podem ser evitadas por algumas definições disponíveis no atual ramo de desenvolvimento Eigen3)

• Otimizações de desempenho inseguras resultam na necessidade de seguir cuidadosamente as regras. O não cumprimento das regras causa falhas.
  • você simplesmente não pode transmitir com segurança o valor
  • o uso de tipos Eigen como membros requer personalização especial do alocador (ou você trava)
  • use com tipos de contêiner stl e, possivelmente, outros modelos requeiram personalização especial de alocação (ou você trava)
  • certos compiladores precisam de cuidados especiais para evitar falhas nas chamadas de função (janelas do GCC)

GMTL

Benefícios: LGPL, API bastante simples, projetada especificamente para mecanismos gráficos. Inclui muitos tipos primitivos voltados para a renderização (como planos, AABB, quatenrions com interpolação múltipla etc.) que não estão em nenhum outro pacote. Sobrecarga de memória muito baixa, muito rápido, fácil de usar. Tudo baseado em cabeçalho, sem vinculação necessária.

Idiocincracias / desvantagens:

• API é peculiar
  • o que pode ser myVec.x () em outra lib está disponível apenas via myVec [0] (problema de legibilidade)
    • uma matriz ou stl :: vetor de pontos pode fazer com que você faça algo como pointsList [0] [0] para acessar o componente x do primeiro ponto
  • numa tentativa ingênua de otimização, removeu o cross (vec, vec) e substituiu o makeCross (vec, vec, vec) quando o compilador elimina temporariamente desnecessários
  • operações matemáticas normais não retornam tipos normais, a menos que você desligue alguns recursos de otimização, por exemplo: vec1 - vec2não retorna um vetor normal, portanto length( vecA - vecB )falha mesmo que vecC = vecA - vecBfuncione. Você deve quebrar como:length( Vec( vecA - vecB ) )
  • operações em vetores são fornecidas por funções externas e não por membros. Isso pode exigir que você use a resolução do escopo em qualquer lugar, pois nomes comuns de símbolos podem colidir
  • você tem que fazer
      length( makeCross( vecA, vecB ) )
    ou
      gmtl::length( gmtl::makeCross( vecA, vecB ) )
    onde, caso contrário, você pode tentar
      vecA.cross( vecB ).length()
    

• mal conservado
  • ainda reivindicado como "beta"
  • documentação faltando informações básicas, como quais cabeçalhos são necessários para usar a funcionalidade normal
    • Vec.h não contém operações para Vetores, VecOps.h contém algumas, outras estão em Generate.h, por exemplo. cross (vec &, vec &, vec &) em VecOps.h, [make] cross (vec &, vec &) em Generate.h

• API imatura / instável; ainda mudando.
  • Por exemplo, "cross" mudou de "VecOps.h" para "Generate.h" e, em seguida, o nome foi alterado para "makeCross". Exemplos de documentação falham porque ainda se referem a versões antigas de funções que não existem mais.

NT2

Não posso dizer porque eles parecem estar mais interessados ​​no cabeçalho da imagem fractal da página da web do que no conteúdo. Parece mais um projeto acadêmico do que um projeto de software sério.

Última versão há mais de 2 anos.

Aparentemente, nenhuma documentação em inglês, embora supostamente exista algo em francês em algum lugar.

Não é possível encontrar vestígios de uma comunidade em torno do projeto.

LAPACK & BLAS

Benefícios: Antigo e maduro.

Desvantagens:

• velhos como dinossauros com APIs realmente ruins

Pelo que vale a pena, tentei Eigen e Tatu. Abaixo está uma breve avaliação.

Vantagens do Eigen: 1. Completamente independente - sem dependência de BLAS ou LAPACK externo. 2. Documentação decente. 3. Supostamente rápido, embora eu não o tenha posto à prova.

Desvantagem: O algoritmo QR retorna apenas uma matriz, com a matriz R incorporada no triângulo superior. Nenhuma ideia de onde vem o restante da matriz e nenhuma matriz Q pode ser acessada.

Vantagens do tatu: 1. Vasta gama de decomposições e outras funções (incluindo QR). 2. Razoavelmente rápido (usa modelos de expressão), mas, novamente, eu não o levei a grandes dimensões.

Desvantagens: 1. Depende do BLAS externo e / ou do LAPACK para decomposições da matriz. 2. Falta a documentação do IMHO (incluindo os específicos do LAPACK, exceto a alteração de uma declaração #define).

Seria bom se houvesse uma biblioteca de código aberto independente e fácil de usar. Corri para esse mesmo problema há 10 anos e fica frustrante. A certa altura, usei o GSL para C e escrevi wrappers em C ++, mas com o C ++ moderno - especialmente usando as vantagens dos modelos de expressão - não devemos mexer com C no século XXI. Apenas meu tuppencehapenny.

Se você está procurando matriz de alto desempenho / álgebra linear / otimização em processadores Intel, eu examinaria a biblioteca MKL da Intel.

O MKL é cuidadosamente otimizado para um desempenho rápido em tempo de execução - em grande parte, com base nos padrões muito maduros do BLAS / LAPACK fortran. E seu desempenho é escalonado com o número de núcleos disponíveis. A escalabilidade viva-voz com núcleos disponíveis é o futuro da computação e eu não usaria nenhuma biblioteca matemática para um novo projeto que não suporta processadores com vários núcleos.

Muito brevemente, inclui:

1. Operações básicas vetor-vetor, matriz-vetor e matriz-matriz
2. Fatoração matricial (LU decomp, eremita, esparsa)
3. Problemas de ajuste de mínimos quadrados e autovalores
4. Solucionadores de sistemas lineares esparsos
5. Solucionador de mínimos quadrados não lineares (regiões confiáveis)
6. Além disso, rotinas de processamento de sinal como FFT e convolução
7. Geradores de números aleatórios muito rápidos (mersenne twist)
8. Muito mais .... veja: link text

Uma desvantagem é que a API MKL pode ser bastante complexa, dependendo das rotinas necessárias. Você também pode dar uma olhada na biblioteca IPP (Integrated Performance Primitives), que é voltada para operações de processamento de imagem de alto desempenho, mas, no entanto, é bastante ampla.

Paulo

Software CenterSpace, bibliotecas .NET de matemática, centerspace.net

Ouvi coisas boas sobre Eigen e NT2 , mas também não as usei pessoalmente. Há também o Boost.UBLAS , que acredito estar demorando um pouco. Os desenvolvedores do NT2 estão construindo a próxima versão com a intenção de inseri-la no Boost, para que isso possa contar para alguma coisa.

Meu lin. alg. as necessidades não ultrapassam o caso da matriz 4x4, por isso não posso comentar sobre funcionalidades avançadas; Estou apenas apontando algumas opções.

Eu sou novo neste tópico, então não posso dizer muito, mas o BLAS é praticamente o padrão na computação científica. O BLAS é na verdade um padrão de API, que possui muitas implementações. Sinceramente, não tenho certeza de quais implementações são mais populares ou por quê.

Se você também deseja fazer operações comuns de álgebra linear (sistemas de resolução, regressão de mínimos quadrados, decomposição etc.), procure no LAPACK .

E o GLM ?

Ele é baseado na especificação OpenGL Shading Language (GLSL) e lançado sob a licença MIT. Claramente direcionado a programadores gráficos

Acrescentarei voto a Eigen: portamos muitos códigos (geometria 3D, álgebra linear e equações diferenciais) de diferentes bibliotecas para esta - melhorando o desempenho e a legibilidade do código em quase todos os casos.

Uma vantagem que não foi mencionada: é muito fácil usar o SSE com Eigen, o que melhora significativamente o desempenho das operações 2D-3D (onde tudo pode ser aumentado para 128 bits).

Ok, acho que sei o que você está procurando. Parece que o GGT é uma solução muito boa, como sugeriu Reed Copsey.

Pessoalmente, montamos nossa própria pequena biblioteca, porque lidamos muito com pontos racionais - muitos NURBS e Beziers racionais.

Acontece que a maioria das bibliotecas de gráficos 3D faz cálculos com pontos projetivos que não têm base na matemática projetiva, porque é isso que dá a resposta que você deseja. Acabamos usando pontos de Grassmann, que têm uma base teórica sólida e diminuímos o número de tipos de pontos. Os pontos de Grassmann são basicamente os mesmos cálculos que as pessoas estão usando agora, com o benefício de uma teoria robusta. Mais importante, isso torna as coisas mais claras em nossas mentes, por isso temos menos bugs. Ron Goldman escreveu um artigo sobre pontos de Grassmann em computação gráfica chamado "Sobre os fundamentos algébricos e geométricos da computação gráfica" .

Não está diretamente relacionado à sua pergunta, mas é uma leitura interessante.

FLENS

http://flens.sf.net

Também implementa muitas funções do LAPACK.

Achei essa biblioteca bastante simples e funcional ( http://kirillsprograms.com/top_Vectors.php ). Estes são vetores simples, implementados por meio de modelos C ++. Nada demais - exatamente o que você precisa fazer com vetores (adicionar, subtrair multiplicar, ponto, etc.).