Temperature times a double

[Mobz87]

Is there a specific reason that I cant do:

Temperature * double

even though I can do it with every other unit?

[angularsen]

Yes, Temperature is tricky, because 0 Celsius != 0 Kelvin.
We added TemperatureDelta for this very case, so you should instead do
Temperature t = Temperature.FromDegreesCelsius(20) * TemperatureDelta.FromDegreesCelsius(2) // 40 degrees C

Edit: Hang on, that's not right either.

[angularsen]

Ah, found it, you can do

Temperature t = Temperature.FromDegreesCelsius(20);
Temperature t2 = t.Multiply(2, TemperatureUnit.DegreeCelsius);
Console.WriteLine(t2); // 40 C

[angularsen]

In either case, multiplication with temperatures is a bit tricky if you don't know the unit you are working with. Thinking in terms of "energy", one would think doubling the Kelvins would be right, but if you are thinking in Celsius (20) and doubling, you expect 40. The reference temperature (zero) is the missing information.

[Mobz87]

It make sense why you have done it that way however I don't think it is that tricky.
As a physicist you always do all you calculations in SI-unit and as long as you keep to that rule you don't have to think about it.

Keeping it in Kelvin you don't have to think about if it is a absolute- or a relative temperature (what you call KelvinDelta [which I can see that you have removed] ).

The way I see it:
You shouldn't use 'Delta' in any of you units.
If you are doing any kind of calculation ( - + * / ) you always go back to the SI-unit and do the calculation. No need for special rules or specifying beforehand rather it is a absolute- or a relative.

So if I have do:

Temperature * double
20°C * 2

It should return:
313°C

and not 40°C!

An ex.

You want to calculate power:
Power = Massflow * specific_heat_capacity * (temperature2 - temperature1)

Lets say:
temperature2 = 30°C
temperature1 = 20°C

If you say that:
Power = Massflow * specific_heat_capacity * (30°C - 20°C)
is equal to:
Power = Massflow * specific_heat_capacity * (10°C)
then you have failed you exam!

If you say that:
Power = Massflow * specific_heat_capacity * (303K - 293K)
is equal to:
Power = Massflow * specific_heat_capacity * (10K)
then you still have a change to pass the exam :-D

Does it make sense?

[angularsen]

It absolutely makes sense and this was in fact the original implementation until this issue came up and the resulting PR:
#218
#219

I have myself stumbled on this and I know others have too. It's an easy mistake to make to try to double a temperature in degrees Celsius or Fahrenheit and expect the resulting value to also double, especially if you are not regularly working with temperatures.

I think this quote puts it well

What is often confusing about the Celsius measurement is that it follows an interval system but not a ratio system; that it follows a relative scale not an absolute scale. This is put simply by illustrating that while 10 °C and 20 °C have the same interval difference as 20 °C and 30 °C the temperature 20 °C is not twice the air heat energy as 10 °C. As this example shows, degrees Celsius is a useful interval measurement but does not possess the characteristics of ratio measures like weight or distance.

So. I see two ways foward:

1. Add back support * and / using Kelvins, add some extra xmldoc to the operator overloads and help consumers learn from their mistakes when they report issues on github.
2. Only provide Multiply(value, unit) and Divide(value, unit) methods, as we already have, and point people to use those instead. The downside is that this is less natural to use in complex arithmetic expressions and maybe less discoverable.

What do you think?

[Mobz87]

Thanks for asking for my opinion.

I think you should add support for + - * / where the calculation is done in kelvin and then inform the programmers that 1°C + 1°C != 2°C and inform about the difference between absolute- or a relative temperature. And that a relative temperature (Delta temperature) doesn't really make sense to have as anything else than Kelvin.
In the world of physicists and engineers you get hanged for expressing a Delta temperature in anything else than Kelvin.

This could also clean up a lot of the confusion about temperatures

An example of the confusion:

Entropy test = Entropy.FromjoulesPerDegreeCelsius(10);
Entropy test1 = Entropy.FromjoulesPerKelvin(10);

This is where you get hanged ;-)
It is not "not-correct" but really really confusing..

If you really want the DegreeCelsius you should say:
Entropy test = Entropy.FromjoulesPerDELTADegreeCelsius(10);

but then we are back to
Entropy test = Entropy.FromjoulesPerKelvin(10);

Another example of the confusion:

Temperature test = Temperature.FromDegreesCelsius(10);
Temperature test1 = Temperature.FromDegreesCelsius(20);

(test1- test).Kelvins.ToString() ;//return 10, which is correct
(test1- test).DegreesCelsius.ToString(); //return 10, but should return -263°C

To sum up:

If you handle temperature like any other unit by doing all the calculation in the SI-unit (Allowing + - * /), everything would be correct and your 'only' problem would be to teach your users the correct way to handle temperature

[angularsen]

Thanks, I value your input. You clearly have a solid grasp on this domain and I agree with almost all you said.

This one I find confusing though:

(test1- test).DegreesCelsius.ToString(); //return 10, but should return -263°C

In the current implementation, Temperature - Temperature returns TemperatureDelta. In my mind at least, that is intuitive as, similar to DateTime - DateTime you get TimeSpan. The DateTime analog works, for me at least, since it too has no zero reference date and you only have relative time scales for different calendars.

So, I would expect 10 in your example above, a difference of 10 degrees Celsius the same way you also have a difference of 10 degrees Kelvin.

Hope you can enlighten me on this part, thanks!

[tmilnthorp]

If you look at the Boost units documentation, they do something similar. Here's the output:

    quantity<absolute<fahrenheit::temperature> >    T1p(
        32.0*absolute<fahrenheit::temperature>());
    quantity<fahrenheit::temperature>               T1v(
        32.0*fahrenheit::degrees);
    
    quantity<absolute<si::temperature> >            T2p(T1p);
    quantity<si::temperature>                       T2v(T1v);
    //]

    typedef conversion_helper<
        quantity<absolute<fahrenheit::temperature> >,
        quantity<absolute<si::temperature> > >          absolute_conv_type;
    typedef conversion_helper<
        quantity<fahrenheit::temperature>,
        quantity<si::temperature> >                     relative_conv_type;
    
    std::cout << T1p << std::endl
              << absolute_conv_type::convert(T1p) << std::endl
              << T2p << std::endl
              << T1v << std::endl
              << relative_conv_type::convert(T1v) << std::endl
              << T2v << std::endl
              << std::endl;

    return 0;

The output is:

{ 32 } F
{ 273.15 } K
{ 273.15 } K
[ 32 ] F
[ 17.7778 ] K
[ 17.7778 ] K

[Mobz87]

Looking at the Unit system you don't see any Delta Units - Try to find me a SI Delta Unit :-)
Since you are trying to replicate the unit system I believe introducing Delta-Units are wrong and are creating unnecessary confusion both for you and for your users and it requires path-work that deviates from the original system.

In the physicists/engineers world this is how it is done:
30°C - 20°C = 10K same as 303K - 293K = 10K

and if you for some reason want to express 10k in °C you get -263°C
303K - 293K = -263°C
Everything above it perfectly fine, yes the -263°C is confusing but nonetheless holds true.
This is why you normally don't express a "delta temperature" in °C

You can not say 30°C - 20°C = 10Delta°C because Delta°C is not defined in the unit system!

If you take MassFlow - MassFlow you get... MassFlow not DeltaMassFlow
If you take Density - Density you get.. Density not DeltaDensity
If you tage Temperature - Temperature you get Temperature not DeltaTemperature
If you tage MassFlow * MassFlow you get MassFlow^2
If you tage MassFlow/MassFlow you get [ - ]

This holds true for every single Unit in the unitsystem!
Thou not saying you can do all the summation 1 + 1 = 2 (!)
And this is what (I believe) is confusing you - most temperatures dont have concentric zero points.

Most units have concentric zero points [ 0Meter = 0cm =0Feet.... ]
If you would express the difference between Meter and feet in y = ax + b you get y = 3.3x + 0
Where y is meter and x is feet and in this case b = 0. Here everything is easy.

With kelvin and DegreesCelsius:
y = 1x + 273.15 where y is kelvin and x is DegreesCelsius

'with kelvin and Fahrenheit
y = 0.55x + 459,67 [Is something like this, cant really remember it correctly but you get the point]

Even your DateTime - DateTime is DateTime!
because DateTime = seconds since 1900

(Seconds between 2010 and 1900) - (Seconds between 2000 and 1900) = (Seconds between 1910 and 1900)
but lets keep Time out of the equation for now :-)

[Mobz87]

A quick summarizing of my points:

• Remove anything with the name of Delta
• Every calculation done in SI-unit

Results in

• No special cases for any unit! Every single unit is treated the same.
• A true copy of the real unitsystem.

[angularsen]

@tmilnthorp

If you look at the Boost units documentation, they do something similar. Here's the output:

Oh gosh I forgot how badly I dislike C++ syntax, thanks for reminding me 😆
So they distinguish multiplication of "SI temperature" in Kelvin scale and multiplication with a "Fahrenheit temperature" in Fahrenheit scale? Seems similar to our Multiply(TemperatureUnit unit) methods.

@Mobz87 From a programmer's perspective in science or engineering, this sounds reasonable. From a programmer's perspective working on a weather app and want to find the difference between the warmest point of day and the coldest and express that in Celsius or Fahrenheit - I'm just imagining up a scenario here - this probably gets confusing real quick.

Even your DateTime - DateTime is DateTime!

No, it's TimeSpan in .NET. It is a period of time between two dates and the analog breaks down when you try to construct a DateTime as the result of the seconds between two dates, that date does not make much sense in how we work with dates and time, the same way subtracting two temperatures to produce a new temperature might seem weird depending on what unit/scale you expect.

I think this is an important point when Kelvin is perhaps a foreign concept and you are simply thinking in Fahrenheit and Celsius, because that's what the imagined app does.
Please consider this:

Scenario: Calculate the degrees of Fahrenheit between warmest and coldest for a day

I speculate most developers would reach for this:

var delta = Temperature.FromDegreesFahrenheit(100) - Temperature.FromDegreesFahrenheit(70);
var deltaF = delta.DegreesFahrenheit;
// Alt1: 100F - 70F = 30F = 30F
// Alt2: 311K - 294K = 17K = -429F
// Alt3: 100F - 70F = TemperatureDelta = 30F

Now, what is reasonable to expect delta to be here?
The scientist would say 17 Kelvins. Obviously! With flames on it.
The majority of programmers, I speculate, would say 30 Fahrenheit.
The layman, non-programmer, non-scientist, my wife, I'm pretty darn sure would say 30 Fahrenheit.

This is an indication of what is intuitive. It's important.

If calculations follow alternative 2 as you propose, this is how I would obtain 30 Fahrenheit:

var delta = Temperature.FromDegreesFahrenheit(100) - Temperature.FromDegreesFahrenheit(70);
var deltaF = (Temperature.FromDegreesFahrenheit(0) + delta).DegreesFahrenheit; // 30

Please correct me if there is an easier way to calculate this. This approach seems very counter-intuitive to me at least. I mean, I understand it, but it is not how I would expect to have to code it.

TL;DR
I claim arithmetic with temperatures is confusing for the average programmer Joe, including myself, and I believe TemperatureDelta adds value to help with this. In particular, calculating the delta temperature of a warm day and express that in Celsius or Fahrenheit seems particularly counter-intuitive to me without the help of TemperatureDelta. Do you see a way to make this easier while keeping the benefits of standardized arithmetic?

I'm not arguing to be difficult and am trying to keep an open mind here, I truly just want to make sure we keep the library intuitive for all our users - not only scientists and engineers. I look forward to your reply :-)

[Mobz87]

Well averaging on temperatures still work:

Temp1 = 10°C
Temp1 = 20°C
(10°C + 20°C) / 2 = 15°C

because

(293k + 303k)/2 = 298k
298k = 15°C

The only things that doesn't work is:

2°C + 2°C != 4°C (This many programmer will run into)
2°C - 2°C != 0°C (This many programmer will run into)
2°C / 2°C != 0°C (Programmer will never do this)
2°C * 2°C != 4°C (Programmer will never do this)

I see that you are caught between doing what is correct (in my world) or whats correct in the minds of most programmers that doesn't study engineering.

I still think doing whats correct is the right think to do here. The only thing you need to teach your programmer is:

If you want to do this
2°C + 2°C = 4°C do instead this 2°C + 2K = 4°C
With this simple information you can create a correct unit system that can be used by both engineers and programmers.

[Mobz87]

