Re: [boost] mcs::units informal review request

From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2007-01-22 17:15:56

On 1/22/07, Noah Roberts <roberts.noah_at_[hidden]> wrote:
> Michael Fawcett wrote:
> > On 1/22/07, Noah Roberts <roberts.noah_at_[hidden]> wrote:
> >> Yes, it does sound familiar but it is just a common way of writing bad
> >> code.  In any given project your base unit should be the same for any
> >> given function.  Anything that accepts a length should accept either
> >> feet or meters, and a mix of both in your project is a Really Bad Thing.
> >
> > And how can you enforce this?  Take for instance a database that holds
> > radar characteristics.  The units that pilots use are always feet (for
> > altitude) and nautical miles (for distances).  Ground elevation data
> > is stored as DTED files which are in meters, where the distance
> > between elevation postings is in latitude/longitude.  Now convert an
> > AGL (Above Ground Level) altitude to an MSL (Mean Sea Level) altitude.
> >  Wait...that requires adding feet (the altitude of the aircraft is
> > always given in feet) to the ground elevation at that particular
> > latitude/longitude (but wait, pilots measure distance in nautical
> > miles, plus the ground elevation is given in meters!).  These are all
> > just errors waiting to happen that a good units library will catch at
> > compile-time.
>
> Well, I guess now that you're more interested in getting defensive than
> talking about this so this is likely to become non-productive.

Not at all.  Just trying to clarify use cases and possible implementations.

> 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".

I agree, but getting into and out of these different "systems" is
often where the problem lies.

> The problem here is that AGL makes less sense in meters for the user.
> Let's further say that AGL might be measured in any given unit for some
> user (This is _very_ common in the field I'm working in).

In my field as well, although in practice, pilots and analysts rarely
look at AGL in any unit other than feet, but the option is at least
there for them if they want to.

> 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.

Oh, I absolutely agree, 100%.  Doing the conversions over and over is
costly.  The costly calculations should all be done in the same
"system" for maximum efficiency.  But again, how to *ensure* that
programmers remember to do the conversion going into and out of that
"system" and how to ensure that it is safe and correct (i.e. is a
compile-time error rather than a (possibly unnoticed) run-time
one...*crash*, and not necessarily a software crash, maybe a plane
crash, or a polar lander crash ;)?

> Your unit setup could be used in the underlying computations to enforce
> a given set of unit->dimension pairs but there is still most definitely
> a need to provide an easy to use runtime equivalent.  Without such the
> unit library is not as useful as it could be and doesn't answer what
> 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
> conversion overhead.  Hence my question about qty<length> qt = 9.3 * psi
> and I have to say I really like that syntax that you've used.

I think you are wrongly attributing code to me.  Matthias has done all
of the work, I was merely commenting on it.

> 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.

I'm having problems seeing why run-time units are necessary for the
use case you came up with (or I'm confused as to your requirements).
Let's say the system we are designing does something trivial -
converts an elevation from AGL to MSL.  The UI presents the user with
an edit box that allows him to type in a number, and a combo box that
allows him to choose the unit (feet, meters, etc).  He hits
"Calculate" and another read-only edit box is populated with a number,
and then he can choose what unit that number is displayed in with yet
another combo box.

All of that can be accomplished using the library as is.  All checking
is done at compile-time to ensure that the units and calculations are
done correctly.

Are there more complicated uses that you were envisioning?

Not defensive, just curious,

--Michael Fawcett