Max Motovilov wrote:
Linear transformations are intentionally left out because they are already there, in uBLAS indeed, didn't want to write vector/matrix calculations again.
Regarding uBLAS: it doesn't look like it is the best match for the job. While the abstraction penalty there is probably very small or nonexistent for the 2x2, 2x3, 3x3 or 3x4 matrices that are likely to be useful for geometrical transformations (provided static arrays are used as underlying container), it just does not offer enough functionality:
- No general matrix inversion, only triangular solvers. While in general case this may well indeed be out of scope for a foundation library, formulas for small matrices of known size are rather simple. And inverted matrices are extremely useful (at least as long as numeric robustness is not the top priority).
Agree that matrix inversion should be there, it is necessary. In earlier sample I used lu_substitute and lu_factorize to invert a uBLAS matrix. Don't know the backgrounds of those calculations, but it worked well.
- No special support for scale+shift matrices (2x3 or 3x4: diagonal + last column). Not that big of a deal, but formulas with them are simpler. More importantly, recognizing this special case as such at compile time helps write good code (e.g. don't want to start rotating raster images unless it is unavoidable...).
- No syntactic sugar: constructors of shift/scale/rotation matrices, classification checks (is it a shift+scale matrix? a rotational matrix? are the X and Y scales identical? is it an invertible matrix? etc...)
None of the above is a real show stopper: missing functionality may well be implemented on top of uBLAS. However I don't really see what non-trivial benefits does uBLAS provide for this specific case -- after all, products are really simple for small matrices of fixed size. Admittedly, I'm as far from uBLAS expert as can be so perhaps someone can point out important things I have missed.
If the general feeling is that uBLAS is not good for this job (I get this impression), then it might be time for a (separate) lightweight vector/matrix library in Boost. I've still the opinion that it should be separate from a geometry library. Any matrix library can be used for geometry transformations. For some simple calculations, that are now "inline", the geometry library needs a lightweight solution. The matrix listed in mail of Noah Stein, partly pasted here:
Matrix<float, 3, 3> m1, m2, m3; m1 = 1.0f, 2.0f, 3.0f, 4.0f, 5.0f, 6.0f, 7.0f, 8.0f, 9.0f;
is looking very good. Barend Gehrels, Amsterdam, the Netherlands