[boost] Re: Re: Physical Quantities revisited

From: Andy Little (andy_at_[hidden])
Date: 2003-10-24 15:40:56

"Phil Richards" <news_at_[hidden]> wrote in message
news:20031024080954.9AA538C029_at_derisoft.derived-software.demon.co.uk...
> On 2003-10-21, Andy Little <andy_at_[hidden]> wrote:
> >  "Paul A. Bristow" <boost_at_[hidden]> wrote in message
> >  news:AHEJIHEOOOBMJPAGPLIPEEIJEHAA.boost_at_hetp.u-net.com...
> [wants all values stored internally as SI units]
> >  Within SI units there are various units within 1 dimension.
> >  ie length has units from nanometres to kilometres (and beyond).
> [... lot of stuff I pretty agree with zapped ...]
>
> Minor quibble: within "SI units", there is one, and only one unit
> for each dimension.
>
> There are multiple defined prefixes for units, but SI (base) defines
> only the 7 basic units.

Ok ... If I go much further with this I will have to get pretty well
acquainted with all this stuff :-)
The S.I. standards provides a very good basis on which to work. Including
what they say is 'not allowed' :-)

>
> Anyway, this thread has gone on in so many different branches
> I think I've started to lose visibility of what is being said
> and why it is or isn't right.

Apologies... I have been trying to be impartial and find weaknesses and
alternatives to my demo.

>
> On the project I work on, we built our own dimensional analysis
> class.  We are (currently) forced to use MSVC++6, and hence
> can't do a lot of the neato template stuff that we would *really*
> like to do.

I recently upgraded to VC7. That played a major part in me attempting and
being able to implement the demo.
(Thanks to Paul Bristow for pointing this out )

> At the simplest level, we have something like (names changed to
> protect the innocent):
>
> typedef Dimensions<double, 1,0,0,0,0,0,0> Time;
> typedef Dimensions<double, 0,1,0,0,0,0,0> Distance;
> ...etc...
>
> And derived quantities like:
> typedef Dimensions<double, -1,1,0,0,0,0,0> Speed;
>

critically here if this was:
typedef Dimensions<double, 1,0,0,0,0,0,0> seconds;
typedef Dimensions<double, 0,1,0,0,0,0,0> metres;
typedef Dimensions<double, -1,1,0,0,0,0,0> metres_per_sec;

ok we could argue about the names, but if there was some standard naming
your code would become more reusable.
in a wider context

> We have the *convention* that these are storing SI based values.
> It is nothing more than convention - the same library can be
> used without change with any _consistent_ set of units.  If you
> want time in hours, and distance in miles, then your speeds
> will be in miles per hour.  The dimensional analysis checking
> works just as well.

Again assuming some standardardised typename... here using the above example
typedef seconds Time;
etc

What you *don't* have is conversions between
> different units.

You could enforce this policy by using a version of the type that defines
one set of units only

>
> This suggests to me that units are orthogonal to dimensional analysis.
> Which I think is what Andy is saying.

The unit(s) define(s) the type with tighter constraints than the
dimension(s).
A physical quantity built on unitless dimensions is too weak as a type.

>
>
> In fact I lied: we don't actually specify the first argument
> as "double", we use a policy type, and use its value_type definition.
> (We stick a lot of other stuff in there to generate fudge-factor
> comparison operators that can be tuned to the domain we are working
> in, but that's not important right now.)
>
> This could probably be allow us to have parallel unit representations
> if we so desired:
>
> typedef Dimensions<SIPolicy, 0,1,0,0,0,0,0> SIDistance;
> typedef Dimensions<ImperialPolicy, 0,1,0,0,0,0,0> ImperialDistance;
>
> This allows:
> SISpeed s = SIDistance(1.0) / SITime(1.0);
>
> But prevents:
> SIDistance sid = ImperialDistance(1.0);

Here again this is probably a question of how you implement the type.
Presumably an implementation could provide constraints on what conversions
are allowed.
Or this might be intrinsic to the implementation.
( This again points up the utility of definable compile time messages. )

Interesting ... thanks :-)

Apologies if this makes no sense but it occurs to me that we are talking
about the same type.
The type is in wide use though in many cases it is implemented as a double
or int etc.
(The question then is what are the benefits and costs of  implementing a
physical quantity type over an int or double etc)
 A lot of this is about standardisation of names... with more or less
flexibility in the underlying implementation.ie at an extreme:

template <typename T>
class pq_length /* or whatever */ {
public:
    typedef  T metres;  // ok the intent is clear
};

pq_length<double>::metres mylen;

Andy Little
andy_at_[hidden]