Hacker News Reader

Comment by nostrademons | Hacker News Reader

I remember hearing this back when I worked on financial software for hedge funds (2005ish), adjusting our product so it represented currencies as integer numbers of cents, taking the change to my boss (the company CEO), and then hearing "Use floats for money. All of our customers do, and if we don't you'll create needless friction for them."

Ran into it more recently when doing cryptocurrency market analytics. Bitcoin represents currency as integer numbers of satoshi, where 100M satoshi = 1 BTC. Ethereum represents it as integer numbers of wei, where 10^18 wei = 1 ETH. I thought I'd be smart and use these fundamental units internally, only to find out that basically every exchange quotes prices in floats. By the time you get the data, it's already lost whatever precision it had, and you're just introducing needless friction by trying to get smart.

Sometimes being compatible is more important than being correct.

View on HN

> and then hearing "Use floats for money. All of our customers do, and if we don't you'll create needless friction for them."

Until a competent customer doesn't, then you've got to explain to them why your calculations are intentionally wrong, never a good look. Regulatory bodies also tends to want the correct decimal numbers.

If 99% of your customers do things the wrong way and 1% wants to do it the "correct" way that you don't support, there's an easy business call: you do it the way the 99% want and tell the 1% "Sorry, we don't support that. Hopefully you'll find a provider who does." Massive portions of the economy are built upon that principle, from IE6 to UNIX to C to VHS to QWERTY to 120V electricity to U.S. custom measurements to MM/DD/YYYY date formats to the use of decimal (as opposed to binary) subdivisions in the first place.

Context matters too: both of these examples are financial modeling as opposed to transactions, where (as riskneutral's sibling comment points out) floating point error is swamped by the errors in your models in the first place, and some concepts can't be modeled at all with integers. Also regulators explicitly don't care about this area: if your models give incorrect results and you trade on them that's your problem.

> Sometimes being compatible is more important than being correct.

It's a simple conversion for the sake of precision. If you are dealing with money transactions, you should strive for precise values wherever and whenever possible.

If your customers are already using floats, precision has already been lost. They're sending you data that already has floating-point round-off. If you then treat that as integer numbers of cents, you're adding additional round-off error by converting their 23 bits of binary precision to 2 digits of decimal precision. It's better to use the same format they do so that all floating-point error occurs within their systems, where it's known, has presumably been judged to be low-risk, and can be compensated for, rather than silently and unpredictably add new sources of error that your customers don't know about.

There is no source of errors in doing: bigint_value = float_value * 10^E if E else float_value float_value = bigint_value / 10^E if E else bigint_value

Obviously only convert to real numbers if you are doing operations on numbers in your system, otherwise keep in client format like you said.

Reply on news.ycombinator.com