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

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

I'm doing that change now...

gael.

On Sun, Nov 22, 2009 at 10:52 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 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
>>>
>>>
>>
>>
>>
>>
>>
>
>
>