fred bertsch wrote:

The review of Andy Little's Physical Quantities System begins today, May 31, 2006, and continues through June 9, 2006.

Hello Boost users, Here is my review of the Physical Quantities System library.

Please always explicitly state in your review, whether you think the library should be accepted into Boost.

I'll start by saying that I think that this library should be accepted into Boost. It fills a major gap in the existing C++ framework for scientific computing by bringing much needed type-checking for physical units. I've been looking for a library that does exactly what PQS does ever since I ran across the Dimensional Analysis section of David Abrahams and Aleksey Gurtovoy's book, C++ Template Metaprogramming.

- What is your evaluation of the design? - What is your evaluation of the implementation?

The only thing lacking in the current implementation is the ability to easily extend current types to include other units. Right now it requires editing the main headers to include the new units. (Andy Little and I have discussed some ways to alleviate this problem which, I believe, he intends to implement in the next version of PQS after the formal review is completed.)

- What is your evaluation of the documentation?

The documentation is solid and provides the reader with a thorough understanding of the library. However, the library is simple enough to use that just reading the Getting Started section was enough to let me get started initially and test out the library to see if it did what I needed.

- What is your evaluation of the potential usefulness of the library?

This library is extremely useful for anyone who deals with values that have associated units. As I mentioned before, a major short-coming of C++ (and all other programming languages that I know of) is that values are represented as dimensionless quantities, and it is the responsibility of the programmer to ensure that all units are consistent. This library removes that burden from the programmer and places it on the compiler. Using the PQS library also makes code self-documenting. All of the variables which in C++ would have to carry their units in comments or variable names can now carry all information in their type, which makes it impossible to have the comment and code get out of sync.

- Did you try to use the library? With what compiler? Did you have any problems?

I used the PQS library to add dimensions (and type-checking) to an existing program that was about 20,000 lines. The process took less than two days total. The process of converting from doubles to dimensioned quantities uncovered a handful of bugs that would have otherwise gone unnoticed, such as comparing a length to an area. I used PQS with MS Visual C++ 7.1 on Windows XP and with gcc 4.0.1 under OS X Tiger. I had no problems with either one.

- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?

I would say that I have put considerable time into the evaluation of the usability of this library. I have put only some time into understanding the design and implementation - just enough to be able to use the library and modify it when needed to add my own units.

- Are you knowledgeable about the problem domain?

I believe that I am knowledgeable about the program domain. I received a Ph.D. in Chemistry and now work as a scientific programmer. Thank you, David Walthall

I hope this beats the deadline. I didn't realise I had to repost after subscribing to boost. I only learned about this review on Wednesday June 7, so I hope this gets in on time. Also, I have not had time to thoroughly review the design. However one aspect of the design was brought to my attention by a colleague, and it is on this I will comment. The aspect that I wish to comment on is the definition of the comparison operations. These are described as being controlled by a parameter BOOST_PQS_COMPARISON_EPSILON, which controls slop in the comparison. I will refer to this as epsilon comparison, as opposed to standard comparison. Looking at the reviews so far, I haven't seen reference to this issue. First the presence of this feature leads me to vote against the inclusion of this library in boost. My reasons follow. This behaviour violates the first principles of the use of operator overloading: the overloaded operators should have comparable semantics to the original operators and should satisfy similar relations, e.g. ++x should behave as x+1. In the context of a physical dimension library, this means the overarching design goal is that operations produce exactly the same results as would be obtained using the underlying numerical types, with the sole exception that the dimension checking prevents invalid combinations of dimensions. With respect to statically typed objects, whether statically defined or created by new and assigned to statically typed pointers, another goal is that there should be negligible increase in running time and the use of memory. Violating these dictums w.r.t. comparison leads to numerous problems. First, important relations no longer apply. For example trichotomy, i.e. exactly one of xy is true, can no longer be guaranteed. This property is relied on for sorting and hence for the proper operation of maps. Second, programmers will invariably read the comparison operators as being comparisons of floats in there usual sense. (For definiteness, I will refer to floats throughout, however these comments apply to any numeric type.) They will expect that they can copy a floating point routine verbatim and obtain the same results But if the value of BOOST_PQS_COMPARISON_EPSILON is changed anywhere in the program, this will no longer be the case and extremely hard to find bugs will occur. In addition, the programmer can no longer be sure what any comparison actually does, and so will have to invest time in checking that the epsilon control variable has not been changed while attempting to determine the cause of a bug. At worst, this will lead to defensive programming practice where every function will save and set this variable on entry and restore it on exit. Even worse, since no one can be sure a function doesn't change this variable, every function will have to save this variable and restore it before and after every function call. Third, the idea that this variable can be set to a single useful value is ill-conceived. When this type of comparison is required, the value of epsilon must be determined for each particular point in the program. It must be large enough to account for the anticipated rounding error at that point, but not too large so as to overly degrade the accuracy of the final result. Often, in fact, entirely different tests may be used, for example instead of x < y+eps, the test may be x < y*(1+ups)+eps. In many cases it may be fabs(x) < eps. Fourth, the use of epsilon comparisons can have a severe impact on performance as the compiler always has to issue operations to perform the full test, even when BOOST_PQS_COMPARISON_EPSILON is set to zero. Finally, it violates the purity of purpose the physical dimensions library. Its sole purpose should be to ensure programmers don't make mistakes which can be caught by dimensional analysis or due to inadvertant mixing of different units. The epsilon comparison proposed has nothing to do with this aim, rather it is attempting to protect inexperienced programmers from certain easily made mistakes. If this functionality is desired, a special template class, entirely separate from the dimensions library should be created and these special types passed as template arguments to the dimensions library. I hope I have not seemed too harsh in my criticism. Fortunately, this problem can be fixed with no imparement to the purpose or functionality of the proposed library.