Re: [boost] Re: Re: Re: Re: Dimensional Analysis

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2005-01-31 15:49:29

>From: "Robert Ramey" <ramey_at_[hidden]>

> Terje Slettebø wrote:
> > What's a dimension library? I.e. how  might
> > it look like, and be used (preferably a code example)? I've searched
> > the Boost list for "dimension library"/"dimensions library", but your
> > posting is the only one coming up.
>
> This whole thread was started by question about
> ...\libs\mpl\doc\tutorial\dimensional-analysis.html which uses dimensional
> analysis as an example of a possible application of mpl. In my view, this
> tutorial is makes a great case for the utility of such a library and
> explanation of how it might be implemented

Agreed. A couple of years ago, I played with a dimensional analysis/quantity
library, myself, using Loki's typelists to store the dimensions. However,
the combination of them were rather involved, and not something like the
elegant solution of using mpl::transform (which didn't exist at the time, at
least not as a Boost library). It was just the terminology, "dimension
library", that I wondered about, and I guessed it was about the dimensions,
without attaching any particular meaning to them (which was the case). It
has been said in this thread that this could sidestep some of the issues of
a unit library, but there still seems to be a number of them for a
dimensional analysis library, such as the number of dimensions, and whether
they should be fractional or not.

As has been noted, a number of dimension/quantity libraries have been
developed and proposed over the years, and I guess one useful test of a
dimension library would be if it's possible to write a useful quantity
library for it (or more). As Andy and others who have been involved in these
discussions are all too aware of, there are many tricky issues involved in
making a quantity library (such as his PQS library), such as "kg" being the
only SI base unit with a prefix, and if you have 1000 * 1 kg, you won't get
1 k(kg), but 1 Mg; the different temperature scales, and perhaps even
support for non-SI units, like feet, mile, etc. As well as how to present
these quantities, internationalisation, and so on.

> > For example, if it only takes care of dimensional analysis (i.e.
> > dimension calculations), how many dimensions should it have, if it's
> > independent of units? If the answer is "user-configurable through
> > typelists/vectors", have anyone done any compile-time timing of
> > dimension calulation-heavy code using this approach, compared to a
> > fixed set of dimensions?
>
> I would expect that number of dimensions would be fixed a compile time.

Then it also depends on how that is done. I'm not saying there's a problem;
I haven't measured, but I think it should be a consideration. I would think
that a simple class template with N integral parameters (or rationals,
somehow), where they are combined to form new types using simple +, -, * and
/, could be a heck of a lot faster at compile time, than one using
mpl::vector, and mpl::transform, and then again I may be wrong, and also the
difference may not be enough to be a problem.

> > Won't this bring us right back to the "how
> > many dimensions"-discussion of a unit/quantity library?
>
> if it were user configurable, I wouldn't think so. I would expect that
such
> a library would have a base implementation along with a higher layer
> specifying a common set of dimensions.  Anyone not happy the the chosen
set,
> he could just use the base layer and use his own set of dimensions.

I wonder what that base functionality would be, when it won't know about the
number of dimensions, and it won't know their meaning. It seems a little
like "stone soup", :) but I'm willing to be convinced. ("Ok, so we can
hardly agree on anything in this library, so let's not make _anything_. Can
we agree on that? Yes!") :)

Regards,

Terje