|Re: [eigen] Google Summer of Code 2018 - Symmetric Matrices for Eigen|
[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]
Hello together,first of all: Thank you again for supporting the idea of implementing a classfor hermitian matrices in Eigen.I would be happy if you could give me some feedback on what I have implementedso far:I've decided to name the class HermitianMatrix and to store either the upper orlower triangular part in rectangular full packed format as suggested by some ofyou. For further information about this storage format seeThe current implementation consists of the following functionality:1. Constructors to build a HermitianMatrix by passing a dense Matrix. Theelements are stored in a dense Matrix in either row or column major.2. Core evaluators for providing the methods coeff(), coeffRef() and theoperator ()3.. Sum and difference assignment operators += and -=4. CwiseBinaryOp for supporting addition and subtraction of two hermitianmatrices.5. Assignment of CwiseBinaryOp to HermitianMatrix.All methods try to use transform the problems of hermitian matrices to problemsof the underlying dense matrix that stores the matrix elements.A problem I'm currently facing is the following: In the case of complex scalars,I want to support real hermitian and not just symmetric matrices. That means whenthe upper triangular part of a matrix is stored in RFPF and the method coeff() orcoeffRef() is called for an element in the lower triangular part, the complexconjugated should be returned. Any idea how this could be handled?I have benchmarked (using Google benchmark) some functionality I've implementedand it looks very good. As an attachment you find some of the benchmark resultsfor addition (including evaluation) for fixed and dynamically sized matrices.I would be really happy about some feedback.All the best,DavidAm 04.05.2018 um 20:28 schrieb David A. Tellenbach <david.tellenbach@xxxxxxxxxxxxx>:Hi all,I doubt that RFPF is superior to simple packed format for 4x4 matricesat least in the case of simple operations I agree (even for bigger matrices). If we additionally consider Peter's argument that a packed format is easier to resize and Christoph's argument that someone could use packed storage and cannot change that, I think we shouldn't just drop the idea of implementing it completely.Nevertheless the RFPF performance speaks for itself. Without deciding to never implement packed storage, the implementation of RFPF should have priority, I guess.Thanks,DavidAm 04.05.2018 um 17:38 schrieb Rasmus Munk Larsen <rmlarsen@xxxxxxxxxx>:I agree with Marton. It doesn' seem worthwhile to complicate the code and increase the API surface for something that is know not to perform well on modern architectures. (It was a different story on Crays with (tiny) solid state memories :-) )On Thu, May 3, 2018 at 11:18 AM, Márton Danóczy <marton78@xxxxxxxxx> wrote:Hi Christoph,supporting the "Packed Format" is not worth it, even LAPACK have dropped support because of the FP routines' subpar performance (see the second comment in this thread: https://github.com/Reference-LAPACK/lapack/issues/245). The RFP format is and will keep being supported by LAPACK (same Github thread).Another reference: https://software.intel.com/en-us/mkl-developer-reference-c-matrix-storage-schemes-for-lapack-routinesBestMártonOn 3 May 2018 at 19:28, Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:Hi,
mostly repeating what I told David privately already:
I suggest implementing a compact _triangular_ matrix which can be used together with SelfAdjointView to represent selfadjoint matrices as well.
And then I'd like to point anyone interested in this discussion to this (very old) feature request:
This also mentions the RFPF suggested by Márton -- but we probably should support both and start with the one which is easier to implement.
On 2018-05-03 00:01, David A. Tellenbach wrote:
my name is David Tellenbach, I'm currently studying Computer Science at the LMU Munich, Germany and got chosen for the Google Summer of Code 2018 Project "Faster Matrix Algebra for ATLAS", supervised by Dmitry Emeliyanov and Stewart Martin-Haugh.
Google Summer of Code is a global program focused on bringing more student developers into open source software development. Students work with an open source organization on a three month programming project during their break from school.
As you might know, our project's task is to implement support for symmetric matrices for Eigen. A short project description is available via the following link: https://summerofcode.withgoogle.com/projects/#5293950017994752 <https://summerofcode.withgoogle.com/projects/#5293950017994752>
The official coding period hasn't started yet and lasts for three month, from May, 14 until August, 14 2018. The time now is meant to get to know the community and people involved.
As far as I see, Eigen basically provides three types of matrices: Dense, sparse and diagonal matrices. Of these types, the class Eigen::DiagonalMatrix seems to be the one that could be most similar to a possible implementation of a class for symmetric matrices. There is no need for storing all elements (as in the case of dense matrices) neither is a sophisticated mechanism to find the position of scalars in the matrix needed (as in the case of sparse matrices). Therefore I’d like to create the for symmetric matrices by deriving from Eigen::EigenBase (as in the case of diagonal matrices).
Of course one goal is to store only the upper or lower triangular part of the matrix since this already defines it completely. Similar to Eigen::DiagonalMatrix the storage could look something like this:
typedef typename internal::traits<Derived>::SymmetricVectorType SymmetricVectorType;
// Store just one triangular part of the matrix
typedef Matrix<_Scalar, (SizeAtCompileTime * SizeAtCompileTime + SizeAtCompileTime)/2,
1, 0, (MaxSizeAtCompileTime * MaxSizeAtCompileTime + MaxSizeAtCompileTime)/2 ,1> SymmetricVectorType;
We plan to provide constructors which take either matrices of type Eigen::Matrix<…> or Eigen::SelfAdjointView<…>.
What do you think about these broad plans so far? We are happy about any feedback.
Dr.-Ing. Christoph Hertzberg
Besuchsadresse der Nebengeschäftsstelle:
Robotics Innovation Center
28359 Bremen, Germany
Postadresse der Hauptgeschäftsstelle Standort Bremen:
Robotics Innovation Center
28359 Bremen, Germany
Tel.: +49 421 178 45-4021
Zentrale: +49 421 178 45-0
Weitere Informationen: http://www.dfki.de/robotik
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
|Mail converted by MHonArc 2.6.19+||http://listengine.tuxfamily.org/|