Re: [boost] [review] pqs

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