Re: [eigen] what to do with old flags like SelfAdjointBit

[ Thread Index | Date Index | More Archives ]

I my opinion we can safely remove those bit flags.

In the Eigenvalues module the two methods using SelfAdjointBit have to be moved/specialized in SelfAdjointView anyway to make them really usable, and so they won't use this bit flag anymore.

About the SparseModule, I've already implemented the same API than for dense matrices, and so they are not needed anymore. Well, this is currently in my fork, so let's say we keep these bit flags until the merge is done.


On Sun, Nov 22, 2009 at 9:42 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:

a long time ago, we thought that properties like "upper triangular" or
"self-adjoint" should be handled as MatrixBase Flags. We have long
changed our minds: they are now handled as special proxy classes like
TriangularView and SelfadjointView, and at the moment we dont even try
to offer storage classes for that. (Note that even in LAPACK, useful
triangular storage is only a recent/future feature.)

This leaves the question, what to do with the old bits such as
SelfAdjointBit, etc. Initially I just wanted to remove these enum
values, but I noticed that quite a bit of code (mainly in Sparse and
in Eigenvalues) is still checking for that bit and has special code
paths. If I just remove SelfAdjointBit, I have to remove that code
too, which is too bad. So instead, let's discuss right now what should
be the proper way to check for selfadjointness on generic types. Note
that i'm only using SelfAdjoint as an example: there are also all the
triangular shapes.


A. we can just keep SelfAdjointBit, just document well that MatrixBase
objects just never have that bit set, but other AnyMatrixBase classes
may still have it.

B. actually i suspect that it will be much more scalable to introduce
structs like this:

template<typename T> struct ei_is_selfadjoint
 enum { ret = 0 };

which partial specializations like:

template< blabla > struct SelfAdjointView< blabla >
 enum { ret = 1 };

C. unify all that in a single struct. We can't really put that in
ei_traits because we want to define that once and for all to 0 for all
MatrixBase objects, we don't want to have to write again and again in
all the ei_traits more boilerplate code. So perhaps ei_shape:

template<typename T> struct ei_shape
 enum { ret = 0 };

which partial specializations like:

template< blabla > struct SelfAdjointView< blabla >
 enum { ret = SelfAdjointBit };

Here, i think of ret as a bit-field. So SelfAdjointBit would survive
but it wouldn't have to have a special value different from MatrixBase
Flags bits. It could be just 1, etc...

Again, i used SelfAdjointBit as an example, think of all the
triangular flags here.


Mail converted by MHonArc 2.6.19+