FixedUnit; just use
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
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*q2 = q1.value * (q2.value*q2.factor+q2.origin) = q1.value*q2.value*q2.factor + q1.value*q2.origin
(q2.value*q2.factor+q2.origin) is const), whatever unit
q2is expressed in. This multiplication does not honor the scale the quantity is expressed in (i.e. the result is independent form any particular scale).
Consider the idael gas equation
p1 * V1 = n*R*T1
p2 * V2 = n*R*T2
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
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
|Generated on Mon Apr 2 22:25:06 2007 for physical_svn by 1.5.1-p1||hosted on|