Re: [eigen] docs updates

[ Thread Index | Date Index | More Archives ]

Benoît Jacob wrote:
No objection, thank you very much for doing this. Worst case, both Gael and I read commit messages anyway.

That's what I figured. I'll keep up with it if I hit places that seem unclear.

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.

The reason that I did that, and cleared up the docs similarly, was at the first glance at the docs I didn't get that you didn't have to specify the sizes -- I just noticed that there were sizes as template parameters and they were required. So when I first tried Eigen, I specified the template parameters ... and then when it always crashed I initially just wrote off the library.

That said, if you're using alloca() anyway for your matrix allocation (under the size limit), I don't see why it wouldn't make sense to go ahead and do that in the fixed size arrays -- or similarly, if you even really need fixed sized ones. If you can get the same results with a simpler API, that would seem to be ideal.

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.

Well, as I mentioned on IRC, our projection matrix is a dense matrix of 3000000 x 24.

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:

I think it depends on what classes of algorithms you're using. I've run across several things that use l1 recently. I however was looking for the l2 norm and ended up using the squared l2 norm. :-)

Maybe something like this?

   L1Norm = 1,    //!< \em Taxi-Cab Norm
   L2Norm = 2,    //!< Euclidean Norm
   LInfNorm = -1 //!< Infinite Norm

 Scalar norm(int p = L2Norm);

Perhaps with a link to

And for norm2() -- just to avoid confusion, I'd prefer squaredNorm() or normSquared()

At this point I've figured out how to do the stuff that I need to do, but I'd still like to see if there are ways that I can help to simplify the API for people that are coming into contact with it for the first time. I suspect the way that I was looking at the library -- having not seriously done any linear algebra for about 8 years -- isn't that uncommon. I was reading through papers and trying to find the quickest ways to work from mathematical-notation to code. At the moment, uBLAS is a little easier there.

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

I agree that the notation could be ambiguous. This is, however, another point where Eigen differs from other libs. How about this -- make a smarter assert that first checks if the vector needs to be transposed and if so gives that as the error message instead of that the sizes aren't the same? In general I like that Eigen uses readable asserts (a big difference to uBLAS), but I think that could be taken even further.

On the things that I've mentioned I wouldn't mind implementing them myself for the most part. But while I felt pretty confident that I wouldn't annoy anyone with docs updates without asking first, I thought API changes would be a little touchier. :-)




Mail converted by MHonArc 2.6.19+