Các thư viện đại số tuyến tính / ma trận / toán học C ++ được sử dụng rộng rãi nhất là gì, và sự đánh đổi chi phí và lợi ích của chúng là gì? [đóng cửa]

Dường như nhiều dự án dần dần xuất hiện nhu cầu làm toán ma trận, và rơi vào cái bẫy của việc xây dựng một số lớp vectơ đầu tiên và từ từ thêm chức năng cho đến khi chúng bị bắt xây dựng một thư viện đại số tuyến tính tùy chỉnh một nửa, và tùy thuộc vào nó.

Tôi muốn tránh điều đó trong khi không xây dựng sự phụ thuộc vào một số thư viện liên quan tiếp tuyến (ví dụ OpenCV, OpenSceneGraph).

Các thư viện toán học / đại số tuyến tính thường được sử dụng là gì và tại sao lại quyết định sử dụng cái này? Có bất kỳ điều gì sẽ được khuyên không nên sử dụng vì một số lý do? Tôi đặc biệt sử dụng điều này trong bối cảnh hình học / thời gian * (2,3,4 Dim) * nhưng có thể sẽ sử dụng dữ liệu chiều cao hơn trong tương lai.

Tôi đang tìm kiếm sự khác biệt liên quan đến bất kỳ: API, tốc độ, sử dụng bộ nhớ, độ rộng / đầy đủ, độ hẹp / độ đặc hiệu, khả năng mở rộng và / hoặc trưởng thành / ổn định.

Cập nhật

Tôi đã kết thúc việc sử dụng Eigen3 mà tôi vô cùng hài lòng.

Có khá nhiều dự án đã giải quyết trên Bộ công cụ đồ họa chung cho việc này. GMTL ở đó rất hay - nó khá nhỏ, rất chức năng và được sử dụng rộng rãi đến mức rất đáng tin cậy. OpenSG, VRJuggler và các dự án khác đều đã chuyển sang sử dụng điều này thay vì toán học ma trận / ma trận cuộn bằng tay của chính họ.

Tôi đã thấy nó khá hay - nó thực hiện mọi thứ thông qua các mẫu, vì vậy nó rất linh hoạt và rất nhanh.

Biên tập:

Sau khi thảo luận về các bình luận và chỉnh sửa, tôi nghĩ rằng tôi sẽ cung cấp thêm một số thông tin về lợi ích và nhược điểm của việc triển khai cụ thể và lý do tại sao bạn có thể chọn cái khác, đưa ra tình huống của bạn.

GMTL -

Lợi ích: API đơn giản, được thiết kế đặc biệt cho các công cụ đồ họa. Bao gồm nhiều loại nguyên thủy hướng đến kết xuất (như mặt phẳng, AABB, quatenrions với nhiều phép nội suy, v.v.) không có trong bất kỳ gói nào khác. Chi phí bộ nhớ rất thấp, khá nhanh, dễ sử dụng.

Nhược điểm: API rất tập trung đặc biệt vào kết xuất và đồ họa. Không bao gồm ma trận mục đích chung (NxM), phân rã và giải ma trận, v.v., vì chúng nằm ngoài lĩnh vực của các ứng dụng đồ họa / hình học truyền thống.

Bản địa -

Lợi ích: API sạch , khá dễ sử dụng. Bao gồm một mô-đun Hình học với các bậc bốn và biến đổi hình học. Bộ nhớ thấp. Giải quyết đầy đủ, hiệu quả cao các ma trận NxN lớn và các thói quen toán học có mục đích chung khác.

Nhược điểm: Có thể là một phạm vi lớn hơn một chút so với bạn muốn (?). Ít thói quen hình học / kết xuất cụ thể hơn khi so sánh với GMTL (nghĩa là: Định nghĩa góc Euler, v.v.).

IMSL -

Lợi ích: Thư viện số rất đầy đủ. Rất, rất nhanh (được cho là người giải nhanh nhất). Cho đến nay, API toán học lớn nhất, đầy đủ nhất. Hỗ trợ thương mại, trưởng thành và ổn định.

