Які найпоширеніші бібліотеки математики векторної / матричної / математичної / лінійної алгебри C ++ та їхні вигідні витрати та вигоди? [зачинено]

Здається, що багато проектів повільно стикаються з необхідністю робити матричну математику і потрапляють у пастку спочатку будувати деякі векторні класи та повільно додавати функціональні можливості, поки вони не потраплять у створення напівзрозумілої власної лінійної бібліотеки алгебри та залежно від неї.

Я хотів би уникнути цього, не будуючи залежності від якоїсь дотично пов'язаної бібліотеки (наприклад, OpenCV, OpenSceneGraph).

Які бібліотеки матричних математичних / лінійних алгебр, що часто використовуються, і чому вирішили використовувати одну над іншою? Чи є якісь поради, які б не радили використовувати з якоїсь причини? Я спеціально використовую це в геометричному / часовому контексті * (2,3,4 дим.) *, Але, можливо, будуватимуть більш високі розмірні дані в майбутньому.

Я шукаю відмінності стосовно будь-якого з: API, швидкості, використання пам'яті, широти / повноти, вузькості / специфічності, розширюваності та / або зрілості / стабільності.

Оновлення

Я в кінцевому рахунку використовував Eigen3, яким я надзвичайно задоволений.

Для цього існує досить багато проектів, які розраховані на інструментарії загальної графіки . GMTL там є приємний - він досить маленький, дуже функціональний і використовувався досить широко, щоб бути дуже надійним. OpenSG, VRJuggler та інші проекти перейшли на використання цього замість власної ручної прокатки математики вертору / матриці.

Я вважаю це досить приємним - він робить все за допомогою шаблонів, тому він дуже гнучкий і дуже швидкий.

Редагувати:

Після обговорення коментарів та редагувань я подумав, що я викину додаткову інформацію про переваги та недоліки конкретних реалізацій, і чому ви можете обрати одну над іншою, враховуючи вашу ситуацію.

GMTL -

Переваги: ​​простий API, спеціально розроблений для графічних двигунів. Включає багато примітивних типів, спрямованих на візуалізацію (наприклад, літаки, AABB, кватерніони з багаторазовою інтерполяцією тощо), яких немає в жодному іншому пакеті. Дуже низький об'єм пам'яті, досить швидкий, простий у користуванні.

Недоліки: API дуже орієнтований саме на візуалізацію та графіку. Не включає в себе матриць загального призначення (NxM), розкладання та вирішення матриць тощо, оскільки вони знаходяться поза сферою традиційних застосувань для графіки / геометрії.

Айген -

Переваги: чистий API , досить простий у використанні. Включає модуль Geometry з кватерніонами та геометричними перетвореннями. Низькі накладні витрати. Повне, високоефективне рішення великих матриць NxN та інших математичних процедур загального призначення.

Недоліки: може бути трохи більше, ніж ви хочете (?). Менше геометричних / рендеринга конкретних процедур порівняно з GMTL (тобто: визначення кута Ейлера тощо).

IMSL -

Переваги: ​​Дуже повна чисельна бібліотека. Дуже, дуже швидко (нібито найшвидший вирішувач). На сьогодні найбільший, найповніший математичний API. Комерційно підтримується, зрілий та стабільний.

Мінуси: вартість - недешева. Дуже мало геометричних / рендеринга конкретних методів, тому вам потрібно буде прокрутити свій власний верх на їх лінійні класи алгебри.

NT2 -

Переваги: ​​надає синтаксис, більш відомий, якщо ви звикли до MATLAB. Забезпечує повне розкладання та розв’язування для великих матриць тощо.

Недоліки: математичні, не орієнтовані на надання. Напевно, не такий виконавський, як Ейген.

ЛАПАК -

Переваги: ​​Дуже стійкі, перевірені алгоритми. Був довгий час. Повне рішення матриці тощо. Багато варіантів незрозумілої математики.

