Re: [boost] new compile-time dimensional analysis and unit library

From: Matthias Schabel (boost_at_[hidden])
Date: 2003-11-19 14:50:28

> ( change to this and it works :
>
> SI<double>::Velocity    v3 =
> SI<double>::Velocity(CGS<double>::Velocity(7.0));
> )

Right - I forgot that the assignment form is not the same as
the normal constructor...

>> so that you can distinguish between raw
>> values and
>> types which result from evaluation of expressions containing
>> dimensioned quantities...
>
> Yep There is an argument for that, but the problem is that you then  
> have two
> types which
> represent exactly the same thing. My monolithic mind tells me that is  
> not a
> good thing.

Hmmm...I would argue that the dimensionless result of a unit  
computation is
fundamentally different than a normal POD value - for example, units of  
angular
measure are technically dimensionless, but there is clear value in  
keeping track of
them.

> The logical extension of your scheme which strips the Power_of_0  
> dimensions
> is to return one with none when its dimensionless...is all I'm saying
> You either choose:
> A) some-pq<000..> =  result of division between two dimensionally  
> equivalent pqs
>  or
> B) inbuilt-type  = result of division between two dimensionally  
> equivalent pqs

If you're representing your dimensions as a fixed length list, this  
works fine, since you
can catch dimension<0,0,0,0,0,0,0>.  However, you run into a problem  
when implementing
it as I have as a variable length list of tagged dimensions:

mpl::list<dim<t1,0>,dim<t2,0>,dim<t3,0> >

and

mpl::list<dim<t4,0>,dim<t5,0> >

are both dimensionless, but would not be recognized as equivalent if I  
didn't reduce them to a
specific dimensionless_type...

> Because a 'dimless pq' is exactly like an inbuilt type you should be  
> able to
> use
> both in exactly the same way. If you get a situation where you can  
> only use
> one or the other
> trouble will soon  follow. And it is difficult to predict every
> circumstance.

The library allows implicit conversion of dimensionless quantities to  
their underlying value
type.  You need to bear in mind that the dimension code can exist on  
top of arbitrary value
types, though - it's not just restricted to PODs :

typedef  
DimensionedQuantity<boost::array<double,5>,SIModel::length_type>  
dvec_type;

tags a fixed length array of 5 elements with a length dimension,  
allowing you to perform normal,
dimension-checked arithmetic on the vectors :

dvec_type	v1,v2;

v1+v2 -> length tagged array
v1*v2 -> length^2 tagged array

> There is no way to find out the value of a or b from c alone.
> If there was you would end up with a 'snowball' effect where the pq  
> gathered
> more and more attributes or history
> as it went through calcs. That is a recipe for diaster in a big  
> successive
> approximation loop I think
> If physicists needed such a beast it would have evolved that way.

I was actually talking about developing a simple way of extending an  
existing
unit system with a set of dimension tags to add others, but the whole  
point is
pretty much a tangent...

> This is an extension of the argument on dimless pqs in a way.
> ie a dimless pq is a scalar and it seems futile/impossible to try to  
> predict
> what it actually represents to the user.
>
> e.g.
> mass_pq a(1),b(2);
> angle_pq alpha =  a / b  ;        // perverse but dimensionally  
> correct I
> flag no error

If anything, I think your example is a point in favor of disallowing  
implicit conversions
from dimensionless types - at least then it would be clear that the  
programmer
intended to do something strange...

Matthias

------------------------------------------------------------------------ 
---------------------------
Matthias Schabel, Ph.D.                           	
Utah Center for Advanced Imaging Research
729 Arapeen Drive
Salt Lake City, UT  84108
801-587-9413 (work)
801-585-3592 (fax)
801-706-5760 (cell)
801-484-0811 (home)
mschabel at ucair med utah edu