Re: [eigen] docs updates

[ Thread Index | Date Index | More Archives ]

On Saturday 11 October 2008 22:48:06 Scott Wheeler wrote:
> Hi folks --
> I've been messing around with Eigen (after trying a few other linear
> algebra libs) and I'm starting to document a few of the points that have
> stumped me at first.  I'll just keep committing those changes unless
> someone explicitly objects.

No objection, thank you very much for doing this. Worst case, both Gael and I 
read commit messages anyway.

> A few notes:
> - When matrix sizes are specified as template parameters they can blow
> up the stack if you're using large matrices.  I documented that, but it
> might be nicer if the code automatically picked up on the large size and
> used heap allocation

This is where it's useful to have your point of view as I didn't expect 
anybody to even try passing large values as template parameters. When you 
pass the size as template parameters, this means the size is known at 
compile-time, which allows to avoid dynamic memory allocation and to unroll 
loops (when appropriate). Of course this only makes sense for small sizes, 
typically up to 4x4, sometimes up to 16x16.

Moreover we set Eigen::Dynamic to 10000 assuming nobody would ever use a fixed 
size of that order of magnitude. If anybody does, he'll get serious 
problems. /me makes a mental note to add a static assert for that.

> - MatrixBase::norm2() sounds like it should be an l2 norm (l2 norms in
> uBLAS are "norm_2", for instance).  If that wasn't there in Eigen 1 it's
> probably worth changing.

We don't aim at compatibility with Eigen 1, and all Eigen1 code in KDE and its 
direct dependencies is ported to Eigen2 (except the old avogadro snapshot 
which needs to be removed).

> It's a little confusing having norm() and 
> norm2() which would seem naturally to be an l1 and l2 norm.  I'll add a
> docs comment there since that cost me a couple hours today.

Sorry about that. I thought that norm() meant the usual norm a.k.a. 
the "length" and norm2() meant squared-norm. I am opposed to using such a 
good function name as norm() to designate the l1 norm which is not a very 
natural thing in math; however if you want the l1 norm of a vector v just do:


and more generally for the l^p norm of v do:

std::pow(v.cwise().abs().cwise().pow(p).sum(), 1/p)

and for the l^infinity norm, do:


> - Would it make sense to ditch RowVector and just have operator*() sort
> out the column / row priority based on the operands?

I'm not convinced: the main advantage would be the possibility of doing

v1 * v2

however currently you can already do

v1.transpose() * v2

since vectors are handled as a special case of matrices. This is more explicit 
and is what you find in pseudocode examples from math books, so I don't think 
people will mind having to write transpose() here.

Moreover the notation v1 * v2 would be very ambiguous: it would seem to mean 
the coefficient-wise product (v1.cwise()*v2).



Mail converted by MHonArc 2.6.19+