Re: [eigen] still the solve() API debate

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2009/9/11 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> First of all I don't like the use of pointers here, because it is not
> a standard c++ practice, and therefore users we'll start wondering: "
> why do they use a pointer here ? maybe because this parameter is
> optional ? hm does not make sense... unless if x==0, then the
> computation is performed in place overwritten b ? or the solve
> function creates the matrix object and then I have to delete it myself
> ? etc. ". OK, maybe I'm exaggerating a bit, but that's the idea.

OK, I didn't know that pointers had such a strong connotation.

>
> ok, now let's summarize, ideally we want an API which satisfies the
> following constraints:
>
> a - concise (not too verbose)
> b - readable
> c - simple behavior
> d - it should return the result so that we can directly use it in an expression
> e - does not create unnecessary temporary
> f - directly works with temporary proxy object
> g - compliant with standard c++ practices

Agree,

>
> since I changed my mind about ReturnByValue inheriting MatrixBase, I
> think opt 3 is the one which best satisfies all these constraints.

Yep, so now we agree.

> However, I (we) forgot to include in the discussion the API of the
> in-place solve functions which should be as close as possible to the
> generic solve().  Currently this only apply to the triangular solver,
> LLT and LDLT, but I think this could also apply to PartialLU. Here the
> problem is a bit different because the result is also and input and so
> only option 1 and 4 could work:
>
> opt 1: A.solveInPlace(&b_and_x);
>
> opt 4: A.solveInPlace(b_and_x.ref());
>
> Since opt 1 does not satisfy the constraint f and that this constraint
> is particularly important for the in-place triangular solver, it
> currently remains the opt 4 only.

OK, provided we find a not-too-heavy API for that, and see below:

> Also, note that a variant of opt 4, is to replace .ref() by the (more
> explicit ?) pair .out() and .inout(), in which case the "InPlace"
> suffix may be removed, e.g.:
>
> Z = 2 * M * A.solve(b.inout())
>
> but note that how subtle the difference is with:
>
> Z = 2 * M * A.solve(b);
>
> so maybe it is better to stuck with .ref() and the InPlace suffix.

Hey, what do you think about renaming .ref() by .inplace() in this
case? Then this API looks quite good to me:

A.solve(b.inplace());

I'd be OK with that API, actually I think that it's not even
significantly heavier than the plain-c++-reference option,
A.solveInPlace(b).

Also, +1 to your idea to make it return a reference to the inplace argument..

Since this is not significantly heavier than the plain-c++-reference
option, does the dilemma that you describe in your next e-mail still
exist? Is this light enough to standardize on even in cases where the
plain-c++-reference option would be applicable?

Benoit