En yaygın kullanılan C ++ vektör / matris matematik / doğrusal cebir kütüphaneleri ve bunların maliyet ve fayda dengesi nedir? [kapalı]

Birçok projenin yavaş yavaş matris matematiği yapma ihtiyacı ortaya çıktığı ve yarım sınıflı bir özel lineer cebir kütüphanesi inşa edene ve ona bağlı olarak yavaşça işlevselliği ekleyen tuzağa düştüğü görülüyor.

Bazı teğetsel ilgili kitaplığa (örneğin OpenCV, OpenSceneGraph) bağımlılık oluşturmadan bunu önlemek istiyorum.

Orada yaygın olarak kullanılan matris matematik / doğrusal cebir kütüphaneleri nelerdir ve neden birini diğerinin üzerinde kullanmaya karar veresiniz ki? Herhangi bir nedenle kullanılmasına karşı önerilecek herhangi bir bilgi var mı? Bunu özellikle geometrik / zaman bağlamında * (2,3,4 Dim) * kullanıyorum, ancak gelecekte daha yüksek boyutlu veriler kullanıyor olabilirim.

API, hız, bellek kullanımı, genişlik / bütünlük, darlık / özgüllük, genişletilebilirlik ve / veya olgunluk / kararlılık ile ilgili farklılıklar arıyorum.

Güncelleme

Sonunda çok mutlu olduğum Eigen3'ü kullandım.

Bunun için Genel Grafik Araç Seti'ne yerleşmiş birkaç proje var . Orada GMTL güzel - oldukça küçük, çok fonksiyonel ve çok güvenilir olacak kadar yaygın olarak kullanılmıştır. OpenSG, VRJuggler ve diğer projelerin hepsi, kendi elle yuvarlanan vertor / matris matematiği yerine bunu kullanmaya başladı.

Oldukça hoş buldum - her şeyi şablonlarla yapıyor, bu yüzden çok esnek ve çok hızlı.

Düzenle:

Yorumlar tartışmasından ve düzenlemelerden sonra, belirli uygulamaların yararları ve dezavantajları ve durumunuz göz önüne alındığında neden birini diğeri seçebileceğiniz hakkında daha fazla bilgi vereceğimi düşündüm.

GMTL -

Faydaları: Özellikle grafik motorları için tasarlanmış basit API. Başka herhangi bir pakette bulunmayan oluşturmaya yönelik birçok ilkel türü (uçaklar, AABB, çoklu enterpolasyonlu quatenrions, vb.) İçerir. Çok düşük bellek yükü, oldukça hızlı, kullanımı kolay.

Dezavantajları: API özellikle oluşturma ve grafiklere çok odaklanmıştır. Genel amaçlı (NxM) matrisler, matris ayrıştırma ve çözme vb. İçermez, çünkü bunlar geleneksel grafik / geometri uygulamaları alanı dışındadır.

Öz -

Faydaları: Temiz API , kullanımı oldukça kolaydır. Kuaterniyonlar ve geometrik dönüşümler içeren bir Geometri modülü içerir . Düşük bellek yükü. Büyük NxN matrislerinin ve diğer genel amaçlı matematiksel rutinlerin tam, yüksek performanslı çözümü.

Dezavantajları: İstediğinizden biraz daha geniş bir kapsam olabilir (?). GMTL ile karşılaştırıldığında daha az geometrik / spesifik rutin oluşturma (örn: Euler açısı tanımları, vb.).

IMSL -

Yararları: Çok eksiksiz bir sayısal kütüphane. Çok, çok hızlı (sözde en hızlı çözücü). Şimdiye kadar en büyük, en eksiksiz matematiksel API. Ticari olarak desteklenen, olgun ve kararlı.

Dezavantajları: Maliyet - ucuz değil. Çok az geometrik / belirli yöntem oluşturma, bu yüzden kendi lineer cebir sınıflarının üstüne kendi rulo gerekir.

NT2 -

Yararları: MATLAB'a alışkınsanız daha tanıdık olan bir sözdizimi sağlar. Büyük matrisler vb. İçin tam ayrışma ve çözme sağlar.

Dezavantajları: Matematiksel, işleme odaklı değil. Muhtemelen Eigen kadar performans göstermez.

LAPACK -

Faydaları: Çok kararlı, kanıtlanmış algoritmalar. Uzun zamandır etrafta. Tam matris çözme, vb. Gizli matematik için birçok seçenek.

Dezavantajları: Bazı durumlarda yüksek performans göstermez. Fortran'dan, kullanım için tek API ile taşındı.

