There are a lot of programs in scientific and engineering computing using lots of different implementations for the handling of physical units. Most of these implementations only deal with a small portion of the overall topic. Considered in detail, this topic is quite complex.
None of the developers consider the topic of physical units as central to their business, and in fact it isn't. Therefore the hope is that an open source development might help to improve the correctness and usability of the scientific software. The library is subject to the Boost Software License. This license is quite liberal, basically you may use (and modify) it in any of your projects (both commercial and open source) without the obligation to publish the rest of your code.
- Earlier error detection during software development. Whenever possible, the compatibilty of physical units is enforced by the compiler. Where more flexible approaches are needed, exceptions are thrown in case of error.
- Comprehensive assortment of predefined SI units.The library goes great length to provide a rich set of units and to provide a clean notation.
- Defined process for the choice of units by the user of the software. The library enables the developers of other software to provide with more flexible user interfaces, e.g. ask the user for his preferred physical units for input and output.
- Defined process for the formatting of physical paramters, eventually configured by the user. The library provides reasonable simple and consistent way to format physical quantities in a human readable way and to read them in again.
- Improved interoperability among different pieces of software. The more programs that use the library, the better. The data conversion efforts to move data between different file formats is hopefully reduced by a consistent formatting and parsing of physical quantities. The formatting provides language-dependend and language-independend formatting options. Clearly for interactions with the user you will take the first, for data storage you should use the latter.
Barton & Nackman (FXIME: reference) do not consider the physical units as central but the physical quantities as central topic. They propose a static, template-based implementation where the pyhsical unit is encoded in the type of the Variable. That way, the compatibility can be checked by the compiler. The key to this technique is that not only types but also integral constant expressions are allowed.
FXIME: example
Such a static approach is suitable for situations where you know at the time of writing the program what kind of physical quantities are considered. This however is less often the case than you might expect at first sight. Examples are any flexible backend-storage for intermedeate results, configurable user interfaces, inputs and outputs.
Furthermore no names and prefixes are supported.
?
?
reviewed and not accepted for boost
mailing list
Abrahams&Gurtovoy
Quan - PQS - reviewed and not accepted for boost
sourceforge - ??
There is no one-to-one mapping of physical quantities and units:
Energy = 5 Newton * 1 meter
Torque = 5 Newton * 1 meter
These two quantities have completely different meanings that has to be furnished by the developer (in this case by the use of suitable variable names). It is impossible to decide automatically on the physical meaning of the expressione "5 Netwon * 1 meter" without further information.
Physical units define certain quantities that other quantities can be compared against (FIXME: ref NIST-website). Thus a unit identifies (only) the scale on which a given physical quantity can be measured on, not the kind of quantity itself. A given unit can preclude a certain set of possibilities but can never give a positive statement.
The are a lot of currencies that money can be measured in. However, these are not trivially convertible by some fixed constants like kilograms and metric tons. Indeed an amount of US dollars is a different quantity than a corresponding amount of Euros, since their relation may vary, i.e. depend of time location and other factors.
If you ever converted your paypal account several times back and forth between different currencies, you already know that such conversion should never be automatic but only done on explicit request.
Additional quantities may be considered as physical, like katal (katalitic behaviour, suggested to the SI commitee), or a measurement of customer satisfaction that is expressed in terms of "subjective assessment" numbers, ranging from 1 (worst) to 10 (best). The system of compile-time checked quantities may be expanded in a header file or the switched to another physical quantity model (see Configuration options). The system of dynamic quantities could be configurable, but is currently not (yet).
There are several quantities that have certain restrictions on their numerical range. Concentrations may not be negative and may not exceed 100%; thermodynamic temperatures below 0 Kelvin don'*t make sense and so on. However negative values may be interpreted as difference between other admissible values. This difference does not really matter most of the time. For units with non-zero offsets however, things get more complex as the difference then has a zero origin.
Examples of units with non-zero origin are temperatures, measured most commonly in Celsius or Fahrenheit. Both of these have an arbitrary origin somewhere in the human-percievable range, but both far away from the origin of the thermodynamic temperature at 0 Kelvin. For the purpose of this library, such offsets are not allowed for template-based implementations of quantities but only for runtime-checked ones.
The handling of nontrivial conversions should be as clean as possible. It is yet unclear how this can be accomplished.
A template based implementation has the potential to run without any overhead with respect to plain numerical values. Depending on your compiler, your milage may vary. No performance tests were done up to now.
In those locations where you need the additional flexibility of a runtime checked implementation, you will in any case pay for it in terms of memory consumption and computational time. Investigations will be made to find a suitable compromise here.
A library of physical units will inevitably define many symbols, of which some might conflict with other symbols in your program. Defining those symbols in a separate namespace surely is a good thing but only half of the solution. Many programmers undermine this by simply importing all symbols from another namespace by "using namespace xyz". This can lead to conflicts; even later, e.g. by additionial predefined units.
Any library suffer from this, a library of physical units defines a large number of mostly short symbol names, so the potential of collisions is particularly high. Basically the issue is to balance comfort versus safety.
A good workable solution is to import only specific symbols by "using physical::unitsymbol_double::cm". Another viable approach is to define a short local alias name for the enclosing namespace by "namespace u=physical::unitsymbol_double" and noting u::cm afterwards. (see namespace physical::unitsymbol_double).
Need clear distinction between Arithmetik and presentation layer.
This library supports only integral exponents to the base units. Units with rational exponents mostly occur in some kind of parameter fitting approaches:
force = alpha * (velocity)^p
Here, alpha should have the unit of Newton*(s/m)^p. But what happens if we decide to express the velocity in any other unit? Due to the nonlinearity introduced by p, this mapping is in general not clear. To avoid that please reformulate the above to
force = beta * (velocity/(m/s))^p
The expression velocity/(m/s) (read: velocity expressed in meter per second) is then dimensionless, while beta has now the unit of Newton.
The overall expression is now independend of the unit the velocity is stated in and no rational exponents are necessary. That is why rational exponents are deliberately not supproted by this library.
Generated on Mon Apr 2 22:25:06 2007 for physical_svn by
 1.5.1-p1
|
hosted on
 |