Different behavior for unit conversion "degC" and "K"

[kaytak]

Hello,
Thank you for making a good work, I use mathjs as a core library in my engineering calculator tool.
In the contexts of heat transfer calculation, I evaluate the following calculation and I got the correct result.

math.evaluate('0.1 kg/s * 4.2 J/K/g * 5 K').toString()
=> '2.10... kW'

However, when I replace "K" with "degC", which shall give the identical result here, the result seems wrong:
math.evaluate('0.1 kg/s * 4.2 J/degC/g * 5 degC').toString()
=> '0.42... kW'

Could you please check this problem?

Best regards,

[gwhitney]

Well, the problem can be greatly simplified: math.evaluate('1 J/degC') returns 0.0036476... J / degC ! Probably easier to track the bug down from this example. There are other related unit weirdnesses I will file a separate issue for, but I think this example is the core of your specific problem.

[gwhitney]

Ah, and the bug has nothing to do with joules, it happens with any unit in that place, e.g., "1 m/degC" evaluates to 0.0036.. m/degC, etc. And degF has the same problem, but it produces a different value: "1 in/degF" evaluates to 0.00217.. in/degF. And it's not just about unit division, it happens with multiplication as well: 1 m degC evaluates to 274.15 m degC and 1 in degF evaluates to 460.67 in degF. So seems like it has something to do with the zero points for these different temperature units being different, even though that should only come into play when converting between different temperature units, not when multiplying a temperature unit by another unit...

[gwhitney]

Further, multiplication with temperature units is not associative: "1 (m degC)" evaluates fine (to "1 m degC").

[gwhitney]

Aha, the problem is that the "offset" of a unit (which only applies to temperature units other than Kelvin and Rankin) is being applied too much. For example "20 degC + 1 degC" is evaluating to "294.15 degC", not "21 degC" as it should. Similarly "20 deg C - 1 deg C" is coming out below -200 degC. I will see if I can produce a PR that tames the offset at least somewhat.