|Re: [eigen] Unifying decomposition interfaces|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Unifying decomposition interfaces
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Wed, 20 May 2009 15:11:01 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=ScAjaJIdtWPXc4R0UBNSpeCISNxC8XQlOctWZoBETEw=; b=BDtkYBS8SdCJ6rH0hr+VmdFvukFi9X5L4rlSLxUE5YnnctbKnIHipZKYnbfLm6Qlik Tp4N5iU+RsyyFIecY8d/vybWAk1REnvqNsu8ig8qjUvRwGUtMP+AyCoRszi7TtY7tn5Y 5yCs8MYr3zq7tzSO4f1KkCcSa0qVRINV0cFXk=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=GhUK1/+I5nhUPsFdlHJn6LMaSO80C2XC2Gkd4eofSHOswJAlN0oTyi4NIrAe9Yv3wz QI7Rg8BKapMMTopGwhfYqTT+ISM/qRp5w8L6nTNJFZhLjECjin51KLgGc8SFE+VVWw0K z3WxLQKJGvuTuY9lXHygFfNoTVSDUED6hM+JU=
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.