Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

64-bit bank balances ‘ought to be enough for anybody’?

tigerbeetle.com

Post reply on HN
Print view View original

251–260 of 372 posts

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#251

Post by marcosdumay »

eternityforest wrote: post #239
hef19898 wrote: post #175

Earlier quoted context omitted.

From experience, those differences surface during stock taking. Amd most companies are really bad at that. And if they surfacey they are corrected by inventors adjustments (in unit of measure, not value, which is a differwnt can of worms). As long as those adjustments aren't to extreme, nobody really cares. A good accountant so will sooner or later investigate those rounding errors, as they will show up somewhere ult…

So accountants are like number detectives doing what's essentially debugging work just like a coder would?

They design the system, detect the failures, explain and correct them. So, their work even is more like programing than your comment implies.

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#252

Post by perihelions »

vidarh wrote: post #236
jjgreen wrote: post #220

Earlier quoted context omitted.

Do it a million trillion times and we're talking cents overdrafted (almost)

If you just add up the errors, sure. What is riskier is that you risk tipping values the wrong direction right before applying a rounding step, or end up with an error right before multiplying a now wrong per-unit value with some large-ish factor. Often these things are not a big problem on their own, but then later gets compounded because someone does something stupid like passing these imprecise values around to be…

- "or end up with an error right before multiplying a now wrong per-unit value with some large-ish factor."

Where in financial accounting do people multiply an amount of money by a multiplicand larger than order-of-unity?

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#253

Post by fer »

yyyk wrote: post #38
throw0101c wrote: post #5

I was under the impression that BCD was generally recommended for money, often because of (IEEE?) rounding and machine precision/epsilon: * https://en.wikipedia.org/wiki/Binary-coded_decimal * https://en.wikipedia.org/wiki/Machine_epsilon

Every financial system I've seen uses either decimal floating point or integers. Using normal float is just asking for trouble.

I've seen floats for money in production, not a financial system per se, but it moved amounts around external systems that often would include some financial ones. It worked surprisingly well given the amounts involved (anywhere from tens to thousands of EUR/USD), and when I asked about the off by +-0.01 errors every now I was told they were "not worth fighting by the customers".

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#254

Post by vidarh »

perihelions wrote: post #252
vidarh wrote: post #236

Earlier quoted context omitted.

If you just add up the errors, sure. What is riskier is that you risk tipping values the wrong direction right before applying a rounding step, or end up with an error right before multiplying a now wrong per-unit value with some large-ish factor. Often these things are not a big problem on their own, but then later gets compounded because someone does something stupid like passing these imprecise values around to be…

- "or end up with an error right before multiplying a now wrong per-unit value with some large-ish factor." Where in financial accounting do people multiply an amount of money by a multiplicand larger than order-of-unity?

In accounting, no, while preparing input to the accounting in the form of generating invoices, I've lost count (sorry) of the number of times I've seen people doing tax calculations etc. on unit prices and then multiplying by number of units ordered, and then further compounding potential issues by adding up these numbers from multiple invoice lines. None of which is usually the right thing to do, all of which you often "get away with" without causing sufficient discrepancies, and so which people often fail to catch in testing. Until you suddenly don't.

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#255

Post by perihelions »

vidarh wrote: post #254
perihelions wrote: post #252

Earlier quoted context omitted.

- "or end up with an error right before multiplying a now wrong per-unit value with some large-ish factor." Where in financial accounting do people multiply an amount of money by a multiplicand larger than order-of-unity?

In accounting , no, while preparing input to the accounting in the form of generating invoices, I've lost count (sorry) of the number of times I've seen people doing tax calculations etc. on unit prices and then multiplying by number of units ordered, and then further compounding potential issues by adding up these numbers from multiple invoice lines. None of which is usually the right thing to do, all of which you o…

- "multiplying by number of units ordered,"

Yeah, that's one example. I wasn't imaginative enough; thanks!

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#256

Post by vidarh »

pixl97 wrote: post #247
vidarh wrote: post #222

Earlier quoted context omitted.