Nhược điểm: Chi phí - không tốn kém. Rất ít phương pháp hình học / kết xuất cụ thể, vì vậy bạn sẽ cần phải tự mình cuộn lên trên các lớp đại số tuyến tính của chúng.

NT2 -

Lợi ích: Cung cấp cú pháp quen thuộc hơn nếu bạn đã sử dụng MATLAB. Cung cấp sự phân tách và giải quyết đầy đủ cho các ma trận lớn, v.v.

Nhược điểm: Toán học, không tập trung kết xuất. Có lẽ không phải là biểu diễn như Eigen.

LAPACK -

Lợi ích: Rất ổn định, thuật toán đã được chứng minh. Đã được khoảng một thời gian dài. Hoàn thành giải ma trận, vv Nhiều lựa chọn cho toán học tối nghĩa.

Nhược điểm: Không hiệu quả cao trong một số trường hợp. Được chuyển từ Fortran, với API lẻ để sử dụng.

Cá nhân, đối với tôi, nó đi đến một câu hỏi duy nhất - bạn dự định sử dụng cái này như thế nào. Nếu bạn tập trung vào kết xuất đồ họa và đồ họa, tôi thích Bộ công cụ đồ họa chung , vì nó hoạt động tốt và hỗ trợ nhiều thao tác kết xuất hữu ích ngoài hộp mà không phải thực hiện theo cách riêng của bạn. Nếu bạn cần giải quyết ma trận mục đích chung (ví dụ: phân tách SVD hoặc LU của ma trận lớn), tôi sẽ đi với Eigen , vì nó xử lý việc đó, cung cấp một số thao tác hình học và rất hiệu quả với các giải pháp ma trận lớn. Bạn có thể cần phải viết nhiều hơn các hoạt động đồ họa / hình học của riêng bạn (trên ma trận / vectơ của chúng), nhưng điều đó không kinh khủng.

Vì vậy, tôi là một người khá quan trọng và nghĩ rằng nếu tôi sẽ đầu tư vào một thư viện, tôi sẽ biết rõ hơn về những gì tôi đang làm. Tôi nghĩ tốt hơn là nên nặng lời chỉ trích và xem nhẹ những lời tâng bốc khi xem xét kỹ lưỡng; những gì sai với nó có nhiều ý nghĩa cho tương lai hơn những gì đúng. Vì vậy, tôi sẽ đi sâu vào đây một chút để cung cấp loại câu trả lời sẽ giúp tôi và tôi hy vọng sẽ giúp những người khác có thể đi theo con đường này. Hãy nhớ rằng điều này dựa trên những gì đánh giá / kiểm tra nhỏ mà tôi đã thực hiện với những lib này. Oh và tôi đã đánh cắp một số mô tả tích cực từ Reed.

Tôi sẽ đề cập đến đầu trang mà tôi đã đi với GMTL mặc dù đó là sự bình dị vì tính không an toàn của Eigen2 là một nhược điểm quá lớn. Nhưng gần đây tôi đã biết rằng bản phát hành tiếp theo của Eigen2 sẽ chứa các định nghĩa sẽ tắt mã căn chỉnh và làm cho nó an toàn. Vì vậy, tôi có thể chuyển qua.

Cập nhật : Tôi đã chuyển sang Eigen3. Mặc dù có những đặc điểm riêng, nhưng phạm vi và sự tao nhã của nó quá khó để bỏ qua và những tối ưu hóa khiến nó không an toàn có thể bị tắt bằng một định nghĩa.

Eigen2 / Eigen3

Lợi ích: LGPL MPL2, API sạch, được thiết kế tốt, khá dễ sử dụng. Có vẻ được duy trì tốt với một cộng đồng sôi động. Bộ nhớ thấp. Hiệu suất cao. Được làm cho đại số tuyến tính nói chung, nhưng chức năng hình học tốt cũng có sẵn. Tất cả lib tiêu đề, không cần liên kết.

