I would love to have floating point decimal on embedded systems rather than a binary floating point unit. But the libraries are generally huge.
I use the equivalent of decimals WAY more on embedded hardware. User entry is always decimal. Percentages--decimal. Time specifications--milliseconds, microseconds, nanoseconds--decimal with precision.
I wind up writing integer fixed-point arithmetic versions of this crap, over and over and over.
Maybe since Moore's law broke and memory transistors are now way more expensive that processor transistors, we'll get decimal floating point as a feature soon.
I won't hold my breath, though.
We only store to hundredths ... oops ... new regulations require us to decimal round to thousandths. Cue full reload of the database with all your numbers in them.
Or, even better, try dealing with mm and mils in the same CAD database simultaneously. (conversion factor of 25.4--a clean number in decimal but very much not in binary)
In addition, you forget that simply adding decimals doesn't work in binary floating point. Adding 0.10 10 times doesn't equal 1.00 in binary floating point no matter how much precision you use.
http://www.vrworld.com/2015/03/24/the-evils-of-floating-poin...
http://sites.ieee.org/scv-cs/files/2013/03/Right-SizingPreci...
One interesting thing, John and I had an argument about the implementation, because there is one part about it that really sucks. Eventually he admitted that it had rankled him too and that the reason why he made this design choice was so that float64 could bitwise map smoothly onto unum{4,6} and float32 onto unum{4,5}... And that people would actually refuse to use unums if not for this direct bitwise mapping! So I capitulated.
Don’t leave us hanging! What is the part that really sucks?
And which part would that be? I'm mostly asking out of curiosity, so don't put yourself out if the answer is too long and involved.
As someone who has implemented a couple FPUs, I can assure you that there are quite a few pieces of IEEE 754 that suck to implement.