From: Matthias Schabel (boost_at_[hidden])
Date: 2007-01-22 17:10:21
> What you are talking about above is exactly what I mean. Those are
> *interface* issues. Doing all the conversions through casts, which
> be converting between these units in-place, is less efficient. A good
> units library would convert all of the above to a base, meters
> instantly and provide only that value to the underlying equations
> 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.
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
> 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
in a pre-specified (at compile-time) system, and back again at the
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
fact, many of the "natural" unit systems used in physics are chosen
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
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>
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
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
> work and I think you have a better solution than Little's attempt.
> 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
I'm mainly concerned with not letting feature-creep derail the
of a library that may only solve a subset of the complete dimensional
problem for inclusion into Boost. I absolutely agree that there is
scope for runtime
units, just not from me right now.
Matthias Schabel, Ph.D.
Assistant Professor, Department of Radiology
Utah Center for Advanced Imaging Research
729 Arapeen Drive
Salt Lake City, UT 84108
matthias dot schabel at hsc dot utah dot edu