Idiocyncracies / nhược điểm: (Một số / tất cả những điều này có thể tránh được bằng một số định nghĩa có sẵn trong nhánh phát triển hiện tại Eigen3)

• Tối ưu hóa hiệu suất không an toàn dẫn đến cần phải tuân thủ cẩn thận các quy tắc. Không tuân thủ các quy tắc gây ra tai nạn.
  • bạn chỉ đơn giản là không thể vượt qua một cách an toàn
  • sử dụng các loại Eigen làm thành viên yêu cầu tùy chỉnh cấp phát đặc biệt (hoặc bạn gặp sự cố)
  • sử dụng với các loại thùng chứa stl và có thể các mẫu khác yêu cầu tùy chỉnh phân bổ đặc biệt (hoặc bạn sẽ gặp sự cố)
  • một số trình biên dịch nhất định cần được chăm sóc đặc biệt để ngăn sự cố trong các lệnh gọi hàm (cửa sổ GCC)

GMTL

Lợi ích: LGPL, API khá đơn giản, được thiết kế dành riêng cho các công cụ đồ họa. Bao gồm nhiều loại nguyên thủy hướng đến kết xuất (như mặt phẳng, AABB, quatenrions với nhiều phép nội suy, v.v.) không có trong bất kỳ gói nào khác. Chi phí bộ nhớ rất thấp, khá nhanh, dễ sử dụng. Tất cả dựa trên tiêu đề, không cần liên kết.

Idiocyncracies / nhược điểm:

• API kỳ quặc
  • những gì có thể là myVec.x () trong một lib khác chỉ có sẵn thông qua myVec [0] (Vấn đề về khả năng đọc)
    • một mảng hoặc stl :: vectơ điểm có thể khiến bạn phải làm gì đó như pointsList [0] [0] để truy cập thành phần x của điểm đầu tiên
  • trong một nỗ lực ngây thơ để tối ưu hóa, đã loại bỏ chéo (vec, vec) và thay thế bằng makeCross (vec, vec, vec) khi trình biên dịch loại bỏ temps không cần thiết
  • Các phép toán thông thường không trả về các loại bình thường trừ khi bạn tắt một số tính năng tối ưu hóa, ví dụ: vec1 - vec2không trả về một vectơ bình thường nên length( vecA - vecB )không thành công mặc dù vecC = vecA - vecBhoạt động. Bạn phải gói như:length( Vec( vecA - vecB ) )
  • hoạt động trên các vectơ được cung cấp bởi các chức năng bên ngoài chứ không phải thành viên. Điều này có thể yêu cầu bạn sử dụng độ phân giải phạm vi ở mọi nơi vì tên biểu tượng phổ biến có thể va chạm
  • bạn phải làm
      length( makeCross( vecA, vecB ) )
    hoặc
      gmtl::length( gmtl::makeCross( vecA, vecB ) )
    nếu không bạn có thể thử
      vecA.cross( vecB ).length()
    

• không được bảo trì tốt
  • vẫn tuyên bố là "beta"
  • tài liệu thiếu thông tin cơ bản như tiêu đề nào là cần thiết để sử dụng chức năng bình thường
    • Vec.h không chứa các hoạt động cho vectơ, VecOps.h chứa một số, những cái khác nằm trong Generate.h chẳng hạn. chéo (vec &, vec &, vec &) trong VecOps.h, [make] chéo (vec &, vec &) trong Generate.h

• API chưa trưởng thành / không ổn định; vẫn đang thay đổi
  • Ví dụ: "chéo" đã chuyển từ "VecOps.h" sang "Generate.h", và sau đó tên được đổi thành "makeCross". Các ví dụ về tài liệu không thành công vì vẫn đề cập đến các phiên bản cũ của các chức năng không còn tồn tại.

NT2

Không thể biết vì dường như họ quan tâm nhiều hơn đến tiêu đề hình ảnh fractal của trang web của họ hơn là nội dung. Trông giống như một dự án học thuật hơn là một dự án phần mềm nghiêm túc.