Недоліки: Не настільки високоефективні в деяких випадках. Перенесено з Fortran, з дивним API для використання.

Особисто для мене зводиться до одного питання - як ти це плануєш використовувати. Якщо ви зосереджуєтесь саме на візуалізації та графіці, мені подобається Generic Graphics Toolkit , оскільки вона добре працює і підтримує багато корисних операцій з виведення з коробки без необхідності впроваджувати власні. Якщо вам потрібно вирішення матриць загального призначення (тобто: розкладання SVD або LU великих матриць), я б пішов з Eigen , оскільки він обробляє це, забезпечує деякі геометричні операції, і дуже добре працює з рішеннями великих матриць. Можливо, вам потрібно буде написати більше власних графічних / геометричних операцій (поверх їх матриць / векторів), але це не жахливо.

Отже, я досить критична людина, і, якщо я буду інвестувати в бібліотеку, я краще буду знати, в що я потрапляю. Я вважаю, що краще уважно ставитись до критики, а також до лестощів при вивченні; те, що не в цьому, має набагато більше наслідків для майбутнього, ніж те, що правильно. Тому я збираюся трохи зайти за борт тут, щоб надати відповідь, яка допомогла б мені, і я сподіваюся, що допоможе іншим, хто може пройти цей шлях. Майте на увазі, що це ґрунтується на тому, що я мало перевіряю / тестую, що я робив із цими лайками О, і я вкрав деякі позитивні описи у Рід.

Я нагадаю зверху, що я пішов з GMTL, незважаючи на це ідіосинкразії, тому що небезпека Eigen2 була занадто великою недоліком. Але нещодавно я дізнався, що наступний випуск Eigen2 буде містити визначення, які вимкнуть код вирівнювання та зроблять його безпечним. Тож я можу переключитися.

Оновлення : я перейшов на Eigen3. Незважаючи на свої ідіосинкразії, його масштаб та елегантність занадто важко ігнорувати, а оптимізації, які роблять це небезпечним, можна вимкнути за допомогою визначення.

Eigen2 / Eigen3

Переваги: LGPL MPL2, чистий, добре розроблений API, досить простий у використанні. Здається, добре підтримує живучу спільноту. Низькі накладні витрати. Висока продуктивність. Створений для загальної лінійної алгебри, але також доступна хороша геометрична функціональність. Вся вкладка заголовка, не потрібно зв'язувати.

Idiocyncracies / downsides: (Дещо / всього цього можна уникнути за допомогою деяких визначень, які доступні в поточній галузі розвитку Eigen3)

• Небезпечні оптимізації роботи призводять до необхідності ретельного дотримання правил. Недотримання правил спричиняє збої.
  • ви просто не можете безпечно передати цінність
  • використання типів Eigen як членів вимагає спеціального налаштування алокатора (або ви завершите роботу)
  • використовувати з типами контейнерів stl та, можливо, іншими шаблонами, потрібні спеціальні налаштування розподілу (інакше ви завершите роботу)
  • певні компілятори потребують особливої ​​обережності для запобігання збоїв у функціональних викликах (вікна GCC)

GMTL

Переваги: ​​LGPL, досить простий API, спеціально розроблений для графічних двигунів. Включає багато примітивних типів, спрямованих на візуалізацію (наприклад, літаки, AABB, кватерніони з багаторазовою інтерполяцією тощо), яких немає в жодному іншому пакеті. Дуже низький об'єм пам'яті, досить швидкий, простий у користуванні. Все на основі заголовка, ніяких посилань не потрібно.

Ідентифікація / мінуси:

