Matthias, I'll split my answer in two parts. The more technical will follow.

A Boost library isn't mandated to completely solve all aspects of a given problem domain for all potential users.

Maybe the whole conflict is only due to fundamentally different expectations. When I read the introduction, full of words like "zero runtime overhead", "in a general and extensible manner", "generic", "arbitrary unitsystem models", "arbitrary value types", "general facility", "fine-grained control", "complete SI and CGS systems" etc then I (and I suppose others as well) get the impression that this library certainly is the definite unit library that claims to solve any unit conversion problem under the sun. Generally speaking, Boost libraries have a very high reputation to actually solve the problem they claim to solve. But this one does not live up to my personal expectations raised by that introduction. This is clear to me, but I am afraid others may take some time to discover that fact the hard way. Maybe the not the library, but just the expectation is wrong. To avoid such misconception, please give your potential users the chance to adjust their expectations beforehand. I'd suggest to add to the documentation a section like the following (not exhaustive, you will probably add other points that are important to you), clearly stating what can and what cannot be expected: "Domain of application and restrictions This library enables to specify the exact physical dimension of any scalar or fixed aggregate quantity by encoding the dimension in the respective type. The type system is able to deduce the internal type of a physical quantity from arithmetic expressions involving other quantities fixed at compile time. For storage in variables however, the user of the library will need to specify the exact type. It is believed that the library is most useful when this type system is applied to the whole program. Since the library does not allow for mixed storage of quantities e.g. in vectors, further workarounds will be necessary when dealing linear algebra like BLAS, LAPACK or other advanced numerical libraries. Because the physical dimensions of all quantities are fixed ad compile time, there is no support for code that acts on certain quantities regardless of what these quantities actually represent, i.e. all quantities specified at runtime of the software. This includes GUI frameworks, post processing or visualization tools. The library provides support for language-independent serialization by the use of Boost.serialization library. No attempt is made to ensure that the units of the deserialized quantities match the ones of the serialized ones. No attempt is made to provide formatting for quantities in human readable form (beyond debugging output). No attempt is made to provide parsing of unit input in human readable form." Does this reflect the the admissible expectations more closely? Yours, Martin.

Martin, Thanks for your comments.

But this one does not live up to my personal expectations raised by that introduction. This is clear to me, but I am afraid others may take some time to discover that fact the hard way. Maybe the not the library, but just the expectation is wrong. To avoid such misconception, please give your potential users the chance to adjust their expectations beforehand.

This is a good suggestion; as you point out, there is no benefit in having the expectations of potential users set beyond the scope of problems that the library actually addresses. I will add a clarifying section on "Domain of application and restrictions" to the documention as you suggest.

Since the library does not allow for mixed storage of quantities e.g. in vectors, further workarounds will be necessary when dealing linear algebra like BLAS, LAPACK or other advanced numerical libraries.

Perhaps Boost.Any provides a solution to this issue? This code compiles OK : boost::numeric::ublas::vector<boost::any> v(3); v(0) = boost::any(quantity<SI::length>(3.0*meters)); v(1) = boost::any(quantity<SI::mass>(3.0*kilograms)); v(2) = boost::any(quantity<SI::time>(3.0*seconds)); I honestly don't know how frequently the problem of containers of heterogeneous quantities will arise, but I understand that there may be situations where this is the case.

The library provides support for language-independent serialization by the use of Boost.serialization library. No attempt is made to ensure that the units of the deserialized quantities match the ones of the serialized ones.

Clearly, there is a limit to what one can accomplish when converting between a data stream of raw bytes to a class. Furthermore, the overhead involved in storing specific type information on units and quantities could be significant, so that storing a large array of quantities would occupy dramatically more disk space than the corresponding array of value types. This problem is a general one, anyway : I don't know of any Boost libraries that provide type checked serialization.

No attempt is made to provide formatting for quantities in human readable form (beyond debugging output).

At present this is true. However, I believe that extending the formatting options is a reasonable request and will be given serious consideration for future incarnations of the library. This would include IO manipulators and facets to control human language dependent output.

No attempt is made to provide parsing of unit input in human readable form."

