Configuration options

This section describes rather the rough goals than the status quo.

1) specification of the physical quantity model (see pkg123.tar)

• SI model (7 base units)
• relativity model (..)
• quantum model (..)
• additional (non-SI) units for special purposes.

==> use different definitions of base units in config namespace and adapt definition in namespace unit.

==> use of preprocessor. Libraries with different quantity model will be incompatible.

1a) order of magnitude of internal numerical value representation

==> adjust the numerical value of the base unit quantity accordingly.

Libraries with different orders of magnitude for the same base unit will be (semantically!) incompatible but will probably link nevertheless, so that this kind of trouble will not be detectable by the build system. FIXME: Is there any way to produce some error in this case?

2) Type of numerical value: FixedPhysical is template of the numerical value type (double or float in most cases). Libraries with different template parameters should use implicit conversion rules between the numerical types. FIXME: This could not be the preferred behaviour in all cases; is there a way to configure this?)

You may choose the numerical type of a physical quantity by using the appropriate namespace: physical::quantity_double::meter physical::quantity_float::meter The same holds for namespaces unit and unitsymbols that are both split up into unit_double/unit_float and unitsymbol_double/unitsymbol_float respectively.

FIXME: I personally would prefer a notation like physical::quantity<double>::meter physical::quantity<float>::meter but the initialisation of const static non-integral template members is more involved and seems to require the repitition of quantity names. FIXME: maybe Boost preprocessor library may help here?

Note that DynamicPhysical is currently not a template and its numerical value type is fixed to double. This is in favour of simplicity of usage and does not hamper the generality too much in my opinion. There might be two reasons to switch to float: (a) to save memory (Not relevant here since we are storing the exponent vector either in full or at least as a pointer using flyweight pattern.) (b) for computational speed (Not relevant here since the computational overhead for exponent handling spoils any gain here)

Units with origin can only be defined as DynamicUnit and thus for double precision. However, for notational simplicity, those DynamicUnits (namely celsius, fahrenheit, reaumur) are defined in both double&float namespaces.

3) world view: Real world software may require different choices of units in the presentation of data to the user. This includes preferences of certain ranges of prefixes(kilo-, mega-, giga-, nano-, pico-..) as well as certain domain specific derived units like revolutions per minute (rpm).

==> Use the dimension system for this. Libraries will be compatible.

4) Parsing options: a) List of accepted unit names b) short names or long names? c) numerical type to produce d) produce numerical result or some internal representation for multiple evaluations (cf. LuK Formula object) ?

---

hosted on