
Boost : 
From: Jan Langer (jan_at_[hidden])
Date: 20040107 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 compiletime 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"
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk