Re: [boost] Re: physical-quantities (was: runtime unit-modifiable ...)

From: Matthias Schabel (boost_at_[hidden])
Date: 2004-01-07 16:33:34

> where dim1 and dim2 are compile time lists (of any kind), which map  
> between a tag for each dimension and a (rational) compile time value,  
> representing the order of this dimension.
>
> this stuff is easily done with mpl. and david a.'s slides are doing  
> it. although it might not be so easy to do it efficiently (thats  
> probably a weak point in matthias' implementation).

There are additional issues which must be considered for a complete and  
general solution (which my library incorporates, probably incurring  
significant compile-time cost) :

1) duplicate units : m s^-1 K^2 m mol m -> m^3 s^-1 K^2 mol needs to  
work for arbitrary ordering of the type list
2) zero dimensions : m s^-1 m^-1 -> s^-1 needs to work for arbitrary  
ordering of the type list
3) dimensionless : m s^-1 m^-1 s -> dimensionless

> an easy way must be provided to define the dimensions for a special  
> user defined system. this system must also be tagged somehow so that  
> if two systems like
>
> 	namespace si {
> 		typedef dimensions::dim1 length;
> 		typedef dimensions::dim2 time;
> 		...
> 	}
> 	namespace my_system {
> 		typedef dimensions::dim1 apples;
> 		typedef dimensions::dim2 oranges;
> 	}
>
> exist, quantities of apples the a length cannot be added by chance.

As it stands, the dimensional analysis code does this; a dimension is  
simply an mpl::list of pairs of tag types and their corresponding  
exponent.  Only identical tag types are reduced and, at this level of  
abstraction, there are no unit systems.  Unit systems can be defined,  
like you've done above, as collections of tag types, either in a  
namespace or in a class.

> then there is a need for a quantity type which brings together a  
> specific dimension, a value type (which i am sure should not be of  
> type double implicitly as implemented by andy, IMHO) and a member of  
> that value type.

Jan, I know I don't provide documentation for my library at this point,  
but you might want to brave the code - it's pretty well commented and,  
except for dimension.hpp (where all the MPL lurks), there's nothing  
really scary in it.  My implementation is already pretty much as you've  
described.

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