Phát hành mới nhất hơn 2 năm trước.

Rõ ràng không có tài liệu bằng tiếng Anh mặc dù được cho là có một cái gì đó bằng tiếng Pháp ở đâu đó.

Không thể tìm thấy dấu vết của một cộng đồng xung quanh dự án.

LAPACK & BLAS

Lợi ích: Cũ và trưởng thành.

Nhược điểm:

• già như khủng long với các API thực sự nhảm nhí

Để biết giá trị của nó, tôi đã thử cả Eigen và Armadillo. Dưới đây là một đánh giá ngắn gọn.

Ưu điểm của Eigen: 1. Hoàn toàn khép kín - không phụ thuộc vào BLAS hoặc LAPACK bên ngoài. 2. Tài liệu đàng hoàng. 3. Cố ý rất nhanh, mặc dù tôi chưa thử nghiệm.

Nhược điểm: Thuật toán QR chỉ trả về một ma trận đơn, với ma trận R được nhúng trong tam giác trên. Không biết phần còn lại của ma trận đến từ đâu và không có ma trận Q nào có thể được truy cập.

Ưu điểm của Armadillo: 1. Phạm vi phân hủy rộng và các chức năng khác (bao gồm cả QR). 2. Nhanh chóng hợp lý (sử dụng các mẫu biểu thức), nhưng một lần nữa, tôi thực sự đã đẩy nó lên các chiều cao.

