Jakie są najczęściej używane biblioteki matematyczne / algebry liniowej C ++ w wektorach C ++ oraz jakie są ich koszty i korzyści? [Zamknięte]

Wydaje się, że w wielu projektach powoli pojawia się potrzeba matematyki matematycznej i wpadają w pułapkę zbudowania klas klas wektorowych i stopniowego dodawania funkcjonalności, dopóki nie zostaną przyłapani na budowaniu na wpół ocenianej niestandardowej biblioteki algebry liniowej i zależnie od niej.

Chciałbym tego uniknąć, nie budując zależności od jakiejś stycznie powiązanej biblioteki (np. OpenCV, OpenSceneGraph).

Jakie są powszechnie używane biblioteki matematyczne / algebry liniowe i dlaczego mieliby decydować się na ich użycie? Czy są jakieś odradzane z jakiegoś powodu? Używam tego konkretnie w kontekście geometrycznym / czasowym * (2,3,4 Dim) *, ale w przyszłości mogę używać danych o wyższych wymiarach.

Szukam różnic w odniesieniu do któregokolwiek z: API, szybkości, wykorzystania pamięci, szerokości / kompletności, wąskości / specyficzności, rozszerzalności i / lub dojrzałości / stabilności.

Aktualizacja

Skończyło się na Eigen3, z którego jestem bardzo zadowolony.

Istnieje wiele projektów, które zdecydowały się na to w Generic Graphics Toolkit . Znajdujący się tam GMTL jest fajny - jest dość mały, bardzo funkcjonalny i był używany na tyle szeroko, aby był niezawodny. OpenSG, VRJuggler i inne projekty przeszły na używanie tego zamiast własnej, ręcznie toczonej matematyki vertor / matrix.

Uważam, że jest całkiem fajny - robi wszystko za pomocą szablonów, więc jest bardzo elastyczny i bardzo szybki.

Edytować:

Po dyskusji na temat komentarzy i zmianach pomyślałem, że przekażę więcej informacji o zaletach i wadach konkretnych wdrożeń oraz o tym, dlaczego możesz wybrać jedną z nich, biorąc pod uwagę twoją sytuację.

GMTL -

Korzyści: prosty interfejs API, specjalnie zaprojektowany dla silników graficznych. Obejmuje wiele prymitywnych typów ukierunkowanych na renderowanie (takich jak samoloty, AABB, quatenrions z wielokrotną interpolacją itp.), Których nie ma w innych pakietach. Bardzo niski narzut pamięci, dość szybki, łatwy w użyciu.

Wady: API jest bardzo skoncentrowane na renderowaniu i grafice. Nie obejmuje matryc ogólnego przeznaczenia (NxM), rozkładu i rozwiązywania macierzy itp., Ponieważ są one poza sferą tradycyjnych aplikacji graficznych / geometrycznych.

Eigen -

Korzyści: Czysty interfejs API , dość łatwy w użyciu. Zawiera moduł Geometrii z czwartorzędami i przekształceniami geometrycznymi. Niski narzut pamięci. Pełna, bardzo wydajna rozwiązywanie dużych macierzy NxN i innych procedur matematycznych ogólnego zastosowania.

Wady: może być nieco większy zakres niż chcesz (?). Mniej procedur geometrycznych / renderujących w porównaniu do GMTL (tj. Definicje kątów Eulera itp.).

IMSL -

Korzyści: Bardzo kompletna biblioteka numeryczna. Bardzo, bardzo szybki (podobno najszybszy solver). Zdecydowanie największy, najbardziej kompletny matematyczny interfejs API. Wspierany komercyjnie, dojrzały i stabilny.

Wady: koszt - nie tanie. Bardzo niewiele metod geometrycznych / renderujących, więc musisz rzucić własne na ich klasy algebry liniowej.

NT2 -

Korzyści: Zapewnia bardziej znaną składnię, jeśli jesteś przyzwyczajony do MATLAB. Zapewnia pełny rozkład i rozwiązywanie dużych matryc itp.

Wady: matematyczne, bez renderowania. Prawdopodobnie nie tak wydajny jak Eigen.

LAPACK -

Korzyści: Bardzo stabilne, sprawdzone algorytmy. Byłem tu od dłuższego czasu. Kompletne rozwiązywanie macierzy itp. Wiele opcji dla niejasnej matematyki.

Wady: w niektórych przypadkach nie tak wydajne. Przeniesiony z Fortran, z nieparzystym API do użytku.

