Каковы наиболее широко используемые библиотеки библиотек/матрицы математической/линейной алгебры С++ и их компромиссы в отношении затрат и выгод?

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

Я бы хотел избежать этого, не создавая зависимости от некоторой связанной с тангенсом библиотеки (например, OpenCV, OpenSceneGraph).

Каковы обычно используемые библиотеки математической математики/линейной алгебры, и почему они решили использовать один над другим? Есть ли что-нибудь, что по какой-то причине было бы рекомендовано против использования? Я специально использую это в геометрическом/временном контексте * (2,3,4 Dim) *, но в будущем может использовать данные с более высокой размерностью.

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

Update

В итоге я использовал Eigen3, которым я очень доволен.

ОТВЕТЫ

Ответ 1

Для этого существует немало проектов, которые были установлены для Generic Graphics Toolkit. GMTL там приятный - он довольно маленький, очень функциональный, и использовался достаточно широко, чтобы быть очень надежным. OpenSG, VRJuggler и другие проекты все переключились на использование этого вместо собственной ручной/вертикальной математики.

Я нашел его довольно приятным - он делает все через шаблоны, поэтому он очень гибкий и очень быстрый.

Edit:

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

GMTL -

Преимущества: простой API, специально разработанный для графических движков. Включает множество примитивных типов, предназначенных для рендеринга (таких как самолеты, AABB, quatenrions с множественной интерполяцией и т.д.), Которые не находятся в каких-либо других пакетах. Очень низкая память, довольно быстрая и простая в использовании.

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

Eigen -

Преимущества: Clean API, довольно проста в использовании. Включает модуль геометрии с кватернионами и геометрическими преобразованиями. Низкая накладная память. Полный, высокоэффективный решение больших NxN-матриц и других математических подпрограмм общего назначения.

Недостатки: может быть немного больше, чем вы хотите (?). Меньше геометрических/рендеринга конкретных процедур по сравнению с GMTL (т.е. Определения угла Эйлера и т.д.).

IMSL -

Преимущества: очень полная числовая библиотека. Очень, очень быстро (возможно, самый быстрый решатель). Безусловно, самый полный, самый полный математический API. Коммерчески поддерживаемый, зрелый и стабильный.

Недостатки: стоимость - не недорогая. Очень мало геометрических/рендеринга конкретных методов, поэтому вам нужно катить свой собственный поверх своих классов линейной алгебры.

NT2 -

Преимущества: Предоставляет синтаксис, более знакомый, если вы привыкли к MATLAB. Обеспечивает полное разложение и решение для больших матриц и т.д.

Недостатки: математические, а не фокусированные. Вероятно, это не так эффективно, как Eigen.

LAPACK -

Преимущества: очень стабильные, проверенные алгоритмы. Был вокруг в течение долгого времени. Полное решение матриц и т.д. Множество вариантов для неясной математики.

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

Лично для меня это сводится к одному вопросу - как вы планируете использовать это. Если вы сосредоточены только на рендеринге и графике, мне нравится Generic Graphics Toolkit, так как он хорошо работает и поддерживает много полезных операций рендеринга из ящик без необходимости выполнять свои собственные. Если вам требуется решение общей цели (т.е. SVD или LU-декомпозиция больших матриц), я бы пошел с Eigen, так как он обрабатывает что обеспечивает некоторые геометрические операции и очень эффективен с большими матричными решениями. Возможно, вам придется писать больше своих графических/геометрических операций (поверх их матриц/векторов), но это не ужасно.

Ответ 2

Итак, я довольно критический человек, и я думаю, что если я собираюсь инвестировать в библиотеку, я бы лучше знал, в чем я ввязываюсь. Я считаю, что лучше критиковать критику и освещать лесть при тщательном изучении; что неправильно с ним имеет гораздо больше последствий для будущего, чем то, что право. Поэтому я собираюсь зайти за борт здесь немного, чтобы обеспечить ответ, который помог бы мне, и я надеюсь, что это поможет другим, кто может путешествовать по этому пути. Имейте в виду, что это основано на том, что небольшое пересмотр/тестирование я сделал с этими libs. О, и я украл некоторые из положительного описания Рида.

Я расскажу о том, что я пошел с GMTL, несмотря на его особенности, потому что непостоянство Eigen2 было слишком большим. Но я недавно узнал, что следующая версия Eigen2 будет содержать определения, которые будут отключать код выравнивания и сделать его безопасным. Поэтому я могу переключиться.

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

Eigen2/Eigen3

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

Idiocyncracies/downsides: (Некоторые из них можно избежать некоторыми определениями, доступными в текущей ветвью развития Eigen3)

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

GMTL

Преимущества: LGPL, простой API, специально разработанный для графических движков. Включает множество примитивных типов, предназначенных для рендеринга (таких как плоскости, AABB, quatenrions с множественной интерполяцией и т.д.), что не входят в какие-либо другие пакеты. Очень низкая накладная память, довольно быстрая, легко использовать. Все заголовки, без необходимости связывания.

