Re: [eigen] solve API
• To: eigen@xxxxxxxxxxxxxxxxxxx
• Subject: Re: [eigen] solve API
• From: Manoj Rajagopalan <rmanoj@xxxxxxxxx>
• Date: Mon, 28 Jun 2010 18:56:28 -0400
• Organization: EECS Dept., University of Michigan, Ann Arbor, MI, USA

```

On Monday 28 June 2010 01:56:44 pm Gael Guennebaud wrote:
> thank you for taking part to the discussion :)
>
> >
> >
> > [I] How about free functions: (with appropriate template params)
> >
> >   MatrixBase solve(MatrixBase const& A, MatrixBase const& b); // on-left
> >   MatrixBase solve(MatrixBase const& b, MatrixBase const& A); // on-right
>
> how do you distinguish between both functions, they have the same
> prototype..
>
> >  Usage:
> >
> >    x = solve(A,b); // left
> >    x = solve(b,A); // right
>
> same, when I see:
>
> X = solve(B,A);
>
> do you want X = B^-1 A or X = B A^-1 ??? we cannot know for you. (X
> and B can be matrices, not only vectors).
>

Yeah the prototype confusion should have caught my eye - C++ won't distinguish
the two. Is there some way to prove that A and b come from different levels
in the MatrixBase specialization hierarchy? If so, then we can disambiguate.
For (bad) example, if A must be a container and not an expression then A will
be of type DenseStorageBase. Then the left vs right could be distinguished.
Right now I think Eigen wants to be able to allow arbitrary expressions for A
also. For the dense case, requiring that A be a DenseStorageBase or even
DenseBase, I think we can overcome the prototype collision.

For other cases like DiagonalBase, TriangularView etc. the disambiguation is
of course automatic ...

Also, I now understand the issue you were raising. Such free functions can be
built by the user as a library on top of the Eigen API that is currently
under discussion.

-- Manoj

```

 Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/