Dla mnie osobiście sprowadza się do jednego pytania - jak zamierzasz to wykorzystać. Jeśli skupiasz się tylko na renderowaniu i grafice, podoba mi się Generic Graphics Toolkit , ponieważ działa on dobrze i obsługuje wiele przydatnych operacji renderowania po wyjęciu z pudełka, bez konieczności implementowania własnych. Jeśli potrzebujesz rozwiązywania macierzy ogólnego przeznaczenia (tj. Rozkładu dużych macierzy SVD lub LU), wybrałbym Eigen , ponieważ obsługuje to, zapewnia pewne operacje geometryczne i jest bardzo wydajny w przypadku rozwiązań o dużych matrycach. Być może będziesz musiał napisać więcej własnych operacji graficznych / geometrycznych (na ich matrycach / wektorach), ale to nie jest okropne.

Jestem więc osobą bardzo krytyczną i jeśli zamierzam zainwestować w bibliotekę, lepiej wiedzieć, w co się pakuję. Wydaje mi się, że lepiej poddać się krytyce i pochlebiać analizie; co jest z tym nie tak, ma o wiele więcej implikacji na przyszłość niż to, co jest właściwe. Więc zamierzam tu trochę przesadzić, aby udzielić odpowiedzi, która pomogłaby mi i mam nadzieję, że pomogą innym, którzy mogą podróżować tą ścieżką. Pamiętaj, że jest to oparte na tym, co niewiele recenzowałem / testowałem w tych bibliotekach. Och, i ukradłem Reedowi niektóre pozytywne opisy.

Wspomnę na górę, że poszedłem z GMTL pomimo jego osobliwości, ponieważ brak pewności Eigen2 był zbyt duży wadą. Ale ostatnio dowiedziałem się, że następne wydanie Eigen2 będzie zawierało definicje, które wyłączą kod wyrównania i uczynią go bezpiecznym. Więc mogę się przełączyć.

Aktualizacja : przełączyłem się na Eigen3. Pomimo jego osobliwości, jego zakres i elegancja są zbyt trudne do zignorowania, a optymalizacje, które czynią go niebezpiecznym, można wyłączyć za pomocą definicji.

Eigen2 / Eigen3

Korzyści: LGPL MPL2, czysty, dobrze zaprojektowany interfejs API, dość łatwy w użyciu. Wydaje się być dobrze utrzymany dzięki żywej społeczności. Niski narzut pamięci. Wysoka wydajność. Stworzony dla ogólnej algebry liniowej, ale dostępna jest również dobra funkcjonalność geometryczna. Wszystkie lib nagłówka, nie wymaga linkowania.

Idiocyncracies / minusy: (Niektórych / wszystkich można uniknąć dzięki niektórym definicjom dostępnym w obecnej gałęzi programistycznej Eigen3)

• Niebezpieczne optymalizacje wydajności wymagają starannego przestrzegania reguł. Nieprzestrzeganie zasad powoduje awarie.
  • po prostu nie można bezpiecznie przekazać wartości
  • użycie typów Eigen jako członków wymaga specjalnego dostosowania alokatora (w przeciwnym razie nastąpi awaria)
  • używać z typami kontenerów STL i ewentualnie innymi szablonami wymagającymi specjalnego dostosowania alokacji (w przeciwnym razie nastąpi awaria)
  • niektóre kompilatory wymagają szczególnej uwagi, aby zapobiec awariom wywołań funkcji (okna GCC)

GMTL

Korzyści: LGPL, dość proste API, specjalnie zaprojektowane dla silników graficznych. Obejmuje wiele prymitywnych typów ukierunkowanych na renderowanie (takich jak samoloty, AABB, quatenrions z wielokrotną interpolacją itp.), Których nie ma w innych pakietach. Bardzo niski narzut pamięci, dość szybki, łatwy w użyciu. Wszystko oparte na nagłówku, nie wymaga łączenia.

Idiocyncracies / minusy:

