Re: [boost] Boost Units library preview

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
> news:E76A322A-1D3B-4B5C-88A0-2B52FD2387EE_at_itp.phys.ethz.ch...
>
> <...>
>
>> 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  
> initial
> 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  
> non-numeric
> 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?

Matthias