| Re: [eigen] Switched libmv to Eigen2; some thoughts and questions. |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen 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
you:
http://download.tuxfamily.org/eigen/golub-van-loan-matrix-computations-3ed-djvu.tar.gz
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:
> >
> > http://eigen.tuxfamily.org/api/structEigen_1_1IOFormat.html
>
> 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)
#include<Eigen/Core>
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)
Cheers,
Benoit
---