• API jest dziwaczny
  • co może być myVec.x () w innej bibliotece jest dostępne tylko przez myVec [0] (problem z czytelnością)
    • tablica lub stl :: wektor punktów może spowodować, że zrobisz coś takiego jak pointList [0] [0], aby uzyskać dostęp do komponentu x pierwszego punktu
  • w naiwnej próbie optymalizacji usunąłem cross (vec, vec) i zastąpiłem makeCross (vec, vec, vec), gdy kompilator i tak eliminuje niepotrzebne temps
  • normalne operacje matematyczne nie zwracają normalnych typów, chyba że wyłączysz niektóre funkcje optymalizacji, np .: vec1 - vec2nie zwraca normalnego wektora, więc length( vecA - vecB )zawodzi, mimo że vecC = vecA - vecBdziała. Musisz owinąć jak:length( Vec( vecA - vecB ) )
  • operacje na wektorach są zapewniane przez funkcje zewnętrzne, a nie przez elementy. Może to wymagać użycia rozdzielczości wszędzie, ponieważ wspólne nazwy symboli mogą kolidować
  • musisz zrobić
      length( makeCross( vecA, vecB ) )
    lub
      gmtl::length( gmtl::makeCross( vecA, vecB ) )
    gdzie indziej możesz spróbować
      vecA.cross( vecB ).length()
    

• nie dobrze utrzymany
  • nadal zgłaszany jako „beta”
  • w dokumentacji brakuje podstawowych informacji, takich jak nagłówki potrzebne do normalnego działania
    • Vec.h nie zawiera operacji dla wektorów, VecOps.h zawiera niektóre, inne są na przykład w Generate.h. cross (vec &, vec &, vec &) w VecOps.h, [make] cross (vec &, vec &) w Generate.h

• niedojrzałe / niestabilne API; ciągle się zmienia.
  • Na przykład „krzyż” został przeniesiony z „VecOps.h” do „Generate.h”, a następnie zmieniono nazwę na „makeCross”. Przykłady dokumentacji zawodzą, ponieważ nadal odnoszą się do starych wersji funkcji, które już nie istnieją.

NT2

Nie mogę powiedzieć, ponieważ wydają się bardziej zainteresowani fraktalnym nagłówkiem obrazu swojej strony internetowej niż treścią. Wygląda bardziej na projekt akademicki niż poważny projekt oprogramowania.

Najnowsze wydanie ponad 2 lata temu.

Najwyraźniej nie ma dokumentacji w języku angielskim, choć podobno gdzieś jest coś po francusku.

Nie mogę znaleźć śladu społeczności wokół projektu.

LAPACK & BLAS

Korzyści: stare i dojrzałe.

Wady:

• stare jak dinozaury z naprawdę kiepskimi API

Za to, co jest warte, wypróbowałem zarówno Eigen, jak i Armadillo. Poniżej znajduje się krótka ocena.

Zalety własne: 1. Całkowicie samowystarczalny - brak zależności od zewnętrznego BLAS lub LAPACK. 2. Dokumentacja przyzwoita. 3. Niby szybko, chociaż nie wystawiłem go na próbę.

Wada: algorytm QR zwraca tylko jedną macierz, z macierzą R osadzoną w górnym trójkącie. Nie ma pojęcia, skąd pochodzi reszta macierzy i nie można uzyskać dostępu do macierzy Q.

Zalety pancernika: 1. Szeroka gama rozkładów i innych funkcji (w tym QR). 2. Racjonalnie szybki (używa szablonów wyrażeń), ale ponownie nie przesunąłem go do wysokich wymiarów.

