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

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen <eigen@xxxxxxxxxxxxxxxxxxx>*Subject*: Re: [eigen] Google Summer of Code 2018 - Symmetric Matrices for Eigen*From*: Rasmus Munk Larsen <rmlarsen@xxxxxxxxxx>*Date*: Mon, 11 Jun 2018 08:48:15 -0700*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ymZhw7Ecpayjvx7VaY//0sW+qQ1LXN88M7RxxobQPYo=; b=DJg8atsSgOfrgtC7wQHQPZJdXDhceLegG3KvosDE6r6EiSDjgl7avcvuS8UPM6L/6t Aw94hbxBhT5Bi4G3LMiNfKG1rz4JuDczYTGBVpM7sziHLxRC00KA2uPwSWM0KupgiYG6 jpMjA/uImvOLWfL6cvPBstByDrZDg0xnjShKPByz1ooSGeiBhxJJu8ntQVKntg8WV2ts DOYQpFb8S5MOpa2nwUgTzApn8rapKzoAzeeoEMaJkgrleAoXmUYgL5JlfOlm1dHRjpVN KAP/myZRpXgGVuhynXdBs1CFlN9RqrsFNHGGJR3K2STqru3Hxtraxd5hbVHMqp9q/ox3 EMQg==

Hi David,

The performance numbers look impressive. Nice work. Looking forward to seeing matrix multiply numbers :-)

Cheers,

Rasmus

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 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:

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

-----------------------------------------------------------------------

**References**:**Re: [eigen] Google Summer of Code 2018 - Symmetric Matrices for Eigen***From:*David A. Tellenbach

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Google Summer of Code 2018 - Symmetric Matrices for Eigen** - Next by Date:
**[eigen] PATCH: Guard CUDA includes with EIGEN_CUDACC** - Previous by thread:
**Re: [eigen] Google Summer of Code 2018 - Symmetric Matrices for Eigen** - Next by thread:
**[eigen] PATCH: Guard CUDA includes with EIGEN_CUDACC**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |