Re: [eigen] Why no LU::solveInPlace()?

[ Thread Index | Date Index | More Archives ]

On 17.08.2010 09:36, Gael Guennebaud wrote:
We definitely have to uniformize that, but actually we could also
consider removing all the solveInPlace functions...

Indeed, when you write:

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).

I really hope that this comparison will be optimized away in most cases by any recent compiler ...

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?

I think the const correctness issues are somewhat related to something I complained about last month (2nd issue of that mail):

I think the clean way would be to pass some wrapper as const reference, which internally holds a non-const reference/pointer. Actually the only objects which can be passed to solveInPlace are direct-access types (unless I'm wrong) so technically you only need to pass a pointer to the start of the data together with the sizes and strides (where the latter can be templated).

Is someone currently working on the 'Direct-access type unification'-TODO? (or on my issue from above's mail?)

I'd volunteer to work out some suggestions/concepts, but currently I am quite busy and you couldn't expect something before mid-September from me :(


Dipl.-Inf. Christoph Hertzberg
Cartesium 0.051
Universität Bremen
Enrique-Schmidt-Straße 5
28359 Bremen

Tel: (+49) 421-218-64252

Mail converted by MHonArc 2.6.19+