Wady: 1. Zależy od zewnętrznego BLAS i / lub LAPACK dla rozkładu macierzy. 2. W dokumentacji brakuje IMHO (w tym specyfikacja LAPACK, inna niż zmiana instrukcji #define).

Byłoby miło, gdyby dostępna była biblioteka typu open source, która jest samodzielna i łatwa w użyciu. Natknąłem się na ten sam problem od 10 lat i robi się to frustrujące. W pewnym momencie użyłem GSL dla C i napisałem wokół niego opakowania C ++, ale w nowoczesnym C ++ - szczególnie korzystając z zalet szablonów wyrażeń - nie powinniśmy mieć problemów z C w XXI wieku. Tylko mój tuppencehapenny.

Jeśli szukasz wysokowydajnej macierzy / algebry liniowej / optymalizacji procesorów Intel, zajrzałbym do biblioteki MKL Intela.

MKL jest starannie zoptymalizowany pod kątem szybkiego działania - w dużej mierze oparty na bardzo dojrzałych standardach BLAS / LAPACK fortran. Jego wydajność skaluje się wraz z liczbą dostępnych rdzeni. Skalowalność zestawu głośnomówiącego z dostępnymi rdzeniami to przyszłość komputerów i nie użyłbym żadnej biblioteki matematycznej, ponieważ nowy projekt nie obsługuje procesorów wielordzeniowych.

W skrócie obejmuje:

1. Podstawowe operacje wektor-wektor, macierz-wektor i macierz-macierz
2. Rozkład macierzy (rozkład LU, pustelnik, rzadki)
3. Problemy z dopasowaniem najmniejszych kwadratów i wartościami własnymi
4. Rozwiązania rzadkich układów liniowych
5. Nieliniowy solver najmniejszych kwadratów (regiony zaufania)
6. Plus procedury przetwarzania sygnałów, takie jak FFT i splot
7. Bardzo szybkie generatory liczb losowych (twist mersenne)
8. Znacznie więcej .... patrz: link tekst

Minusem jest to, że interfejs API MKL może być dość złożony w zależności od potrzebnych procedur. Możesz także rzucić okiem na ich bibliotekę IPP (Integrated Performance Primitive), która jest ukierunkowana na operacje przetwarzania obrazów o wysokiej wydajności, ale jest jednak dość szeroka.

Paweł

Oprogramowanie CenterSpace, biblioteki .NET Math, centerpace.net

Słyszałem dobre rzeczy o Eigen i NT2 , ale też osobiście ich nie używałem. Jest też Boost.UBLAS , który, jak sądzę, robi się trochę długi w zębie. Deweloperzy NT2 budują następną wersję z zamiarem wprowadzenia jej w Boost, więc to może się na coś liczyć.

Mój lin. alg. potrzeby nie wykraczają poza obudowę macierzy 4x4, więc nie mogę komentować zaawansowanych funkcji; Wskazuję tylko kilka opcji.

Jestem nowy w tym temacie, więc nie mogę powiedzieć dużo, ale BLAS jest standardem w naukowym przetwarzaniu. BLAS jest tak naprawdę standardem API, który ma wiele implementacji. Nie jestem pewien, które implementacje są najbardziej popularne i dlaczego.

Jeśli chcesz mieć także możliwość wykonywania typowych operacji algebry liniowej (systemy rozwiązywania, regresja metodą najmniejszych kwadratów, rozkład itp.), Spójrz na LAPACK .

Co z GLM ?

Jest oparty na specyfikacji OpenGL Shading Language (GLSL) i wydany na licencji MIT. Wyraźnie skierowany do programistów graficznych

Dodam głosowanie na Eigen: do tej biblioteki przeniosłem dużo kodu (geometria 3D, algebra liniowa i równania różniczkowe) z różnych bibliotek - poprawiając zarówno wydajność, jak i czytelność kodu w prawie wszystkich przypadkach.

Jedną z zalet, o której nie wspomniano: jest bardzo łatwy w użyciu SSE z Eigen, co znacznie poprawia wydajność operacji 2D-3D (gdzie wszystko można uzupełnić do 128 bitów).

Okej, myślę, że wiem, czego szukasz. Wygląda na to, że GGT jest całkiem dobrym rozwiązaniem, jak sugerował Reed Copsey.

Osobiście stworzyliśmy własną bibliotekę, ponieważ bardzo dużo radzimy sobie z racjonalnymi punktami - wiele racjonalnych NURBS i Beziers.

Okazuje się, że większość bibliotek graficznych 3D wykonuje obliczenia z punktami rzutowymi, które nie mają podstaw w matematyce rzutowej, ponieważ to właśnie daje ci odpowiedź, której potrzebujesz. W końcu wykorzystaliśmy punkty Grassmanna, które mają solidne podstawy teoretyczne i zmniejszyły liczbę typów punktów. Punkty Grassmanna to w zasadzie te same obliczenia, których używają teraz ludzie, z korzyścią dla solidnej teorii. Co najważniejsze, w naszych umysłach wszystko staje się bardziej zrozumiałe, więc mamy mniej błędów. Ron Goldman napisał artykuł na temat punktów Grassmanna w grafice komputerowej zatytułowany „O algebraicznych i geometrycznych podstawach grafiki komputerowej” .

Nie bezpośrednio związane z twoim pytaniem, ale ciekawa lektura.

FLENS

http://flens.sf.net

Implementuje również wiele funkcji LAPACK.

Uważam tę bibliotekę za dość prostą i funkcjonalną ( http://kirillsprograms.com/top_Vectors.php ). Są to wektory z gołą kością zaimplementowane za pomocą szablonów C ++. Żadnych wymyślnych rzeczy - tylko to, co musisz zrobić z wektorami (dodawanie, odejmowanie, mnożenie, kropka itp.).