Re: [eigen] Google Summer of Code 2018 - Symmetric Matrices for Eigen

On Sun, Jun 10, 2018 at 3:00 PM David A. Tellenbach <datell@xxxxxxxxxxxxx> wrote:

Hello together,

first of all: Thank you again for supporting the idea of implementing a class
for hermitian matrices in Eigen.

I would be happy if you could give me some feedback on what I have implemented
so far:

https://bitbucket.org/tellenbach/eigen/src/HermitianMatrix/

I've decided to name the class HermitianMatrix and to store either the upper or
lower triangular part in rectangular full packed format as suggested by some of
you. For further information about this storage format see

http://www.netlib.org/lapack/lawnspdf/lawn199.pdf

The current implementation consists of the following functionality:

1. Constructors to build a HermitianMatrix by passing a dense Matrix. The
elements are stored in a dense Matrix in either row or column major.
2. Core evaluators for providing the methods coeff(), coeffRef() and the
operator ()
3.. Sum and difference assignment operators += and -=
4. CwiseBinaryOp for supporting addition and subtraction of two hermitian
matrices.
5. Assignment of CwiseBinaryOp to HermitianMatrix.

All methods try to use transform the problems of hermitian matrices to problems
of 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 when
the upper triangular part of a matrix is stored in RFPF and the method coeff() or
coeffRef() is called for an element in the lower triangular part, the complex
conjugated should be returned. Any idea how this could be handled?

I have benchmarked (using Google benchmark) some functionality I've implemented
and it looks very good. As an attachment you find some of the benchmark results
for addition (including evaluation) for fixed and dynamically sized matrices.

I would be really happy about some feedback.

All the best,
David

Am 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 matrices

at 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,
David

Am 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-routines

Best
Márton

On 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:
http://eigen.tuxfamily.org/bz/show_bug.cgi?id=42
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.

Cheers,
Christoph

On 2018-05-03 00:01, David A. Tellenbach wrote:

Hello together,

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.

Thanks,
David

--
Dr.-Ing. Christoph Hertzberg

Besuchsadresse der Nebengeschäftsstelle:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Postadresse der Hauptgeschäftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 1
28359 Bremen, Germany

Tel.: +49 421 178 45-4021
Zentrale: +49 421 178 45-0
E-Mail: christoph.hertzberg@xxxxxxx

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
Steuernummer: 19/672/50006
-----------------------------------------------------------------------