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