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

243

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.

Catskul
źródło
2
Ponieważ wspomniałeś o OSG i OpenCV, domyślam się, że potrzebujesz tylko grafiki wektorowej / matryc typu 3D, czyli: matryc 3x3 i 4x4. Na tej podstawie oparłem swoją odpowiedź, ale możesz sprecyzować, jak dokładnie tego używasz - czy potrzebujesz rozwiązania macierzy? Matematyka o wyższych wymiarach? itp.
Reed Copsey
W tej chwili robię tylko rzeczy oparte na geometrii 2D, ale hipotetycznie czasami potrzebujesz operacji 3x3 na danych 2D i nie jest jasne, czy dane 3D, a zatem operacje 4x4 mogą być konieczne. Chcielibyśmy korzystać ze wspólnej biblioteki w całej firmie. Nie mam pojęcia, jakie byłyby kompromisy. Bardziej ogólne byłoby lepiej, ale za jaką cenę jest pytanie.
Catskul
1
Jeśli robisz tylko transformacje geometryczne, naprawdę polecam przyjrzenie się GGT, jak wspomniałem w mojej odpowiedzi. Jest to bardzo kompletne, ale tak naprawdę nic NIE robi, A więc jest to bardzo czysta, łatwa opcja. BLAS i LAPACK są bardziej przeznaczone do kompleksowych rozwiązań matrycowych (tj. Matryc 50x50, matryc rzadkich itp.) Do celów naukowych i matematycznych, a nie transformacji geometrycznych.
Reed Copsey

Odpowiedzi:

114

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.

Reed Copsey
źródło
Czy oceniałeś inne biblioteki przed podjęciem decyzji o GMTL? Powierzchowne porównanie doprowadziło mnie do wniosku, że Eigen był lepiej obsługiwany, ale na podstawie przeglądu odpowiednich stron internetowych. Czy znasz jakieś szczególne zalety jednego nad drugim?
Catskul
Eigen również działa dobrze. W czasie mojego dochodzenia nie było tak dojrzałe, ale uważam, że w tym momencie byłaby to dobra opcja. GMTL był używany dość szeroko i był bardzo dojrzały i solidny, kiedy zdecydowałem się go użyć.
Reed Copsey,
Myślę, że sprowadzę moje pytanie do sedna: czy dokonałeś subiektywnego wyboru, takiego jak „To wygląda lepiej”, czy też gdzie były specyficzne funkcje (API, prędkość, użycie pamięci, szerokość, wąskość, rozszerzalność), które zrobiły różnicę. Przypuszczam, że dojrzałość spełnia te kryteria, ale jeśli dojrzałość byłaby jedyną miarą, wyobrażam sobie, że wybrałbyś opcję opartą na BLAS lub LAPACK.
Catskul
Wybrałem to po wypróbowaniu wielu opcji i oparłem je na: wydajności, użyteczności i niskim nakładzie czasu wykonywania / kompilacji. Eigen wygląda teraz znacznie lepiej niż wtedy, więc nie mogę między nimi oceniać. Byłem jednak bardzo zadowolony z GMTL do naszych zastosowań.
Reed Copsey,
Właśnie dlatego lubię GMTL i używałem go. Po prostu czułem się bardzo naturalnie i był bardzo, bardzo łatwy w obsłudze. Wspierał także wszystko, czego potrzebowałem, w tym przypadku, ponieważ martwiłem się o bezpośrednią obsługę transformacji geometrycznej i rotacji czwartorzędu.
Reed Copsey,
38

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
Catskul
źródło
1
Jeśli chodzi o twierdzenia wyrównane wg Eigen: aby uzyskać wysoką wydajność operacji SSE (1,2,3 lub 4) dla małych zestawów danych, absolutnie potrzebujesz wyrównanych danych. Niezrównane operacje ładowania / przechowywania są znacznie wolniejsze. Decyzja między wyrównanym lub niewyrównanym ładowaniem / przechowywaniem również wymaga czasu. Każda implementacja „ogólnego przeznaczenia” miałaby naprawdę trudny czas, robiąc właściwą rzecz dla wszystkich, chyba że podzieliłaby interfejs również na operacje „wyrównane” i „niewyrównane” - i znowu nie jest to po prostu ogólny cel.
Joris Timmermans,
@Catskul Chciałbym użyć Eigen3. Czy mógłbyś rozwinąć „optymalizacje, które sprawiają, że jest to niebezpieczne, można wyłączyć za pomocą definicji”? Inne problemy wymienione w Eigen2 są szczegółowo opisane w dokumencie w Tematach związanych z problemami z wyrównaniem . Mogę żyć z tymi problemami.
Ali
Problemy z bezpieczeństwem odnoszę się do wszystkich związanych z wyrównaniem i są takie same z Eigen2. Jeśli nie masz nic przeciwko Eigen2, wszystko będzie w porządku z Eigen3.
Catskul
2
BLAS i LAPACK nie są tak naprawdę bibliotekami, ale specyfikacjami / interfejsami API. mogłeś wspomnieć o ich początkowych implementacjach przez netlib lub inne implementacje, takie jak ATLAS i OpenBLAS.
Foad
12

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.

