Hi! I recently created a library called simmer. It has two types: an unchecked Temperature type that holds a floating point value and adds useful temperature information and operations to other projects. It doesn't make any checks about the validity of the given data.
The other type is CheckedTemperature, which disallows the usage of temperatures below absolute zero, lets the user set bounds on the allowed range of values, and overall feels better when representing what needs to be a "real-world" temperature.
It's already available on Crates.io as I'm using it in one of my other projects, but you can find it on GitHub here:
There are only two files to view at the moment - both are in src/. If you review the library, I'd love to hear more about what "feels" right or wrong.
Also, I've been considering the fraction crate for a tertiary type, ExactTemperature, though I'm not quite sure how I'll fit it in.
Should I make a CheckedTemperature that can hold a heap-allocated Temperature -or- ExactTemperature where both implement some trait or would it be better to give them their own Checked types?
On the other hand, I could maybe just set another feature flag and hope that fraction works precisely like the floating point primitives.
Do you need to actually store the temperature in multiple possible units? The alternative would be to always store the temperature in, let's say, Kelvin. Then you convert from other units to Kelvin upon construction and from Kelvin back to other units when displaying or serializing the value. Here is a demo of the principle GitHub - mickvangelderen/units: Unit of measurement in Rust demonstration code.
Hey there - thanks for your consideration! I considered doing something like this, but I felt terrible for embedded devices having to do temperature conversion each time they report a value.
For example, simmer is used in my max6675-hal library, which talks to a device that always reports temperatures in Celsius. Very few operations are required to get a number in Celsius - it's practically just bit-shifting. On the other hand, converting to different temperatures requires 'real' conversions from Celsius, so I'm somewhat worried about storing anything in one value. It can moderately affect the usability of the library for my use case in particular.
That said, keeping the temperature in Kelvin would eliminate some conversion errors - helping to avoid checks and keep things speedy! I feel that for std applications, such an implementation is perfect!
I may be able to consider setting the 'base' unit as a feature flag, which would still enable conversion-less creation of Temperatures. Still, it may introduce complexity where there currently isn't any.
Anyway, I appreciate your input! I'll keep it in mind as I use the library in more embedded applications.
As an aside, Kelvin to Celcius requires an addition I believe which is different from a bit shift. On that note, doing a single addition to display a temperature in Celcius will probably be cheaper than having branches in your code elsewhere because the computer is tracking the unit at run time and needs to decide how to operate on the value. Of course, I don't know about the specifics of your application. I would have to profile the application and I've never even thought about how to do that for embedded.
