Re: [Boost-users] [Units] Temperature conversion problem

Subject: Re: [Boost-users] [Units] Temperature conversion problem
From: Pieter (PieterB_at_[hidden])
Date: 2011-12-14 17:37:42

>>>> If 'f' is 212ºF, why, when converting it to ºC, do I end up at 117
and change? Is this really what we should expect? It seems that this very
simple use case produces unexpected, and to a casual user wrong, results. I
understand the need for complexity but it seems to show up very early in the
user experience. 
>>> 
>>> Because a temperature change of 212ºF is equal to a temperature change
of 117.778ºC = (5/9)*212. What would you expect the following to do: 
> >
>> [ snipped a very complete response ]
> 
>> Hi Matthias,
> >
 Sorry, I didn't explain myself very well. I was merely surprised that
quantities of temperature are, by default, temperature differences not
absolute temperatures. With my rusty engineering hat on, I'd have expected
quantities of temperature to be absolute so they're consistent with the
published literature. I think of temperature differences as needing
explanation such as outputting a Celsius temperature difference as º∆C
(delta ºC, ºdC, ...) rather than expressing a temperature difference with
just ºC. Operating under the principle of least surprise, I found the
default temperature behavior surprising, that's all. I don't know how useful
temperature difference by itself really is but I'd guess it's less common
than absolute temperatures or normalized temperatures though differences are
useful, for example, in temperature gradients. 
>Don't mean to come across as prickly - there was just a lengthy debate on
this topic during review. Basically, while the first order "principle of
least surprise" is probably for temperatures to be absolute, this would make
quantities of temperature an anomalous special case relative to all other
quantities and would immediately cause problems when someone wanted, e.g.,
to implement something like the Planck radiation law, etc... In any case, we
do appreciate feedback and try to incorporate suggestions for improvements
wherever possible. 
>Cheers,
>Matthias

Dear Matthias,

In the example given by you earlier: 

quantity<fahrenheit::temperature> f(32*fahrenheit::temperature()); 
quantity<celsius::temperature> c(0*celsius::temperature()); 
std::cout << f+quantity<fahrenheit::temperature>(c) << std::endl; 
std::cout << quantity<celsius::temperature>(f)+c << std::endl; 

would give different outputs 32+32 = 64 and 0+0 = 0 if the temperature were
to be interpreted as being absolute.

As far as I see it, it is in fact not ‘the order of conversion, but rather
the scale that is used to do the addition in is what matters: in the
Fahrenheit scale, taking twice the absolute temp. means something different
than taking twice the absolute temperature in the Celsius scale (due to the
affine relation between the scales). This does not make it meaningless to
allow such additions (or other arithmetic operations).
To give an example: take Plank’s radiation law which computes radiation of a
body as a function of the temperature T in K, which is of the form (for
appropriate constants a1 and a2):

B(T) = a1*(1-exp(a2*T))^-1

As arithmetic is not allowed on absolute temperatures, my implementation
would have to define T as a relative temperature, something like (in
admittedly non-compiling 'code'):

 quantity<intensity> BodyRadiation(const quantity<si::temperature>& T) {
        // define a1 and a2 here
       return	a1*(1/(1-std::exp(a2*T)));
}

Suppose the radiating body is at room temperature which I measure using my
thermometer on the wall as 20.0 degrees Celsius. When I would define this as
a relative temperature:

 quantity< celsius::temperature> TRoomInCelcius(20.0);

and plug it into the radiation law: 

Intensity = BodyRadiation(quantity<si::temperature>(TRoomInCelcius))

This would give wrong results (without any warning) as the value  T = 20K
would be used unintentionally. I know it is the intent of the library to
emphasize safety over convenience but I fail to see a problem with my
abstraction here, while I don't regard this safe behavior.

To get correct results I would need to define my room temperature as being
absolute:

 quantity< absolute<celsius::temperature> > TRoomInCelcius (20.0);

then translate it into an absolute temperature in K:

quantity<absolute< si::temperature> > TRoomInK(TRoomInCelcius);

and then ‘somehow’ translate this into a relative temperature to be plugged
into the model, maybe like:

 quantity<absolute<si::temperature> > TZero(0*si::kelvin) ;
quantity<si::temperature> T(TRoomInK – TZero); Intensity = BodyRadiation(T)

which is far from elegant of course.

Core of the matter is that I need the temperature to be converted using the
‘absolute’ notion, while I need it to be interpreted as ‘relative’ to be
able to use it in the radiation law. This while the underlying numerical
value of the ‘relative’ and ‘absolute’ temperature is the same and in both
cases represents the same measured value. If arithmetic on the absolute type
was allowed, this could all be avoided as the model could be specified in
‘absolute’ temperature – I don’t really understand why you say that would
not make sense. 

I am not sure whether there is an elegant solution to allow this in natural
manner. Maybe conversion for units with affine relations between scales
should only be allowed to be explicitly done in either the absolute or
relative manner, which could possibly also relieve the need for two
different 'types' of temperature; as the example shows a single measurement
can have both 'relative'  and 'absolute' interpretations in the current
system depending on the context in which it is used and the type of
conversion that the context requires.

Does this make any sense to you?

Kind regards,
Pieter