Francis Urquhart
źródło
2
Armadillo ma celową składnię podobną do Matlaba, dzięki czemu jest łatwy w użyciu. Nie jestem pewien, co masz na myśli przez „brak dokumentacji ... specyfikacje w LAPACK”. Dokumentacja wyraźnie dokumentuje wszystkie dostępne funkcje użytkownika, wraz z przykładami ich użycia. Chodzi przede wszystkim o bibliotekę otoki C ++, aby odciąć się od złożoności i szczegółowości LAPACK. Zawsze możesz przejrzeć źródło, jeśli chcesz zobaczyć, jak Armadillo nazywa LAPACK.
mtall,
Czy chodzi o rozkład QR w Eigen, czy masz na myśli Eigen2 czy Eigen3?
qed
11

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

Paweł
źródło
8

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.

Jeff Hardy
źródło
Z mojego doświadczenia (większe matryce) Boost.UBLAS jest używany częściej. Kiedy jednak się temu przyjrzałem, nie podobało mi się to (głównie z powodu dokumentacji), więc skoncentrowałem się na Eigen. Eigen ma moduł geometrii , ale sam go nie użyłem.
Jitse Niesen
Eigen jest najwyraźniej używany przez ROS (wierzbowy garaż), Celestię, Koffice i libmv. Widzę trochę gadania o UBLAS, ale z trudem spotkałem projekt, który reklamuje się za jego pomocą. To samo dotyczy NT2. Czy możesz wyjaśnić, jakie dobre rzeczy usłyszałeś?
Catskul,
Było to w dyskusji na liście mailingowej Boost o dodaniu nowoczesnej biblioteki LinAlg do Boost - zarówno Eigen, jak i NT2 zostały wymienione jako potencjalni kandydaci, ale tylko programiści NT2 wyrazili zainteresowanie jego kontynuacją. Obie biblioteki wydawały się przyzwoite; jak powiedziałeś, Eigen jest trochę bardziej popularny, a także bardziej C ++ - ish; NT2 został zaprojektowany tak, aby jak najbardziej naśladować MATLAB.
Jeff Hardy
8

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 .

davidtbernal
źródło
7

Co z GLM ?

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

użytkownik3742582
źródło
cóż, zapewnia wektor programowania grafiki i macierze. wprowadza sporo kosztów ogólnych, aby zachować zgodność z GLSL (jeśli możesz to zrobić w GLSL, w większości przypadków jest to lepsze w GLSL, szczególnie w GL 4.x), i brakuje wielu prymitywów programowania grafiki (frustum, AABB, BB, elipsoida ). Swizzle interfejs jest otyły. Znacznie lepsza alternatywa byłaby, gdyby miał funkcje „.xyzz ()” generowane przy pewnym generowaniu kodu. Jest idealny, gdy musisz prototypować aplikacje OpenGL i zaczyna pokazywać swoje negatywne strony w większych projektach. nigdy nie koduj biblioteki matematycznej.
CoffeDeveloper
5

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).

