Sadly, there is literally no way to get this right. In 10.4.0, the expression 1 degC == 9/5 degF returned false, even though everyone knows that a Celsius degree is 9/5 the size of a Fahrenheit degree, and this is "fixed" in 10.4.2 -- that expression now returns true. The underlying difficulty is that there is no way to tell if an amount denominated in degC or degF means a specific temperature value, or a difference in temperatures. And the old way of handling things led to nonsense answers when adding/subtracting temperatures and when doing enthalpy calculations. So big picture, 10.4.2 is an improvement over 10.4.0. And note that 10.4.2 specifically disallowed sign(-2 degC) because as an absolute temperature it's absolutely positive and as a temperature change it's definitely negative.

That said, the apparent wrongness/rightness of 37 degC == 98.6 degF is absolutely an issue from a usability point of view. Hopefully UnitMath when it is adopted will bring some sanity here. But in the meantime until that happens I can think of only three ways to proceed:

1. Disallow comparison of unit values in units with different offsets. So Michael's expression would throw an error because it is inherently ambiguous.
2. Split the tiny handful of units with offsets (I think it is just degC and degF, but maybe I've forgotten something) into two units each, one for specific temperature values and one for temperature changes. This is a real thing, see https://physics.stackexchange.com/questions/278678/degree-celsius-vs-celsius-degree. So 37 degC would be a specific temperature equal to 98.6 degF, and 37 Cdeg would be a temperature change equal to 66.6 Fdeg. (Clearly this is the satanic option.) This is likely the "right" response, but it is also a fair amount of work: we would have to teach mathjs it is illegal to add two degC values and that the difference of two degC values is a Cdeg value and that you can't multiply a degC value but you can multiply a Cdeg value, etc.
3. Lurch along with a kludge on top of a band-aid, and interpret 37 degC == 98.6 degF as (37 degC to degF) == 98.6 degF which does currently return true (and could perhaps serve as a workaround for you while this is being resolved: explicitly convert early to the same unit system whenever possible). But inevitably as long as quantities remain ambiguous between specific values and changes, any fix will eventually inevitably lead to other problems.

@josdejong , thoughts?

Thanks Glen for your in-depth reply. Man this is really tricky stuff.

Your option (2) is indeed the proper one: make a clear distinction between absolute temperature and a relative temperature, and do not allow adding absolute temperatures but, and force adding a relative temperature to an absolute one. It feels though like overkill to me, and before we would go that route, we should get a clear overview on the normal use cases and see how that would work out.

I think right now, we will serve most "typical" use cases if we apply your option (3). That's a small and pragmatic solution. Shall we go for that?

(Same issue holds for !=, <, > <=, >=)

@gwhitney Thank you so much for that explanation. I was able to get by for now with option 3, but this does make me appreciate the complexity at play here even more.

OK, given Michael's comments, it seems like (3) is OK to try at least as a temporary band-aid until UnitMath is available. (That's @ericman314, right? Eric, are you aware of the absolute-relative temperature issues that need to be handled in some consistent fashion in UnitMath?)

I'll try to work up a PR for (3) as soon as I can, but if publishing that leads to another round of concerns surfacing, there's probably no choice but to bite the bullet and do (2).

Personally, I have always used degC and degF for absolute temperatures, and K and R for relative temperatures. So for me at least, the problem's already been solved. Any other usage of degC and degF is ambiguous, so we just need to choose a behavior (my vote is treat them as always absolute) and document that very clearly. Then K and R could be used in things like J/K.

Since a relative Celsius degree is identical to a Kelvin degree (and similarly for Fahrenheit and Rankin), that is one way to go, with degC and degF as always absolute. @josdejong given that it seems like UnitMath is going to go that way, should mathjs follow suit and head that direction right now? In that case, the solution here would be to revert #2501, and instead:

