|Re: [eigen] Why no LU::solveInPlace()?|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Why no LU::solveInPlace()?
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Tue, 17 Aug 2010 09:36:40 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=4zwb4AU9fNeWzJNCGhrFFjOHEN6EUrvHYy65K/2bTf8=; b=v5JQypOnWD5Wi5V9aiD4Nbiae3DcWcxZbfjeqb5kARQ2yVgrl1zAAGoR5/H1IV6M3v 8NIrDmjVcQfaUUKwkQi5DB6hLaDrIoznc6iGSQYZsYHQ90F7a4kXMrfmibELEb5WB+xE veHBTAVhZvvql2Qj/QrP19fWCyCKLqqemZOT4=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=Uhtb3PgWSSCvL3e8YvgDdE/JL27Rco5JFRkEep44v5zEd3NNURRf/nGuuGM9R5T4HB 0AaipSG6bkEnvrcBJcOEQCtBQNTLm1uzj509MKIfMOma7TA9olJFWjk/2zkmWW27rhId R7nDxyLjSY3d4LSLH5RH1ObbX94uopZTCgzGQ=
We definitely have to uniformize that, but actually we could also
consider removing all the solveInPlace functions...
Indeed, when you write:
X = A.lu().solve(X);
Eigen automatically performs the solve operation inplace, just like it
would do with :
- simpler API: only one function
- works fine with writable temporary objects, e.g., X.col(j) =
- need to write the "source" and "destination" object twice
- requires one runtime test (one pointer comparison which is disabled
at compile time if the types do not match).
Recall that to make the solveInPlace() function to work with writable
temporary objects we either have to declare the argument as a const
reference or enforce the user to name the temporary that can be a real
pain without the C++1x auto keyword.
What other people think about it?
On Mon, Aug 16, 2010 at 4:21 PM, Manoj Rajagopalan <rmanoj@xxxxxxxxx> wrote:
> I see LLT::solveInPlace() and ei_inplace_solve() for LU but no
> LU::solveInPlace(). Could this member function be considered for inclusion at
> least for a uniform API?