Şahsen benim için, tek bir soruya geliyor - bunu nasıl kullanmayı planlıyorsunuz? Eğer sadece render ve grafiklere odaklanıyorsanız, iyi performans gösterdiğinden ve kendi uygulamanızı uygulamak zorunda kalmadan kutudan birçok yararlı oluşturma işlemini desteklediğinden, Generic Graphics Toolkit'i seviyorum . Genel amaçlı matris çözme işlemine ihtiyacınız varsa (yani: büyük matrislerin SVD veya LU ayrışması), Eigen ile birlikte giderim , çünkü bazı geometrik işlemler sağlar ve büyük matris çözümleri ile çok performans gösterir. Kendi grafiklerinizi / geometrik işlemlerinizi (matrislerinin / vektörlerinin üstüne) daha fazla yazmanız gerekebilir, ancak bu korkunç değildir.

Bu yüzden oldukça eleştirel biriyim ve bir kütüphaneye yatırım yapacaksam, kendimi neyin içine soktuğumu daha iyi bilirdim. İnceleme sırasında eleştiriye ve yassılığa ışık tutmanın daha iyi olduğunu düşünüyorum; yanlış olan şey gelecek için doğru olandan çok daha fazla sonuç doğurur. Bu yüzden, bana yardımcı olabilecek bir tür cevap sağlamak için buraya biraz fazla gideceğim ve umarım bu yolda ilerleyebilecek başkalarına yardımcı olur. Bunun, bu kitapçıklarla yaptığım küçük incelemelere / testlere dayalı olduğunu unutmayın. Oh ve ben Reed'in bazı olumlu açıklamalarını çaldık.

Eigen2 güvensizliğinin bir dezavantajı çok büyük olduğu için kendine özgü olmasına rağmen GMTL ile gittiğimi belirteceğim. Ancak son zamanlarda Eigen2'nin bir sonraki sürümünün hizalama kodunu kapatacak ve güvenli hale getirecek tanımları içereceğini öğrendim. Böylece geçiş yapabilirim.

Güncelleme : Eigen3'e geçtim. Her ne kadar kendine özgü ifadelerine rağmen, kapsamı ve zarafeti göz ardı etmek çok zordur ve güvensiz hale getiren optimizasyonlar bir tanımla kapatılabilir.

Eigen2 / Eigen3

Faydaları: LGPL MPL2, Temiz, iyi tasarlanmış API, kullanımı oldukça kolaydır. Canlı bir toplulukla iyi korunmuş gibi görünüyor. Düşük bellek yükü. Yüksek performans. Genel lineer cebir için üretilmiştir, ancak iyi geometrik işlevsellik de mevcuttur. Tüm başlık lib, bağlantı gerekmez.

