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

From: Jan Langer (jan_at_[hidden])
Date: 2004-01-07 17:59:02

Matthias Schabel wrote:
> 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

yes i had a look at your library and i also (think i) understood the 
dimensional analysis part. and i would also agree in general with the 
interface of that part.

i also found that your version _looks_ very inefficient. i implemented 
this part on my own using mpl::vector where the dimension tag is the 
index into the vector and the stored value is the power of the dimension 
(a little like david abrahams slides) but i had not enough time to do 
all issues. for example your code implicitly differentiates between 
different systems, whereas my code didnt (at least at the dim. analysis 
level), eg:

namespace physics {
        typedef integral_c <int, 0> length_tag;
        typedef integral_c <int, 1> mass_tag;
}
namespace fruit {
        typedef integral_c <int, 0> apples_tag;
        typedef integral_c <int, 1> oranges_tag;
}

// creates a vector which is empty except Value at position Tag
template <typename Tag, typename Value = mpl:.integral_c <int, 1> >
struct construct_dimension { ... };

typedef construct_dimension <length_tag>::type length_type;
typedef construct_dimension <apples_tag>::type apples_type;

now apples_type is equal to length_type and thats obviously wrong.
        
so i think this is not going to work like i tried it. want is really 
needed is an associative container in the mpl. we both just tried to 
emulate one. the vector is fast but too inflexible and your list 
approach works fine but is too inefficient.

>> 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.

thats great. sorry for mentioning it again (although having looked at 
your library ;-) )

>> 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.

yes, but i had not enough time to look really into the details. and it 
was difficult because you never know from the code what are the 
implementational details, what is the real usage and what is syntactical 
sugar. eg, i thought from looking at andys examples, that the value_type 
in his lib is always double.

what i also like about your library is the use of namespaces and the 
fact that dimensions are specialized for physics and the unit systems 
like si, usw. use them together (i dont know how andy does this). 
although the special definitions and namings might need some more work 
towards the end.

jan

-- 
jan langer ... jan_at_[hidden]
"pi ist genau drei"