Re: [Quantity-devel] temperature conversion

[<ber...@t-...>]

I have fixed the Fahrenheit bug.
However, another problem appeared:
If we perform arithmetic operations (e.g., add, operator+) with objects from the 
same group (e.g., TemperatureGroup), but with different Unit (e.g., of type 
Temperature, with U = DefaultUnit = Kelvin, and of type 
DegreeCelsiusTemperature, with U = DegreeCelsius), then incompatibilities arise.
Either the addition operation is no longer commutative, or the results are 
commutative, but counter-intuitive.
For example, if we have (with rounded values)

Temperature T1 (298.0);           // T1 = 298.0 K = 25 oC
DegreeCelsiusTemperature T2 (0.); // T2 = 0 oC = 273 K

then, when (1) we recalculate the value of the second operand to that of the 
first and perform the addition, we get

T1 + T2 = 571 K     i.e. 298 K + (recalculated from 0 oC) 273 K, result in
                                                                  Kelvin
T2 + T1 = 25 oC     i.e. 0 oC + (recalculated from 298 K) 25 oC

The problem is that 25 oC != 571 K, and might be worse if we do someting like
T = T1 + T2 + T3 ...

When (2) we perform the addition always in the default unit (Kelvin) and 
recalculate to the result unit after the addition, we get

T1 + T2 = 571 K      i.e. 298 K + (recalculated from 0 oC) 273 K, result in 

                                                                   Kelvin
T2 + T1 = 298 oC     i.e. (recalculated from 0 oC) 273 K + 273 K = 571 K,
                             recalculated into 298 oC

In the second case, the two values can be interconverted ok (i.e. 298 oC are 571 
K), but we would intuitively expect the result to be 25 oC + 0oC = 25 oC.

What possible solutions do we have?

(1) decide for one of the above - but which one? - and accept the situation
(2) remove DegreeCelsiusTemperature from TemperatureGroup and put it into a
     new GT, simultaneously disallow operations between objects of same dimension
     but different variable type. This would require an explicit conversion if
     arithmetics between the types are desired, which would not be possible with
     the present constructors.

Any ideas?
Bernd
-- 
=======================================================================
Bernd Speiser
Institut f"ur Organische Chemie
Auf der Morgenstelle 18
D-72076 T"ubingen
Germany
phone: +49-7071-2976205 (office) +49-7071-2976242 (laboratory)
fax:   +49-7071-295518
e-mail: ber...@un...
Internet: http://www.uni-tuebingen.de/speiser
=======================================================================