Handling temperature units

[jameysharp]

It looks to me like the units package doesn't currently support converting between units that have different zero-points, such as between degrees Kelvin, Celsius, and Fahrenheit. How could that work?

[goldfirere]

A great question. My first thought is that it could hook into some of the vector-spaces stuff, as that library differentiates between points and vectors nicely. (We don't want to shift the zero-point when converting between a change in Fahrenheit temperature and a change in Celsius temperature!)

I don't have too many cycles right now to devote to units, but I'd be very happy to see a description of this feature, or, even better, a pull request about it! The hardest part here is probably the design. If you (or anyone) does that, I could have a go at the implementation, which is likely easier.

[nushio3]

I have given thought for this. Particularly, this feature will allow me to set the air conditioner more easily when I am in U.S. territory.

I am disappointed to tell my current conclusion is that unit systems cannot handle the shifting of zero-points, since quantities can be raised to powers. Therefore, zero-point of a quantity hold a physical meaning. For the case of the temperature unit, see the Stefan–Boltzmann law:

j=σT^4

The T in the law is in the unit of Kelvin, where 0K corresponds to no energy distributed per degree of freedom. To obtain a finite j for T=0℃ is beyond the current system of quantity calculus.

I guess that a safe solution is to construct A (Qu l d n) or Qu l d (A n) where A is some Affine space, so that A can support the zero-point shift.

p.s. I haven't had many spare cycles for a long time, too, and I'm especially feeling sorry for Richard for being such!

[mrcjkb]

I"m a bit late to the party, but here are my thoughts:

What are the use cases for performing arithmetic with temperatures in °C or °F? Switching between °R and K (1 °R = 1.8 K) should be enough for switching between SI and U.S. systems. It is common practise to convert temperatures from °C to K, or from °F to °R before performing any computations with them.

Any law can be expressed in terms of deltas. For example, the Boltzmann law could be rewritten as

j = σ * (T0 + T)^4

where T0 is absolute zero. So this law is still true in °C, for T0 = -273.15 °C.

What if the Unit class had a baseUnitZeroPointOffset function that defaults to 0? I guess there would be more to consider than this, otherwise this issue wouldn't have the "Hard" label.

Another unit that might be tricky to support: Decibel, which has a logarithmic scale.

[goldfirere]

@MrcJkb That sounds plausible to me. Maybe there would be knock-on consequences? For example, what if there were a non-zero base point in an energy unit. Does that possibility mean that all laws involving energy would now have to take this into account? I would hope not.

As for next steps: units is very much in maintenance mode for me. I am happy to continue making sure it compiles with future GHCs and dependency upgrades, and I would review any full-fledged design. But I do not expect to return to completing creative design for this package. So, @MrcJkb or anyone else: please work out the details, and I will review! However, please do not expect me to do so. Time is always limited! :)

[mrcjkb]

@goldfirere that would certainly sound like a headache. But technically, there's nothing preventing me from defining a 'CookieMeter', unit for lengths, with its base-point being the length of my cat's tail. Maybe this would require a separate class of "impure" units...

I'll be glad to play around with this if I can find some time.

[goldfirere]

I only ask that they not be called "impure", as I've always thought an impure unit was something like the amount of money in some currency, where conversions are effectful (both in that they cost something and are a function of time). Though, really, euros and dollars should be different dimensions, not units, I think. But I digress....