• API химерний
  • що може бути myVec.x () в іншій lib, доступне лише через myVec [0] (проблема читабельності)
    • масив або stl :: вектор точок може змусити вас зробити щось на зразок pointsList [0] [0] для доступу до компонента x першої точки
  • в наївній спробі оптимізації видаляється хрест (vec, vec) і замінюється makeCross (vec, vec, vec), коли компілятор так чи інакше усуває непотрібні темпи
  • звичайні математичні операції не повертають нормальні типи, якщо ви не відключили деякі функції оптимізації, наприклад: vec1 - vec2не повертає нормальний вектор, тому length( vecA - vecB )не vecC = vecA - vecBпрацює, хоча працює. Ви повинні загортатись так:length( Vec( vecA - vecB ) )
  • Операції над векторами забезпечуються зовнішніми функціями, а не членами. Це може вимагати використання роздільної здатності скрізь, оскільки загальні імена символів можуть стикатися
  • ви повинні зробити
      length( makeCross( vecA, vecB ) )
    або
      gmtl::length( gmtl::makeCross( vecA, vecB ) )
    де інакше ви можете спробувати
      vecA.cross( vecB ).length()
    

• недостатньо підтримується
  • як і раніше заявляється як "бета"
  • в документації відсутня основна інформація, наприклад, які заголовки потрібні для нормальної функціональності
    • Vec.h не містить операцій для Vectors, VecOps.h містить деякі, інші є в Generate.h, наприклад. хрест (vec &, vec &, vec &) у VecOps.h, [make] хрест (vec &, vec &) у Generate.h

• незрілий / нестабільний API; все ще змінюється.
  • Наприклад, "cross" перемістився з "VecOps.h" на "Generate.h", а потім назву було змінено на "makeCross". Приклади документації не вдається, оскільки все ще відносяться до старих версій функцій, які вже не існують.

NT2

Не можу сказати, оскільки їх, здається, більше цікавить заголовок фрактальної зображення їх веб-сторінки, ніж вміст. Виглядає більше як академічний проект, ніж серйозний програмний проект.

Останній реліз понад 2 роки тому.

Мабуть, жодної документації англійською мовою, хоча нібито десь є щось французькою.

Не можете знайти сліди спільноти навколо проекту.

LAPACK & BLAS

Переваги: ​​Старі та зрілі.

Недоліки:

• старі як динозаври з дійсно хитрими API

Що варто, я спробував і Ейген, і Армаділло. Нижче наведена коротка оцінка.

Переваги власних властивостей: 1. Повністю автономна - відсутність залежності від зовнішнього BLAS або LAPACK. 2. Документація гідна. 3. Нібито швидко, хоча я не поставив це на тест.

Недолік: алгоритм QR повертає лише одну матрицю з матрицею R, вбудованою у верхній трикутник. Немає уявлення, звідки береться решта матриці, і жодна матриця Q не може бути доступна.

Переваги Armadillo: 1. Широкий спектр декомпозицій та інших функцій (включаючи QR). 2. Розумно швидко (використовує шаблони виразів), але знову ж таки, я не дуже підштовхував це до високих розмірів.

