Re: [eigen] solve API

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

On Mon, Jun 28, 2010 at 5:15 PM, FMDSPAM <fmdspam@xxxxxxxxx> wrote:
>  Just my 2 cent:
>
> I know, that expression do not have to be evaluated but nevertheless
> I would try to avoid the word "inverse()", because of lession #1: "Never use
> matrix inversion".

This rule exists only because of the poor implementation/API of the
other libs ;)

I'm kidding, I see your point, but I don't see it as a strong argument
against inverse.

In books you never use "solve" in your mathematical formula, but
always write, e.g., A^1 B. Wouldn't it be convenient to be able to
write code which closely follow what you found in a textbook, or to
write code as you write formulas on your paper sheets without worrying
about performance? Actually, I'm pretty sure that many newcomers to
linear algebra do not know about these details, and simply write what
they read in their favorite book:  A.inverse() * B (I've seen that
several times). So if A.inverse() would return a A.lu().inverse()
proxy, then no more worry.

>
> What about
>
> x = b * A.adjoint().lu().invertor()     (like benoit's solver())
>

As I said to Manoj, this is not equivalent to have the adjoint applied
on the inverse proxy (lu.inverse().adjoint()) because I want to be
able to use the LU dec to solve both adjoint and non adjoint problems.

So it should be:

LU<> lu(A);

x = lu.invertor() * b;
y = lu.invertor().adjoint() * b;

but "invertor().adjoint()" is a bit weird. Nonetheless, I prefer
invertor()  to solve() or solver().


>
> But cleaner for me to read is, what Manoj suggesting:
>>
>>     x = solve(A,b); // left
>>     x = solve(b,A); // right
>>     x = solve(b, A.triangularView<Lower>()); // Gael's example
>
> It's OK to read and understand w/o scarring about "inverse()" too.

it is really ambiguous because

x = solve(b,A);

can mean x = b^-1 A, and anyway this proposal works at a different
level that the one we are considering.

cheers,
gael

>
> --Frank
>
>
>