Units with non-zero origins

For the compiletime checked units, no offsets are allowed for simplicity reasons. Thus there is no need to have a FixedUnit; just use FixedPhysical instead.

In the dynamic case, non-zero origins are allowed. A DynamicUnit consists of a set of exponents and a scale. The scale in turn consists of a factor and an origin. Common units for the temperature like Celsius or Fahrenheit can therefore only be expressed in terms of DynamicUnit Temperatures are internally expressed in Kelvin which in turn has zero origin and thus available as FixedQuantity.

Please be aware that in case of u.scale.origin!=0, the multiplication by a scalar (e.g. float or double value) is not consistent with the multiplication by a dimensionless physical quantity.

I) multiply two quantities: (assume q1.factor=1, q1.origin=0):

q1*q2 = q1.value * (q2.value*q2.factor+q2.origin)
	  = q1.value*q2.value*q2.factor + q1.value*q2.origin

this is designed to produce always the same quantity (i.e. (q2.value*q2.factor+q2.origin) is const), whatever unit q2 is expressed in. This multiplication does not honor the scale the quantity is expressed in (i.e. the result is independent form any particular scale).

Example:

Consider the idael gas equation

p1 * V1 = n*R*T1

and then an adiabatic change of pressure to p2:

p2 * V2 = n*R*T2

What temperature will result?

n = p1 * V1/(R*T1)
T2 = p2 * V2/(n*R) = p2 * V2/(p1 * V1/(R*T1)*R) = (p2 * V2) / (p1 * V1) * T1

T1 is a physical quantity that is independend of the units it is expressed in. Consider T1 to be 1 degree Celsius and the ratio (p2*V2)/(p1*V1) to be equal 2. The resulting temperature is then not 2 degree Celsius as one might assume at first glance, but 2*(273.15+1)K=548,3K=275,15 degree Celsius. For this kind of computations, we need to handle absolute temeratures in Kelvin.

From this point of view, it gets clear that 2*(1*Celsius) is something completely different than (2*1)*Celsius. In fact, Celsius should be of the kind "unit" while (1*Celsius) is a temperature and thus of the kind "quantity". Those two classes then behave differently in the multiplication by a real.

Please note that in the case of linear (trivial) units only, this difference does not mean much; we can just intermix the two (as we do with FixedPhysical). In the presence of nonlinearities (offsets, logarithmic scales) the difference does indeed matter.

There should be no implicit conversion (but nevertheless an explicit one!) from physical quantities to physical units. The explicit conversion will be needed for the definition of derived (aka non-base) units: kilometer (km) may thus be stated in term of meter as 1000*m and so on.

The other way round concerns the conversions form units to quantities. Clearly, the product 1*Celsius is a physical quantity, but is the same valid for Celsius without a number in front? Probably not; thus we should not provide a conversion here.

This has a nice side effect: It will then be posssible to use the division by a unit as conversion from a physical quantity to a numerical representation of that quantity in the respective unit. This is a quite commom notation in the engineering sciences:

(100*Celsius)/Celsius     = 100

But contrast this with the ratio of two physical quantities:

(100*Celsius)/(1*Celsius) = (373,3K)/(274,3K) = 373,3/274,3

A similar reasoning is applicable to logarithmic scales (e.g. decibel - db):

(a*db) + (b*db) = ...
(a*db) * (b*db) = (a+b)*db

However, I am not so sure about the actual engineering practice in this area. (FIXME: What does the Schaeffler company guidelines, NIST web site, and others tell us about?)

II) multiply scalar with quantity:

a*q2 = a * q2.value*q2.factor + q2.origin

Note that q2.origin is not scaled here. a*q is designed to honor the scale q2 is stated in. This is necessary for that 20*celsius really means (20+273.15)K instead of (20*273K).

---

hosted on