Недоліки: 1. Залежить від зовнішнього BLAS та / або LAPACK для матричного розкладу. 2. Документація не має IMHO (включаючи специфіку wrt LAPACK, крім зміни оператора #define).

Було б добре, якби була доступна бібліотека з відкритим кодом, яка є автономною та простою у використанні. Я стикався з цим самим питанням 10 років, і це стає неприємним. Якось я використовував GSL для C і писав навколо нього обгортки C ++, але з сучасними C ++ - особливо з використанням переваг шаблонів виразів - нам не слід було возитися з C у 21 столітті. Просто мій туппенчахапенний.

Якщо ви шукаєте матричну / лінійну алгебру / оптимізацію високоефективної роботи на процесорах Intel, я би поглянув на MKL-бібліотеку Intel.

MKL ретельно оптимізовано для швидкого виконання робочого часу - значна частина заснована на дуже зрілих стандартах fortran BLAS / LAPACK. А його продуктивність масштабується з кількістю наявних ядер. Гнучка масштабованість з наявними ядрами - це майбутнє обчислень, і я б не використовував жодну математичну бібліотеку для нового проекту, не підтримує багатоядерні процесори.

Дуже коротко, вона включає:

1. Основні операції вектор-вектор, вектор-матриця та матриця-матриця
2. Матрична факторизація (розпад LU, герміт, розріджений)
3. Найменші квадрати та проблеми з власним значенням
4. Рідкі лінійні системні рішення
5. Нелінійний розв'язувач найменших квадратів (довірчі регіони)
6. Плюс підпрограми обробки сигналів, такі як FFT та convolution
7. Генератори дуже швидких випадкових чисел (mersenne twist)
8. Набагато більше .... див .: текст посилання

Мінусом є те, що API MKL може бути досить складним залежно від підпрограм, які вам потрібні. Ви також можете поглянути на їхню бібліотеку IPP (Integrated Performance Primitive), яка орієнтована на високопродуктивні операції обробки зображень, але, тим не менш, досить широка.

Пол

Програмне забезпечення CenterSpace, бібліотеки .NET Math, centerpace.net

Я чула хороші речі про Eigen та NT2 , але особисто також не використовувала. Є також Boost.UBLAS , який, на мою думку, трохи затягується в зуб. Розробники NT2 будують наступну версію з наміром перетворити її в Boost, так що це може розраховувати на щось.

Мій лін. alg потреби не виходять за межі корпусу матриці 4x4, тому я не можу коментувати розширені функціональні можливості; Я просто вказую на деякі варіанти.

Я новачок у цій темі, тому не можу сказати багато чого, але BLAS - це майже стандарт у наукових обчисленнях. BLAS - це фактично стандарт API, який має багато реалізацій. Я, чесно кажучи, не впевнений, які реалізації найбільш популярні чи чому.

Якщо ви також хочете мати можливість робити звичайні лінійні алгебри (розв’язування систем, регресія найменших квадратів, декомпозиція тощо), погляньте на LAPACK .

Що з GLM ?

Він заснований на специфікації OpenGL Shading Language (GLSL) та випущений під ліцензією MIT. Чітко націлена на графічних програмістів

Я додам голосування за Ейґена: Я переніс багато коду (тривимірної геометрії, лінійної алгебри та диференціальних рівнянь) з різних бібліотек до цієї - покращуючи як продуктивність, так і читабельність коду майже у всіх випадках.

Одна з переваг, про яку не згадувалося: дуже просто використовувати SSE з Eigen, що значно покращує продуктивність операцій 2D-3D (де все може бути додано до 128 біт).

Гаразд, я думаю, я знаю, що ти шукаєш. Схоже, що GGT є досить хорошим рішенням, як запропонував Рід Копсі.

Особисто ми розгорнули власну маленьку бібліотеку, бо багато маємо справу з раціональними пунктами - багато раціональних НУРБ та Безьє.

Виявляється, більшість бібліотек 3D графіки роблять обчислення з проективними точками, які не мають основи в проективній математиці, тому що саме так ви отримуєте потрібну відповідь. Ми закінчилися з використанням точок Грассмана, які мають суцільну теоретичну основу та зменшили кількість типів балів. Точки Грассмана - це в основному ті самі обчислення, які зараз використовують люди, з користю від надійної теорії. Найголовніше - це робить речі яснішими в нашій свідомості, тому у нас менше помилок. Рон Голдман написав документ про точки Грассмана в комп'ютерній графіці під назвою "Про алгебраїчні та геометричні основи комп'ютерної графіки" .

Не пов’язаний безпосередньо з вашим запитанням, але цікавим прочитаним.

ФЛЕНС

http://flens.sf.net

Він також реалізує багато функцій LAPACK.

Я знайшов цю бібліотеку досить простою та функціональною ( http://kirillsprograms.com/top_Vectors.php ). Це голі кісткові вектори, реалізовані за допомогою шаблонів C ++. Немає фантазійних речей - лише те, що потрібно робити з векторами (додавання, віднімання множення, крапка тощо).