This is true at present. Since, as you already are aware, the unit must be specified at compile time, this would provide minimal utility at present. However, we would be delighted to work with you to ensure compatibility and interoperability if you are interested in implementation of a library for handling runtime units. Ultimately, as many if not most participants in Boost are volunteers doing the work on their own time, expecting complete solutions of significant problems like those posed by units to be provided in monolithic form, I believe, will just end up preventing anything at all from being accomplished in the problem domain. Ultimately, the process functions best via collaboration, with multiple individuals contributing their expertise to solve problems within their domain of experience and interest. Regards, Matthias

...

Since the library does not allow for mixed storage of quantities e.g. in vectors, further workarounds will be necessary when dealing linear algebra like BLAS, LAPACK or other advanced numerical libraries.

Perhaps Boost.Any provides a solution to this issue? This code compiles OK :

BLAS does not congest boost::anys. It crunches numbers. Bare-bone floating point numbers, in single precision and contiguous memory for best performance. I like the picture of a conveyor belt for the transportation of my quantities: Near the end of the belt, there is a last check that everything is in correct shape (aka unit) and then - off it goes: Undressed of all other attributes, the naked numbers get fed into that horrible numbercrunching monster machinery. After getting out on the other side, they will get nicely dressed again and released into the shiny world anew. :-) Consequently, I consider a separation of concerns here: To the number crunching monster, it should look like a POD floating point field. To the outside, we need to dress these numbers with their further attributes. That could be done by some proxy or facade object that models a quantity but only holds a reference to the actual location of the numerical value instead of the numerical value itself. Those proxy objects could be both either static or dynamic in nature, just as needed. A separate object for each number, that would clearly incur a noticeable overhead. To keep that manageable, it appears quite practicable to provide one such object for larger parts of the floating point field, implementing the usual sequence semantics. (More gentle minds do not feed those cute quantities to a monster, they do perform a conversion into a dimensionless system beforehand.)

Clearly, there is a limit to what one can accomplish when converting between a data stream of raw bytes to a class.

I would have expected an attempt to catch at least the major sources of errors. Otherwise you end up with the same kind of vulnerability as the Mars Climate Orbiter teams. This time, not on the level of subroutine calls but of files written by on program and read by the another one. For an example, you could check whether the stringified unit of the quantity that is to be deserialized is the same as the stringified unit of the quantatity that has previously serialized. I.e. something along the lines of template<class Archive,class Unit,class Y> inline void serialize(Archive& ar,boost::units::quantity<Unit,Y>& q,const unsigned int version) { static std::string s1=stringify(unit<Dim,System>()); std::string s2(1); ar & q.value(); ar & s2; if (s1!=s2) throw incompatibilty_exception(q, s); }

Furthermore, the overhead involved in storing specific type information on units and quantities could be significant, so that storing a large array of quantities would occupy dramatically more disk space than the corresponding array of value types.

Cleary, safety does not come for free. However in the case of a large vector of quantities of the same type (the only one you considered so far), the unit need to get checked only once for the whole vector, not repeatedly for each and every element therein (much like the sequence semantics I mentioned above). That should alleviate the associated overhead sufficiently to get manageable again. Yours, Martin.

BLAS does not congest boost::anys. ^^^^^^^^ Ooops, sorry for the typo. Should be "digest".

Once you feed boost::any int to BLAS, it probably gets a congestion... ;-)

Nope. Your dialog manager would keep track of the unit and set appropriately upon initialization and/or user interaction. Your reader would then be as simple as setting the value directly to the quantity. Alternatively you might have something like this:

quantity<abstract> on_dialog_ok() { quantity<abstract> dist; dist.set_unit(combo.selected_item().data()); dist.set_value(entry.value().as_double()); }

No more switch statement smell.

Yes, but then again, the unit of "dist" cannot be hardcoded in its C++ type anymore. I may be missing something, but I do not see how the above code could be made to work with the library under review. Yours, Martin.

On 3/27/07, Noah Roberts <roberts.noah@gmail.com> wrote:

Nope. Your dialog manager would keep track of the unit and set appropriately upon initialization and/or user interaction. Your reader would then be as simple as setting the value directly to the quantity. Alternatively you might have something like this:

quantity<abstract> on_dialog_ok() { quantity<abstract> dist; dist.set_unit(combo.selected_item().data()); dist.set_value(entry.value().as_double()); }

I see. Would the implementation allocate a derived class based on the unit type, or just dispatch during arithmetic based on unit type? I suppose it works out to about the same penalty either way, virtual function or if statement for every arithmetic. It would probably be a lot cleaner to go the derived class route though.

No more switch statement smell.

