I decided years ago that the next time I hear someone suggesting we use floats / doubles to represent money amounts, I am going to punch them in the face.
This gets repeated a lot, and I don't disagree. But I find odd that doubles would be so unsuitable for monetary (and other similar) arithmetic; in principle you have 15 significant digits which should be more than enough, and precise control how the results are rounded. And all the basic arithmetic should return correctly rounded values to the last ULP. So it is weird that those tools are still not good enough and it is also difficult (at least for me) to fully characterize why exactly they are not suitable.
Part of me wonders if this (justified!) fear of floats is in part because a history of bad implementations (looking at x87) and difficulties in controlling floating-point env (looking at libs randomly poking fpenv), and less due floats intrinsically being bad.
The problems of floats are not the number of significant digits, it’s the imprecision of the representation (floats don’t just cut off at the end), that these imprecisions compound, and that float operations are not commutative. At the end of the day, 0.1 + 0.2 != 0.3 is a fact you have to live with.
X87 does not really factor into it, if anything in your view of the world x87 floats would be better since x86-EP is 80 bits. Except its involvement now leads to intermediate-precision-driven inconsistencies.
Control (which you mention) and consistency are the issues, as well as the interaction between that and comparators.
Guarding against floating-point issues or considering precision errors is neither part of school-learned arithmetics, nor of most CS programs, to almost every developer just flings around floats like they’re genuine reals, and when problems start surfacing floats are so threaded through without consideration it becomes very hard to untangle, which leads to local patch jobs which make the problem worse.
You can get a bunch of bits, but how you handle it make a ton of differences
Plus, so little languages care about us living in the business world. You can count with fingers in a single hand the languages that are meant for business app.
All the others are bad languages (and libraries, frameworks, data stores), ill-suited for the job. And so, all of them need to reimplement (badly, ad-hoc, bug-ridden) version of money and friends.
And weirdly, no hardware support at all, so our friends on C say: "Look, no important to handle money, bye" and nobody else does it either.
If you’d ever had to bill millions of customers for precise amounts of electricity and gas at precise prices… you would hate floats and you’d hate that any idiot will act as though excel is gospel truth.
I heard that countless times, and I understand the reason (mainly: floats are binary, money amounts are decimal), but then, how do you split a $10 bill between 3 people.
$3.33 for each is not good, because in the end you have to pay $10, not $9.99. You can use a double, which is more precise, but in a less predictable way. You can use factions, which is exact, but it may become unmanageable after some time. Or you can have one of the three pay $3.34, but which one? I guess there are rules for that, probably a lot more complicated than "use an integer number of cents".
If you have a few grown-up adult parties, e.g. cofounders, partners, then split like [(n-1) x round(total/n), whats_left]. The last one is how sql select sees it.
If you have potentially penny-hysterical kinds (taxes, anonymous group customers), round in their favor and throw pennies into your own expenses.
If n ~~ total, e.g. $100.00 over 700 people, don’t do that, it’s bad accounting.
I worked with finance and accounting half my life. They just don’t fall into these philosophical dilemmas.
We use long double to present financial money amounts with a little safety on top of it before it’s consumed by whatever JavaScript (Typescript really) frontend it heads to. Works fine. Outside of the need for speed it’s one of the few areas we use c in our backend services.
We don’t store the data in floats or anything resembling it, however.
Please stop repeating this nonsense. It's purely based on ignorance and only pushes more people into it.
This is universally repeated by people that have not written any modern financial software and who don't understand floats.
If all you do is add US dollars and pennies, then maybe you can get by with integers. Once you do anything else in modern finance integers puke completely. There's a reason scientific computing doesn't use integers, but prefers floats/double - they are much easier to use to get the best answers per compute.
For example, if you need to do anything with interest, which is fundamental, you'll soon find doubles are vastly better than bitsize equivalent integers, no matter what scaling/fixed-point/other tricks you employ. Add in currency differences (Yen to USD is a large multiplier, etc), any longer range calculations (50-100 year loans or flows), aggregation of varying items, derivatives, and on and on. Telling anyone in the field you're going to use integers will get you laughed at - the problem is not floats, the problem is the programmer hasn't taken a single class on numerical analysis and has not enough skill to do financial software.
For example, one of the simplest things one needs to do is compute compound interest, say computing mortgage tables, with say principal P (left), annual (or weekly, or daily..) rate R, for N years, periodic payment m, and you want to compute payments and schedule.
In reals, this is simple: each cycle you do something like
r = (1+R/12)
P -= m
P = (1+r)*P
Then you write out values you need.
Trying to write this software with integers, no matter what scaling, fixed-point, shifting, and other tricks you employ, is going to be vastly more complex and error prone than simply using doubles. If you don't think so, pick a bit budget, say 32, or 64, for you base number type, and show me your code. Then I'll show you the naive one with doubles vastly outperforms your code.
This continues through all of modern finance.
So stop repeating this ignorance that one should use integers for money - that is purely a result of being ignorant about how to write robust numerical code, and only pushes people down a far worse rabbit hole when they hit issues with ints and try to patch them one at a time via ad-hoc hacks.
There's a reason scientists use floating point, not ints, to do real numerical work.
Assuming you want your money to actually add up correctly, then floats are always the wrong choice.
If you’re not interested in accurate accounting, the. Sure floats are fine, but when you’re working with money, accurate accounting tends to be the expectation.
zokier|2 years ago
Part of me wonders if this (justified!) fear of floats is in part because a history of bad implementations (looking at x87) and difficulties in controlling floating-point env (looking at libs randomly poking fpenv), and less due floats intrinsically being bad.
masklinn|2 years ago
X87 does not really factor into it, if anything in your view of the world x87 floats would be better since x86-EP is 80 bits. Except its involvement now leads to intermediate-precision-driven inconsistencies.
Control (which you mention) and consistency are the issues, as well as the interaction between that and comparators.
Guarding against floating-point issues or considering precision errors is neither part of school-learned arithmetics, nor of most CS programs, to almost every developer just flings around floats like they’re genuine reals, and when problems start surfacing floats are so threaded through without consideration it becomes very hard to untangle, which leads to local patch jobs which make the problem worse.
mamcx|2 years ago
You can get a bunch of bits, but how you handle it make a ton of differences
Plus, so little languages care about us living in the business world. You can count with fingers in a single hand the languages that are meant for business app.
All the others are bad languages (and libraries, frameworks, data stores), ill-suited for the job. And so, all of them need to reimplement (badly, ad-hoc, bug-ridden) version of money and friends.
And weirdly, no hardware support at all, so our friends on C say: "Look, no important to handle money, bye" and nobody else does it either.
bazoom42|2 years ago
Some values like 0.3 simply cannot be represented precisely with floats.
smallnamespace|2 years ago
For a less exotic example, consider that Excel, widely used by actual accountants, uses floats throughout to represent numbers.
Affric|2 years ago
If you’d ever had to bill millions of customers for precise amounts of electricity and gas at precise prices… you would hate floats and you’d hate that any idiot will act as though excel is gospel truth.
mglz|2 years ago
How so? Can't you just use long integers with cents or 1/1000th of a cent?
GuB-42|2 years ago
$3.33 for each is not good, because in the end you have to pay $10, not $9.99. You can use a double, which is more precise, but in a less predictable way. You can use factions, which is exact, but it may become unmanageable after some time. Or you can have one of the three pay $3.34, but which one? I guess there are rules for that, probably a lot more complicated than "use an integer number of cents".
wruza|2 years ago
If you have a few grown-up adult parties, e.g. cofounders, partners, then split like [(n-1) x round(total/n), whats_left]. The last one is how sql select sees it.
If you have potentially penny-hysterical kinds (taxes, anonymous group customers), round in their favor and throw pennies into your own expenses.
If n ~~ total, e.g. $100.00 over 700 people, don’t do that, it’s bad accounting.
I worked with finance and accounting half my life. They just don’t fall into these philosophical dilemmas.
devjab|2 years ago
We don’t store the data in floats or anything resembling it, however.
greyw|2 years ago
lionkor|2 years ago
aleph_minus_one|2 years ago
SideQuark|2 years ago
This is universally repeated by people that have not written any modern financial software and who don't understand floats.
If all you do is add US dollars and pennies, then maybe you can get by with integers. Once you do anything else in modern finance integers puke completely. There's a reason scientific computing doesn't use integers, but prefers floats/double - they are much easier to use to get the best answers per compute.
For example, if you need to do anything with interest, which is fundamental, you'll soon find doubles are vastly better than bitsize equivalent integers, no matter what scaling/fixed-point/other tricks you employ. Add in currency differences (Yen to USD is a large multiplier, etc), any longer range calculations (50-100 year loans or flows), aggregation of varying items, derivatives, and on and on. Telling anyone in the field you're going to use integers will get you laughed at - the problem is not floats, the problem is the programmer hasn't taken a single class on numerical analysis and has not enough skill to do financial software.
For example, one of the simplest things one needs to do is compute compound interest, say computing mortgage tables, with say principal P (left), annual (or weekly, or daily..) rate R, for N years, periodic payment m, and you want to compute payments and schedule.
In reals, this is simple: each cycle you do something like
Then you write out values you need.Trying to write this software with integers, no matter what scaling, fixed-point, shifting, and other tricks you employ, is going to be vastly more complex and error prone than simply using doubles. If you don't think so, pick a bit budget, say 32, or 64, for you base number type, and show me your code. Then I'll show you the naive one with doubles vastly outperforms your code.
This continues through all of modern finance.
So stop repeating this ignorance that one should use integers for money - that is purely a result of being ignorant about how to write robust numerical code, and only pushes people down a far worse rabbit hole when they hit issues with ints and try to patch them one at a time via ad-hoc hacks.
There's a reason scientists use floating point, not ints, to do real numerical work.
doubloon|2 years ago
saagarjha|2 years ago
avianlyric|2 years ago
If you’re not interested in accurate accounting, the. Sure floats are fine, but when you’re working with money, accurate accounting tends to be the expectation.