Re: [boost] [Review] Quantitative Units library review begins today March 26

From: Steven Watanabe (steven_at_[hidden])
Date: 2007-03-28 13:05:11

AMDG

"Eric Lemings" wrote:

> <snip>
>
> Undoubtedly, the scope of this library should include the dimensional
> analysis framework which defines the fundamental types/metatypes (e.g.
> dimension, unit, quantity), their semantics, and their operations.  It
> should also include only the most common dimensions such as the physical
> dimensions (time, length, mass, etc.) and allow, at least, other
> universal
> dimensions (e.g. currency).  Other, more specialized dimensions should
> be defined elsewhere.
>   
That was one of out goals.  The units that we have are implemented 
solely in terms
of the dimension/unit/quantity framework.
> The scope should not include any facilities for input and output.  It
> should also not prevent such support however.  (Input and output of
> units and measures can be handled by extending C++ locales with new
> facets.  C++ locales already deal with I/O of time and money.  More
> about internalization and localization below.)
>   
Input is definitely beyond the scope of the library.  We have implemented
primitive output.... On further thought, we should probably just have
an output operator for quantity that prints the value_type then the unit and
leave unit output alone.
> The scope should not classify units of measurement into exclusionary
> systems.  True, many programs/programmers will have restrictions that
> prevent/exclude use of any units of measurement outside a well-known
> set of units but the other extreme is also quite possible.  A program
> may allow arithmetic/conversions between any and all units known to the
> development/operating environment.  In such cases, the programmer is not
> concerned in the least with systems of units and classification of
> units into systems becomes totally irrelevant (and impossible for many
> older and rarer units of measure).  Therefore, if constraining units
> into discrete systems is a desired objective, it should be the
> responsibility of the program rather than the library.
>   
Allowing conversion between units having different dimensions and allowing
fundamental units whose dimensions are not fundamental e.g. quarts for 
volume
is very very difficult to implement.  Off hand, I think that it requires 
defining
some special system (probably SI) and converting through that system.
> Whether the scope should include a particuar system of units (e.g. SI
> units, Imperial units) is debatable.  Personally, I believe each system
> of units should be treated much the same way C++ currently treats
> locales.  The library may contain, even mandate, a "default" set of
> units (e.g. SI) but including even the most common modern units is
> beyond the scope of the library.  (Which units are modern?  Which units
> are common?)  Each system of units can therefore be defined separately
> as an extension to the underlying framework.
>   
Absolutely
> I'll post more specific review comments about the proposal later.
>
> Thanks,
> Eric.
>   
Thanks!

In Christ,
Steven Watanabe