Nhược điểm: 1. Phụ thuộc vào BLAS bên ngoài và / hoặc LAPACK cho phân tách ma trận. 2. Tài liệu thiếu IMHO (bao gồm LAPACK cụ thể, ngoài việc thay đổi câu lệnh #define).

Sẽ thật tuyệt nếu một thư viện mã nguồn mở có sẵn, khép kín và dễ sử dụng. Tôi đã gặp vấn đề tương tự trong 10 năm và nó trở nên bực bội. Tại một thời điểm, tôi đã sử dụng GSL cho C và viết các trình bao bọc C ++ xung quanh nó, nhưng với C ++ hiện đại - đặc biệt là sử dụng các lợi thế của các mẫu biểu thức - chúng ta không nên gặp rắc rối với C trong thế kỷ 21. Chỉ cần tuppencehapenny của tôi.

Nếu bạn đang tìm kiếm ma trận / đại số tuyến tính / tối ưu hóa hiệu suất cao trên bộ xử lý Intel, tôi sẽ xem thư viện MKL của Intel.

MKL được tối ưu hóa cẩn thận cho hiệu suất thời gian chạy nhanh - phần lớn dựa trên các tiêu chuẩn fortran BLAS / LAPACK rất trưởng thành. Và hiệu suất của nó quy mô với số lượng lõi có sẵn. Khả năng mở rộng rảnh tay với các lõi khả dụng là tương lai của điện toán và tôi sẽ không sử dụng bất kỳ thư viện toán học nào cho một dự án mới không hỗ trợ bộ xử lý đa lõi.

Rất ngắn gọn, nó bao gồm:

1. Các phép toán vectơ cơ bản, vectơ, ma trận và ma trận
2. Yếu tố ma trận (LU decomp, hermiti, thưa thớt)
3. Phù hợp với bình phương nhỏ nhất và các vấn đề eigenvalue
4. Giải quyết hệ thống tuyến tính thưa thớt
5. Bộ giải bình phương tối thiểu phi tuyến tính (vùng tin cậy)
6. Các thói quen xử lý tín hiệu cộng như FFT và tích chập
7. Máy phát số ngẫu nhiên rất nhanh (mersenne twist)
8. Nhiều hơn nữa .... xem: liên kết văn bản

Một nhược điểm là API MKL có thể khá phức tạp tùy thuộc vào thói quen mà bạn cần. Bạn cũng có thể xem thư viện IPP (Nguyên tắc hiệu suất tích hợp) của họ, hướng đến các hoạt động xử lý hình ảnh hiệu suất cao, nhưng vẫn khá rộng.

Paul

Phần mềm CenterSpace, thư viện .NET Math, centrepace.net

Tôi đã nghe những điều hay về Eigen và NT2 , nhưng cá nhân tôi cũng không sử dụng. Ngoài ra còn có Boost.UBLAS , mà tôi tin rằng sẽ có một chút dài trong răng. Các nhà phát triển của NT2 đang xây dựng phiên bản tiếp theo với ý định đưa nó vào Boost, vì vậy điều đó có thể được tính cho một cái gì đó.

Lin của tôi alg các nhu cầu không vượt quá trường hợp ma trận 4x4, vì vậy tôi không thể nhận xét về chức năng nâng cao; Tôi chỉ chỉ ra một số tùy chọn.

Tôi chưa quen với chủ đề này, vì vậy tôi không thể nói nhiều, nhưng BLAS gần như là tiêu chuẩn trong điện toán khoa học. BLAS thực sự là một tiêu chuẩn API, có nhiều triển khai. Tôi thực sự không chắc chắn việc triển khai nào là phổ biến nhất hoặc tại sao.

Nếu bạn cũng muốn có thể thực hiện các phép toán đại số tuyến tính phổ biến (hệ thống giải, hồi quy bình phương nhỏ nhất, phân tách, v.v.) hãy xem xét LAPACK .

Còn GLM thì sao?

Nó dựa trên đặc tả Ngôn ngữ tạo bóng OpenGL (GLSL) và được phát hành theo giấy phép MIT. Rõ ràng nhắm vào các lập trình viên đồ họa

Tôi sẽ thêm phiếu bầu cho Eigen: Tôi đã chuyển rất nhiều mã (hình học 3D, đại số tuyến tính và phương trình vi phân) từ các thư viện khác nhau sang thư viện này - cải thiện cả hiệu suất và khả năng đọc mã trong hầu hết các trường hợp.

Một lợi thế không được đề cập: rất dễ sử dụng SSE với Eigen, giúp cải thiện đáng kể hiệu suất của các hoạt động 2D-3D (trong đó mọi thứ có thể được đệm thành 128 bit).

Được rồi, tôi nghĩ rằng tôi biết những gì bạn đang tìm kiếm. Dường như GGT là một giải pháp khá tốt, như đề xuất của Reed Copsey.

Cá nhân, chúng tôi đã cuộn thư viện nhỏ của riêng mình, bởi vì chúng tôi xử lý các điểm hợp lý rất nhiều - rất nhiều NURBS và Beziers hợp lý.

Nó chỉ ra rằng hầu hết các thư viện đồ họa 3D thực hiện các tính toán với các điểm phóng chiếu không có cơ sở trong toán học phóng xạ, bởi vì đó là những gì giúp bạn có câu trả lời bạn muốn. Chúng tôi đã kết thúc bằng cách sử dụng các điểm Grassmann, có nền tảng lý thuyết vững chắc và giảm số lượng các loại điểm. Điểm Grassmann về cơ bản là cùng các tính toán mà mọi người đang sử dụng, với lợi ích của một lý thuyết mạnh mẽ. Quan trọng nhất, nó làm cho mọi thứ rõ ràng hơn trong tâm trí của chúng tôi, vì vậy chúng tôi có ít lỗi hơn. Ron Goldman đã viết một bài báo về các điểm Grassmann trong đồ họa máy tính có tên "Trên nền tảng đại số và hình học của đồ họa máy tính" .

Không liên quan trực tiếp đến câu hỏi của bạn, nhưng một bài đọc thú vị.

HOA

http://flens.sf.net

Nó cũng thực hiện rất nhiều chức năng LAPACK.

Tôi thấy thư viện này khá đơn giản và có chức năng ( http://kirillsprograms.com/top_Vector.php ). Đây là các vectơ xương trần được thực hiện thông qua các mẫu C ++. Không có công cụ ưa thích - chỉ là những gì bạn cần làm với vectơ (thêm, trừ nhân, chấm, v.v.).