I agree that the first line is wrong regardless what you actually want to express.

• If the two operands are really meant to be temperature points then the result is a change or difference of temperatures and it's unit must be left to K or set to Delta°C. Setting it to °C is wrong.
  
• If the second operand actually is meant to be a temperature difference or change, then it must have the unit K or Delta°C.

The second line can be right or wrong, depending on your actual intent.

• If the first operand is a meant to be a temperature point and second operand is meant to be a temperature difference or change, then the result is a temperature point and the unit can be K or °C. Nothing wrong then.
  
• Surely, if the equation is meant to represent something different, then it would be wrong. But that can be said of any equation in any document.

If everything is meant to be temperature differences, then this one is correct:

The right way is @ post 4,
i.e: put unit on the maths, not on individuals

Quite right: wrong question may be implicit of wrong answer !
Assume you have a differential meter, it performs [a-b]and you put
the unit you wish ... per say => answer= $
SI temperature unit is K ... thus post 4 is correct two ways.

In order to follow the rules in the document, you need to tell temperature differences from absolute (or thermodynamic) temperature for a given quantity. Thus, any object representing such quantities must have an attribute to indicate the type.

In non-automatic documents, the correct conversion between K and °C (with or without offset) is done based on context information, which is outside the actual maths.

The regulations ignore the needs of context-free self-contained physical equations handling. Just as Eurocode ignores FEA for local stresses.

Thus, whenever you want to use °C in automatic documents with unit handling, you have to indicate on a per-use base, which conversion to apply. In SMath, values of physical quantites are represented by unit and number. In some cases, the correct application of conversion rules or the correct choice of result units would require additional information (type of quantity) be taken into account.

The place of Delta°C or Delta°F is being a way to convey (and indicate) this information to the logic. I think it does the trick without blowing up the underlying infrastructure.

If you want to use °C in SMath, you most likely also have to be aware of Delta°C.

Unit tracking in SMath isn't really quantity tracking but it helps doing physical calculations correctly.

Storing all values in K actually is the source of the problem. When values given in °C are to be stored in K, then you need to know whether you have a difference or a thermodynamic temperature. Would you prefer a context menu entry to provide that information?

There is a way to consistently use °C: use this exclusively for the whole document and all occurances of temperature quantities. All gradients, conductivities, capacities etc must use °C in their definitions as well and do no conversion to K internally. You actually can do that in SMath by defining your own °C unit, here I defined one with an attached space character:


celsius.sm (3kb) downloaded 22 time(s).

The drawback of this is that you can't convert such °C based quantities to K without saying if the offset is to be applied.
Edit: Also, you are restricted to the setting °C or K globally for the document and can't make the decision on a per input/output base.

Edited by user 07 September 2018 00:26:23(UTC)  | Reason: Not specified