Boost logo

Boost :

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


Martin Schulz <Martin.Schulz <at>> 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);
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

Boost list run by bdawes at, gregod at, cpdaniel at, john at