I have an edit that I think might be controversial, but I don't expect that anyone is watching this discussion page, so I'm going to go ahead and make it before waiting for feed back. But let me just explain so that there is some context.
I went through a process of trying to select a library and made the mistake of starting to use one (eigen) before I really understood it. Instead my decision was based on a superficial review of what I could find out there, and some word of mouth suggestions from other developers. While it's easy to find a list of reasons why someone *should* use a lib, it's less common for projects to publish a list of why now.
For me it turned out that the issues related to alignment, that come from aggressive optimization, are a trade off that is not appropriate for my project. However I would have liked to have figured that out before having started integrating it into my project.
So I'm trying to prevent that from happening to other developers.
Benoit Jacob says:
Look, this is not the right way to do things. Just because this wiki may be edited by anybody doesn't mean that highly visible controversial changes may go without prior discussion.
You are right that probably nobody is watching the discussion page, but you should have contacted us by e-mail. By the way, we don't even have a way to contact you after you made a controversial change?
That said I appreciate you starting the separate page "Pitfalls", it's useful. Notice how I had started something similar in the FAQ, which I agree fits better under "Pitfalls".
Here's to address your concerns:
- about the inconveniences caused by vectorization: you just have to define EIGEN_DONT_ALIGN and Eigen won't annoy you anymore. That is with the development branch. In the 2.0 branch, define both EIGEN_DONT_VECTORIZE and EIGEN_DISABLE_UNALIGNED_ARRAY_ASSERT. If you want, I can backport the EIGEN_DONT_ALIGN thing to the 2.0 branch.
- about the pitfall of having to #include the right headers, well the same is true for any library. With any library, you would first look up the documentation to check what header to #include. It's the same for Eigen. Granted, Eigen is a bit more tricky because 1) some _methods_ inside a class may require a different header and 2) the error messages are more scary, but this is still not in my opinion a grave enough concern that we should have to make our Overview sound bad.
Finally, about the cosmetic change of putting the TOC to the right, well I'm not sure about it because 1) now there's a bad alignment issue between the text in the yellow frame and the rest; 2) the TOC was more convenient on the left, now it's exiled too far away; 3) to me there was no "formatting problem" to fix in the first place, i thought that was looking fancy.
Benoit Jacob says:
Incidentally, i've had to backport the EIGEN_DONT_ALIGN thing to 2.0 for other reasons. So with the latest 2.0 branch (to become 2.0.6) you can just define EIGEN_DONT_ALIGN and forget about all alignment issues.
sorry : /
Yeah I guess I could have tried to email someone. I suppose it was laziness on my part. I figured someone would pick it up pretty quickly and change it if it wasn't acceptable. Sorry about that; I apologize.
Also, thanks for the additional info about turning off the alignment specialization. With that knowledge, I may actually go back to using Eigen2.
A week or two ago I posted a question, and then just recently, an answer, on stackoverflow about the selection of which linear algebra package to use. You can see it here if you are interested:
Andy.somerville 05:40, 21 September 2009 (UTC)
Benoit Jacob says:
OK, no problem.
We just don't want to receive flak for a deficiency in the C++98 standard (lack of explicit alignment support) that is anyway getting addressed in the next revision (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2341.pdf).
To comment on your answer at stackoverflow: again, you can get rid of this today with EIGEN_DONT_VECTORIZE and EIGEN_DISABLE_UNALIGNED_ARRAY_ASSERT, no need to wait for the next version. Sorry for the lack of documentation until now.
I don't really know how a "discussion" page is supposed to be run; feel free to empty it when you think that we're done.