From: Matthias Troyer (troyer_at_[hidden])
Date: 2006-08-24 11:03:06
On Aug 24, 2006, at 11:17 PM, Andy Little wrote:
> "Matthias Troyer" <troyer_at_[hidden]> wrote in message
>> Why not just use a ublas vector or MTL vector with a quan quantity?
>> As i mentioned before I see no reason for reinventing the wheel. I
>> still have not seen your reason for having your own vector classes.
> My use cases for vectors are limited to vectors representing 2
> dimensional and 3
> dimensional space. I find it convenient to represent a vector in 3
> dimensions as
> a container with 3 elements representing the direction and
> magnitude projected
> onto the x, y, z axes. I will certainly look into UBLAS, but my
> impression is that it is quite heavyweight for this task. Though I
> havent looked
> at MTL, I would guess that it is even more complex than UBLAS. I
> will look at
> MTL2, but so far I have been unable to locate any information on MTL4.
For that purpose the Blitz++ TinyVector class seems ideal, and I
think that MTL4 will have something similar.
> For matrices my tests have been limited to homogeneous
> transformation matrices.
> In this case the matrix elements for a *simple/obvious*
> implementation of a
> matrix for a physical quantity are comprised of various types,
> comprising of the
> quantity type, the reciprocal of the quantity and numeric types. It
> may be
> possible to somehow 'tag' a numeric matrix as a quantity matrix,
> but I havent
> invetigated that.
Just use a quantity as value type? What's the problem with that?
> I havent looked into other use cases for linear algebra in
> association with Quan
> however. It may be that in the general case ( for large matrices)
> that it is
> impractical ( IOW the costs outweigh any possible benefits) to use
> types as the elements, but that remains to be investigated.
Why? What should be the problem? Your quantity is just a number, and
the rest is compile time type information? Or is a quantity heavier
than just a floating point number?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk