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

From: Phil Richards (news_at_[hidden])
Date: 2005-10-20 12:56:45

On 2005-10-20, Deane Yang <deane_yang_at_[hidden]> wrote:
>  Phil Richards wrote:
> > I gave up trying to progress with boost-ing it because I couldn't see
> > a path of consensus to what was actually wanted.  There seemed to be
> > a desire for more flexibility, and I couldn't see the point :-(
[...]
> > In fact, all I've ever needed is physical4_system (mass, length,
> > time, temperature), and never need to convert units because we
> > always insist on everything being in SI.
>  Yes, this was a major issue.
> 
>  Do we want a general dimensions library (without even predefining ANY 
>  dimensions at all) that I claim would have  extremely broad 
>  applicability outside physics, or do we want a physical-dimensions-only 
>  library that predefines a standard or basic collection of physical 
>  dimensions.?

The difficulty with not having some basics defined is that it makes
things a lot more complicated :-)

SI length is defined as having unit in meters.  meters has
dimensionality of length^1, in SI (and Imperial, for that matter).

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.

(You can define any basis set you like, and call things in it anything
you like (everything is partitioned either by class or namespace scopes)
but it won't let you mix-and-match things of different families.)

>  I am strongly in favor of the former, I have also never understood why
>  the latter couldn't be built using the former anyway, so the library 
>  could have two layers to it. The physicists could ignore the lower layer 
>  completely, and I could ignore the upper one.

Ok, give a few examples of different basis sets that may be wanted :-)
The best thing to drive this forward are real use-cases for the library.
Without them, we'll just go round in circles again.

phil
-- 
change name before "@" to "phil" for email