Re: [Boost-users] [Units] Temperature conversion problem
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:
quantityfahrenheit::temperature f(32*fahrenheit::temperature());
quantitycelsius::temperature c(0*celsius::temperature());
std::cout << f+quantityfahrenheit::temperature(c) << std::endl;
std::cout << quantitycelsius::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 quantitysi::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(quantitysi::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< absolutecelsius::temperature > TRoomInCelcius (20.0);
then translate it into an absolute temperature in K:
quantity
participants (1)
-
Pieter