I agree on the smell...Thankfully it's very contained when using the compile-time version. It seems like with a run-time component that was interoperable with the compile-time one, you could have zero run-time overhead during computations as well as get rid of all switch statements at the boundaries (reading/writing from database or GUI). Something like: quantity<SI::length> on_dialog_ok() { quantity<abstract> dist; dist.set_unit(combo.selected_item().data()); dist.set_value(entry.value().as_double()); return quantity<SI::length>(dist); } --Michael Fawcett

On 3/28/07, Steven Watanabe <steven@providere-consulting.com> wrote:

Here is how I would do it:

quantity<SI::length> on_dialog_ok() { double conversion = combo.selected_item().data(); double value = entry.value().as_double(); return quantity<SI::length>::from_value(conversion * value); }

There may be some confusion (again) on my part as to what combo.selected_item.data() is returning, and how it's useful to the quantity directly. I was assuming from Noah's post that it was either the integer of the currently selected item in the combo box, or the string of the currently selected item in the combo box. I can see how both of those could be immediately useful to the run-time quantity. It would either know that the number, say 5, mapped to feet, or it would be passed "feet". What does your version do exactly? What is combo.selected_item().data() returning, why is it a double, and how does from_value use it? --Michael Fawcett

Steven Watanabe wrote:

The confusion could be on my part. I was thinking that the combo box would allow arbitrary data to be associated with the each item. If this is not the case then you need either a map or a switch statement regardless of whether the units are compile time or runtime.

Well, not arbitrary but some data that is meaningful to the code using it that is not displayed to the user. In my case I was thinking a unit type that exists solely for providing conversions. Not always is that a multiplication. For instance gage pressures adds an extra value on top of any conversion when converted from an absolute. There are also cases, that though may be rather questionable, in which two disparate dimensions are used for the same kind of thing. For instance, a user can often request that pressures are reported in a "hydrostatic" pressure, which is a length. A hydrostatic unit might contain information necessary to do the dimensional conversion to be used in a pressure quantity. For this reason the unit type cannot be a primitive if the library is to encompass this use, which I think it should. Also, your idea has problems when you account for rounding. Rounding is often done before you display data to a user. In cases when this data can come from a calculation or from the user it is hard to decide when to round and when not. If you apply rounding and conversions on both input and output and add rounding into the mix you can have a user entered value that gets reported back to the user as something else. This is not acceptable in many cases. At any rate, there are ways to solve the whole thing regardless. The question is, what is the use of a library that only does static conversions. How often is one going to use multiple "systems"? The problem of writing expressions in one set of units that may be different than the rest of the system is easily accomplished with the use of static constants. I believe that the cases when a static system is better are actually very small and it is for that reason that I don't believe this library is a good candidate for boost inclusion since the object of boost is to provide generic and commonly useful libraries. The dimensional analysis part is very generic and useful but the static only unit part detracts from this usefulness.

Steven Watanabe wrote:

I may be wrong, but in order to avoid any excess loss of precision you have to store a set of all the base units and track the actual unit at runtime involving a merge with every multiplyor divide. This kind of overhead is not always acceptable.

I don't understand what you are saying.

...

At any rate, there are ways to solve the whole thing regardless. The question is, what is the use of a library that only does static conversions.

As has been stated many times conversions are not the primary point of the library.

I've never seen that stated. I don't believe it either. If conversions are not the point of the library than why is a very significant portion of the library dealing with units and conversions?

Michael Fawcett wrote:

On 3/27/07, Noah Roberts <roberts.noah@gmail.com> wrote:

...

Nope. Your dialog manager would keep track of the unit and set appropriately upon initialization and/or user interaction. Your reader would then be as simple as setting the value directly to the quantity. Alternatively you might have something like this:

quantity<abstract> on_dialog_ok() { quantity<abstract> dist; dist.set_unit(combo.selected_item().data()); dist.set_value(entry.value().as_double()); }

I see. Would the implementation allocate a derived class based on the unit type, or just dispatch during arithmetic based on unit type? I suppose it works out to about the same penalty either way, virtual function or if statement for every arithmetic. It would probably be a lot cleaner to go the derived class route though.

No virtual function would be required. template < typename D > struct unit { double convert(double base_value) const { return base_value * cv_fact; } private: double cv_fact; }; D is the dimension and simply makes sure you don't intermix dimensions as it would be unassignable to any quantity except ones in the same dimension.