İdiocyncracies / downsides: (Bunların bazıları / hepsi mevcut geliştirme dalı Eigen3'te bulunan bazı tanımlarla önlenebilir )

• Güvenli olmayan performans optimizasyonları kurallara dikkatle uyulmasına neden olur. Kurallara uyulmaması çökmelere neden olur.
  • güvenli bir şekilde değer katamazsınız
  • Eigen türlerinin üye olarak kullanılması özel ayırıcı özelleştirme gerektirir (veya kilitlenir)
  • stl konteyner türleri ve muhtemelen diğer şablonlar ile kullanın özel ayırma özelleştirme gerekli (ya da çökecek)
  • bazı derleyiciler işlev çağrılarında çökmeleri önlemek için özel dikkat gerektirir (GCC pencereleri)

GMTL

Faydaları: LGPL, Oldukça Basit API, özellikle grafik motorları için tasarlanmıştır. Başka herhangi bir pakette bulunmayan oluşturmaya yönelik birçok ilkel türü (uçaklar, AABB, çoklu enterpolasyonlu quatenrions, vb.) İçerir. Çok düşük bellek yükü, oldukça hızlı, kullanımı kolay. Tüm başlık tabanlı, bağlantı gerekmez.

Idiocyncracies / olumsuzlukları:

• API ilginç
  • başka bir lib'de myVec.x () işlevi yalnızca myVec [0] aracılığıyla kullanılabilir (Okunabilirlik sorunu)
    • bir dizi veya stl :: nokta vektörü, ilk noktanın x bileşenine erişmek için pointsList [0] [0] gibi bir şey yapmanıza neden olabilir
  • derleme gereksiz temperleri ortadan kaldırdığında naif bir optimizasyon girişiminde, çapraz (vec, vec) kaldırıldı ve makeCross (vec, vec, vec) ile değiştirildi
  • Normal matematik işlemleri, bazı optimizasyon özelliklerini kapatmazsanız normal türleri döndürmez. Örneğin: vec1 - vec2normal bir vektör döndürmez, bu yüzden çalışır length( vecA - vecB )olsa bile başarısız olur vecC = vecA - vecB. Şunun gibi sarmalısınız:length( Vec( vecA - vecB ) )
  • vektörler üzerindeki işlemler üyelerden ziyade harici fonksiyonlar tarafından sağlanır. Bu, yaygın sembol adları çarpışabileceği için kapsam çözünürlüğünü her yerde kullanmanızı gerektirebilir
  • yapmak zorundasın
      length( makeCross( vecA, vecB ) )
    ya
      gmtl::length( gmtl::makeCross( vecA, vecB ) )
    da başka türlü deneyebilirsin
      vecA.cross( vecB ).length()
    

• bakımlı değil
  • hala "beta" olarak iddia ediliyor
  • normal işlevselliği kullanmak için hangi başlıklara ihtiyaç duyulduğu gibi temel bilgileri eksik belgeler
    • Vec.h, Vektörler için işlemler içermez, VecOps.h bazılarını içerir, diğerleri Generate.h dosyasındadır. VecOps.h içinde çapraz (vec &, vec &, vec &), Generate.h içinde [make] cross (vec &, vec &)

• olgunlaşmamış / kararsız API; hala değişiyor.
  • Örneğin "cross", "VecOps.h" den "Generate.h" e taşındı ve daha sonra adı "makeCross" olarak değiştirildi. Artık mevcut olmayan işlevlerin eski sürümlerine başvurduğu için dokümantasyon örnekleri başarısız oluyor.

NT2

Anlayamıyorum çünkü web sayfalarının fraktal resim başlığına içerikten daha fazla ilgi duyuyorlar. Ciddi bir yazılım projesinden çok akademik bir projeye benziyor.

En son 2 yıl önce yayınlandı.

Görünüşe göre İngilizce hiçbir belge olsa bir yerde Fransızca bir şey var.

Proje çevresinde bir topluluğun izini bulamıyorum.

DİZÜSTÜ & BLAS

Faydaları: Yaşlı ve olgun.

Downsides:

• gerçekten berbat API'lerle dinozorlar kadar eski

Değeri için, hem Eigen hem de Armadillo'yu denedim. Aşağıda kısa bir değerlendirme yer almaktadır.

Eigen Avantajları: 1. Tamamen müstakil - harici BLAS veya LAPACK'a bağımlı değildir. 2. Belgeler iyi. 3. Test edilemese de hızlı.

Dezavantaj: QR algoritması, R matrisi üst üçgenin içine gömülü olarak sadece tek bir matris döndürür. Matrisin geri kalan kısmının nereden geldiği hakkında bir fikir yoktur ve hiçbir Q matrisine erişilemez.

Armadillo Avantajları: 1. Çok çeşitli ayrışma ve diğer fonksiyonlar (QR dahil). 2. Oldukça hızlı (ifade şablonlarını kullanır), ama yine, gerçekten yüksek boyutlara itmedim.

Dezavantajları: 1. Matris dekompozisyonları için harici BLAS ve / veya LAPACK'e bağlıdır. 2. Belgelerde IMHO mevcut değil (#define ifadesini değiştirmekten başka, LAPACK wrt özellikleri dahil).

Kendi kendine yeten ve kullanımı kolay bir açık kaynak kitaplığı mevcut olsaydı iyi olurdu. Aynı sorunu 10 yıldır yaşadım ve sinir bozucu oluyor. Bir noktada, C için GSL kullandım ve etrafına C ++ sarmalayıcıları yazdım, ancak modern C ++ ile - özellikle ifade şablonlarının avantajlarını kullanarak - 21. yüzyılda C ile uğraşmak zorunda kalmamalıyız. Sadece benim tuppencehapenny.

Intel işlemcilerde yüksek performanslı matris / doğrusal cebir / optimizasyon arıyorsanız Intel'in MKL kütüphanesine bakarım.

MKL hızlı çalışma süresi performansı için özenle optimize edilmiştir - bunların çoğu çok olgun BLAS / LAPACK fortran standartlarına dayanmaktadır. Ve performansı mevcut çekirdek sayısı ile ölçeklendirilir. Mevcut çekirdeklerle eller serbest ölçeklenebilirliği, bilgisayar kullanımının geleceğidir ve yeni bir proje için çok çekirdekli işlemcileri desteklemeyen herhangi bir matematik kütüphanesi kullanmam.

Çok kısaca şunları içerir:

1. Temel vektör-vektör, vektör-matris ve matris-matris işlemleri
2. Matris çarpanlara ayırma (LU decomp, hermityan, seyrek)
3. En küçük kareler uydurma ve özdeğer problemleri
4. Seyrek doğrusal sistem çözücüleri
5. Doğrusal olmayan en küçük kareler çözücü (güven bölgeleri)
6. Artı FFT ve evrişim gibi sinyal işleme rutinleri
7. Çok hızlı rasgele sayı üreteçleri (mersenne twist)
8. Çok daha fazlası .... bakınız: bağlantı metni

Bir dezavantajı, MKL API'sinin ihtiyacınız olan rutinlere bağlı olarak oldukça karmaşık olabilmesidir. Ayrıca, yüksek performanslı görüntü işleme operasyonlarına yönelik olan, ancak yine de oldukça geniş olan IPP (Entegre Performans İlkelleri) kütüphanelerine de göz atabilirsiniz.

Paul

CenterSpace Yazılımı, .NET Matematik kütüphaneleri, centerpace.net

Eigen ve NT2 hakkında iyi şeyler duydum , ama kişisel olarak da kullanmadım. Dişte biraz uzadığına inandığım Boost.UBLAS da var . NT2'nin geliştiricileri, bir sonraki sürümü, Boost'a almak amacıyla inşa ediyorlar, bu da bir şey için sayılabilir.

Linim. alg. ihtiyaçları 4x4 matris kasasının ötesinde garanti edilmez, bu yüzden gelişmiş işlevsellik hakkında yorum yapamam; Sadece bazı seçeneklere dikkat çekiyorum.

Bu konuda yeniyim, bu yüzden çok şey söyleyemem, ancak BLAS bilimsel hesaplamada standarttır. BLAS aslında birçok uygulamaya sahip bir API standardıdır. Hangi uygulamaların en popüler ya da neden olduğuna dürüstçe emin değilim.

Ortak lineer cebir işlemlerini de yapmak istiyorsanız (çözme sistemleri, en küçük kareler regresyonu, ayrışma, vb.) LAPACK'e bakın .

GLM ne olacak ?

OpenGL Gölgelendirme Dili (GLSL) spesifikasyonuna dayanır ve MIT lisansı altında yayınlanır. Açıkça grafik programcılarına yönelik

Eigen için oy ekleyeceğim: Farklı kütüphanelerden buna çok sayıda kod (3D geometri, doğrusal cebir ve diferansiyel denklemler) taşıdım - neredeyse tüm durumlarda hem performansı hem de kod okunabilirliğini geliştirdim.

Bahsedilmeyen bir avantaj: SSE'yi Eigen ile kullanmak çok kolaydır, bu da 2D-3D işlemlerin performansını önemli ölçüde geliştirir (her şeyin 128 bite kadar doldurulabileceği yerlerde).

Tamam, sanırım ne aradığını biliyorum. Reed Copsey'in önerdiği gibi GGT'nin oldukça iyi bir çözüm olduğu anlaşılıyor.

Şahsen, kendi küçük kütüphanemizi yuvarladık, çünkü rasyonel noktalarla çok fazla rasyonel NURBS ve Bezier ilgileniyoruz.

Çoğu 3D grafik kütüphanesinin, projektif matematikte temeli olmayan projektif noktalarla hesaplamalar yaptığı ortaya çıkıyor, çünkü bu size istediğiniz cevabı veriyor. Sonunda sağlam bir teorik dayanağı olan ve puan türü sayısını azaltan Grassmann puanlarını kullandık. Grassmann noktaları temel olarak insanların şu anda kullandığı hesaplamalar ve sağlam bir teorinin avantajı. En önemlisi, aklımızdaki şeyleri daha açık hale getiriyor, bu yüzden daha az hata var. Ron Goldman, bilgisayar grafiklerinde Grassmann noktalarına "Bilgisayar Grafiklerinin Cebirsel ve Geometrik Temelleri Üzerine" adlı bir makale yazdı .

Sorunuzla doğrudan ilgili değil, ilginç bir okuma.

FLENS

http://flens.sf.net

Ayrıca birçok LAPACK işlevi de uygular.

Bu kütüphaneyi oldukça basit ve işlevsel buldum ( http://kirillsprograms.com/top_Vectors.php ). Bunlar C ++ şablonları ile uygulanan çıplak kemik vektörleridir. Hiçbir fantezi şeyler - sadece vektörler ile yapmanız gereken (toplama, çıkarma, çarpma, nokta, vb).