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

[ Thread Index | Date Index | More Archives ]

ok, good,

then I think the best solution is to introduce a DenseExpressionBase
class just like we have a DenseStorageBase class to be able to select
lightweight expressions and pass them by value to a solveInPlace()


On Fri, Sep 3, 2010 at 1:32 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> For MatrixXf we don't. For Matrix2f we might (as the branching's cost
> can be non-negligible)... I really can't make up my mind. On the one
> hand it is unusual for us in Eigen to do this kind of if(), and it is
> unusual for us to tolerate even small / potential overheads when the
> matrices at hand may be fixed-size. On the other hand, since we don't
> currently have fixed-size specializations for these decompositions, we
> do currently have overhead in these decompositions. Yet again, this
> new if() would be a kind of overhead inherent to the API. Also, what
> if the B is an expression that takes longer to write. Then having to
> write it twice will be annoying. For example:
> = A.solve(;
> Finally, a solveInPlace() method is easy to look up and understand for
> people who just want to write code quickly and be sure that stuff is
> optimized. It's explicit.
> Maybe a good compromise is to keep solveInPlace() and also do the if()
> in solve(). Should make everyone happy: people who care about the cost
> of the if() will typically be able to use in-place solving anyway.

Mail converted by MHonArc 2.6.19+