• clearly document that degC and degF only record absolute temperatures, not a temperature change.
• disallow addition of degC or degF
• make sure degC + K is allowed and decide what units it should have (similarly for degF + R)
• change a subtraction of degC to produce K and a subtraction of degF to produce R
• disallow multiplication of degC, degF by anything without first converting to K or R (to avoid the problem in Different behavior for unit conversion "degC" and "K" #2499 that started this whole thing)

Have I missed anything? Let me know if I should embark on this direction.

P.S. Note of course this latter proposal would mean that the "resolution" of the problem in #2499 would be that the second multiplication that the poster there tried would throw an error (presumably suggesting use of K) rather than return a spurious result. That would definitely be better than the prior behavior, but presumably not what the poster was hoping for...

To make this a little nicer, we could perhaps also make the "pure" unit degC (i.e. a valueless instance) automatically convert to K when it is used in a product or quotient. Then at least it would be easier to see that 5 J/K * 2 degC is an error (and 5 J/degC would have automatically converted to 5 J/K by the time you got to the explicit multiplication in 5 J/degC * 2 degC, so again it would perhaps be clearer why it's an error.)

Anyhow, let me know your thoughts. In case it wasn't clear, this latest proposal is basically the same as option (2) above, just without introducing new units Cdeg and Fdeg, but instead using K and R for temperature changes.

Personally, I have always used degC and degF for absolute temperatures, and K and R for relative temperatures.

Since a relative Celsius degree is identical to a Kelvin degree (and similarly for Fahrenheit and Rankin), that is one way to go, with degC and degF as always absolute. @josdejong given that it seems like UnitMath is going to go that way, should mathjs follow suit and head that direction right now?

Yes, it makes sense to me, it sounds like the proper solution to separate absolute from relative temperatures 👍

@gwhitney your list with changes looks complete to me, thanks. I'm thinking about how to make sure that there are still practical ways to do real-world calculations with temperatures. Do we need special conversion functions to convert from absolute to relative temperatures and vice versa?

Well, Kelvin (and Rankin) is both absolute and relative, thanks to the existence of absolute 0. So the conversion functions you need are ... to K and ... to degC.

Oh, and we need to disallow scalar multiples of degF and degC as well; it makes no sense to double or halve, for example, an absolute temperature like 20degC.

Well, Kelvin (and Rankin) is both absolute and relative, thanks to the existence of absolute 0. So the conversion functions you need are ... to K and ... to degC.

That sounds straightforward 👍

Oh, and we need to disallow scalar multiples of degF and degC as well; it makes no sense to double or halve, for example, an absolute temperature like 20degC.

Yes, could be. But does it really harm if you want to multiply an absolute temperature like 20 degC with two?

Well, the harm is that the client might want the answer to be 40 degC but the only answer consistent with how Unit is implemented is 313.15 degC. How would that answer be useful? Also, we agree that 20 degC + 20 degC is disallowed (makes no sense to add two specific temperatures), but this is equivalent to 2(20 degC), so the latter should be disallowed as well.

I started working on an implementation last night and ran into a code organization question: currently many operations on units are just defined in the various operation implementations, like add, subtract, etc. -- there is no Unit.add() method. So these operations use a bit of the innards of Unit, i.e. Unit is not tightly encapsulated. That leads to some repeated code in these operations.

With making degC etc being only specific temperatures, there will be more internal checking that needs to be added to these operations, so my inclination will be to move them into Unit, where this code can be more easily shared.

But then look what will happen with something like unaryMinus. The code for signature 'Unit' will become just 'u.unaryMinus()' . That function will do its checks, but typically eventually will have to negate its value, so presumably it will call unaryMinus(u.value) - redispatching to the very typed-function that brought you there in the first place. As long as u.value is not itself a unit, which it can't be, this is not actually circular, but it is circuitous. The same roundaboutness is actually already there in unaryMinus, just it somehow seems worse when it's split between two entirely different files. Is this of any concern to you, and if so do you have any suggestions on how best to organize the code in this regard?

You're right, makes sense indeed to disable these kind of operations with misleading outcome. Thanks

It makes sense to me to move these basic operations like add and subtract to the Unit class if that allows reducing duplication.

Yeah I understand what you mean with the circular issue. It should go "alright" (ie. not causing an infinite loop) as long as you only use these functions passing numeric values. So far I've solved a similar circularity in calculating on matrices vs scalars by introducing addScalar, multiplyScalar, divideScalar (not supporting matrices), and use these in the functions add, multiply, divide which do support matrices. We could introduce something similar for units vs numeric inputs. It introduces quite some overhead though, and so far I'm a bit reluctant to take such a step (especially since from a pragmatic point of view there is no problem, and if there is a problem introduced during development you'll notice it immediately).

Hi,

Recently I was having an issue with this while checking if a certain temperature was lower than another (I already solved my issue just wanted to share some tests).

On versions newer than 11.4.1 the comparison is not reliable. The following example is validating that 0 degC == 0 degC and (-1 degC < 0 degC) and (0 degC < 1 degC)with different units.

freezing = 0 degC to [degC, K, degR, degF];
freezing == transpose([freezing])

# yields
# [[true,  false, false, false],
#  [false, true,  true,  false],
#  [false, true,  true,  false],
#  [false, false, false, true]]

oneCelsius = 1 degC to [[degC], [K], [degR],[degF]];
minusOneCelsius = -1 degC to [[degC], [K], [degR],[degF]];
(minusOneCelsius < freezing) and (freezing < oneCelsius)

# yields
# [[true,  false, false, false],
#  [false, true,  true,  false],
#  [false, true,  true,  false],
#  [false, false, false, true]]

All of these shall be true, which were ok on version 11.4.1 (broadcasting aside)

I see it was intended as a solution for #2499 but I think it was an issue by the user as it's known that for example $\frac{J}{kg \cdot K}$ is the same as $\frac{J}{kg \cdot C}$, since an increment of temperature of one degC is the same as an increment of one K and mathjs has a warning relative to the use of arithmetic operations with degC or degF (as does EES)

From other software I've used in the past; deltas or increments shall be managed in K or degR and that's why #2499 was having issues.

• https://en.wikipedia.org/wiki/Specific_heat_capacity#International_system
• https://fchart.com/ees/eeshelp/19.vfrh.htm

Yes, I think the response planned here would solve your issues, but it never got implemented. It got sidelined by the effort to reorganize mathjs in a TypeScript-friendly way, and then that stalled with some type reflection issues, and then I took on a visiting professor position so I didn't have time to devote to mathjs, and I haven't yet really gotten back into things. But as far as I know a PR implementing the final plan settled on here would still be welcome. But see the code-organization questions I raised the last time I tried to create such a PR.

Oh ok, got it, thanks!

I've read some of the discussions regarding Typescript and types and it seems like a huge effort.

I recently left a part time professor position due to a personal time related situation. Now I've had a few chances to participate in this project which I've been wanting to do since a few years.

I will review this discussion better to see if it's something I can work with as my programming skills are limited.