ima
źródło
1
Całe „jeśli to zrobisz, to upewnij się, że ...” wydaje mi się trochę czerwoną flagą. Do tej pory dwukrotnie napotkałem te problemy i właśnie zacząłem z nich korzystać. Naprawdę miałem nadzieję, że nie będę obciążać przyszłych programistów za znajomość wszelkiego rodzaju osobliwości każdej biblioteki, w tym: w szczególności problemy z wyrównaniem, w których ulega awarii, jeśli nie używasz niektórych makr za każdym razem, gdy masz członków, oraz fakt, że udostępnili funkcje dla poszczególnych osób klasy w wielu nagłówkach. Samo to może nie powstrzymać mnie przed wybraniem go, ale wysłałem trochę czerwonej flagi.
Catskul,
1
Wyrównanie i to makro ma znaczenie tylko wtedy, gdy używasz SSE, co w żadnym wypadku nie jest wymagane. A jeśli korzystasz z SIMD, problemy te wzrosną niezależnie od używanej biblioteki. Przynajmniej Eigen nie tylko ulega awarii, ale dostarcza sensowne komunikaty o błędach, które bezpośrednio wskazują na problem.
ima
I jest prosty sposób na uniknięcie makra wyrównania - użyj wskaźników lub referencji jako członków.
ima
1
Nie sądzę, że to prawda. Nie użyłem żadnych specjalnych opcji SSE i dostałem kilka awarii po użyciu go z kontenerami STL. Tak, wiem, że daje ci pomocne wiadomości, i tak, wiem, że są specjalne instrukcje, ale o to mi chodzi. Nie chcę obciążać innych programistów specjalnymi instrukcjami dla każdej dołączonej biblioteki. Na przykład rzecz „nie przechodzić przez wartość” jest po prostu zbyt duża.
Catskul,
Właśnie odkryłem, że najnowsza gałąź programistyczna ma pewne definicje, których można użyć do wyłączenia wyrównania i uniknięcia powiązanych problemów.
Catskul,
4

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.

tfinniga
źródło
Celowo jest otwarty, ponieważ nie wiem, jakie są kompromisy. Prawdopodobnie słusznie jest powiedzieć, że geometria jest naszym głównym problemem, ale jej wymiary nie są jasne. Obecnie jest to 2/3 (2 + czas) i może hipotetycznie być dość wysokie (3dims + czas + mapy wielu wymiarów).
Catskul
Zgadzam się z pytaniem. Na przykład wiele aplikacji tego rodzaju wymaga wydajności w czasie rzeczywistym (spójne zachowanie w czasie), podczas gdy wiele innych jest w porządku, rezygnując z spójności i / lub szybkości dla dokładności.
TED
Mówisz, że z bibliotek, które badałeś, żadna nie zajmowała się NURBS i Beziers? Czy jest jakiś szczególny powód, dla którego nie wzięto jednej z istniejących bibliotek i nie budowano obok niej obsługi NURBS i Beziera?
Catskul
Próbowałem powiedzieć, że racjonalne NURBS i Beziers używają racjonalnych punktów kontrolnych znacznie bardziej niż większość aplikacji 3D, więc popełnialiśmy więcej błędów. Zazwyczaj większość aplikacji 3d ma tylko waniliowe punkty 3d i wektory, dopóki nie przejdzie transformacji perspektywy. Wiele naszych algorytmów musi być w stanie poprawnie obsługiwać punkty ważone / racjonalne / rzutowe i kartezjańskie,
poruszanie
0

FLENS

http://flens.sf.net

Implementuje również wiele funkcji LAPACK.

Michael Lehn
źródło
0

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.).

Clark Gamble
źródło
1
Według stanu na grudzień 2019 r. Link jest niestety zerwany
10762409 mówi Przywróć Monikę