Re: [eigen] Unifying decomposition interfaces

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

2009/5/20 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
> On Wed, May 20, 2009 at 2:16 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> In such an extreme case as 2x2, eventually we want to have fixed-size
>> specializations for all decompositions.
>
> For the 2x2 Eigenvalue decomposition case I have well tested routines.
> How do you intend to do the specialization? Specialize compute() only
> via an external struct with a run-method (as it is e.g. done in the
> Transform class)? Just wondering...

I'm not decided (didn't think much about it yet). It's nontrivial
because often compute() is not the only thing that needs to be
specialized, e.G. in LU we also need to specialize solve().

For eigendecomposition, yes, afaics compute() is the only thing
needing specialization, so your approach is good (afaics).

>
>> I just had a look at LU and have 2 remarks.
>> a) we'll have to decide how to guard against using an uninitialized
>> decomposition. I would like to advocate using ei_assert(). In
>> decompositions that store a pointer to the original matrix, this is a
>> great thing to test for. Otherwise add a bool m_initialized member.
>
> Do you propose every single function to be safe-guarded or is it fine
> when some functions return empty matrices or similar return values
> indicating that something is handled the wrong way?

At first glance, i'd rather have asserts in every public function but
feel free to break the rule... i didn't look at that very closely.

Cheers,
Benoit