I would compare doing
2°C + 2°C and expecting 4°C
as saying
Monday + Tuesday = Wednesday

but saying:
Monday + 48hours = Wednesday makes much more sense
just like
2°C + 2K = 4°C

I hope you understand this analogy.

If you for your v4.0.0 are up for creating a unit system that are more physicist/engineer friendly I would be happy to help both with guidance and programming. I really like your project(!) but as you might be able to tell, it is important to me that the unit calculation is done correctly :-)

[angularsen]

2°C / 2°C != 1°C (Programmer will never do this)

Might do that to find ratio. Today was 50% warmer than yesterday.
I can't think of a scenario for multiplying temperatures though.

Monday + 48hours = Wednesday makes much more sense

I agree, but I also read hours as Kelvins and TimeSpan as TemperatureDelta in this analog - so I do think that type has some merit.

2°C + 2K = 4°C

Is this the correct form or should delta symbol be used here? 2°C + 2Δ°K = 4°C

Not to beat a dead horse, but conversions of temperature difference/delta is a thing: wolframalpha.com, nettam.com, schneider-electric.com

How about this:

1. * / for Temperature and double, using Kelvins
2. + - * / (??) for Temperature and Temperature, using Kelvins
3. + - * / of Temperature and TemperatureDelta
4. Temperature.Add/Multiply/Divide() methods with double and TemperatureUnit (similar to TemperatureDelta, but maybe helps with discoverability?)

Something like this:

var fahr100 = Temperature.FromDegreesFahrenheit(100);
var fahr50 = Temperature.FromDegreesFahrenheit(50);
var deltaFahr2 = TemperatureDelta.FromDegreesFahrenheit(2); // 2 Δ°F or 1.1 Δ°K

// Temperature and double
Temperature fahr660 = fahr100 * 2.0; // Add
Temperature fahrMinus180 = fahr100 / 2.0; // Add

// Temperature and Temperature
Temperature fahr173k = fahr100 * fahr100; // Weird when not using Kelvins, but is correct
Temperature kelvin1 = fahr100 / fahr100; // Weird when not using Kelvins, but is correct
Temperature fahr660 = fahr100 + fahr100; // Weird when not using Kelvins, but is correct
Temperature fahr0 = fahr100 - fahr100; // Weird when not using Kelvins, but is correct

// Temperature and TemperatureDelta
Temperature fahr200 = fahr100 * deltaFahr2; // Add
Temperature fahr50 = fahr100 / deltaFahr2; // Add
Temperature fahr102 = fahr100 + deltaFahr2; // Keep
Temperature fahr98 = fahr100 - deltaFahr2; // Keep

// Not sure to add/keep or remove these? Might help with discoverability.
Temperature fahr98 = fahr100.Add(-2, TemperatureUnit.Fahrenheit); // Add/remove
Temperature fahr200 = fahr100.Multiply(2, TemperatureUnit.Fahrenheit); // Keep/remove
Temperature fahr50 = fahr100.Divide(2, TemperatureUnit.Fahrenheit); // Keep/remove

// Remove these, weird order. It's like TimeSpan+DateTime.
Temperature fahr120 = deltaFahr20 + fahr100; 
Temperature fahr80 = deltaFahr20 - fahr100;

// Other usages
double ratio = fahr100.DegreesFahrenheit / fahr50.DegreesFahrenheit; // 2

[Mobz87]

You are right doing a Today was 50% warmer than yesterday. will not give you the expected result when doing the calculation in kelvin.
But Today was 50% warmer than yesterday. is still a funny thing to say because

For people using celsius:
Today was 50% warmer than yesterday.

For people using Fahrenheit:
Today was 30% warmer than yesterday.

For people using Kelvin:
Today was 10% warmer than yesterday.

And if you still want to do this calculation, you can just turn your celsius into a doubles and do the math.

Is this the correct form or should delta symbol be used here? 2°C + 2Δ°K = 4°C

Not to beat a dead horse, but conversions of temperature difference/delta is a thing: wolframalpha.com, nettam.com, schneider-electric.com

delta Δ is absolutely a thing! but it is not a unit and when you implement something that is not a unit into a unit, that's where things get confusing (and wrong in my world)

When you look at a unit (°F, °K , °C) you can't tell if it a absolute or relative (delta) by looking at the unit.