| Re: [eigen] Unifying decomposition interfaces |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Unifying decomposition interfaces
- From: Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>
- Date: Wed, 20 May 2009 14:59:53 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=qcqQvEku4uaD1AC0X+o/EkuSdwCQJhKJfdxNd+vpL/k=; b=FlyuCya2t6QTjgFXX2ERKOqmWoOWG8aFThzI3zZDRSFCCuUEbdcX0Y5Ok3/cdV4oZI n5nfxkz0riMEecDR/eCjoDi5JAq8iF73JGdyo7QVk+QJvNS1I4Wz6fbUfIr2Zj5gznzK Pvvj7JTtThLqKxrxC/YeltNHvRjSFHj8ja9kQ=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=HpuqDilfL/TcQfBFb03XfMUQWJFAI8DQqxG9hYZHzZkbc9JklA6qSKJd3HfstQ511S zGp6cRCw6V492bsTRpxZOQ4V3Jl3iK4l88arzw0lj7Fj+Xdq0GRkAUk28lmB7cGjtuOd bAaE27M7rChbtYU6ER1YLAPSpd2b6QXcwmbRk=
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 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?
> b) you name the pointer m_pOriginalMatrix. So far we didn't do the
> "p". I would advocate m_originalMatrix: the compiler takes care
> already of checking that we're remembering that it's a pointer (so we
> must use ->...)
done...
- Hauke