On 6/6/2016 11:36 AM, Observer wrote:
It's more complicated than that. Part of what you need is to be able to declare a variable as (say) having two significant fractional digits, and have the rounding rules be implicitly applied when saving to that variable, producing an exact representation of the rounded result in storage. And part of the reason for that is that if you compare "3.499" to "3.501" (as the originally computed numbers) when only 2 sig figs should be in play, they must compare equal. This is very much unlike what happens with binary floating point, where exact comparisons are rarely possible due to low-order bit differences. In commercial decimal-arithmetic applications (think "money"), the low-order bits are supposed to be discarded for almost all values that actually represent an amount of currency. For reliability of the application, this has to be built into the data type, not dependent on programmer vigilance. That is, just like certain other language features, a decimal type without implicit truncation would be thought of as "doesn't scale well".
What I've done, though I know that I won't convince any users of BigDecimal, is use longs and have them represent pennies instead of dollars. Then they're all exact to two places.
