Re: [boost] [Review] Quantitative units - compile time vs runtime

From: Steven Watanabe (steven_at_[hidden])
Date: 2007-03-27 11:52:24

AMDG

Martin Schulz <Martin.Schulz <at> synopsys.com> writes:

> 
> Hello everybody,
> 
> my background is in software development for scientific and engineering
> computing, facing complex applications in industry. Therefore, I may
> take the opposite stand here. For fairness, I must add that I am
> somewhat from the competion, as I have started my own little (not yet
> upgrown) project in this area.
> 
> Practically speaking, when developing such a technically minded piece of
> software, approximately 30% of the development effort goes into the
> computation kernel whereas the remaining 70% of the effort goes to the
> overall infrastructure, business layer, presentation layer (batch, gui,
> api,..), interoperability, productizing etc.  It is sad to say, but such
> is life.
> 
> <snip>
> 
> I feel a far stronger need for a physical unit library in two other
> parts: Namely the business locgic and the presentation layer.
>
> <snip>

I'm sorry.  I don't understand what you are getting at.
would something like this be more acceptable.

unit meters(_symbol = "m", _conversion_factor_to_si = 1);
unit kilograms(_symbol = "kg", _conversion_factor_to_si = 1);
unit seconds(_symbol = "s", _conversion_factor_to_si = 1);

unit joules(kilograms * meters * meters / (seconds * seconds),
            _symbol = "J",
            _name = "Joule");

unit hours(_name = "hour", _conversion_factor_to_si = 1/(3600.0));

unit kilowatt_hours(joules / seconds * hours, _name = "kilowatt-hour");

quantity<double> energy(2.89 * joules);

Or is it primarily IO that you want.

istringstream stream("1.29038761 J");
quantity<double> energy;
stream >> energy;
cout << symbol << energy << endl;  //1.29038761 J
cout << name << energy << endl;  //1.29038761 Joule
assert(energy.value() == 1.29038761);
assert(energy.unit() == joules);
energy.convert_to(kilowatt_hours);
cout << name << energy << endl;  //... kilowatt-hours

> I like the notion of a unitsystem as a mean of choice for the internal
> represenation of the quantities (and have already taken that idea to my
> own project). On the other hand: the length of my desk is a physical
> quantity that exists independently of the unit it is expressed in. The
> numerical value of that quantity is only fixed for a given unitsystem
> but this is an implementation detail, not a principal thought or
> definition. Thus I find the definition "A quantity is defined as a value
> of an arbitrary value type that is associated with a specific unit."
> somewhat irritating. 

Trying to give a quantity an absolute
meaning leads to defining everything
in terms of SI.

> Some more details:
> ------------------
> 
> <snip>
> 
> I got the impression that the intent of the following code is not so
> obvious:
> quantity<force>     F(2.0*newton);
> std::cout << "F  = " << F << std::endl;
> The author states that the intent is obviously F  = 2 m kg s^(-2); In
> contrast to the author, I personally would naturally expect something
> like:
> F = 2.0[N]
> This issue is not half as superficial as it might seem at first glance.
> In fact that is what the whole presentation layer stuff is all about. 

I agree.  The ouput that we have is not really useful
for anything other than debugging.

> I have yet to see any stringend need for rational exponents. They rather
> obscure the physical meaning of certain terms, imho.

They are present because someone needed them.

> To define all possible conversions of n unitsystems, you'll need about
> O(n*n) helper structs to be defined. I may be overlooking some more
> elaborated automatism, though. However, we are likely to face a larger
> number of unitsystems as already the conversion of "cm" in "m" requires
> different systems.

Yes.  That is a problem.  There is no way to avoid it that I know.
Suppose that you need meters, feet, furlongs, and miles.  Then,
you will need 12 conversion factors.  Now, it would be possible
for the library to automatically work out meters->feet e.g. if
feet->meters is already defined, but that still requires O(n*n)
specializations.  Unless the library makes one unit special
there is no way to reduce this to O(n).

> The handling of temperatures (affine units in general) is correct but
> not very practical.
> 
> The executive summary:
> ----------------------
> 
> <snip>
> 

Thanks for you comments.

In Christ,
Steven Watanabe