> I consider running from “amounts as integer” systems these days (but usually unfortunately can’t).
In the context of Fintech, how do you otherwise resolve floating point rounding issues if not representing amounts with integers?
> I consider running from “amounts as integer” systems these days (but usually unfortunately can’t).
In the context of Fintech, how do you otherwise resolve floating point rounding issues if not representing amounts with integers?
Native decimal types, if your system has them. Many languages and databases used in financial contexts do.
But native decimal libraries are almost always floating point.
Do people not know what a floating point number is?
That’s alright, the important part here is that they’re decimal, not binary. You don’t want 0.1 + 0.2 to equal 0.300…004.
There are pretty trivial ways to use binary floating point values that don't result in 0.1 + 0.2 producing 0.30000...4 and it saddens me when this topic comes up and people go to such extreme lengths to recreate a second hand buggy reimplementation of a subset of floating point numbers to do it.
An integer for the value (scaled by number of decimals) and an integer value for the number of decimals. Different systems may use different values, even for the same currency or asset.
What exactly do you think a floating point number is?