[Review][PQS] Physical Quantities System review (May 31 through June 9)
The review of Andy Little's Physical Quantities System begins today, May 31, 2006, and continues through June 9, 2006. Download: pqs_3_1_0 is the Official Boost Review version of pqs. (Please note that pqs_3_1_0 has a bug in one header. This can be either patched according to the latest release notes, "relnotes.txt" available from http://tinyurl.com/7m5l8 or alternatively download pqs_3_1_1, which is basically equivalent to pqs_3_1_0, except the bug has been fixed there. Description PQS (Physical Quantities System) is designed to replace the use of floating point types for modelling physical quantities in C++ programs. Advantages include automated dimensional analysis checking, automatic unit conversions, self documentation of code and uniform mechanisms for dealing with physical quantities overall, allowing better interoperability, accuracy and repeatability among engineering, physics and trade applications. The library will ultimately consist of various types for modelling quantities in different situations. The t1_quantity, which is the first to be implemented, performs all its dimensional analysis checks as well as parts of its unit conversion calculations, at compile time rather than runtime, for maximum efficiency. PQS is designed with a firm commitment to the SI system, as being the internationally agreed preferred system of units. A reasonable selection of common quantities and units is included in the review version for demonstration purposes. The intent is to expand on this to include all the common quantities mentioned in Appendix B.8 and B.9 of the NIST SI document: http://physics.nist.gov/cuu/pdf/sp811.pdf The library also defines a selection of physical constants again intended as a flavour of the constants that would be included in a full library implementation as outlined in: http://physics.nist.gov/cuu/pdf/chart1.pdf Review questions: Please always explicitly state in your review, whether you think the library should be accepted into Boost. You might want to comment on the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? -Fred Bertsch
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
"David Walthall" <walthall@stanfordalumni.org> wrote in message news:e61nrs$s4r$1@sea.gmane.org...
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.
Great! Thanks!
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.)
Absolutely. Thanks for coming up with the mechanism!
- 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.
Good. The Getting Started section was the most enjoyable part to write and should probably be made easier to get at.
- 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.
That sounds very similar to the original use case for the library. Its nice to have the confirmation from elsewhere that it does what its intended to.
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
Thanks for the taking the time to submit the review. regards Andy Little
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 x<y, x==y or x>y 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.
"Peter C B Henderson" wrote: [cut stuff re comparuisons] Hi Peter, I have replied on the developers list FWIW regards Andy Little
participants (4)
-
Andy Little
-
David Walthall
-
fred bertsch
-
Peter C B Henderson