Conversion of channels to different systems of measurements

Question

How do convert from one system to another and not create false precision (http://wikipedia.org/wiki/False_precision) of the data? For example, if we look at the Yahoo Weather API (http://developer.yahoo.com/weather/documentation.html) which is used for the Yahoo Weather Binding (http://github.com/eclipse/smarthome/tree/master/extensions/binding/org.eclipse.smarthome.binding.yahooweather) reports values in US or Metric units.
For example, if you query the Yahoo weather api for Las Angeles, CA in US units (http://weather.yahooapis.com/forecastrss?w=2442047), It returned:
Temperature: 71 F
Pressure: 29.94 in
And, if you query the Yahoo weather api for Las Angeles, CA in Metric units (http://weather.yahooapis.com/forecastrss?w=2442047&u=c), it returned:
Temperature: 22 C
Pressure: 1013.6 millibar
The Smart Home Yahoo weather binding is making queries using metric units. So we'll use that as the base for conversions. To convert from C to F the formula is: C x 9/5 + 32 = F. which in the above example is:
22 x 9/5 + 32 = F
71.6 = F
And to convert from F back C the formula is (F - 32) x 5/9 = C
(71.6 - 32) x 5/9 = C
22 = C
But if we didn't keep the .6 around (like Yahoo does), we'd have the following:
(71 - 32) x 5/9 = C
21.66666666666... = C
In this case, we'd want to scale the number to something reasonable to not give the indication of false precision to downstream consumers of the channel. At some point you need to decide how many digits are significant in the result and round appropriately. The scientific community solves this problem using the Significant Figures rules (http://wikipedia.org/wiki/Significant_figures), and the arithmetic section (http://wikipedia.org/wiki/Significant_figures#Arithmetic) applies to what should be done. It has the following:
Quote:
A common guide often used when performing calculations by hand is as follows.
For multiplication and division, the result should have as many significant figures as the measured number with the smallest number of significant figures.
For addition and subtraction, the result should have as many decimal places as the measured number with the smallest number of decimal places (for example, 100.0 + 1.111 = 101.1).
In a base 10 logarithm of a normalized number, the result should be rounded to the number of significant figures in the normalized number. For example, log10(3.000×104) = log10(104) + log10(3.000) ≈ 4 + 0.47712125472, should be rounded to 4.4771.
When taking antilogarithms, the resulting number should have as many significant figures as the mantissa in the logarithm.
When performing a calculation, do not follow these guidelines for intermediate results; keep as many digits as is practical (at least 1 more than implied by the precision of the final result) until the end of calculation to avoid cumulative rounding errors.
Since the value is consumed downstream, this implies that we should keep around 1 digit of precision since the original number (71) had 0 digit of precision. This would give the scaled value of 21.7C. Now if we were to convert back from C to F:
21.7 x 9/5 + 32 = F
71.06 = F
And since this is no longer a intermediate value, and since this is not an intermediate value, the resulting value would be 71F, which matches the starting value of 71F.
BTW, the first example also followed the significant figures, but the math didn't need to be scaled due to the order of the calculation.
To take this one step further, the calculation from mbar to inHg is mbar x 0.02952998751 = inHg:
1013.6 x 0.02952998751
29.9315953401 = inHg
And scaled the value is 29.93, but in this case the multiplier is so small, you'd probably want to keep 2 digits of precision (29.932). The calculation from inHg to mbar is inHg x 33.8638815 = mbar:
29.93 x 33.8638815 = mbar
1013.54597329 = mbar
1013.54 mbar (scaled)
29.932 x 33.8638815 = mbar
1013.61370106 = mbar
1013.614 mbar (scaled)
Adding a second digit of precision in this case produce a result that was closer to the starting value, If this approach is used, there will need to be some sort of thought put into how much additional precision is needed for each calculation. In some cases one digit will be enough, but other cases might require more. This would be dependent on the multiplier or other variables used in the calculation.

Answer 1

Yahoo!'s weather API is obviously rounding off more precision than their underlying weather stations can provide, probably because it's easier to read fewer digits (i.e., the output is already formatted for display), and perhaps they assume the consumers of the data are not attempting to perform further calculations across sets of data that depend on all available accuracy. I'm sure the weather stations' sensors are reporting more precisely than whole Celsius degrees, for example, but the Yahoo! Weather API isn't providing it. I can imagine the Yahoo! Weather API reports current values for the purpose of easily reading current conditions.
If, on the other hand, you were the operator of your own weather station and wanted to perform calculations across sets of historical measurements from your sensors, you would most likely want to store exactly as much precision as the equipment provided. The unit system used to present the data would only be relevant at the time the data was presented for display, and would not be a justification to erode the accuracy of the reported values by rounding during unit conversion. In other words, rounding is a good way to present final values so they are easy to read, but is a bad idea if you are going to store values that may be used in further calculations where you want to preserve as much accuracy as was available when the samples were first collected.
openHAB lets users format decimal values so they are easy to read using format strings like %.1f, so there can be no confusion about false precision.
...adding:
I know there has been work in OH2 to handle the unit systems used for item states, so ideally binding authors could be freed from having to convert unit systems, and unit conversions could potentially be performed in the presentation layer without bindings having to worry about it. So whatever units were reported to the binding could be passed along without conversion.