
Boost : 
From: Barend Gehrels (barend_at_[hidden])
Date: 20080328 16:51:35
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
> nontrivial 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk