On 10/20/05, Phil Richards <news@derived-software.ltd.uk> 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