The problem with double is that any decimal value is just an approximation! Look into it!
When receiving information from sensors in OpenHAB, depending on the binding you will see strange values with undefined floating point precision, making double calculations useless.
So no, my statement is not misleading at all.
It’s how Java works!
Did you look at the compared results with/without double? They are indeed different but not significantly different. There are not many sensors reading to 0.0001% resolution.
People get the hump when an expected 25.0 is shown as 24.99999999999, but that is a matter of (poor) presentation, not accuracy.
On the practical side, there is any case no Log function available to OH Rules that works with BigDecimal, so far as I know.
As you have found, math::log(x) is the natural log e
Are you sure you want log10 in this equation? The usual presentation of Steinhart–Hart describes log e
You are right, in this case the difference is irrelevant, but when iterative calculations are done the error increases exponentially when using double for no defined precision floating point values , ie Colebrooke White equation (been there, done that )!
So as best practice, I would stick to BigDecimal for all such values. The BigDecimal class handles rounding in a very specific way, giving the option to the programmer to choose how and when to round.
People have been doing complex calculations for years using IEEE double floats, much more complex, and more importantly, much more ill-conditioned than the Colebrooke [sic] White equation. Check out LINPACK, for example, that goes back to the 1970s and FORTRAN 66, as I recall.
What you suggest is hardly “best practice” or, for that matter, common practice. Being able to control the rounding of BigDecimal is certainly interesting, but hardly required for most engineering/control applications. The computational cost of using a BigDecimal can be a burden for embedded systems, both in terms of available CPU cycles, as well as the associated power load.
The world has been running just fine on 4- and 8-bit microcontrollers for decades.
We definitely agree to disagree !
I do agree on one thing: history is what makes the present and possible future!
I will not start an argument on the cumbersome of double subtraction and many other limitations when dealing with undefined float points!
I agree that you can solve anything with the methods you specified, but with a custom approach to each and every process, not in a general and applicable way for any process!
The creators of the BigDecimal class are as you say: clueless! They have been wasting valuable resources for nothing!