2ufac“°C” gives an incorrect answer

[abcdvvvv]

2ufac"°C" gives 548.3 (K), something may be wrong here.
Although ufac"2°C" gives the correct answer, 275.15, this notation seems not conform to the general paradigm of the package, because for other units, the constants are written first, for example, 2ufac"cm".
Is there any way to fix it?

[j-fu]

Thanks, this is indeed wrong, and I consider this as a bug to be fixed (so no breaking release).

The result of ufac"°C" is just a number (274.15), the prefix just triggers multiplication of numbers.
Whereas with Unitful, u"°C" it is of a special type which knows what must be done if we write
2u"°C" .

As a bugfix, I will disable handling of affine units and relative temperature
scales in LessUnitful and throw an error if they are encountered.

I think the approach I am using here does not allow to support these.

DynamicQuantities.jl provides another alternative to Unitful which is significantly more sophisticated
than LessUnitful.

In the moment it does not support affine quantities either:
SymbolicML/DynamicQuantities.jl#144

However, unless with LessUnitful there is a path to an implementation, see this PR over there:
SymbolicML/DynamicQuantities.jl#159

[abcdvvvv]

Thank you for such a detailed reply and for taking this issue seriously. However, as a user, I don't want to have too much trouble, so compared with DynamicQuantities.jl, I'll fall back to unitful.jl+lessunitful.jl for now.

[abcdvvvv]

Oh, wait, I have an idea. You could consider implementing this function in your package, it could solve the problem effectively!

unitfactor(a::Unitful.Temperature) = float(ustrip(upreferred(a-0unit(a))))

When a is u"°C" or u"°F", a-0unit(a) this subtraction automatically raises the dimension to Kelvin or Rankine!

[j-fu]

This is indeed what was happening in the background powered by Unitful. This helps to with u"2°C" but
not with 2u"°C" . And also with disabling handling of affine units via type dispatch.

An alternative to throwing errors is to document things and and over the responsibility to the user. But I think it is too easy to overlook this issue (as happened with me...) and it is safer to disable handling of °C and °F altogether.

[Deduction42]

As the author of SymbolicML/DynamicQuantities.jl#159, I can tell you that affine units are horrible and should not be used directly in mathematical expressions (instead they should be converted to non-affine units as soon as possible). The AffineDimensions in this pull request will interpret scalar multiplication of an affine unit intuitively:

2*ua"°C"
>> 2.0 °C  

but this is a baked-in behavior of the "Quantity" type. This package will not allow you to do mathematical operations on affine quantities with other units except for subtraction, which explicitly eliminates the offset. This is because it is unclear if "2.0 °C" really means "275.15 K" (an absolute value) or "2.0 K" (a difference).

The main reason this pull request exists is to be able to handle affine units without the Unitful.jl extension (which allows you to convert Unitful.jl units to DynamicQuantities).