Idiocyncracies/отрицательные стороны:

  •  API
  • причудливый  
    • то, что может быть myVec.x() в другой lib, доступно только через myVec [0] (проблема чтения)
      • массив или stl:: vector точек может заставить вас сделать что-то вроде pointList [0] [0] для доступа к х-компоненту первой точки
       
    • в наивной попытке оптимизации, удаления креста (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 не содержит операций для векторов, VecOps.h содержит некоторые - другие, например, в Generate.h. cross (vec &, vec &, vec &) в VecOps.h, [make] cross (vec &, vec &) в Generate.h
  •  
  • незрелый/нестабильный API; все еще меняется.  
    • Например, "cross" переместился с "VecOps.h" на "Generate.h" и то имя было изменено на "makeCross". Недопустимые примеры документации потому что все еще относятся к старым версиям функций, которые больше не существуют.

NT2

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

Последний релиз более 2 лет назад.

По-видимому, на английском языке нет документации, хотя, возможно, что-то есть на французском языке.

Не удается найти трассировку сообщества вокруг проекта.

LAPACK & BLAS

Преимущества: Старые и зрелые.

Downsides:

  • старые как динозавры с действительно дрянной API

Ответ 3

Если вы ищете высокопроизводительную матричную/линейную алгебру/оптимизацию на процессорах Intel, я бы посмотрел библиотеку Intel MKL.

MKL тщательно оптимизирован для быстрой работы во время исполнения - большая часть из них основана на очень зрелых стандартах BLAS/LAPACK fortran. И его производительность масштабируется с количеством доступных ядер. Масштабируемость без помощи рук с доступными ядрами - это будущее вычислений, и я бы не использовал математическую библиотеку для нового проекта, не поддерживая многоядерные процессоры.

Вкратце, он включает в себя:

  • Основной вектор-вектор, вектор-матрица, и матрично-матричные операции
  • Матричная факторизация (LU decomp, эрмитовая, разреженная)
  • Задачи с наименьшими квадратами и проблемы с собственными значениями
  • Решаемые линейные системные решатели
  • Нелинейный решатель наименьших квадратов (области доверия)
  • Плюс процедуры обработки сигналов, такие как БПФ и свертка
  • Очень быстрые генераторы случайных чисел (mersenne twist)
  • Гораздо больше.... см.: текст ссылки

Недостатком является то, что API MKL может быть довольно сложным в зависимости от требуемых подпрограмм. Вы также можете взглянуть на свою библиотеку IPP (Integrated Performance Primitives), которая ориентирована на высокопроизводительные операции обработки изображений, но тем не менее довольно широка.

Пол

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

Ответ 4

Для чего это стоит, я пробовал как Эйген, так и Армадилло. Ниже приведена краткая оценка.

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

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

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

Недостатки: 1. Зависит от внешних BLAS и/или LAPACK для матричных разложений. 2. В документации отсутствует ИМХО (включая специфику по LAPACK, кроме изменения оператора #define).

Было бы неплохо, если бы была доступна библиотека с открытым исходным кодом, которая является автономной и простой в использовании. Я столкнулся с этой проблемой в течение 10 лет, и это расстраивает. В какой-то момент я использовал GSL для C и писал обложки С++ вокруг него, но с современным С++ - особенно с использованием преимуществ шаблонов выражений - нам не нужно было возиться с C в 21 веке. Просто мой tuppencehapenny.

Ответ 5

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

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

Ответ 6

Я новичок в этой теме, поэтому не могу сказать много, но BLAS в значительной степени является стандартом в научных вычислениях, BLAS фактически является стандартом API, который имеет множество реализаций. Я честно не знаю, какие реализации наиболее популярны или почему.

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

Ответ 7

Как насчет GLM?

Он основан на спецификации OpenGL Shading Language (GLSL) и выпущен под лицензией MIT. Очевидно, что он нацелен на графических программистов.

Ответ 8

Я добавлю голос для Eigen: я поместил много кода (3D-геометрию, линейную алгебру и дифференциальные уравнения) из разных библиотек в этот, улучшив как производительность, так и читаемость кода почти во всех случаях.

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

Ответ 9

Хорошо, думаю, я знаю, что вы ищете. Похоже, что GGT - довольно хорошее решение, как предположил Рид Копси.

Лично мы катали нашу собственную небольшую библиотеку, потому что мы имеем дело с рациональными точками - много рациональных NURBS и Безье.

Оказывается, большинство библиотек 3D-графики выполняют вычисления с проективными точками, не имеющими базиса в проективной математике, потому что это дает вам ответ, который вы хотите. Мы закончили использование точек Грассмана, которые имеют прочную теоретическую основу и уменьшили количество точечных типов. Грассманские точки - это в основном те же самые вычисления, которые люди используют сейчас, используя надежную теорию. Самое главное, это делает вещи более ясными в наших умах, поэтому у нас меньше ошибок. Рон Голдман написал статью о грассмановых точках компьютерной графики под названием "Об алгебраических и геометрических основах компьютерной графики" .

Не имеет прямого отношения к вашему вопросу, но интересное чтение.

Ответ 10

FLENS

http://flens.sf.net

Он также реализует множество функций LAPACK.

Ответ 11

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