Strange. Google doesn't know anything about "range accuracy". And I have no idea how streaming SIMD Extensions (SSE) is supposed to magically cure the precision problems inherent in binary floating-point. SSE is a performance feature. And only on certain hardware. A fundamental precept of Java is "Write Once, Run Anywhere
", which negates hardware-specific solutions.
Floating-point numbers have Machine epsilon
. That is the indicator of how precise a value can be for the machine quantity in question. At the epsilon level, you have an upper and lower bound to the possible actual value, but the true actual value is pure fuzz.
Computers cannot work with mathematical abstractions, only machine quantities. So live with it. There's a whole mathematical discipline of error analysis and it's fundamental to engineering and has been since slide rules and analog measuring instruments. Engineering specs are not considered complete without tolerances. And in many cases, those tolerances are far less than the epsilon uncertainty of common floating point implementations.
Computer output routines can and often do allow for the fuzziness of the data they are dealing with. That's what gives us a printed output of "6.1" when the actual bit-for-bit value of a float is more like 6.0000000000009976 or 6.0000000000010032.
But in the Real World everything has its limits and only a fool expects precision where there is none. Only in pure mathematics can you be 100% precise. And then only until you apply the mathematics to something tangible. You can complain that floating-point pennies don't balance a checkbook, but the minute you go from bookkeeping to accounting even pennies get fuzzy as interest-rate functions, currency conversions and the like chew on them. On the bookkeeping side, you have 2 choices: use BigDecimal (or something equivalent such as a hand-rolled Currency class) or scale floating-point up 2 orders of magnitude so that integral numbers of pennies actually register as integral values. People have done both.
Yes, I'd like to be able to use a currency class that allowed mathematical operators, but so far no one has persuaded the architects of Java to permit operator overloading, and mathematical operators in Java apply only to primitives, not classes.
If your real gripe is that you cannot add and subtract money, consider COBOL. It has no such problems. It was designed for it. But here also, consider that not every country on Earth has only 2 decimal places to their units of specie.