[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen 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?
enum
{
L1Norm = 1, //!< \em Taxi-Cab Norm
L2Norm = 2, //!< Euclidean Norm
LInfNorm = -1 //!< Infinite Norm
};
Scalar norm(int p = L2Norm);
Perhaps with a link to http://en.wikipedia.org/wiki/Norm_(mathematics).
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. :-)
Cheers,
-Scott
---