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.