Re: [eigen] docs updates |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] docs updates*From*: Benoît Jacob <jacob@xxxxxxxxxxxxxxx>*Date*: Sun, 12 Oct 2008 02:21:26 +0200*Cc*: Scott Wheeler <wheeler@xxxxxxx>

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 ---

**Follow-Ups**:**Re: [eigen] docs updates***From:*Scott Wheeler

**References**:**[eigen] docs updates***From:*Scott Wheeler

**Messages sorted by:**[ date | thread ]- Prev by Date:
**[eigen] docs updates** - Next by Date:
**Re: [eigen] docs updates** - Previous by thread:
**[eigen] docs updates** - Next by thread:
**Re: [eigen] docs updates**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |