[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen 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:
v.cwise().abs().sum()
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:
v.cwise().abs().maxCoeff()
>
> - 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).
Cheers,
Benoit
---