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