Boost logo

Boost :

From: Matt Calabrese (rivorus_at_[hidden])
Date: 2005-10-20 13:25:40

On 10/20/05, Phil Richards <news_at_[hidden]> wrote:

> If you change your basis set for dimensional analysis, then length
> may not be a basis dimension in this new basis set. This different
> new (derived) definition of "length" dimensionality has to exist in
> a different namespace to SI length. And it *can't* interoperate
> with it particularly easily - you would have to specify the
> transformation of each basis dimension from one family to the other.
> Which, funnily enough, is where I got to with my "dimensionality
> family" stuff. I was never enormously convinced of my solution, it
> has to be said, but it works if all you want to do is define disjoint,
> non-interacting, dimensional analysis systems.

Again though, I question why you would ever want to do this. Whether a unit
classification (dimension) you are using is fundamental on or not shouldn't
affect how you use it in code. You can work with the units the same way
whether they are fundamental or derived, so why would you want to make a
system where "velocity" is fundamental? The only place where it would make a
difference that I can think of at the moment is with type traits, but in
that case you can just have separate traits defined for the same units, as
opposed to making a whole new system of redundant unit types. I.E. you can
do is_derived< SI, velocity > or is_derived< your_system, velocity >. This
is a better solution, in my opinion, since it doesn't require making an
entire new system of units and avoids all of the needs to have a way to
convert between a fundamental velocity and a derived velocity, since now
they are still just represented with the same type. This also succeeds at
minimizing the number of types and templates which would need to be used.

-Matt Calabrese

Boost list run by bdawes at, gregod at, cpdaniel at, john at