[Units] Temperature conversion problem
Hi,
There appears to be a temperature conversion problem between ºC and ºF. Here's a simple test that shows the error under both gcc and Intel on both Darwin and Linux (with Boost trunk).
brisc:~ kbelco$ cat test3.cpp
#include <iostream>
#include
http://www.boost.org/doc/libs/1_48_0/doc/html/boost_units/Examples.html#boos...
Hi,
There appears to be a temperature conversion problem between ºC and ºF. Here's a simple test that shows the error under both gcc and Intel on both Darwin and Linux (with Boost trunk).
brisc:~ kbelco$ cat test3.cpp #include <iostream> #include
#include #include #include int main(int, char **) { using namespace boost::units; quantityfahrenheit::temperature t(100 * celsius::temperature());
// expect output of 212 F, produces 180 F // seems like not adding 32º offset when computing F = (C * 9/5 + 32) std::cout << t << std::endl;
return 0; }
brisc:~ kbelco$ icpc -g -Iboost test3.cpp
brisc:~ kbelco$ ./a.out 180 F
-- Noel
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Nov 30, 2011, at 2:24 PM, Matthias Schabel wrote:
http://www.boost.org/doc/libs/1_48_0/doc/html/boost_units/Examples.html#boos...
Oh, okay, missed that. So I probably don't fully understand what the units library is doing but I find this behavior a bit worrisome. [kbelco@wsblade001 ~]$ cat test3.cpp int main(int, char **) { quantityfahrenheit::temperature f(212 * fahrenheit::temperature()); quantitycelsius::temperature c(f); std::cout << f << std::endl; std::cout << c << std::endl; return 0; } [kbelco@wsblade001 ~]$ ./a.out 212 F 117.778 C 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. -- Noel
Oh, okay, missed that. So I probably don't fully understand what the units library is doing but I find this behavior a bit worrisome.
[kbelco@wsblade001 ~]$ cat test3.cpp
int main(int, char **) { quantityfahrenheit::temperature f(212 * fahrenheit::temperature()); quantitycelsius::temperature c(f); std::cout << f << std::endl; std::cout << c << std::endl; return 0; }
[kbelco@wsblade001 ~]$ ./a.out 212 F 117.778 C
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:
int main(int, char **)
{
quantityfahrenheit::temperature f(32*fahrenheit::temperature());
quantitycelsius::temperature c(0*celsius::temperature());
std::cout << 2.*f << std::endl;
std::cout << 2.*c << std::endl;
std::cout << f+quantityfahrenheit::temperature(c) << std::endl;
std::cout << quantitycelsius::temperature(f)+c << std::endl;
return 0;
}
? What does multiplying an absolute temperature by 2 mean? Should the last two lines give me 32+32 = 64 and 0+0 = 0? Why would the order of conversion matter? I understand the desire for temperature to equate to the common interpretation, but this approach quickly becomes problematic when you allow arithmetic operations. The same issue arises in std::chrono in differentiating between specific time points and durations. If you want a temperature point, use quantity< absolutefahrenheit::temperature >. This will have the added benefit of allowing conversions but disallowing operations that don't make sense... Some code:
#include <iostream>
#include
On Nov 30, 2011, at 4:00 PM, Matthias Schabel wrote:
Oh, okay, missed that. So I probably don't fully understand what the units library is doing but I find this behavior a bit worrisome.
[kbelco@wsblade001 ~]$ cat test3.cpp
int main(int, char **) { quantityfahrenheit::temperature f(212 * fahrenheit::temperature()); quantitycelsius::temperature c(f); std::cout << f << std::endl; std::cout << c << std::endl; return 0; }
[kbelco@wsblade001 ~]$ ./a.out 212 F 117.778 C
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. That said, I'm sure you have good reasons for the choices you made. And let me say that I'm impressed with your library and look forward to using it going forward. Thanks again for your very detailed response. -- Noel
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
participants (2)
-
Belcourt, Kenneth -
Matthias Schabel