Re: [boost] Interest in dimension/unit-checking library?

From: Matt Calabrese (rivorus_at_[hidden])
Date: 2005-10-11 22:17:35

On 10/11/05, Deane Yang <deane_yang_at_[hidden]> wrote:
>
> Useful info

Thanks, again.

But couldn't this be done rather nicely using the MPL map type, using a
> compile-time rational number type? I'm not exactly sure how to contruct
> the derived unit type from the unit types of two factors, but I bet it
> could be done most easily using this approach.

Yeah, in fact that's how I already work with types. The classifications and
unit types internally have maps whose keys are the fundamental types which
make up the derived type, and the mapped type is a group of information
which also contains the power of each fundamental type. All have to do is
use rationals, which I already have available, instead of integral types
inside the mapped type.

One thing I'll mention, in case anyone can think of something better, is
that comparison of classifications and unit types takes either constant time
or N*log(N) for a comparison resulting in true_, where N is the number of
fundamental types which make up the derived type. This is due to the fact
that the order of elements in a compile-time associative sequence in MPL is
determined by how the sequence is created (and I see no simple way to make
consistently ordered sequences of types at compile-time without requiring
intrusive information, which is not an option in this case). So, in order to
perform a proper comparison, I cycle through the fundamentals of one type
and check the corresponding mapped type on the other type if an element with
the same key exists. Hence, N*log(N) time for a comparison resulting in
true_. Thankfully, due to the nature of templates, this time won't be needed
in every check, since once the template is instantiated, the calculations
won't have to be performed again with redundant instantiations. Aside from
that, prior to doing the complex comparison described, I do a raw is_same
check, which would run in constant time and is all that is required in the
case that it yields true_, in the hope that in many situations the type will
have been formed in a similar manner, meaning the complex check would not be
required.

Still, if anyone can think of a more efficient way of handling this without
requiring a worst case scenario of N*log(N) time for comparisons yielding
true_, I'm all ears.

--
-Matt Calabrese