From: Leland Brown (lelandbrown_at_[hidden])
Date: 2006-06-07 18:52:05
I'm glad to see all the interest this library is gaining!
David Greene <greened <at> obbligato.org> writes:
> Andy Little wrote:
>
> > acceleration::millimeters_div_seconds_squared acc;
> >
> > is a real handful compared with:
> >
> > acceleration::mm_div_s2 acc;
FWIW, in my implementation I just used:
acceleration acc = 10.0 * millimeter / sqr(second);
and lived with the extra divide and multiplies - again assuming the overhead is
low because most of my code is doing computations on these variables once the
values have been assigned. Getting the numeric input values in is just a small
part of the processing time in my application. If this is not true for other
people, perhaps there's a way to maintain the sort of syntax above yet avoid
the extra arithmetic using template metaprogramming - I haven't thought it
through.
> >>The ability
> >>to create units like Megabytes and Mibibytes would help tremendously.
> >
> > OK. Firstly I should point out that bytes and their units arent physical
> > quantities and so according to my self imposed rules re PQS, I ( and the SI)
> > dont cover them under physical quantities.
>
> I think restricting the library to "physical quantities" is a big
> mistake. You've put a _lot_ of effort into getting the metaprogramming
> right for his and we ought to try to re-use it wherever possible. I
> don't relish the idea of creating a parallel "electrotechnology system"
> framework that looks exactly like pqs but with powers of 2 and 10 (to
> do the conversions). Let's get it right in a single library.
Several reviewers have made comments to this effect. It seems there is a need
in a variety of non-physics contexts as well for a general units conversion
library.
However, IMHO, PQS is *not* a units library. Its purpose is to do dimensional
analysis. For this reason (as well as a weaker one I mentioned in another
followup post), I oppose the name "units" for the library. That would only add
to the confusion. Units conversion is a necessary part of the library (or
adjuct to it) in order to create the dimensional quantities, but the core
purpose and utility of the library is its compile-time checking of dimensional
formulas and enforced documentation of dimensions (as well as units).
Perhaps, as Gerhard Wesp suggested in one of his posts (sorry, I don't know how
to include a message reference):
> I think that handling of dimensional quantities and conversion factors
> are orthogonal concepts and should be separated.
If there's a way to do this, perhaps the units conversion can be made more
general and put into a separate library, and the dimensional analysis library
can make use of it. But please, let's not lose sight of the great importance
of a dimensional analysis library. Many users (though perhaps a minority) find
this *very* useful.
> > I could provide the ability to customise the number of available dimension
> > 'slots' via a macro. This might speed compilation for users that regularly
only
> > use length, mass, and time for example.
>
> I was thinking along those lines as well.
Not a bad idea. In my implementation, in fact, we only needed length and time
dimensions, since the masses effectively cancel out of all our motion
equations, and only integer exponents, so I coded it in this limited form.
-- Leland