Re: [eigen] Student contribution

[ Thread Index | Date Index | More Archives ]

Rather than making the SVD effort direction dependent on generalizing the Bidagonalization class, would it make sense to move in an orthogonal direction and focus the effort on decomposing square or tall matrices, at least initially? This should simplify the code, require only the UpperBidiagonalization, and decrease the scope.  This improves the probability the students will get to a point of usefulness in a limited time.  It is trivial to wrap a "tall SVD" to make a general purpose SVD: [u,s,v]=svd(A)  <=> [v,s,u] = svd(A').  The resulting wrapper may have some inefficiencies on wide matrices due to the initial transpose, but I'd be surprised if it was much.    If the students finish quickly, or if parallel development is desired; the task of Bidiagonalization could also be performed, but it would not need to be a prerequisite for the rest of the SVD.

-- Mark

On 05/22/2013 06:13 AM, Benoit Jacob wrote:

2013/5/21 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
Hi and welcome!

Indeed, a divide-and-conquer SVD would still be very useful. There is
already a bidiagonalization class so that you can focus on the divide
and conquer part,

 Just a side note. Last I checked (I haven't contributed for a terribly long time, so what I say may be outdated) we only have a UpperBidiagonalization class. We don't have anything doing lower-bidiagonalization. That means that we only can bidiagonalize matrices where rows >= cols.

The right solution to that problem, I believe, is *not* to have another LowerBidiagonalization class, or a templatized Bidiagonalization class.

Instead, I believe that the right solution is to have a single Bidiagonalization class that can switch between "upper" and "lower" at runtime. That gives a lot more flexibility and smaller binary code, and that is what LAPACK's SGESDD,

it is doing that, and a look at its code suggested that it had found an elegant way of switching at runtime between upper- and lower-bidiagonalization without any significant performance penalty.

Anyway, it also is a perfectly valid approach to focus on square matrices for a first implementation and only start worrying about these questions afterwards.

This is a very useful thing to add to Eigen so let me wish you good luck with this project!


Mail converted by MHonArc 2.6.19+