For it to be written off as error you need to know the discrepancy, which means you need to know what it's supposed to be. When e.g. calculating the VAT or sales tax you owe the government, if the rounding deviates from legal requirements then unless it's in their favour you can be in for a bad time.

I think for most large businesses there are pretty considerable error bars here. If you say you owe 1,000,000 a year in VAT and the government says you owe 1,010,000 it's cheaper to pay the difference then dig into why it's off.

If you report 1,000,000 and certify that it's the right number, and the government audits you and find you should have paid 1,010,000, then depending on jurisdiction you might be entirely ok, or you might find you're not going to be paying just the difference, and interest, but also a fine, and bearing the cost of additional audits going forward, and that your finance director will not appreciate having to address questions aimed at figuring out whether anything criminal is involved. Repeat the mistake a few times, and the level of scrutiny will escalate.

There's a reason that in 28 years of working in software, the only thing the financial teams I've worked with have obsessed over have been whether or not we get the VAT calculations right, and the "sticker price" of the discrepancy has never been what they worry about. For calculations that does not involve getting tax amounts wrong, they often couldn't care less about much bigger discrepancies, but get tax wrong in the wrong jurisdiction and it's a lot of pain.

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#257

Post by deciplex »

vidarh wrote: post #184
lxgr wrote: post #145

Earlier quoted context omitted.

The article is about data types for storage, not for intermediary values used as part of calculations, though. Are you proposing that everybody is storing monetary values "wrong", too? And as a meta-point: > I have been fighting over this with countless people, teams and companies. [...] I have never in my life joined a software project for any organisation that was able to do basic arithmetic on money correctly [...…

A shocking number of people (edit: who implement billing related software) are unaware of how many decimal points of accuracy their local tax code requires to calculate vat or sales tax correctly. And those things are often specified in terms of arithmetic correctness. I had our CFO stand behind me while I talked him through every step of our VAT calculations once, because he was legally responsible if I made us roun…

> done something grossly incompetent like used floats for those calculations

So, in another life I worked on reporting software for a foreign branch of a US bank. You've heard of the bank. You would probably recognize the CEO's name, in fact.

We had been fucking this up for years. I fixed it. We had some customers who yelled at us because our reports were "wrong" i.e. they were double checking our work and apparently making the same mistake. They could not be reasoned with. Bear in mind, we're talking about differences of pennies, or a few dollars on very large transactions. Some of our customers insisted we were calculating the values incorrectly and demanded we "fix" it.

What do you think happened next? You have one guess.

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#258

Post by walnutclosefarm »

I'd like a report back from TigerBeetle on how many applications they actually support where the high order 64 bits are nonzero. I would note that the entire US GDP is less than 10^15 cents, and that 2^64 accommodates just shy of 10^19 in signed integers. So, even if your database had a justification for thousands of a cent transactions (not intermediate results, but recordable transactions), you'd still need to have transaction entries larger than the US annual GDP to roll over into the high order 64 bits.

TigerBeetle may have made the right choice for some market, but I predict that there are vanishingly few sales calls where this becomes an important selling point, unless it's potential customers wondering why they are wasting all those bits and checks for a whole lot of freakin' zeros.

Re: 64-bit bank balances ‘ought to be enough for anybody’?

#259

Post by manicennui »

lxgr wrote: post #145
onetimeuse92304 wrote: post #24

Specialising in financial software, over the past 2 decades I have been fighting over this with countless people, teams and companies. For accounting you should only ever use arbitrary precision math library with ability to specify rounding rules. If your programming environment/language does not have one, it is unsuitable to be used for accounting, billing, invoicing, payments, etc. Having the underlying library is,…

The article is about data types for storage, not for intermediary values used as part of calculations, though. Are you proposing that everybody is storing monetary values "wrong", too? And as a meta-point: > I have been fighting over this with countless people, teams and companies. [...] I have never in my life joined a software project for any organisation that was able to do basic arithmetic on money correctly [...…

I agree with the parent. Almost everyone thinks floats are fine. I work in lending, and many of my coworkers, who claim to have CS degrees, do not understand floats at all.
Post reply on HN