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

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2009/11/22 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>
> 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.

ok, thanks for the reply. So i do nothing for now.

I also don't do the renaming UpperTriangular--->Upper to limit
conflicts, until your merge.

Benoit

>
> gael.
>
> On Sun, Nov 22, 2009 at 9:42 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
> wrote:
>>
>> Hi,
>>
>> 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.
>>
>> Solutions:
>>
>> 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.
>>
>> Benoit
>>
>>
>
>
>
>
>