Re: [eigen] Switched libmv to Eigen2; some thoughts and questions.

[ Thread Index | Date Index | More Archives ]

On Sunday 16 November 2008 00:18:05 Keir Mierle wrote:
> In typical vision applications, a common occurrence is solving Ax = 0 where
> A contains measurements (or numbers derived from measurements) from images.
> In theory the A matrix should be singular, but because of measurements is
> not. So the SVD provides the 'best' null vector given noise.

OK, we are talking of exactly the same thing.

> I tried finding a copy of Matrix Computations online, but sadly the
> critical pages are missing from Google's book previews.

A while ago, I found a scanned copy on a P2P network. I uploaded it there for 

It's in DJVU format, it opens at least in DjView, KDVI, Okular provided you 
have the appropriate packages installed.

> I will see about 
> finding a copy next week. I didn't find any good descriptions of how to
> implement the SVD online. It appears computing the SVD breaks down into two
> phases: 1. Bidiagonalize A into UBV (via householder reflections or
> somesuch), then 2. Eliminate the superdiagonals via rotations (QR) or
> similar. Bidiagonalize is useful on its own, and there are multiple ways of
> accomplishing it, so separating it out seems good.

Why not; we already have tridiagonalization by the way.

> One issue with reusing the QR and LU methods already in eigen as part of an
> SVD solver is that it does not appear possible to use existing matrices for
> the storage, rather than having them private members of the QR/LU class.
> Have you guys considered making the API such that the user can supply
> allocated matrices for the results? I may be misunderstanding the API.

Hm indeed that's not currently possible. I actually didn't know that QR was 
useful as a step in SVD. That can be changed if that's really useful. 
Actually, QR is almost the same thing as Gram-Schmidt orthonormalization, so 
that makes sense.

> > > One issue with Eigen2 is that the default formatting for output is not
> >
> > very
> > Gael already fixed this :) Using the IOFormat class you get very
> > customizable
> > IO.
> >
> > See this:
> >
> >
> Yes, I saw this; my issue is not that it can't be done, it's that the
> default is not good. I am not sure what justification there is for the
> current default format; why is it not aligned?

Please SVN up, as of r885517 you are able to change the default format by 
#defining EIGEN_DEFAULT_IO_FORMAT before including Eigen, like this:

#define EIGEN_DEFAULT_IO_FORMAT IOFormat(choose your parameters)

It defaults to just IOFormat() which I keep unaligned because I think that as 
soon as people care about prettiness of the format, they will want to 
fine-tune their parameters anyway. The default, raw format is at least useful 
for outputting to a ascii file. The aligning is costly. For the docs, we'll 
use an aligned default format.

>    - Have a compile define to switch the default if so desired (not sure
> how else this could be done).

Yes exactly what I've done.

> Having the ability to output to C and Eigen2 is very useful as well,
> because sometimes you want to take the result of a computation and put it
> back into source code (particular for unit testing). I also did this for
> libmv1, where I had a function 'output_to_c(name)' which produced
> double name[2][2] = { {1, 2}, {3, 4} };

Yes, Eigen's IOFormat allows you to do that, so with the new 
EIGEN_DEFAULT_IO_FORMAT you're one LOC away of having this as the default.

Personnally, I'm interested in outputting to LaTeX,
\left(\begin{matrix} 1 & 2 \\ 3 & 4 \end{matrix}\right)



Mail converted by MHonArc 2.6.19+