[snip]
What you are talking about above is exactly what I mean. Those are *interface* issues. Doing all the conversions through casts, which will be converting between these units in-place, is less efficient. A good units library would convert all of the above to a base, meters usually, instantly and provide only that value to the underlying equations while reporting values using the units logical for the user for that use. There is no reason why the different calculations you speak of should actually do their calculations in different "systems".
Noah - I really, really recommend you look at the review of PQS. There are several posts that deal with the question of why you can't do all your calculations in SI units and why it's bad to force library users to use SI (even though it is nominally an international standard).
user (This is _very_ common in the field I'm working in). Now we need some way of getting an AGL value from the user in an arbitrary unit but making sure calculations don't keep converting it and adding overhead we don't want or need. The best way to do this is to have the AGL value convert when the user enters it or when the calculation performed to find it is assigned to the value...and only at those times. Then your whole underlying functions would all use a particular "system" that these runtime united values convert to.
If all you're concerned with is being able to convert some input into a quantity in a pre-specified (at compile-time) system, and back again at the end, that's a relatively easy problem (other than deciding how to parse input).
seems to me as the more general and practical use. I also think it should be easy for the developer to write the equations in one set of units but have the code calculate in the base units without adding
See my previous post on electrostatic force for why this doesn't work - you can't always guarantee that equations remain the same in different unit systems...in fact, many of the "natural" unit systems used in physics are chosen specifically to simplify the form of common equations.
conversion overhead. Hence my question about qty<length> qt = 9.3 * psi
I'm hoping you mean : quantity<SI::pressure> qt = 9.3*psi; ? To solve the input/output problem, you could just write a runtime function that converts units in a variety of input systems into the system in which you want to do your computations (again, assuming that the internal system is fixed at compile time): template<class System,class Y> quantity<unit<System,pressure_type>,Y> pressure_converter(const std::string& q); quantity<SI::pressure> qt = pressure_converter<SI,double>("9.3 psi"); or you could just define the conversion factors in the desired unit system directly: static const quantity<SI::mass> pound(kilogram/2.2); static const quantity<SI::length> inch(meter*2.54/100.0); static const quantity<SI::pressure> psi = 1.0*pound/(inch*inch); quantity<SI::pressure> qt = 9.3*psi;
I'm not saying this library is no good or not useful. You've done good work and I think you have a better solution than Little's attempt. What I'm saying is that in order to answer the general case it needs to answer runtime units either directly or by thoroughly documenting how it could be done.
It sounds like you have me and Michael confused...any way, no hard feelings. I'm mainly concerned with not letting feature-creep derail the potential consideration of a library that may only solve a subset of the complete dimensional analysis/units problem for inclusion into Boost. I absolutely agree that there is scope for runtime units, just not from me right now. Matthias ---------------------------------------------------------------- Matthias Schabel, Ph.D. Assistant Professor, Department of Radiology Utah Center for Advanced Imaging Research 729 Arapeen Drive Salt Lake City, UT 84108 801-587-9413 (work) 801-585-3592 (fax) 801-706-5760 (cell) 801-484-0811 (home) matthias dot schabel at hsc dot utah dot edu ----------------------------------------------------------------