Floating Point
-
Too bad the 16p16 is so slow and large, cool that 8p8 is better.
I suspect that either could be far faster if done in assembly, as floating point must be.@Yveaux - can you share the test program you used?
Let's not throw the baby out with the bathwater. There are two problem domains here.
-
Calculations using non-integer values as operands and results (plus/minus/divide/multiply/sqrt).
-
Representing non-integer values over a network, and converting between this representation and the textual display used by humans (and whatever format is used by sensors).
Fixed point can be great for the first domain, although in this case the C/C++ implementation has some tradeoffs in size and speed compared to the compiler supported floating point.
But fixed point math is not as well targeted at the second domain. For a sensor value like 29.7 degrees, fixed point has an inexact and sometimes cumbersome representation. To see what I mean, follow the whole chain of converting a DHT-22 value into fixed point for OTA transport, and then into a comma separated string representation for consumption by a home automation interface (and display to a user). The time and library size will be dominated not by basic arithmetic operations among fixed point values, but by the conversions into and out of that format. The DHT-22 value can be relatively efficiently converted to a 2 byte integer 297 and a one byte scaling factor 1; and those can be converted to the string "297" and then "29.7" without a large library.
This is NOT to disparage fixed point math where it works well.
-
